1. Introduction

This paper gives an overview of different network deployment (ND) scenarios and describes the specific installation and configuration steps that need to be done before you can use Process Choreographer in a distributed environment. This paper also covers how to manage business processes in a distributed environment.

General information about installing and customizing the different network deployment setups is covered in the WebSphere Application Server InfoCenter.

Back to top

2. Network deployment scenarios for Process Choreographer

You might want to think about using Process Choreographer in a distributed environment if:

• The administrative overhead to manage several Process Choreographer instances becomes too high. In a distributed environment, you can use the network manager as a single point of administration to do this.
• Single machines cannot handle the required workload. In a distributed environment, you can collect application servers together as a WebSphere cluster to share the workload. If you use WebSphere MQSeries clustering or a central queue manager, you can also achieve intraprocess workload balancing.

The following sections give an overview of different distributed environments and the requirements that Process Choreographer has on each of these. The scenarios start with the first node in the cell and become increasingly complex.

2.1. The first node in a cell

For the first node in an ND-managed WebSphere cell, Process Choreographer requires that a database must be accessible from the deployment manager node. Before you can configure the business process container, access to the remote database must be established.

2.2. Independent application server and remote

The database used by Process Choreographer can be on any machine that is local or remote to the application server. The remote system can be a machine outside the WebSphere cell. The application server and the network manager node need access to the database system.

The deployment manager requires that the database names for each database system are unique in the WebSphere cell. The same database name must be used on the network manager and the corresponding application server.

2.3. Multiple application servers

The additional node contains multiple application servers. Each application server requires its own database.

2.4. Intraprocess load balancing

To enable intraprocess load balancing for Process Choreographer, you must either collect the queue managers in a WebSphere MQSeries cluster or set up a central queue manager on an WebSphere MQSeries server.

All application servers in the same WebSphere cluster use the same database. This database typically resides on a dedicated database system. You can also use one of the WebSphere cluster nodes for the database system. However, this is not recommended because if this system fails, all the application servers belonging to the WebSphere cluster are affected.

Figures 4 and 5 show ND setups for intraprocess load balancing.

2.5. Availability and failover support

Single points of failure in a distributed environment are the database system and the central queue manager system. The services provided by the application servers become highly available when WebSphere clustering is established. For the queues, you can either establish WebSphere MQSeries clustering or the queue manager must reside on a system that is protected by a high availability solution, for example, HACMP on AIX. The only way to protect the databases is to use a high availability system.

Back to top

3. Installing a distributed environment for Process Choreographer

Most of the steps to install Process Choreographer are covered in the WebSphere Application Server InfoCenter. Further information is given here only for the steps that are different from the stand-alone application-server installation.

To install the distributed environment:

1. Install the database system of choice and WebSphere MQSeries.
2. Establish modification on the systems involved. By default, the root user is used to start WebSphere. Enable the root user to use the database system.
3. Install WebSphere Application Server Enterprise on all the application servers. If you want to use embedded messaging, make sure that you choose a full installation.

   WebSphere MQSeries is required on WebSphere cluster nodes where intraprocess workload management (WLM) or failover capabilities are to be used. On these nodes, ensure that the embedded messaging feature is not installed.

   Note: Cloudscape does not support remote database access and therefore you cannot use it as a database system for Process Choreographer in a distributed environment. This means that you also cannot use the Process Choreographer sample configuration offered during the installation of the WebSphere Application Server Enterprise.

4. Install WebSphere Application Server Network Deployment on the network manager.
5. Install WebSphere Application Server Enterprise on the network manager.

3.1. Installing the database system

You can use different database systems for different Process Choreographer business process containers. Your database can run on DB2, Oracle, or Sybase. The steps to install each of these database systems are described here.

To install DB2:

1. Install DB2 Enterprise Edition 7.2 FP7 on the machine where the database is to be located.
2. Install the DB2 run-time client on all the application server machines and on the network manager machine. This is the minimum requirement. However, you can install DB2 Enterprise Edition instead of the DB2 run-time client on these machines.
3. If you administer the DB2 instances on the database machine remotely, create an administrative DB2 instance, db2as.
4. Create a DB2 instance on the database machine. The default is db2inst1. This DB2 instance is used throughout this paper.
5. On SMP machines, update the number of processors that can be used:

   /usr/lpp/db2_07_01/adm/db2licm -l

   
   

To install Oracle:

1. Install the Oracle server on the machine where the database is located.
2. Install the Oracle client on all the application server machines and on the network manager machine.
3. Set the environment variables ORACLE_BASE and ORACLE_HOME for the root user.

To install Sybase:

1. Install the Sybase server on the machine where the database is located.
2. Install the Sybase client on all the application server machines and on the network manager machine.
3. To get XA support, enable the DTM option for Sybase:

   option "enable DTM" must be set to "1" option "enable xact coordination" must be set to "1" add role "dtm_tm_role" to user "sa"

   
   

