Environment planning for transactional batch applications and compute-intensive applications
New or existing cell
We can choose to configure the batch environment in an existing WebSphere Application Server cell or we can build a new cell entirely.
On the application server nodes where we want the job scheduler and batch container functions, use the administrative console to activate the functions. No action is necessary on the deployment manager node.
Job types
There are two job types. They are hosted in the WAS environment.
- Transactional batch
Runs transactional batch applications that are written in Java and implement a WAS programming model. They are packaged as EAR files and are deployed to the batch container hosted in an application server or cluster.
The transactional batch programming model provides a container-managed checkpoint/restart mechanism that enables batch jobs to be restarted from the last checkpoint if interrupted by a planned or unplanned outage.
- Compute-intensive
Runs compute-intensive applications that are written in Java and implement a WAS programming model. They are packaged as EAR files and are deployed to the batch container hosted in an application server or cluster.
The compute-intensive programming model provides a lightweight execution model based on the common framework
For all batch environments, deploy the job scheduler on a WAS server or cluster. To set up an environment to host transactional batch or compute-intensive job types, deploy the batch container to at least one WAS server or cluster. The transactional batch, compute-intensive applications, or both are installed on the same WAS server or cluster.
Relational database
The job scheduler and batch container both require access to a relational database. The relational database used is JDBC connected. Access to the relational database is through the underlying WAS connection management facilities. The relational databases supported are the same as those relational databases supported by WAS, including DB2, Oracle, and others.
When configuring an EJB Timer/Scheduler, remember that the default scheduler uses the simple file-based Apache Derby database by default so that we can quickly get a functioning environment up and running. DO NOT use the Derby database for production use. Moreover, the default Derby database does not support a clustered job scheduler, nor a clustered batch container.
A highly available environment includes both a clustered job scheduler, and one or more clustered batch containers. Clustering requires a network database. Use production grade databases such as DB2 for this purpose. Network Derby works also, but lacks the robustness necessary for production purposes. Do not use the network version in production.
Application JPA settings always override the settings on this page.
Security considerations
Security for the batch environment is based on the following techniques:
- WebSphere authentication for access to job scheduler interfaces. Users defined to the active WebSphere security registry can authenticate and gain access to the web, command line, and programmatic interfaces of the job scheduler.
- Role-based security for permission rights to job. Authenticated users must be assigned to the appropriate roles in order to perform actions against jobs. There are three roles:
- lrsubmitter
- Users in the lrsubmitter role can submit and operate on their own jobs, but on no others.
- lradmin
- Users in the lradmin role can submit jobs and operate on their own job or the jobs of anyone else.
- lrmonitor
- Users assigned the lrmonitor role only can view jobs and job logs of all users.
We can assign these roles using the job scheduler configuration page in the administrative console.
High availability considerations
Use clustering for high availability of batch components. Deploy and operate on clusters using the job scheduler and batch container.
Use typical application clustering techniques with the job scheduler to ensure that it is highly available. The job scheduler supports multiple methods of access to its APIs: web application, command line, web service, and EJB. Ensuring that highly available network access to a clustered job scheduler depends on which job scheduler API access method. The batch container is made highly available by deploying it to a cluster. The job scheduler automatically recognizes the batch container is clustered and takes advantage of it to ensure a highly available execution environment for the batch jobs that run there.
Related:
Job scheduler security overview Batch applications, jobs, and job definitions Secure the job scheduler using roles