Interconnected buses
A service integration bus topology can contain many interconnected service integration buses to form a large messaging network. The bus an application connects to is called its local bus. There can be connections from that local bus to other service integration buses, which are called foreign buses. Buses can also be linked to IBM MQ resources, for example IBM MQ queue managers. IBM MQ resources are also regarded as foreign buses.
A bus must be contained in a single cell; that is, a bus cannot span multiple cells. However, a cell can contain more than one bus. In this situation, each bus in the cell is foreign to each other bus in the cell. We can connect buses together in a cell, or between different cells.
The following scenarios are examples of situations when we might connect service integration buses in an organization:
- We can deliberately separate the messaging infrastructure to aid management.
- We can restrict access to certain messaging resources within a single WebSphere Application Server cell, because a cell can contain multiple service integration buses.
- We can span multiple administrative cells, by connecting a service integration bus in one cell to a service integration bus in another cell.
When buses are connected, applications can send messages to applications on other buses, and use resources provided on other buses. Published messages can span multiple buses where the connections between the buses are configured to allow it.
To create a connection between two buses, the administrator of the local bus configures a foreign bus connection that represents the second bus, and associated with the local bus. The foreign bus connection contains a routing definition, or virtual link. A physical link, called a service integration bus link, is created automatically. The link is from a messaging engine in the local bus to a messaging engine in the foreign bus, and these two messaging engines are known as gateway messaging engines. The administrator of the second bus also configures a foreign bus connection to represent the first bus, as a property of the second bus.
To create a link between a bus and an IBM MQ queue manager, the administrator of the local bus configures a foreign bus connection that represents the IBM MQ queue manager, as a property of the local bus. The foreign bus connection contains a routing definition, or virtual link. A physical link, called a IBM MQ link, is created automatically. The link is from a messaging engine in the local bus to a queue manager or queue sharing group in the foreign bus. The messaging engine is known as a gateway messaging engine, and the queue manager or queue sharing group is known as the gateway queue manager.
Figure 1. Service integration buses are connected through service integration bus links
Routing between buses
The route between two buses can be indirect, passing through one or more intermediate foreign buses. In Figure 1, Bus 1 is connected to Bus 5 indirectly. For more information about direct and indirect routing between service integration buses, refer to the subtopics.
For more information about foreign buses, see Foreign buses. For conceptual overviews of point-to-point and publish/subscribe messaging, see Point-to-point messaging across multiple buses and Publish/subscribe messaging across multiple buses.
Security when connecting buses
A multiple bus topology has the following security requirements:
- We must protect the integrity and confidentiality of the data that is transported between the buses. We can protect the communications links using an SSL. For more information, see Protecting messages transmitted between buses.
- We must establish trust between two buses. Trust between messaging engines at WAS v7.0 or later is established using a LTPA token, and no further
configuration is required.
If the bus has a WAS v6 bus member (that is, a mixed-version bus), trust is established using an inter-engine authentication alias. The inter-engine authentication alias is configured when we add a member to a bus or with the bus security settings. The identity is passed to the remote bus where the identity is authenticated, then checked to see if it matches the configured inter-engine authentication alias on the other bus.
- We need the definition of relevant authorizations to allow messages
to travel between the buses. There are two phases to authorization
when communicating with a foreign bus:
- The user that is 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 be configured to accept the incoming message onto the target destination.
For more information about security, see Service integration security and Secure access to a foreign bus.
Connect buses in different cells
To connect a local bus to a foreign bus in a different cell from the local bus, provide a value for one or more bootstrap endpoints, that is, the host, port location, and transport chain for the messaging engine on the foreign bus that the local service integration bus connects to.
Connect buses with cluster bus members
To connect a local bus to a foreign bus in a different cell from the local bus when the remote messaging engine is in a cluster, change the value for the bootstrap endpoints. This value must list all the bootstrap endpoints that the cluster uses to allow access to the gateway messaging engine in the cluster.
See steps relating to setting bootstrap endpoints in Configure a connection to a non-default bootstrap server.
Subtopics
- Foreign buses
We can configure a service integration bus to connect to, and exchange messages with, other messaging networks. To do this, we configure a foreign bus connection, which represents either another service integration bus, or an IBM MQ queue manager or (for IBM MQ for z/OS) queue-sharing group, that the existing service integration bus can exchange messages with. In this way, we can extend the network of buses that can exchange messages. - Point-to-point messaging across multiple buses
Point-to-point messaging uses queue destinations, where each queue destination represents a message queue. - Publish/subscribe messaging across multiple buses
In service integration, publish/subscribe messaging uses topic space destinations, where each topic space destination represents a set of "publish and subscribe" topics. When multiple buses are connected using a service integration bus link, messages published in a topic space in one bus are accessible to subscribers on a topic space in another bus. - Bus topology that links to IBM MQ networks
Service integration buses can link to IBM MQ networks. Applications connected to an IBM MQ queue manager or queue-sharing group can send messages to an application that is attached to a service integration bus, and vice versa. - Direct and indirect routing between service integration buses
Use direct or indirect connections to interconnect service integration buses so that all the buses can exchange messages.
Related: