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 or server
clusters 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. By adding server clusters as members of a bus,
you can increase scalability and achieve high availability. 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.
With SIBus-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.
- Create a gateway service: Use the Web services
gateway to map an existing service - either an inbound or an outbound service
- to a new Web service that appears to be provided by the gateway.
You can change the service integration topology to suit your needs; for
example:
- You can add application servers or server clusters 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 or
server clusters as members of those buses. Each bus operates as a separate
environment, unless connected by a gateway messaging engine.