An initial network deployment configuration consists of
a deployment manager server that has a daemon for the z/OS® system
on which the deployment manager runs. After a network deployment cell
is created, you can add application server nodes by creating and federating
new empty managed nodes, or by federating stand-alone application
server nodes into the network deployment cell.
To install WebSphere® ESB into
a network deployment environment, you must configure both a deployment
manager node and an empty managed node before federation. Then to
perform federation you run the job BBOWMNAN. When you federate an
empty node to the deployment manager it becomes a managed node because
it is being administered by the deployment manager. The managed node
contains a node agent but no application servers. You can add an application
server or cluster to the node with the administrative console.
The deployment manager runs the administrative console applications
and is used for centralized administration tasks, such as managing
the configuration of all of the managed nodes in its cell and deploying
applications to selected servers and clusters in the cell. The deployment
manager runs on one node, and application servers run in different
nodes.
A basic network deployment configuration is made up of the following
components:
- A deployment manager server running in a separate node that runs
the administrative console application, which you can use to deploy
applications.
- One or more application server nodes on each z/OS® target
system hosting portions of the cell. Each node consists of a node
agent and some number of application servers. Each node must be federated
into the deployment manager cell.
- A single location service daemon on each z/OS system.
One daemon server must exist for each cell, which runs constantly,
checking and distributing server workload.
- A DB2® database. DB2® Universal Database™ version
8.1 is the default database type for network deployment environments.
The following figure shows a network deployment configuration
that consists of a deployment manager server that has a daemon for
the z/OS system on which the deployment manager
runs. The deployment manager is administering four servers, A,B,C,
and D via two node agents:

You must have the following configured before you can create a
network deployment topology:
- WebSphere Application Server
for z/OS must be
configured on the server with a deployment manager node and an empty
managed node that has not been federated to the deployment manager.
It is important that the empty managed node is not federated before
running the installation script. You will federate the node after
you have augmented it to contain WebSphere ESB for z/OS configuration
data.
- Your UNIX® user ID must have permission to access the UNIX® shell
because this is where you run the installation and augmentation scripts.
Providing access involves making modifications to your RACF® (security)
profile and creating a home directory within the UNIX shell.
The home directory is where you begin a UNIX session,
and where you store environmental variable files that are required
to run programs. You can also use the home directory as the main directory
for keeping your work data.
- The WebSphere ESB for z/OS product
code must have been loaded onto the system from tape, so you can use
it to install and configure WebSphere ESB for z/OS.
When configuring a deployment manager node, keep the following
in mind:
- When allocating target data sets it is possible, though not recommended,
to use the same target data sets that you may have used for a stand-alone
application server node. The job names for each configuration are
very similar to one another, and if you use the same target data sets,
you may find it difficult to keep the two sets of jobs separate. Therefore,
create a new set of target data sets for the deployment manager node
and keep the two sets of jobs separate from one another.
- Share the root of the file system across all processors apart
from the configuration of the deployment manager in a file system
on a generic system mount point.
It is very important that you plan your WebSphere Process
Server for z/OS configuration before you start, especially
when configuring a network deployment cell. There are many choices
and you must understand the factors that influence these choices to
make the correct decisions during the installation process.
Advantages of a network deployment configuration- One of the main advantages of a network deployment configuration
is availability. When the configuration contains multiple LPARs, you
can reduce single points of failure and maintain availability during
planned and unplanned outages.
- You can configure how messages are delivered. For example, you
can specify secure assured delivery where messages are assured not
to get lost and are transported securely, or best-effort where messages
might get lost in case of a system failure.
- You can set up a network deployment cell to have several servers
that host mediation modules. Mediation modules provide scalability
(the ability to handle more client connections) and greater message
throughput.
- You can create server clusters. With server clusters you can manage
a group of servers together and enable those servers to participate
in workload management.
- Your bus environment might be made up of several stand-alone and
deployment manager profiles, to provide separate administrative domains
for different departments or to separate test and production facilities.
Each profile has its own SCA.SYSTEM service integration bus.