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.
The Job Repository is where the batch runtime keeps track of everything that is going on. It knows about jobs that have run in the past as well as jobs currently executing. It has application checkpoint data to be used if a failed job needs to restart.
In order to function properly, the batch runtime that is part of the Liberty server needs to be able to update the tables that make up the Job Repository. As with much of the security stuff we’ll discuss here, exactly how you do this depends on the platform you are running on and the database implementation.
Of course, it isn’t enough to just allow access to the tables by the server itself. You want to deny access to those tables to anyone that shouldn’t have access. Since all operational batch activities should go through the REST interface and the batch code, there’s no real reason for anyone (except perhaps a DBA) to have any access to the tables directly. No one should need to go poking around in the tables to find the state of a job, and certainly no one should be manually making updates to the table content.
Similarly, in a multi-server batch environment where jobs are being queued from a dispatcher to an executor server, access to the queue itself will be important. Just as with the Job Repository tables, the server itself needs to be able to write to (dispatcher) or read from (executor) the queue to put/get messages (technically, since it is a “destructive” read, the executor needs write/update access too). And also, like the Job Repository, you don’t want or need any others being able to directly access the queue, with the possible exception of an MQ administrator. And, yet again, exactly how you do this will depend on the messaging implementation and the platform.
Finally, if you configure the servers to publish event messages to the batch topic tree at significant points in job processing, you’ll need to allow the servers (both dispatchers and executors) to publish into that topic tree. You’ll also need to identify any necessary subscribers that are interested in batch events and allow them to subscribe. It is important to block out any access from unauthorized users as you certainly don’t want the possibility of ‘fake’ events introduced into the system by an unauthorized publisher. And, since the event messages can include job log contents which could contain sensitive information (depends what the batch application logs) you’ll want to control subscriber access also.