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.
The following capabilities are provided by a service integration
bus:
- 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 may 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.
Through the service integration
bus Web services enablement (SIBWS), you can achieve the following goals:
- You can take an internal service that is available at a service destination, and make
it available as a Web service.
- You can take an external Web service, and make it available at a service
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.