Batch environment planning for transactional batch applications and compute-intensive applications

When planning your batch environment, consider certain factors that can help you design your environment to best suit your needs.

Before you build your environment, carefully consider the goals that you want to accomplish. For example, you can configure your batch environment in an existing cell or build a new cell. Also, you must decide what relational database to use, the security you need, and what your availability requirements are. The following sections contain information about each of these considerations.

New or existing cell

You can choose to configure your batch environment in an existing WebSphere® Application Server cell or you can build a new cell entirely. Your choice depends on whether you want a new environment isolated from any existing WebSphere Application Server environment, or whether you want to add the capabilities of batch to an existing environment.

On the application server nodes where you 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 WebSphere Application Server environment.
  1. Transactional batch

    Runs transactional batch applications that are written in Java and implement a WebSphere Application Server programming model. They are packaged as Enterprise Archive (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.

  2. Compute-intensive

    Runs compute-intensive applications that are written in Java and implement a WebSphere Application Server programming model. They are packaged as Enterprise Archive (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 WebSphere Application Server 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 you 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 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:
  1. 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.
  2. 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 two 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.
    These roles are assigned through 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 Enterprise JavaBeans (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 information
Securing the job scheduler using roles
Batch applications, jobs, and job definitions
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Feb 6, 2014 8:11:25 PM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-mp&topic=cgrid_cgplan
File name: cgrid_cgplan.html