This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.The next post in the series is
here.
This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
The issue can be found here.
The original specification requires the job to be defined through an XML file included as part of the application package. The specific XML syntax is called Job Specification Language, or JSL. The Liberty implementation allows you to provide the JSL as part of the payload on a REST API to start a job, but it is still JSL and has to exist somewhere. The idea behind this proposal is to be able to define the job on the fly, from some sort of API.
Of course, one option would be to just let you use one of the various APIs (JAX-P, etc etc) that allow you to programmatically build an XML document. The Job Operator API could be updated to allow you to pass in one of those document types as a different signature of the start method. Instead of specifying the name of the JSL file, you would just provide the JSL directly as an object.
Handy, but still basically just JSL. We could take this a step further and provide an API (or perhaps a set of APIs) that allow you to define the job more directly, without going through XML definition. Of course, it would be fairly similar to creating an XML document. Presumably you’d call some API to create a job, then another to create a step within the job (like creating an element within an XML document). But you’d have actual step objects to manipulate.
I’m honestly not sure that having specific APIs like this really gets you very much if you’re essentially just building XML anyway. But, if we know the job is going to run right here in the same JVM that is defining the job, well then we could add all sorts of things that just can’t be done in XML. Instead of having a property for some batch artifact value that’s a string in XML, you could have the value be an entire object. All sorts of possibilities open up if you don’t have to flatten everything into text.
But, of course, this then precludes the ability to run the job in a different JVM. Although I suppose you could require that any objects you used for this sort of thing be serializable. You wouldn’t typically try to type out a serialized object into XML yourself, but a generated document (or a ‘job’ object) could be easily defined to accept one.
I’m sure there’s lots of other clever possibilities here that I’m overlooking. The whole idea seems really interesting to me, but I think it also opens up a lot of possibilities for confusion and complexity, so we’d have to be careful not to define an entirely new specification with all different capabilities.. if that’s what we want, perhaps a totally separate specification is called for, instead of complicating this one. Maybe.
Thoughts?