Service integration configurations

A service integration configuration 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 configuration is based on one or more service integration buses that provide a managed communication fabric that supports service integration through asynchronous messaging.

A bus is a group of one or more interconnected bus members, each of which is an application server or an application server cluster. 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 applications send and receive messages.

• An application can produce messages for a destination regardless of which messaging engine the producer uses to connect to the bus.

• An application 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 the default messaging provider for JMS applications.

Many scenarios only require a simple bus configurations, for example, a single server. If we add multiple servers to a single bus, you increase the number of connection points for applications to use. If we add server clusters as members of a bus, we 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 configurations, 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 independent departments might want a separately administered bus in each location.

With bus-enabled Web services we 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.

We can change the service integration configuration to suit your needs, for example:

• We 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.

• We can change the configuration of the data source for a messaging engine, for example to use a different JDBC provider.

• We 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.

• We can connect a message-driven bean to consume messages from a destination on a remote cell.

Subtopics

• Bus configurations
  We can connect buses in different ways depending on the requirements. For example, we can link messaging engines to distribute message workload, and to provide availability if there is a system failure.

• Bootstrap members
  An application inside a client container or application server outside the cell, cannot connect directly a bus inside the cell. This is because the client container or application server outside the cell, does not have access to cell configuration information. Therefore, to connect to a bus, the application must bootstrap to an application server inside the cell. That application server identifies a server inside the cell that is a bus member. Then, the client or application server outside the cell, will be able to connect to the bus inside the cell. A bootstrap member is an application server or cluster configured to accept requests to bootstrap into the service integration bus. The bootstrap member authenticates a connection request, and directs the request to a suitable bus member. The administrator configures the bootstrap member policy for the bus to determine which types of server can service requests to bootstrap.

Related tasks

Configure a connection to a non-default bootstrap server

Service integration custom properties

Related information:

JMS activation specification [Settings]