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.
A while back we talked about a command line interface (CLI for short) called
batchManager. This is just a little Java program that uses the Liberty Batch REST interface to submit jobs and perform other batch-related operations. On z/OS there is a second CLI called, conveniently,
batchManagerZos. Why have two?
There’s nothing wrong with the Java CLI (batchManager). But given a z/OS environment there are a few things that could be made easier or simpler. First of all, since
batchManager is written in Java, you have to start up a JVM to run it. In a z/OS environment a Java Batch job is likely being run from inside some JCL. One step of that JCL job will be used to submit the Java Batch job (more on this topic next time). Well, if you’re going to have to start a JVM in order to submit the job, why not just start the JVM and run the batch work right there? That makes the first difference between
batchManagerZos the fact that the z/OS specific CLI is written in ‘C’ and thus doesn’t require a JVM.
It is also often the case that the JCL job submitting the Java Batch job is running on the same z/OS system as the Java Batch job will run on (or at least where a Liberty Batch Dispatcher is located). That means going through a TCP/IP connection to drive a REST interface is a bit heavy. WebSphere Liberty supports the WOLA (WebSphere Optimized Local Adapters) interface which allows direct cross-memory communication between the client and server. The
batchManagerZos CLI uses WOLA to communicate with the target Liberty server.
Using WOLA means the communication doesn’t flow over TCP/IP which means it doesn’t need to be encrypted which allows you to avoid the configuration required for SSL. That simplifies the setup. The WOLA protocol also just ‘picks up’ the identity of the client and propagates it to the server (lifting it from the associated ACEE). That means the client doesn’t have to supply a userid/password as part of establishing the connection.
Of course, SOME security set up is required to enable WOLA and allow the client to access the server using WOLA services.
And, since the ‘L’ in WOLA stands for ‘Local’,
Next time we’ll look at integrating
batchManagerZos can only communicate with servers on the same z/OS system. It can’t reach across the sysplex to a server on a different z/OS system.
batchManagerZos calls into a JCL job.