Batch applications are Enterprise JavaBeans (EJB) based Java 2 Platform Enterprise Edition (J2EE) applications. These applications conform to a few well-defined interfaces that allow the batch runtime environment to manage the start of batch jobs destined for the application.
Batch job steps
A batch job can be comprised of one or more batch steps. All steps in a job are processed sequentially. Dividing a batch application into steps allows for separation of distinct tasks in a batch application. A batch step is implemented as a local container-managed persistence entity bean that uses WebSphere Extended Deployment provided home, business and key interfaces. The business interface, com.ibm.websphere.batch.BatchJobStepLocalInterface, of a batch step EJB provides methods that the batch runtime environment invokes to control a batch application.
You can submit job schedules so that jobs will be processed at a certain time. You can also configure job schedules such that a job can recur on a specific time of day or week, and so on. When you are ready to submit a job, you can choose to delay the submission of it by specifying the start date and time of when you want to run the job.
Batch controller bean
In its deployment descriptor, a batch application is required to declare a special stateless session bean. This bean acts as a batch job controller and must contain enterprise beans references to all the batch step enterprise beans being used in the batch application. The implementation of this bean is provided by WebSphere Extended Deployment, not by the batch application. The bean only needs to be declared in the batch application deployment descriptor. Only one controller bean can be defined per batch application.
Batch data streams
A batch step can have zero or more batch data streams (BDS) associated with it. A BDS is a Java class that implements the com.ibm.websphere.batch.BatchDataStream interface. A BDS is a Java object that reads the input stream that contains the data to be processed by a batch step. A BDS can also be an output stream that writes data instead of reading it.
Methods on the BatchDataStream interface allow the batch runtime environment to manage the data stream being used by a batch step. For example, one of the methods retrieves current cursor information from the stream to keep track of how much data has been processed by the batch step.
Checkpoint algorithms
The batch runtime environment uses checkpoint algorithms to decide how often to commit global transactions under which batch steps are invoked. The XML Job Control Language (xJCL) definition of a batch job defines the checkpoint algorithms to be used. Properties specified for checkpoint algorithms in xJCL allow for checkpoint behavior, such as transaction timeouts and checkpoint intervals, to be customized for batch steps. WebSphere Extended Deployment provides time-based and record-based checkpoint algorithms. A checkpoint algorithm SPI is also provided for building additional custom checkpoint algorithms.
Packaging
A batch application is packaged as a standard Java 2 Platform Enterprise Edition (J2EE) EJB application inside a J2EE Enterprise Archive (EAR) file. You must package batch step entity enterprise beans and batch data stream classes that the batch steps have to be packaged with the application. The batch job controller bean also needs to be declared in the enterprise bean deployment descriptor of each batch application. Use standard J2EE development tools to develop and package the batch application EAR file.
Results algorithm
Results algorithms are an optional feature of the batch programming model. Results algorithms are applied to batch steps based on their return codes. The algorithms are used to manipulate the return codes of batch jobs. Additionally, these algorithms are place holders for triggers based on step return codes.