Compute-intensive programming model

Compute-intensive applications are applications that perform computationally intensive work that does not fit comfortably into the traditional Java EE request and response paradigm.

Compute-intensive applications

There are a number of characteristics that can make these applications unsuitable for traditional Java EE programming models:

• The need for asynchronous submission and start of work

• The need for work to run for extended periods of time

• The need for individual units of work to be visible to and manageable by operators and administrators

The compute-intensive programming model provides an environment that addresses these needs. The compute-intensive programming model is centered around two basic concepts:

1. The use of jobs to submit and manage work asynchronously

2. A minor extension to the asynchronous beans programming model to support work that runs for an extended period

The following sections provide additional information about the extensions to the asynchronous beans programming model.

Controller bean

The controller bean is a stateless session bean defined in the compute-intensive application deployment descriptor that allows the runtime environment to control jobs for the application. The implementation of this stateless session bean is provided by the application server. The application includes the stateless session bean, shown in the following definition, in the deployment descriptor of one of its enterprise bean modules. Exactly one controller bean must be defined for each compute-intensive application. Since the implementation of the controller bean is provided in the application server runtime, application deployers do not request deployment of enterprise beans during deployment of compute-intensive applications.

<session id="supply a suitable name here">
   <ejb-name>CIController</ejb-name>
   <home>com.ibm.ws.ci.CIControllerHome</home>
   <remote>com.ibm.ws.ci.CIController</remote>
   <ejb-class>com.ibm.ws.ci.CIControllerBean</ejb-class>
   <session-type>Stateless</session-type>
   <transaction-type>Bean</transaction-type>
   <resource-ref id="WorkManager_ResourceRef">
      <description>
         WorkManager used to execute jobs.
             <res-ref-name>wm/CIWorkManager</res-ref-name>
      <res-type>commonj.work.WorkManager</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Shareable</res-sharing-scope>

Packaging a compute-intensive application

The logic for a compute-intensive application with some number of CIWork objects plus the classes to support those CIWork objects, is packaged in an enterprise bean module in a Java EE application EAR file. The deployment descriptor for the enterprise bean module must contain the definition of the stateless session bean previously described. If the application itself uses other enterprise beans or resources, then the definitions for those beans and resources might also be in the deployment descriptor. We can use Java EE development tools such as IBM Rational Application Developer to develop and package compute-intensive applications in the same way that they are used to construct Java EE applications containing enterprise bean modules and asynchronous beans. We can also use the pgcpackager task to package compute-intensive applications.

Life cycle of a compute-intensive application

A compute-intensive application is started by the application server in the same way as other Java EE applications. If the application defines any start-up beans, then those beans are run when the application server starts. When a job arrives for the application to run, the compute-intensive execution environment invokes the CIControllerBean stateless session bean defined in the application EJB module deployment descriptor. The JNDI name of this stateless session bean is specified in the XML Job Control Language (xJCL) for the job. For each job step, the CIControllerBean stateless session bean completes the following actions:

1. Instantiates the application CIWork object specified by the class name element in the xJCL for the job step using the no-argument constructor of the CIWork class.

2. Invokes the setProperties() method of the CIWork object to pass any properties defined in the xJCL for the job step.

3. Looks up the work manager defined in the deployment descriptor of the enterprise bean module and uses it to asynchronously call the run() method of the CIWork object.

If the job is canceled before the run() method returns, then the CIControllerBean invokes the CIWork object release() method on a separate thread. It is up to the developer of the long-running application to arrange for logic in the release() method to cause the run() method to return promptly. The job remains in a cancel pending state until the run() method returns.

If the job is not canceled and the run() method returns without returning an exception, then the job completed successfully. If the run() method returns an exception, then the job status is execution failed. After the run() method returns either successfully or with an exception, no further calls are made to the CIWork object. All references to the run() method are dropped.

Compute-intensive job step

Unlike other batch jobs, compute-intensive jobs consist of one job step. This job step is represented by an instance of a class that implements the com.ibm.websphere.ci.CIWork interface. The CIWork interface extends the commonj.Work work interface from the application server asynchronous beans programming model and JSR 237. These extensions consist of two methods that provide a way to pass the job-step-specific properties specified in the job to the CIWork object.

See the API documentation for more details.

To learn about asynchronous beans, see Using asynchronous beans.

Related concepts

Transactional batch and compute-intensive batch programming models

Batch programming model

APIs

Related tasks

Develop a simple compute-intensive application

Use asynchronous beans