WebSphere Extended Deployment Compute Grid, Version 6.1
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Understanding the Compute Grid environment

This topic describes components that comprise a typical Compute Grid environment.

The elements in the Compute Grid environment

The basic Compute Grid environment is comprised of the elements depicted in the following diagram:
Compute Grid elements
The following list describes the numbered items in the previous diagram:
  1. Job scheduler

    The job scheduler is the Compute Grid component that provides all job management functions, such as submit, cancel, restart, and so on. It maintains a history of all jobs, including those waiting to run, those running, and those that have already run. It also maintains usage data for jobs that have run. The job scheduler is hosted in a WebSphere Application Server (or cluster) in a WebSphere Network Deployment environment. A WebSphere cell can have no more than one job scheduler.

  2. Batch container

    The batch container is the Compute Grid component that provides the execution environment for the batch jobs. Java 2 Platform Enterprise Edition (J2EE)-based batch applications run inside the WebSphere batch container. Native execution applications run inside a separate container, which is described in the following section. The batch container is hosted in a WebSphere Application Server (or cluster) in a WebSphere Network Deployment Network Deployment environment. A WebSphere cell can have any number of batch containers.

  3. J2EE batch application

    J2EE batch applications are regular WebSphere J2EE applications, deployed as an Enterprise Archive (EAR) file, that contain implementations of one or more Java batch applications. These Java batch applications follow either the transactional batch or compute-intensive programming models.

  4. xJCL

    Jobs are described using a job control language. Compute Grid jobs use an XML based job control language. The job description identifies which application to run, its inputs, and outputs.

  5. Web, Shell, API

    The job scheduler exposes three API types to access its management functions: a Web interface called the job management console, a shell command line called lrcmd, and APIs, available as either Web Services and EJBs.

  6. Scheduler tables

    The job scheduler uses a relational database to store job information. It can be any relational database supported by WebSphere Application Server. If the job scheduler is clustered, the database must be a network database, such as DB2.

  7. Container tables

    The batch container uses a relational database to store checkpoint information for transactional batch applications. The database can be any relational database supported by WebSphere Application Server. If the batch container is clustered, the database must be a network database, such as DB2.

  8. JDBC

    This is standard JDBC connectivity to the scheduler and container tables, as supported by WebSphere Application Server's connection manager.

Basic environment for native execution jobs

The Compute Grid job scheduler can also manage native execution jobs. A native execution job is a job that describes the invocation of a native application, which is any application that can be run as a non-interactive background command. This includes Java main programs, compiled applications written in languages such as COBOL or C++, and virtually any kind of script.

The following diagram depicts the additional elements that comprise the environment for running native execution jobs:


Environment for running native execution jobs

  1. Native execution endpoint

    A native execution endpoint is a node in the WebSphere cell on which native execution jobs can run. Both WebSphere Application Server and non-WebSphere Application Server nodes can be used to run native execution jobs. On WebSphere Application Server nodes, the node agent is used by the job scheduler to control native execution jobs. On non-WebSphere Application Server nodes, the middleware agent controls native execution jobs.

  2. Nodeagent

    A WebSphere Application Server node can be an execution endpoint for native execution jobs. The job scheduler sends a native execution job to the nodeagent. The nodeagent then creates a native operating system process in which the specified native application is invoked.

  3. Native application

    The native application runs in its own process and is passed input parameters specified in the job description (xJCL). The process is configured with environment variables specified in the xJCL.

  4. Middleware agent

    Native execution jobs can also run on non-WebSphere nodes. A non-WebSphere Application Server node is also known as a middleware node. A middleware node requires a small control agent, called the middleware agent in order to run native execution jobs. The middleware agent provides a control point for the job scheduler. Through the middleware agent, the job scheduler sends a native execution job to run on the middleware node. The middleware agent, like the nodeagent, runs each native execution application in its own process.




Related concepts
xJCL elements
Middleware agent
Related tasks
Developing Compute Grid applications
Configuring the job scheduler
Related information
Planning your Compute Grid environment
Configuring grid endpoints
Concept topic    

Terms of Use | Feedback

Last updated: Oct 30, 2009 6:22:16 PM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/prodovr/ccgunder.html