The JSR-352 (Batch Applications for the Java platform) has been released and included in JEE7 over half a year ago, so now I see conference talks and workshops popping up explaining it, and that’s a good thing, people need to know about it. Spring Batch had a lot of influence in the spec and will implement it in Spring Batch 3.0.
Since the JSR-352 explicitly targets the Java Enterprise AND the Java Standard Edition, I see arguments coming up that you should use the application server’s implementation of the JSR-352 whenever you’re in a JEE environment, and that you can use Spring Batch whenever you’re not. I don’t think it’s that easy.
Actually, using Spring Batch in a JEE environment is a quite common thing these days. Classic batch processing is an enterprise thing, and a lot of them still operate on JEE application servers. And hey, you get XA transactions to work there, so in many cases it’s a reasonable thing to do.
I will talk about criteria for choosing an implementation of the JSR-352 in a future post, today I just want to point out that you have a choice, even if your application server vendor is fix. And if it’s not, you even have more choices.
The architecture for running JSR-352 batch jobs in your JEE7 application server with its implementation of JSR-352 looks like this:
The architecture for running JSR-352 batch jobs in your JEE application server with Spring Batch looks like this:
This deployment model is running very stable at a lot of customers, and liking or not liking one or another is an academic thing, since both work well, and that’s what counts in the enterprise (actually, we don’t know if the JEE7 only model works well, since there are no serious implementations until now).
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 a following blog post I will put together criteria for choosing, so stay tuned.