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.
If you’ve decided this is the programming model you want to use, you’ve still got several choices about where to run it. To start with there are several different implementations of the specification. The original reference implementation is the basis for some of them (including the one in Liberty). In some cases you can run Jakarta Batch in a simple stand-alone JVM, while in others you’re part of a larger server environment (which would be the case with Liberty).
What you choose is probably going to depend a lot on what you’re already doing. If, for example, you’ve already got a lot of Liberty servers running OLTP workloads, it would probably make sense to run the batch workloads in Liberty.
Another factor might be how you intend to manage the JVMs that are running the jobs. Are you going to start a JVM to run a job, then tear it down when the job is done, or keep it around as a job-server (for z/OS folks, think of it as a JES initiator).
On the one hand, starting and stopping a lot of JVMs seems like unnecessary overhead, but that’s more in keeping with a containerized environment where you might provision an instance of an image to run a job. But, of course, you could provision an instance of a job-server that will run lots of jobs taken from a queue or something like that. Our discussion of Kubernetes Jobs made clear you’ve got a lot of options.
Hopefully, if you’re reading this thinking I’ll tell you what the ‘best’ approach is, you’ve figured out that I’m not going to do that. As with most things, there are a lot of different approaches you can take and you need to weigh your own particular needs against the pros and cons of each one. And what is a ‘pro’ to me might not be to you (and vice versa).
But our question isn’t actually what the best environment is any more than it is what the best platform or best language is. The question is whether Liberty makes a good option. Obviously I think it does or I wouldn’t have spent months of blog posts on our implementation of the specification. I think having the infrastructure of the server, with all its other features, including integration with z/OS, around the batch container make it a very viable option for your Java Batch workloads.
When I started writing this I thought I was going to get into a long list of the benefits of Liberty, but looking back over it I can see all I’ve done is wave my hands around a lot and told you to reach your own decision based on your own needs. All in all that’s probably the best advice I can give…