WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #78: The Multi-Server Batch Configuration – Executors

By David Follis posted Wed February 19, 2020 07:41 AM

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

Last time we talked about configuring a WebSphere Liberty server to act as a batch dispatcher.  The results of a job being submitted via the REST interface to the dispatcher are entries in the Job Repository about the job and a message in a queue that represents the job.

This time we’ll look at what happens to that message to get the job running.  To get things moving we need another server that includes the batchJmsExecutor configuration element.  This element includes attributes that point to the configuration for an activation specification and a queue.  This configuration tells the batch executor code how to find the queue where the dispatcher is placing messages.

When a message turns up, an executor will pick up the message and process it.  This is very similar to how Message Driven Beans (MDBs) are processed, although with some special ‘batch’ code doing the message handling. 

The batch code will look at the message contents (which includes the job identifier) and find the information in the Job Repository for this job that was placed there by the dispatcher.  This is why the dispatchers and executors using the same queue need to be sharing the same Job Repository.

Once it knows what to do, the batch code will launch the job.  The job will run (hopefully to a successful completion) and make updates in the Job Repository as it progresses.  These updates enable REST clients to make requests asking about status of the job to a dispatcher and get the right answers.  The clients submitted the job, but don’t really need to know which server wound up running the job.  The dispatcher can give them access to job status without needing to know.

Of course, you can create more than one executor to process messages from the job queue.  You might want to have different applications hosted in different servers, so there needs to be a way to make sure the right messages get to the right servers. 

That’s our topic for next time!