Processing Modes

Processing modes adjusted to the specific task of the batch program make sure the implementation of the program is done with the right complexity. Hence, the developmental and operational efforts are optimized.

The bmap4j processing layer supports the following processing modes:

• Sequential
• Parallel

Transaction Models

The parallel processing takes place in an EE environment using so called message-driven-beans (MDB's). In Java EE, this is the only allowed option to run multiple parallel threads. To achieve this, the asynchronous messaging-mechanism of the applications server is used. Thus, the designer is deliberately released from the complexity and error-proneness of parallel processes in the developmental stage.

On the one hand the parallel processing with JMS helps achieve the required performances. But on the other hand from the point of view of the programmer the control of the individual thread lies mainly with the application server. The application server assures with its transaction processing capabilities, that the data processed by the thread is rolled-back, if an error occurs during processing of a thread. In many cases, this is the desired behavioral pattern.

However this behavior can result in a repeated processing of erroneous slices and thus increase the threat of a system break-down. In this case, special framework transaction models like

• Consume-On-Exception
• Max-Worker-Run

help maintain control.

Java EE

Complex parallel flow models with the appropriate transaction models can be efficiently designed and operated with EE. Therefore bmap4j uses Java EE and especially EJB3 for processing. This allows for programs to directly profit from advantageous characteristics the Java EE platform brings along, e.g. portability, scalability and safety.

Because the processing is based strictly on Java EE standards, a batch program developed under bmap4j can be run without any problems on different Java EE certified application servers. Thus, a vendor lock-in to the batch extension of each application server manufacturer can be avoided in the area of batch processing.

Even simple programs that would run without problems in an SE environment, can directly benefit from an EE deployment by using the existing deployment-features or benefit for example from the diverse pooling-mechanisms.