3.2. Installing WebSphere MQSeries

If you want to use WebSphere clustering as described in this paper, install WebSphere MQSeries 5.3 CSD 1 on all application server machines. On SMP machines, ensure that all CPUs can be used:

setmqcap #CPUs

If you work with embedded messaging, you do not need to install WebSphere MQSeries.

Back to top

4. Configuring the components in the distributed environment

To configure the components in the distributed environment:

1. Set up the database system.
2. Set up WebSphere MQSeries.
3. Set up WebSphere Application Server Network Deployment.
4. Add nodes and servers. For information on how to add nodes and servers, refer to the WebSphere Application Server InfoCenter.
5. Create a WebSphere cluster. For information on how to create a WebSphere cluster, refer to the WebSphere Application Server InfoCenter.
6. Configure Process Choreographer.

4.1. Setting up the database system

Your database can run on DB2, Oracle, or Sybase. The steps to set up each of these database systems are described here.

To set up DB2:

1. Create a dedicated file system for the databases.
2. Start the DB2 instance:

   db2start

   
   
3. Catalog the remote instance. Refer to the DB2 documentation for the parameters that can be used with this command. Replace <IP-address> with the IP address or host name of the database server.

   db2 catalog tcpip node reminst1 <IP-address> server 50010 remote_instance db2inst1

   
   Note: If you use a local DB2 instance on AIX 4.3.3 or later and attempt more than ten local concurrent DB2 connections from a single process, DB2 issues SQL1224N and the WebSphere administration server fails with StaleConnectionException. For information on how to avoid this problem, see the Hints and Tips for DB2.
4. Test communication to the remote instance:

   db2 attach to reminst1 user db2inst1 using <password>

   
   To reset the attachment, use the detach command:

   db2 detach

   
   
5. Copy createDatabaseDb2.ddl from an application server machine to the database node.
6. Edit createDatabaseDb2.ddl and change the database name. You can also change the database path. It is recommended that you create a createDatabaseDb2.ddl for each database.
7. Create the database:

   db2 -tf createDatabaseDb2.ddl db2 connect to <DatabaseName> db2 bind /home/db2inst1/sqllib/bnd/@db2cli.lst blocking all grant public db2 connect reset

   
   Repeat this step for each database.
8. On the deployment manager node and on the associated application server nodes, catalog the corresponding database:

   db2 catalog database <DatabaseName> as <DatabaseAlias> at node reminst1

   
   
9. Verify that the database catalog entries are correct and you can connect to the database:

   db2 connect to <DatabaseAlias> user db2inst1 db2 connect reset

   
   

To set up Oracle:

1. Create a dedicated file system for the databases.
2. Establish a net service name for the database on all machines.
   • For Oracle 8.1.7:

     su - oracle export DISPLAY=<hostname>:0.0 netasst select local select service naming click edit -> create net service name <DatabaseName> protocol TCP host name <hostname> port <port> Oracle 8i service name <DatabaseName>

     
     
   • For Oracle 9i:

     su - oracle export DISPLAY=<hostname>:0.0 netca select local net service name config select add select Oracle8i or later database or service service name <DatabaseName> protocol TCP host name <hostname> port <port> net service name <DatabaseName> <pre>

     
     
3. Use the Oracle tools to create an empty database with the JServer option enabled. For information on how to do this, refer to the Oracle documentation.
4. Start the Oracle listener on the database machine.
5. Create the database schema for each database:

   sqlplus <OracleUser>/<OraclePassword>@<DatabaseName> \ @createTablespaceOracle<8|9>.ddl <TableSpaceDirectory> sqlplus <OracleUser>/<OraclePassword>@<DatabaseName> \ @createSchemaOracle<8|9>.ddl

   
   

To set up Sybase:

1. Create a dedicated file system for the databases.
2. Establish a net service name for the database on all machines:

   su - sybase export DISPLAY=<hostname>:0.0 dsedit select add new server entry server name <ServerName> select add new network transport transport type tli tcp host name <hostname> port number <port>

   
   
3. Edit the createDatabaseSybase120.ddl file and change the database name. It is recommended that you create a dedicated createDatabaseSybase120.ddl for each database.
4. Create the database:

   su - <SybaseUser> isql -U <UserId> -P <Password> -S <ServerName> \ -i createDatabaseSybase120.ddl

   
   Repeat this step for each database.

4.2. Setting up WebSphere MQSeries

It is recommended that you create a dedicated file system for the queue managers on each node. You can set up WebSphere MQSeries as:

• A WebSphere MQSeries cluster parallel to the WebSphere cluster
• A central queue manager accessed through the WebSphere MQSeries client interface

