This section examines the second style of jobs discussed previously — jobs that perform multiple actions per processing iteration. Batch processing by its very nature is "iterative" (and the word itself indicates "multiples"). Chapter 14 stated the following about the case study's batch processes:
The manager components will be responsible for selecting the appropriate records from the database and delegating the processing of an individual record (or batch of records) to a processing component. The manager will also be responsible for maintaining the overall status of the job so that it can be reported to the outside world.
The processing components will perform the actual functional batch processing on the individual record or batch of records (using framework components, where necessary).
This separation is shown again in Figure 16-3.
This section builds on this simplistic figure to flesh out some of the methods and interfaces that the batch processes (managers and processors) would need to implement to support fast and reliable processing that can be triggered via multiple channels.
In the online application, a web page calls the managers via web services. The managers accept a TransactionContext object, which they use, populate, and return to the page. In the case of batch, the manager component needs to be ...