If you choose a Complete (default) installation for WebSphere ESB,
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 ESB, 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 ESB profiles
you need to create, and what databases you want messaging engines to use.
- You can install WebSphere ESB 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 ESB,
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,
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.
Alternatives 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.
When using a bus, you might
observe that the size of requests causes a messaging engine to discard data
already in a buffer more 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 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 ESB,
or to link a bus to WebSphere MQ. You can also use a WebSphere ESB 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 ESB 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.