WebSphere Application Server

JSR-352 (Java Batch) Post #75: Introducing Batch Server Topology Considerations

By David Follis posted 18 days ago

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 iTunesGoogle PlayStitcher, or use the link to the RSS feed

This post will kick off a series discussing various topology considerations when running Java Batch applications in Liberty.  At first glance you might wonder what kind of topology you can even have.  All our discussions so far have involved using JobOperator or the REST interface to submit a job to a Liberty server that runs the job.  There’s not a lot of topology involved.

But that server keeps track of things in a Job Repository that is really just a set of tables in a database.  Could multiple servers share those tables?  What consequences would that have?

To make things more interesting, the WebSphere Liberty implementation supports a multi-server configuration with some servers acting as ‘dispatchers’ and others acting as ‘executors’ which actually run the jobs.  The work is passed from a dispatcher to executor via a messaging queue.  This capability introduces quite a few interesting topology possibilities.

And, of course, you could have several different Job Repositories and several sets of servers acting as dispatchers and executors and multiple different queues.  You could create quite a mess. 

Adding one more twist to this is the batch events topic root.  Remember that a server can be configured to publish ‘event’ messages to a topic tree.  The root for that topic tree (and for that matter, the messaging system containing the tree) is configured as part of the server configuration.  You could have multiple topic tree roots being used by different servers if you wanted to separate them.  Would you?  Would that separation line up with sets of dispatchers and executors or users of particular Job Repositories?  Again, a great opportunity to make a big confusing mess of things.

We’ll get into all this in more detail, but, as a quick rule, remember that job identifiers (instance and execution IDs) are unique with a Job Repository.  Those identifiers show up in messages between dispatchers and executors and in event messages published to the topic tree.  That suggests some alignment between users of a particular set of Job Repository tables and users of these other artifacts.  You don’t want a server using one repository to get a message from a server using a different repository because the identifiers are referring to different actual jobs. 

That should be enough to get you worried.  Over the next few weeks we’ll try to sift through how all this works..