You must install WebSphere MQSeries on each machine in the WebSphere cluster and create two queue managers for each application server in this cluster. One of these queue managers owns the process queues. This queue manager is used by the process engine to get messages (receive from). The other queue manager has no queues. It is used by the process engine to put messages on (send to). Each queue manager in the WebSphere MQSeries cluster must have a unique name.

All the queue managers used by the application servers in the WebSphere cluster must be in the same WebSphere MQSeries cluster. At least one of these queue managers must host the WebSphere MQSeries cluster repository. To avoid a single point of failure, it is recommended that you define another queue manager to host a second repository. You can choose any queue manager to be the second repository. This queue manager should be located on another node.

Communication in the WebSphere MQSeries cluster is done through channels. Each queue must have a unique port assigned to it. It is recommended that you use unique ports throughout the WebSphere MQSeries cluster. Figure 7 shows the channels required for a WebSphere MQSeries cluster with three application servers, six queue managers, and one repository.

If you define a second repository, this increases the number of available sender channels. Figure 8 shows WebSphere MQSeries clustering with a second repository.

To set up WebSphere MQSeries:

1. Change a queue manager to hold a repository:

   ALTER QMGR REPOS('<ClusterName>') REPOSNL(' ')

   
   
2. Allow remote administration of queue managers. This step is optional but remote administration can be useful for complex configurations:

   DEFINE CHANNEL('SYSTEM.ADMIN.SVRCONN') TYPE(CHLTYPE)

   
   
3. Define a cluster receiver for each queue manager:

   DEFINE CHANNEL('TO.<QueueManager>.TCP') + CHLTYPE(CLUSRCVR) + CLUSTER('<ClusterName>') + CLUSNL(' ') + CONNAME('<TCP/IP-addr>(<TCP-Port>)') + DESCR('Cluster receiver channel at <QueueManager> TCPIP') + MAXMSGL(4194304) + TRPTYPE(TCP) + MCAUSER('<Principal>') + REPLACE

   
   
4. Define a sender channel from each queue manager to each repository queue manager. Do not define a sender channel from the repository queue manager to itself.

   DEFINE CHANNEL('TO.<TargetQueueManager>.TCP') + CHLTYPE(CLUSSDR) + CONNAME('<TargetTCP/IP-addr>(<TargetTCP-Port>)') + CLUSTER('<ClusterName>') + CLUSNL(' ') + DESCR('Cluster sender channel to <TargetQueueManager> TCPIP') + MAXMSGL(4194304) + TRPTYPE(TCP) + MCAUSER('<TargetPrincipal>') + REPLACE + NPMSPEED (NORMAL)

   
   
5. Start a listener for each queue manager. You can start a listener manually:

   runmqlsr -t tcp -p <port> -m <QueueManager>

   
   

When all the defined cluster channels are running, the cluster is operational. To check the status of the channels, use the MQ command:

display chstatus(*) 
     

This requires a dedicated WebSphere MQSeries server with a central queue manager. This queue manager is responsible for both the "put" and the "get" messages.

To set up a central queue manager:

1. Copy the script $WAS_HOME/ProcessChoreographer/createQueues.sh on UNIX (createQueues.bat on Windows platforms) from a WebSphere Application Server Enterprise node to the WebSphere MQSeries server.
2. Run the createQueues script with the name of the queue manager.
3. Add a listener:
   • On UNIX, add a dedicated port for the new queue manager to the file /etc/services:

     <Service:Name> <port>/tcp <Service:Name> name of the queue manager service <port> port for the queue manager

     
     Add a dedicated port for the new queue manager to the file /etc/inetd.conf

     <Service:Name> stream tcp nowait mqm /usr/mqm/bin/amqcrsta amqrsta -m < QueueManager> <Service:Name> name of the queue manager service (the same as in /etc/ services) <Service:Name> name of the queue manager

     
     
   • On Windows platforms, use WebSphere MQSeries Explorer to add the listener.

4.3. Setting up WebSphere Application Server Network Deployment

The network deployment machine must have access to the databases on the application servers used by Process Choreographer. Because network deployment nodes and application server nodes are typically distributed on different machines, the database must be accessed remotely from the network deployment machine. The way in which the database is accessed depends on the database system you use.

• For DB2, the database must be catalogued and accessed via an alias name.
• For Oracle, TNS (TCP net service name) is used to access the database.
• For Sybase, the node that hosts the database is the key to access the database.

For all database systems, the database must have a unique name in the cell so that it can be accessed. This name must also be the same on the network deployment node and the corresponding application server.

Note: You must add the fully-qualified path names of all the database drivers, for example, db2java.zip for DB2 to the classpath of the network deployer process.

Refer to the WebSphere Application Server InfoCenter for other setup information.

4.4. Configuring Process Choreographer

