This topic provides information about the service integration
topologies that you can configure. A service integration topology
can range from a single host running two connected applications to
a globally-dispersed set of hundreds or thousands of communicating
applications running over the bus.
A service integration topology is based on one or more service
integration buses that provide a managed communication fabric that
supports service integration through synchronous and asynchronous
messaging.
A service integration bus supports
applications using message-based and service-oriented architectures.
A bus is a group of one or more interconnected servers that have been
added as members of the bus. Applications connect to a bus at one
of the messaging engines associated with its bus members.
A service integration bus provides the following
capabilities:
- Any application can exchange messages with any other application
by using a destination to which one application sends,
and from which the other application receives.
- A message-producing application, that is, a producer,
can produce messages for a destination regardless of which messaging
engine the producer uses to connect to the bus.
- A message-consuming application, that is, a consumer,
can consume messages from a destination (whenever that destination
is available) regardless of which messaging engine the consumer uses
to connect to the bus.
The service integration bus is sometimes referred
to as the messaging bus if it is used to provide the
messaging system for JMS applications using the default messaging
provide.
Many scenarios require a simple bus topology; perhaps,
for example, a single server. By adding multiple servers to a single
bus, you can increase the number of connection points for applications
to use. Servers,
however, do not have to be bus members to connect to a bus. In more
complex bus topologies, multiple buses are configured, and can be
interconnected to form complex networks. An enterprise might deploy
multiple interconnected buses for organizational reasons. For example,
an enterprise with several autonomous departments might want to have
separately administered buses in each location.
With bus-enabled Web services
you can achieve the following goals:
- Create an inbound service: Take an internally-hosted
service that is available at a bus destination, and make it available
as a Web service.
- Create an outbound service: Take an externally-hosted
Web service, and make it available internally at a bus destination.
You can change the service integration topology to suit your needs;
for example:
- You can add application servers as new bus members. Each new bus member is automatically
assigned a messaging engine, with default data source, and a default
exception destination. The messaging engines can communicate with,
and use resources provided by, all other messaging engines on the
bus.
- You can change the configuration of the data source for a messaging
engine, for example to use a different JDBC provider.
- You can create new buses and add application servers as members of
those buses. Each bus operates as a separate environment, unless connected
by a gateway messaging engine.