o you thought batch programming had died and gone the way of the COBOL dinosaur. Think again. Despite the trends toward real-time solutions, companies still run essential business processes using batch technologiesand with good reason. Batch processing has its place, and it's not just within legacy systems. Some problems just aren't suited to the trendy on-line, real-time solutions. High-volume business processes, such as bulk data upload and downloads, data cleansing (ETL Extract, Transform, Load), file import and export, billing and letter, statement and report generation, are typically best performed as batches.
Identifying Batch Scenarios
Batch processes are not typically associated with J2EE architectures. But this doesn't mean that J2EE can't cut itquite the contrary. Rather, when to apply a batch solution and how to implement it in the context of J2EE are generally misunderstood.
To understand whether you have a potential batch scenario, first examine your business problem for a few tell-tail indicators. For example, does your business function fall into one or more of the following scenarios:
- Not required to be triggered or processed in real-time
- High volume, involving thousands, hundreds of thousands, or millions of data rows or transactions
- Computationally expensive, and you don't want this cost to be part of your on-line application
- Unable to be triggered by a particular user action as the data is incomplete or unstable; Data stabilises after the fact or when some other business process occurs
- Triggered by a high-level, overarching business or time-based event
If it does, you have two choices:
- Batch processing: Use batch processes to process the work off-line.
- Real-time asynchronous processing: Use fine-grained timers or asynchronous event triggers (such as JMS) to pass responsibility from on-line to back-end functions.