Environment planning for transactional batch applications and compute-intensive applications
When planning the batch environment, consider certain factors that can help you design the environment to best suit the needs.
Before you build the environment, carefully consider the goals to accomplish. For example, we can configure the batch environment in an existing cell or build a new cell. Also, decide what relational database to use, the security we need, and what the availability requirements are. The following sections contain information about each of these considerations.
New or existing cell
We can choose to configure your batch environment in an existing WAS cell or we can build a new cell entirely. Your choice depends on whether we want a new environment isolated from any existing WebSphere Application Server environment, or whether to add the capabilities of batch to an existing environment.
On the application server nodes where we want the job scheduler and batch container functions, use the 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, you must deploy the job scheduler on a WAS server or cluster. To set up an environment to host transactional batch or compute-intensive job types, you must deploy the batch container to at least one WebSphere Application Server server or cluster. The transactional batch, compute-intensive applications, or both are installed on the same WebSphere Application Server 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 WebSphere Application Server connection management facilities. The relational databases supported are the same as those relational databases supported by WebSphere Application Server, including DB2 , Oracle, and others.
The simple file-based Apache Derby database is automatically configured for you by default so that we can quickly get a functioning environment up and running. However, 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 DB2for this purpose. Network Derby works also, but lacks the robustness necessary for production purposes. Do not use the network version in production.
Avoid trouble: Application JPA settings always override the settings on this page.gotcha
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 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 concepts
Job scheduler security overview Batch applications, jobs, and job definitions
Related tasks
Secure the job scheduler using roles