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!