In this article we're going to take a look at Spring Batch 2.0, the latest version of the Spring Batch framework. Our approach will be strongly practical: we'll cover the key ideas without dwelling too much on the details, we'll get you up and running with one of the sample applications that ships with Spring Batch, and finally we'll take a closer look at the sample app so you can understand what's going on.
At the time of this writing Spring Batch 2.0 is actually in RC2 status, so there may be minor changes between now and the GA release.
Let's begin with an overview of Spring Batch itself.
What Is Spring Batch?
While there are lots of different frameworks for building web applications, building web services, performing object/relational mapping and so forth, batch processing frameworks are comparatively rare. Yet enterprises use batch jobs to process billions of transactions daily.
Spring Batch fills the gap by providing a Spring-based framework for batch processing. Like all Spring frameworks, it's based on POJOs and dependency injection. In addition it provides infrastructure for building batch jobs as well as execution runtimes for running them.
At the highest level, the Spring Batch architecture looks like this:
In figure 1, the top of the hierarchy is the batch application itself. This is whatever batch processing application you want to write. It depends on the Spring Batch core module, which primarily provides a runtime environment for your batch jobs. Both the batch app and the core module in turn depend upon an infrastructure module that provides classes useful for both building and running batch apps.
Batch processing itself is a decades-old computing concept, and as such, the domain has standard concepts, terminology and methods. Spring Batch adopts the standard approach, as shown in figure 2:
Here we see a hypothetical three-step job, though obviously a job can have arbitrarily many steps. The steps are typically sequential, though as of Spring Batch 2.0 it's possible to define conditional flows (e.g., execute step 2 if step 1 succeeds; otherwise execute step 3). We won't cover conditional flows in this article.
Within any given step, the basic process is as follows: read a bunch of "items" (e.g., database rows, XML elements, lines in a flat file—whatever), process them, and write them out somewhere to make it convenient for subsequent steps to work with the result. There are some subtleties around how often commits occur, but we'll ignore those for now.
With the high-level overview of Spring Batch behind us, let's jump right into the football sample application that comes with Spring Batch.