WebSphere WebSphere Application Server Version 6.1.x Feature Pack for Web Services Operating Systems: AIX, HP-UX, i5/OS, Linux, Solaris, Windows, z/OS

Multiple bus topology

A service integration bus messaging topology can contain multiple interconnected service integration buses. For each bus in the topology, the other buses that are connected to it via a link are its foreign buses. It is also possible to connect service integration buses with a collection of WebSphere MQ resources such as WebSphere MQ queue managers. The WebSphere MQ resources are regarded as foreign buses.

A bus must be contained within a single cell; that is, a bus cannot span multiple cells. However, a cell may contain more than one bus. In this case, each bus in the cell is foreign to each other bus in the cell. You can connect buses together within a cell, or between different cells. Regardless of where a bus exists, if one bus is foreign to the other, a foreign bus link must be created in both directions.

You may want to connect service integration buses in the following scenarios:

When buses are connected using a foreign bus link, applications can send messages to applications on other buses, and use resources provided on other buses. Published messages can span multiple buses where the links between the buses are configured to allow it.

To create a link between two buses, the administrator of the local bus creates a foreign bus that represents the second bus, as a property of the local bus. The administrator of the second bus also creates a foreign bus to represent the first bus, as a property of the second bus. Each administrator then creates a virtual link and a physical link (called a service integration bus link) from the local bus to the foreign bus.

Figure 1. Service integration buses are connected via service integration bus linksFive service integration buses are connected using service integration bus links.

Routing between buses

The route between two buses can be made indirectly, through one or more intermediate foreign buses. In Figure 1 Bus 1 can be connected to Bus 5 indirectly. For a conceptual overview of the two methods, refer to Direct and indirect routing between service integration buses.

For more information about foreign buses see Foreign buses. Conceptual overviews of achieving point to point and publish subscribe messaging can be found in Point-to-point messaging across multiple buses and Publish/subscribe messaging across multiple buses.

Security considerations

When connecting buses note the following security considerations:
  • Integrity and Confidentiality of the data being transported between the buses. Integrity and Confidentiality can be easily established by protecting the communications links with SSL. For more information see Protecting data transmitted between linked buses.
  • Trust establishing trust between the two buses. Trust is established by the use of an inter-bus authentication alias. This is configured on the service integration bus link. The identity is passed to the remote bus where the identity is authenticated, then checked to see if it matches the configured inter-bus authentication alias on the other bus.
  • Authorization defining the relevant authorizations to allow messages to travel between the buses. There are two phases to authorization when communicating with a foreign bus:
    • The user connected to the local bus has to be explicitly granted access to send messages to the foreign destination, failure at this level is reported back to the client.
    • The foreign bus must then be configured to accept the incoming message onto the target destination.
For more information about security, refer to Security considerations for service integration buses and Securing access to a foreign bus.

Considerations with buses with clustered bus members

If you want to connect your local bus to a foreign bus, and the remote messaging engine is in a cluster, you must change the bootstrap endpoint value. It should list all bootstrap endpoints used by the cluster to allow access to the messaging engine.

For more information, see steps 1 and 2 of Configuring a connection to a non-default bootstrap server. Although this task primarily describes how to configure a JMS connection factory, it is also applicable to setting several bootstrap endpoint values if the remote messaging engine is in a cluster.

Considerations with connecting buses in different cells

There is no difference in how you set up the link for buses within the same cell or in different cells. In both cases, you provide values for the bootstrap endpoints. In the first case, you provide the host name of a node with a server in the same cell, and in the other case the host name of a node with a server in a different cell.

Related tasks
Planning a bus topology
Planning issues common to all bus topologies
Planning a multiple-server bus without clustering
Planning a multiple-bus topology
Planning a topology that includes WebSphere MQ
Connecting buses

Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 27 November 2008
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.wsfep.multiplatform.doc/concepts/cjj0004_.html

Copyright IBM Corporation 2004, 2008. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)