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.
-----
There are a lot more open Jakarta Batch issues, but I’ve run out of the ones that I thought were interesting enough to write about. If I skipped your favorite one, feel free to post something here about it.
What I’d like to do now is start looking at some of the readers, writers, processors, and batchlets that are available for you to use. The ones I’ll be talking about are available from Apache BatchEE and JBeret. I’m sure there are others in other places, but these are the ones I felt like writing about.
Apache BatchEE started out as a fork of the reference implementation of JSR-352 written by IBM as part of creating the original specification and TCK. As we’ve noted earlier, Open Liberty is also derived from the same reference implementation.
Like Liberty, the BatchEE implementation added some things. Some of these are built right into the implementation, like the ability to have @StepScoped and @JobScoped objects. That’s another idea that has been kicked around for inclusion in the specification.
They also included global step and job listeners. You can define these to get control for jobs/steps that run in a given environment without needing to include them in the application itself. This is somewhat like JES Exits on z/OS, if that helps…
They also added a JMX wrapper around the JobOperator interface. This is kind of like the REST interface that Liberty has provided for the same purpose.
The BatchEE implementation also includes a GUI to help you perform Job Operator functions. This is similar to the Batch tool that is part of the Liberty Admin Center. The BatchEE GUI rests on the JMX wrapper much as the Liberty Batch tool rests on the (ahem) REST interface.
JBeret is part of the WildFly Java EE implementation and handles the Java Batch part. They also have a REST API and a GUI.
Both both JBeret and BatchEE have a set of Readers, Writers, Processors, and Batchlets (JBeret calls them ‘support’ and BatchEE calls them ‘extensions’). These should be able to be used (perhaps with a bit of touching up) in any JSR-352/Jakarta Batch implementation (the wonders of an open specification).
In the coming weeks I’ll be taking a closer look at some of these and how they work.