At the QCon conference, Dave Syer today gave an update on the Spring Batch project that is approaching the 1.0 release (scheduled for next week). Batch Processing has to do with processing (typically large) “batches” or sets of input data at regular intervals instead of continuously, “on-line”, for some reason (cost, time, throughput, etc). Within the Java EE platform, you are then forced to leave the familiar area of Application Server Container services and support. The challenges you have to face (“chunking” work into atomic, transactional units-of-work, retry mechanisms in case of transient problems, error reporting and restart features in case of unrecoverable problems, …) are mundane and unsexy. Never the less we have to deal with them, over and over again.
This is an area that is ideal for framework support: Let the framework take care of the batch-related responsibilities, and allow an application developer to plug in reusable business logic into a batch execution scenario. At Callista, we have written several such project- and customer-specific frameworks over the years, since no suitable commercial or open-source alternatives have existed. This is clearly an area where the JavaEE platform is missing an important piece.
Spring Batch changes the scene. It is a light-weight framework for Batch Processing that blends very well with the rest of the Spring framework family: Business logic expressed as Spring beans can easily be reused in Batch scenarios, where the batch semantics is applied as decorators to the business logic, and where the Spring Batch framework provides well architected solutions to most of the recurring Batch challenges.
So, good news for everyone that has already committed to using the Spring DI container. If your business logic lives in EJB 3.0 beans, Spring Batch won’t be of any help. Let’s hope that the Spring Batch initiative influences the JavaEE 6 JCP work. It is badly needed!