Java Reference
In-Depth Information
processes: you get to focus more on solving technical issues than on moving form fields three pixels to
the right on a web application. The question is, with existing infrastructures on mainframes and all the
risks of adopting a new platform, why do batch in Java?
Why Do Batch Processing in Java?
With all the challenges just listed, why choose Java and an open source tool like Spring Batch to develop
batch processes? I can think of six reasons to use Java and open source for your batch processes:
maintainability, flexibility, scalability, development resources, support, and cost.
Maintainability is first. When you think about batch processing, you have to consider maintenance.
This code typically has a much longer life than your other applications. There's a reason for that: no one
sees batch code. Unlike a web or client application that has to stay up with the current trends and styles,
a batch process exists to crunch numbers and build static output. As long as it does its job, most people
just get to enjoy the output of their work. Because of this, you need to build the code in such a way that it
can be easily modified without incurring large risks.
Enter the Spring framework. Spring was designed for a couple of things you can take advantage of:
testability and abstraction. The decoupling of objects that the Spring framework encourages with
dependency injection and the extra testing tools Spring provides allow you to build a robust test suite to
minimize the risk of maintenance down the line. And without yet digging into the way Spring and Spring
Batch work, Spring provides facilities to do things like file and database I/O declaratively. You don't have
to write JDBC code or manage the nightmare that is the file I/O API in Java. Things like transactions and
commit counts are all handled by the framework, so you don't have to manage where you are in the
process and what to do when something fails. These are just some of the maintainability advantages that
Spring Batch and Java provide for you.
The flexibility of Java and Spring Batch is another reason to use them. In the mainframe world, you
have one option: run COBOL on a mainframe. That's it. Another common platform for batch processing
is C++ on UNIX. This ends up being a very custom solution because there are no industry-accepted
batch-processing frameworks. Neither the mainframe nor the C++/UNIX approach provides the
flexibility of the JVM for deployments and the feature set of Spring Batch. Want to run your batch
process on a server, desktop, or mainframe with *nix or Windows? It doesn't matter. Need to scale your
process to multiple servers? With most Java running on inexpensive commodity hardware anyway,
adding a server to a rack isn't the capital expenditure that buying a new mainframe is. In fact, why own
servers at all? The cloud is a great place to run batch processes. You can scale out as much as you want
and only pay for the CPU cycles you use. I can't think of a better use of cloud resources than batch
processing.
However, the “write once, run anywhere” nature of Java isn't the only flexibility that comes with the
Spring Batch approach. Another aspect of flexibility is the ability to share code from system to system.
You can use the same services that already are tested and debugged in your web applications right in
your batch processes. In fact, the ability to access business logic that was once locked up on some other
platform is one of the greatest wins of moving to this platform. By using POJOs to implement your
business logic, you can use them in your web applications, in your batch processes—literally anywhere
you use Java for development.
Spring Batch's flexibility also goes toward the ability to scale a batch process written in Java. Let's
look at the options for scaling batch processes:
