Spring Batch - Spring Enterprise Recipes: A Problem Solution Approach - page 351

C H A P T E R 9
■ ■ ■
Spring Batch
Previous chapters discussed JMS and Spring Integration, which provide essential framework
infrastructure for very common types of problems in an event-driven architecture (EDA). Another
common kind of processing requirement is batch processing, which is both a complement and
sometimes necessary extension to event-driven processing.
Batch processing has been around for decades. The earliest widespread applications of technology
for managing information (information technology) were applications of batch processing. These
environments didn't have interactive sessions and usually didn't have the capability to load multiple
applications in memory. Computers were expensive and bore no resemblance to today's servers.
Typically, machines were multiuser and in use during the day (time-shared). During the evening,
however, the machines would sit idle, which was a tremendous waste. Businesses invested in ways to
utilize the offline time to do work aggregated through the course of the day. Out of this practice emerged
batch processing.
Batch processing solutions typically run offline, indifferent to “events” in the system. In the past,
batch processes ran offline out of necessity. Today, however, most batch processes are run offline
because having work done at a predictable time and having “chunks” of work done is a requirement for a
lot of architectures. A batch processing solution doesn't usually respond to requests, although there's no
reason it couldn't be started as a consequence of a message or request. Batch processing solutions tend
to be used on large datasets where the duration of the processing may be unknown. A process might run
for minutes, hours, or days!
Batch processing has had a long history that informs even modern batch processing solutions.
Mainframe applications used batch processing, and one of the largest modern day environments
for batch processing, CICS on z/OS, is still fundamentally a mainframe operating system. Customer
Information Control System (CICS) is very well suited to a particular type of task: take input, process it,
and write it to output. CICS is a transaction server used most in financial institutions and government
that runs programs in a number of languages (COBOL, C, PLI, and so on). It can easily support
thousands of transactions per second. CICS was one of the first “containers,” a concept familiar to
Spring and Java EE users, even though CICS itself debuted in 1969! A CICS installation is very expensive,
and although IBM still sells and installs CICS, many other solutions have come along since then. These
solutions are usually specific to a particular environment: COBOL/CICS on mainframes, C on Unix,
and, today, Java on any number of environments. The problem is that there's very little standardized
infrastructure for dealing with these types of batch processing solutions. Very few people are even aware
of what they're missing because there's very little “native” support on the Java platform for batch
processing. Businesses that need a solution typically end up writing it in-house, resulting in fragile,
domain-specific code.