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.
We haven’t talked about how a batch application is packaged. You can package them as web applications (.war files) or as enterprise applications (.ear files) and deploy them into a server just like any other web or enterprise application.
The archive file contains all the Java .class files needed for the batch application (ok, it can be more complicated, but we’ll go with that for our purposes here). But the specification also says that the JSL is contained inside the same archive file in a folder called batch-jobs under the META-INF folder.
Well that’s pretty nifty. The JSL that defines what the flow through the various bits of Java code that make up the batch job will be lives inside the very same archive file that contains all that application code. For DevOps stuff where you’re trying to manage keeping all the bits of an application together, moving it from dev to test to prod, having it all in one archive makes that pretty easy.
But if you’re from a z/OS background you might be used to thinking of JCL, application source code, and application binaries as very separate things. Maybe you library the source code somewhere and have a separate process for managing the binaries and the JCL. Keeping this all together just isn’t how you do things. That’s ok..
One of the features of the Liberty Batch REST interface is the ability to provide the JSL along with the request to start the job. In a later post we’ll get to how you’d integrate submitting Liberty Batch jobs in an Enterprise Batch environment, but for now just know that this makes it possible to have the JSL as instream data inside JCL.
Essentially your Enterprise Scheduler will run JCL, just like it does today, and that JCL executes something (we’ll get there pretty soon) that drives the REST interface to submit the Java Batch job and the JSL is right there in a “DD *” entry in your JCL (or off in some dataset a JCL DD card points to).
But this applies to uses in non-z/OS environments too. Anyplace that you are using the REST interface to submit a job you can choose to have whatever client is driving the interface managing the JSL and supply it as part of the job-start request..
This capability is all part of the WebSphere Liberty implementation of JSR-352.