Java Reference
In-Depth Information
•
Mainframe:
The mainframe has limited additional capacity for scalability. The
only true way to accomplish things in parallel is to run full programs in parallel on
the single piece of hardware. This approach is limited by the fact that you need to
write and maintain code to manage the parallel processing and the difficulties
associated with it, such as error handling and state management across programs.
In addition, you're limited by the resources of a single machine.
•
Custom processing:
Starting from scratch, even in Java, is a daunting task. Getting
scalability and reliability correct for large amounts of data is very difficult. Once
again, you have the same issue of coding for load balancing. You also have large
infrastructure complexities when you begin to distribute across physical devices
or virtual machines. You must be concerned with how communication works
between pieces. And you have issues of data reliability. What happens when one
of your custom-written workers goes down? The list goes on. I'm not saying it
can't be done; I'm saying that your time is probably better spent writing business
logic instead of reinventing the wheel.
•
Java and Spring Batch:
Although Java by itself has the facilities to handle most of
the elements in the previous item, putting the pieces together in a maintainable
way is very difficult. Spring Batch has taken care of that for you. Want to run the
batch process in a single JVM on a single server? No problem. Your business is
growing and now needs to divide the work of bill calculation across five different
servers to get it all done overnight? You're covered. Data reliability? With little
more than some configuration and keeping some key principals in mind, you can
have transaction rollback and commit counts completely handled.
As you see as you dig into the Spring Batch framework, the issues that plague the previous options
for batch processing can be mitigated with well-designed and tested solutions. Up to now, this chapter
has talked about technical reasons for choosing Java and open source for your batch processing.
However, technical issues aren't the only reasons for a decision like this. The ability to find qualified
development resources to code and maintain a system is important. As mentioned earlier, the code in
batch processes tends to have a significantly longer lifespan than the web apps you may be developing
right now. Because of this, finding people who understand the technologies involved is just as important
as the abilities of the technologies themselves. Spring Batch is based on the extremely popular Spring
framework. It follows Spring's conventions and uses Spring's tools as well as any other Spring-based
application. So, any developer who has Spring experience will be able to pick up Spring Batch with a
minimal learning curve. But will you be able to find Java and, specifically, Spring resources?
One of the arguments for doing many things in Java is the community support available. The Spring
family of frameworks enjoy a large and very active community online through their forums. The Spring
Batch project in that family has had one of the fastest-growing forums of any Spring project to date.
Couple that with the strong advantages associated with having access to the source code and the ability
to purchase support if required, and all support bases are covered with this option.
Finally you come to cost. Many costs are associated with any software project: hardware, software
licenses, salaries, consulting fees, support contracts, and more. However, not only is a Spring Batch
solution the most bang for your buck, but it's also the cheapest overall. Using commodity hardware and
open source operating systems and frameworks (Linux, Java, Spring Batch, and so on), the only
recurring costs are for development salaries, support contracts, and infrastructure—much less than the
recurring licensing costs and hardware support contracts related to other options.
I think the evidence is clear. Not only is using Spring Batch the most sound route technically, but it's
also the most cost-effective approach. Enough with the sales pitch: let's start to understand exactly what
Spring Batch is.
