If you choose a Complete (default) installation for WebSphere Process Server,
you get a single-server bus environment. If this is not adequate for your
service applications, you can create a bus environment that includes a choice
of bus topologies including a multiple-server bus in a deployment manager
cell, several single-server buses that use different servers, and other buses
for serving applications or linking to WebSphere MQ.
Why and when to perform this task
If you choose a Complete (default) installation for WebSphere Process Server, you get a stand-alone node in its own administrative domain, known as a cell.
The node hosts one server that is assigned to the SCA.SYSTEM bus for the cell,
for you to deploy SCA modules.
If your SCA modules only need one server,
you can use the SCA.SYSTEM bus of the Complete (default) installation. If
your service applications need more than one server, you need to choose between
a variety of bus topologies.
You should choose the bus environment needed
for an
enterprise service bus before
deploying SCA modules, because it affects installation-related actions, including
what
WebSphere Process Server profiles
you need to create, and what databases you want messaging engines to use.
- You can install WebSphere Process Server with
the default stand-alone server profile, start with the SCA.SYSTEM bus provided
then, if needed, later create a deployment manager profile and profiles for
managed nodes, for a more advanced bus environment.
- To use more than one server in your bus environment, you need to use a
profile for a managed node in a deployment manager cell.
- You might choose your bus environment before installing WebSphere Process Server,
then install the profiles that you need to best support your chosen bus environment.
Besides using the SCA.SYSTEM bus provided for SCA modules, you
can create other application servers and service integration buses to
support other applications and modules, or to connect to WebSphere MQ networks.
This set of topics is mainly focused on using the SCA.SYSTEM bus to support
SCA modules.
Information about using other service integration buses,
as in WebSphere Application Server Network Deployment,
version 6,
is provided by links into the WebSphere Application Server topics.
To
choose a bus environment, consider the following points and the descriptions
of bus topologies given in the sub-topics referred to below.
Steps for this task
- Consider the number of client connections and the throughput that
you want for modules deployed to a bus.
The aim is to identify
the point at which the performance of the modules, as perceived by the clients,
starts to deteriorate:
- The number of concurrent client connections to the bus beyond which the
performance starts to deteriorate when new client connections are made.
- The number of requests and replies flowing through a messaging engine
beyond which the performance starts to deteriorate when new attempts are made
to send requests through the messaging engine.
It is not possible to give a specific formula that applies to
all environments, because it depends on the characteristics of the host on
which the server runs, the nature of the modules deployed, and other factors.
If
you use a single-server bus and observe that the number of client connections
is causing a deterioration in performance, or that the throughput starts to
deteriorate, you can increase the capacity of the bus environment in several
ways:
- In a stand-alone profile, you might create several single-server buses
using the same server. This enables the client connections to be distributed
across several buses, but the throughput of requests still depends on the
one server.
- For greater capacity of client connections and request throughput, you
might use multiple servers distributed across several buses. (To use multiple
servers distributed over one or more buses, you need to have a server profile
for a managed node in a deployment manager cell.)
- Consider the size of requests flowing through a messaging engine.
Every messaging engine manages two memory buffers that contain requests
and request-related data. If there is not enough space when the messaging
engine attempts to add data to a buffer, the messaging engine might discard
data already in the buffer to make space.
You might observe that a running
messaging engine discards data from its buffer more often than
is acceptable. In this case, you might add another server to the bus, to provide
another messaging engine. Alternatively, you might choose to create several
single-server buses that use different servers as their bus members. The messaging
engine in each server uses a separate set of memory buffers, and a separate
data store. (To use multiple servers distributed over one or more buses, you
need to have a server profile for a node in a deployment manager cell.)
- Consider if you want to use different qualities of service for
your service applications.
Each bus has a unique configuration
of qualities of service and other properties. You might choose to create several
buses and configure them with different qualities of service, then deploy
each of your modules to the bus that has a suitable configuration.
- Consider other reasons for using multiple servers within a bus.
A
service integration bus consisting
of just one server is adequate for some applications. However, there are advantages
in using more than one server in a bus (with each server providing a messaging
engine):
- Spreading messaging workload across multiple servers.
- Placing request processing close to the requester applications, so as
to reduce network traffic. For example, if the sending and receiving applications
are running in the same server process it would be inefficient to route all
the requests that flow between them through a messaging engine running in
a remote server.
- Improving availability in the face of system or link failure. This includes
removing a single point of failure, and allowing store and forward between
two servers should this be required.
- Providing improved scalability
- Accommodating firewalls or other network restrictions that limit the ability
of network hosts to all connect to a single messaging engine.
- Consider other reasons for using a multiple SCA.SYSTEM bus environment.
Because each service integration bus has
a separate configuration, you might choose to have several buses each with
a different configuration suitable for separate modules; for example, you
might have some buses for a production environment with security, and other
buses for testing without security.
You might also choose to create
several buses to separate the administration of modules; for example, separate
administrative cells and their SCA.SYSTEM buses might be used for different
departments within organizations, or perhaps to separate test and production
facilities.
Besides the SCA.SYSTEM buses, other buses might be created
for other application use, and can be connected to allow messaging across
the buses. Buses in different organizations can also be connected. When buses
are interconnected, applications can send messages to applications on other
buses, and use resources provided on other buses. Published messages can also
span multiple buses, if the links between the buses are configured to allow
it.
- Consider reasons for using non-SCA service integration buses.
Besides the SCA.SYSTEM bus used for SCA modules, you can also create
other service integration buses that
you can use to support the service integration logic provided by the modules.
For example, the SCA.APPLICATION.cell_name.Bus is provided
and used to define JMS queue destinations and other JMS resources for modules
deployed with JMS bindings.
You can create other buses for use as in WebSphere Application Server, for
applications acting as service requesters and providers within WebSphere Process Server,
or to link a bus to WebSphere MQ. You can also use a WebSphere Process Server deployment
manager to manage separate application servers, for use with applications
and modules deployed onto WebSphere Application Server.
- Consider if you want application servers that do not support SCA
modules.
A WebSphere Process Server deployment
manager cell can include application server nodes that run WebSphere Application Server servers.
You can use these application servers for applications and modules supported
by WebSphere Application Server.
You do not need to add the application servers into a service integration bus,
unless you want to exploit the service integration technologies of WebSphere Application Server.
Last updated: Wed 06 Dec 2006 07:08:08
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)