Before you can work with business process applications on a WebSphere application server, you must configure the business process container. The configuration creates the entries on the application server that are needed to access the database and the queues.

You must configure a business process container for each stand-alone application server and for each cluster in the cell where you want to run process applications. Each business process container is independent from the others in the cell. Therefore each business process container needs its own database. This means that there must be a Process Choreographer database for each stand-alone application server and for each cluster.

You can configure a business process container in the following ways:

• Use the installation wizard. This is the recommended way to configure a business process container. The wizard guides you through most of the configuration steps. However, it does not cover the creation of the physical resources. You have to configure all the application servers in a cluster separately, although all the configured objects in a cluster must be identical. For example, the JNDI name for the data source of your cluster must be the same on all cluster members.
• Use the scripts provided in the Process Choreographer directory to create the resources used by the business process container, such as JDBC providers, data sources, listener ports, and message destinations. Default values are documented in the WebSphere Application Server InfoCenter.
• Configure a stand-alone application server, including the business process container, as described in the WebSphere Application Server InfoCenter. Add this application server to a cell. You can now use this application server for cloning.

The naming conventions for business process containers depend on whether the container is installed on a cluster or a node. For a cluster, BPEContainer_<clusterName> is used and for a node BPEContainer_<nodeName><serverName> is used. These are the names that are shown in the administrative console.

If you need to uninstall a business process container from an application server or a cluster, ensure that there are no business process applications installed on that application server or cluster. If business process applications are still installed, the uninstall will fail.

Back to top

5. Verifying the installation

To verify that Process Choreographer is installed correctly in the distributed environment:

1. Install the travel booking sample. Use the administrative console to install the following files. The files must be installed in the order shown:
   1. SamplesGallery.ear
   2. TravelBooking.ear
   3. TravelBookingSamp.ear
2. Run the travel booking sample.

   To run the sample, start a Web browser with the URL http://<hostname<:<port</TravelBooking/ and follow the instructions on this page.

Back to top

6. Managing business process applications

Business process applications contain the business processes. The additional considerations for managing business process applications in a distributed environment are described here.

6.1. Installing a business process application

When you install a business process application, you add configuration data to the WebSphere configuration repository and process meta data to the Process Choreographer databases.

A business process application consists of at least one FAR file and at least one WAR file or EJB jar. You install these applications in the same way as other J2EE applications; use either the administration scripts or the application install windows on the administrative console. However, because FAR files are not J2EE modules, they do not appear on the application install windows.

Currently, all the FAR files belonging to your business process application are distributed to the application servers and WebSphere clusters where you install any of the EJB jars or WAR files belonging to your application. It is recommended that you install all your modules on the same application servers and WebSphere clusters. As a consequence, you must configure business process containers on all these application servers and WebSphere clusters.

If you want to separate WAR files from the FAR files of your application, put them in a different EAR file and install this file separately. You cannot separate EJB jars from FAR files.

When you install a process application, all the stand-alone servers and at least one application server of each WebSphere cluster where you want to install the application modules must be running. The corresponding database servers must also be running.

If only some of the required servers are available at installation time, install the application on the servers and WebSphere clusters that are running. You can map the application to further servers and WebSphere clusters later. See Editing a business process application for information on how to do this.

6.2. Uninstalling a business process application

When you uninstall a business process application, you remove it from the all the servers and WebSphere clusters on which it is installed. If you want to remove the business process application from selected servers or WebSphere clusters only, use application editing.

To uninstall a business process application in a distributed environment:

1. Ensure that all the stand-alone servers, at least one application server per cluster, and the corresponding database servers are running.
2. Stop all process templates belonging to the application. This stops the process template on all the application servers and WebSphere clusters on which the the application is installed.
3. Remove all instances of the process templates.
4. Uninstall the business process application.

6.3. Editing a business process application

When you edit a business process application, you change the mapping of the application modules to the application servers and WebSphere clusters in the cell. You can use the administrative console or administration scripts to change this mapping.

Only the EJB modules and Web modules appear in the administrative console. If you change the mapping of your EJB or Web modules, the mapping of the process modules (FAR files) is changed accordingly.

During the editing of a business process application, the following restrictions apply:

• If you remove the mapping of a module to an application server or a WebSphere cluster, then the process templates of that application must be stopped and all instances of the templates must be removed from the database belonging to the corresponding application server or WebSphere cluster.
• All application servers and at least one member of each WebSphere cluster that you want to change (remove or add) must be running. The associated database servers must also be running.

Resources

• IBM WebSphere Business Integration Information Center
  
  

About the authors

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• 1. Introduction
• 2. Network deployment scenarios for Process Choreographer
• 3. Installing a distributed environment for Process Choreographer
• 4. Configuring the components in the distributed environment
• 5. Verifying the installation
• 6. Managing business process applications
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers