Servers can be configured in different topologies, and the installation
procedure you use varies according to the type of topology you select. To
help you decide which installation method is best for you, four common topologies
are described, along with diagrams and detailed steps to guide you through
the installation procedure.
WebSphere Process Server includes server
software and client software. You must install the server software, but the
client software is optional. Typically, you install the Message Service Client
software on systems where you have C, C++, or .Net messaging applications
or C++ Web services running.
Establishing the server environment for
WebSphere Process Server involves:
- Installing a set of core system files called system files. These
system files include command files and other product binary files. System
files can be updated by installing refresh packs or fix packs.
- Configuring either a stand-alone profile or a number of managed profiles
(in a network deployment environment). Each profile provides a separate runtime
environment for the server processes that are defined to it. During management
and running of these servers, the configuration files, data files, and log
files can be created, read, updated, or deleted, but there is only read access
to the system files. When you use a refresh pack to update a set of system
files, then all of the profiles associated with the installation will begin
using the updated files as they are started.
Figure 1. Separation of system files and profiles
You can install the WebSphere Process Server system
files once and then create multiple profiles on the same system. Or, you can
install multiple separate versions of the product, each with its own profiles,
on one or more systems. The product files are installed in the installation
root (WebSphere Application Server_HOME). In some environments,
the distinction is made between the directory for the core product files (WebSphere
Application Server_INSTALL_ROOT) and the directory for the profile
files (USER_INSTALL_ROOT).
WebSphere Process Server is
built on WebSphere Application Server Network Deployment,
version 6.
You can augment WebSphere Application Server profiles
to become WebSphere Process Server profiles,
converting from a WebSphere Application Server scenario
to WebSphere Process Server,
for deployment manager and stand-alone profiles; custom profiles can be converted
only if they have not been federated.
You begin the installation for
each topology by performing either a Complete or a Custom installation (by
selecting
Complete or
Custom on
the Installation type panel in the installation wizard). A Complete installation
installs the system files and automatically creates a default stand-alone
server profile with a samples gallery. A Custom installation installs the
core product files but does not create a stand-alone server profile.
Important: This simple installation, described in "Topology 1" below,
is adequate for evaluation or proof-of-concept purposes related to the programming
model. "Topology 4," described later in this topic, is adequate for evaluation
or proof-of-concept purposes related to non-functional requirements such as
availability or scalability.
You can then customize your system
in different ways as described in the following topologies.
Types
of installations
You can install the server on server hardware as
individual
stand-alone servers or as a
managed group of servers.- A stand-alone server profile has its own administrative console
and all sample applications (if you performed a Complete installation or selected
to install the sample applications gallery feature during a Custom installation).
Each stand-alone server is fully operational and is managed independently
from all other servers.
There are two main types of stand-alone server installations:
- One stand-alone server on one system (described in "Topology 1")
- Multiple stand-alone servers on a single installation on one system (described
in "Topology 2")
- A managed group of servers, also known as a cell,
uses a deployment manager for centralized administration tasks, such as managing
the configuration for all of the managed nodes in its cell and deploying applications
to selected managed nodes in the cell. All profiles in the cell share command
files and other product binary files. The main reason to use managed nodes
in a cell rather than using the same number of stand-alone servers is the
centralized administration that the deployment manager provides for the cell.
If
you want to balance workload, such as service requests, over a set of servers,
you can create a server cluster, then add servers as members of that cluster.
You can also create a backup cluster, to provide failover support for the
server cluster to which it is assigned.
There are two main types of
server cell installations:
- Deployment manager and managed nodes (cell) on a single installation on
one system (described in "Topology 3")
- Deployment manager and managed nodes on a single installation on multiple
systems, with a server cluster (described in "Topology 4")
- Topology 1: One stand-alone server on one system
This procedure gives you a stand-alone server profile named default and
a server named server1. This profile is a separate data partition
with files that define the stand-alone server environment.
Figure 2. One
stand-alone server profile on a single server
Complete the following steps to perform a single-server installation
with one stand-alone server:
- Perform a Complete installation. A Complete installation installs the core product files and creates
a stand-alone server profile named default and a server named server1.
- Start server1 by using the First Steps console
or the startServer server1 command.
- Topology 2: Multiple stand-alone servers on a
single installation on one system
You can create several
stand-alone server profiles on the same server.
Each profile can have
unique modules and applications, configuration settings, data, and log files.
You can use multiple profiles to create separate server environments that
you dedicate to different purposes. For example, each stand-alone server profile
can be a separate test environment that you assign to a programmer or a development
team.
Complete the following steps to create multiple stand-alone servers
on one system:
- Perform a Complete installation. A Complete installation installs the core product files and creates
a stand-alone server profile named default and a server named server1.
- Start server1 by using either the First Steps
console or the startServer server1 command.
- Run the Profile wizard to create
another stand-alone server profile on the same system.
- Topology 3: Deployment manager and managed nodes
(cell) on a single installation on one system
You can create
a cell, a group of managed servers, on a single server from one installation
of the core product files. Use the Profile wizard and the deployment
manager to create one or more custom nodes.
The deployment manager
provides administration for all managed nodes in its cell. In a cell, modules
and applications are run by the managed nodes, not by the deployment manager.
Each managed node has a server process, called the node agent,
used by the deployment manager to manage servers on that node. You must start
the node agent before you can start the servers.
Periodically, the configuration
and application files on a managed node are refreshed from the master copy
of the files hosted on the deployment manager. This process is called synchronization.
Figure 3. A managed node in a deployment manager cell
Complete the following steps to create a deployment manager and
managed nodes on a single installation on one system:
- Perform a Custom installation. A Custom installation installs the core product files but does
not create a stand-alone server profile. You will also create databases for
the server repository, for the business process container and the human task
container, and for the messaging engine.
- Run the Profile wizard to create
a deployment manager profile.
- Start the deployment manager using the First Steps console or
the startManager command.
- Use the Profile wizard to create
a custom profile. During profile creation, choose whether to federate the custom node
immediately or at a later time. To federate the custom node later, use the
procedure described in Federating custom nodes to a
deployment manager.
When
you federate a custom node into the deployment manager cell, the node is converted
into a managed node.
In certain secure environments, the Profile wizard
cannot federate a custom profile into a cell. In such cases you must use the addNode command
instead. If you have configured the deployment manager to use a Java management
extension (JMX) connector type other than the default simple object access
protocol (SOAP) connector, use the addNode command to add
the node to the cell.
- Create either a server or server cluster using the default WebSphere
Process Server template.
- Configure the server or cluster. Before
deploying any modules onto the new server or cluster, configure the server
or cluster with the WebSphere Process Server environment by setting up for Service Component Architecture, business process container, human task container, and Common Event Infrastructure.
- Start the server or cluster. You
can use the First Steps console, administrative console, or the startServer server_name command
to start the server. You can use the administrative console to start a server
group.
To create additional managed nodes on the same server, repeat steps 4 through 7 for
each new node.
To add managed nodes on another server in the system,
see "Topology 4."
- Topology 4: Deployment manager and managed nodes
on a single installation on multiple systems, with a server cluster
The primary advantage of a cell over a stand-alone server is single-point
manageability; from one cell you can set up application interactions and also
enable WebSphere Application Server clustering. Access is streamlined; for
example, if you have a deployment manager located on one server, a managed
node installed on another server, and a third server holding a managed node
with a server cluster, you can federate all of the managed nodes into the
same deployment manager cell, as portrayed in the following figure. Scalability
and workload management offer additional benefits.
When you have multiple
servers and multiple managed nodes, you can create multiple managed nodes
on the same server using vertical scaling, and create cell members
on multiple servers using horizontal scaling.
Figure 4. Several managed nodes in a multiple-server deployment manager cell
Complete the following steps to install a cell of managed server
nodes on three servers, with the deployment manager on its own server:
- Perform a Custom installation
on each of three servers. A Custom installation installs the core product files but does
not create a stand-alone server profile.
- Create three databases. You can
create the WebSphere Process Server repository database manually and perform
its schema and table creation tasks during the creation of the deployment
manager profile. You can also create the database by executing the script createDB_supported
database management system.sql found in the directory install_root/dbscripts/CommonDB/dbType. This directory also contains files such as createTable_YYY_XXX.sql,
for creating schemas and tables, although it is simpler to let the Profile
wizard perform these tasks as you create the deployment manager profile. See
the documentation for your database management system for more information
on using the SQL file. You can create the database for the optional messaging engine manually, deferring the task
of schema and table creation to individual messaging engines during their
initial startup. You can create the database for the business process container
and human task manager by following the instructions at Creating the database for the business process
container. You will create the fourth required database, the Common
Event Infrastructure database, in a later step.
- Create a deployment manager profile
on one server (Server A) using the Profile wizard.
- Start the deployment manager using the First Steps console for
Dmgr01 or the startManager command.
- Create one or more custom profiles
on each of the other two servers (Server B and Server C) using the Profile
wizard.
- Federate the nodes.
- Create the necessary server clusters in
the clustered environment. Depending on your network needs, you
might need a cluster for monitored events, a cluster for administration applications,
and a cluster for service applications. After a cluster is created, you can
use the administrative console to configure the cluster.
- Create the Common Event Infrastructure
database.
- Use the administrative console to perform resource creation and configuration tasks specific
to your network. Depending on your network deployment, you might need to:
- Create messaging engine resources: for more information, see Preparing a server or cluster to support
Service Component Architecture applications.
- Configure the WebSphere Process Server support
cluster: configure the business rules manager, install
the application for the Common Event Infrastructure event server and install the application for the Common Event Infrastructure message database
application and configure the JDBC resource create messaging services, and,
if the appropriate failed event destinations have not been already created
and configured, you need to create them from the administrative console by
completing the following steps:
- Expand Service integration and click on Buses.
- Select the SCA.SYSTEM.cell name.Bus bus.
- Under Destination resources, click on Destinations.
- Select the New button:
- In the Create new destination panel, select the Queue radio
button, and then click Next.
- In Step 1, provide WBI.FailedEvent.Deployment Target
Cluster Name as the Identifier,
and then click Next.
- In Step 2, select the Messaging Cluster as the Bus
member, and then click Next.
- In Step 3, click Finish.
- Save and synchronize the configuration change.
- Configure the WebSphere Process Server deployment
target cluster: perform the SCA configuration, configure the Business Process Choreographer, and install the human task manager container.
- Configure the WebSphere Application Server messaging cluster: Add members to the SCA buses.
Before adding any other members, add the Messaging Cluster as
the lone member of the SCA buses that have no members; configure the messaging engines, and pin the messaging engines. You also might need to
perform these procedures for your other messaging engines.
- Restart the deployment manager.
After completing the installation, you will have the appropriate
number of profiles and servers for your topology.
You can run the samples to explore their functions (if you installed
the Sample applications gallery feature). You can also deploy your own mediation
modules, or adapt the server and bus environment to your needs.