As you might already know, the JSR-352 is the standardization effort for batch processing in Java. It has been released and included in JEE7 this year, which means that every JEE7 application server will have batch processing capabilities. As I pointed out in a previous post , even if you’re application server vendor is fix, you still have a choice when it comes to choosing an implementation of the JSR-352.
Okay, so you have a choice, then how do you choose? Of course, it’s not about what the JSR-352 offers, since everybody’s implementing it. You choose an implementation of the JSR-352 by what it offers beyond the JSR-352. In this post I put together some criteria for this choice, based on the experience with implementing Spring Batch in typical enterprise companies like insurances and banks. By now, there is no serious implementation of the JSR-352, even Spring Batch is not this far, so there’s no possibility to compare solutions right now. But as soon as there are any, we can apply the following criteria, ordered by importance.
- Testability
It should be possible to run batch jobs in a JUnit integration test, without having to deploy it on the application server. Development productivity and potential test coverage is much higher this way. - Components
Having a clean programming model for batch jobs is nice, but to become really fast in developing batch jobs you need pre-defined, well-tested components. Spring Batch has a lot of ItemReaders, ItemWriters, PartitionHandlers and so on for all kinds of data and infrastructures. - Monitoring
The JSR-352 defines batch job meta data like JobExecutions, JobInstances, StepExecutions and so on. There should be a nice way to access this data with a graphical user interface where you may start und stop jobs as well. Spring Batch has Spring Batch Admin for this. In addition, look for monitoring interfaces like JMX for monitoring tools. - Community
A developer-friendly community brings a lot of productivity. So check for Google results, an active forum, activity on stackoverflow to see how your product competes here. - Job inheritance
A feature that might not sound that important, but in fact is used in almost every Spring Batch project I know. In big companies you usually have some requirements that apply to every job written in the whole company, like a protocol listener, logging initialization, exit code converter and many more. Developers should not need to add the appropriate listeners themselves, instead they may just inherit a parent job definition. And then in projects with a lot of very similar batch jobs a parent job definition that includes all the common stuff makes sense as well. - Open Source
There has been a lot of discussions whether Open Source is good or not, I won’t repeat them here. I prefer Open Source to closed source because as a developer I don’t want to be damned to open some ticket somewhere instead of walking through the code and see what’s wrong. As a decider I of course would check carefully on the quality of the Open Source project of my choice – but at least I can do that. - Security
Security is always important, not everybody should be able to start und stop jobs, and not everybody should be able to view the batch meta data. - Scalability options
Scaling is important, and this is just at number eight because the most important scalability option – Local Partitioning – is included in the JSR-352. But there are more (in Spring Batch: Multi-threaded Step, Remote Partitioning, Parallel Step, Remote Chunking), so a check on the other scalability options your solution offers. - Configuration options
The JSR-352 defines an XML-based job configuration model. Spring Batch offers configuration in Java, which is type-safe, ensures a lot of things at compile-time (not runtime) and supports refactoring in every IDE. This is not mission critical, that’s why it’s at number nine, but still it’s nice to have a choice. - Extensibility
Extensibility is a very important thing, and it’s just at number ten because the JSR-352 API offers most of the stuff you’ll ever need for extensions, like starting and stopping jobs, accessing the batch meta data and write custom components. Still, there might be things you wanna do that are not covered by the JSR-352.
10 criteria, some quite broad, some a very concrete feature. The ordering is done with the experience of implementing Spring Batch in bigger companies. You may have a different ordering, you may skip one or two on the list and add another, but you can’t deny that these are important topics. Choosing an implementation of the JSR-352 should be done with care, because you’ll likely stick to it for a long time. These criteria will help you doing it.
Was this post helpful?
More articles
fromTobias Flohre
16.2.2022 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Tobias Flohre
Senior Software Developer
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.