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.

The topic for a specific message (publication) is a property of the message. A service integration topic space destination is not localized in a particular bus member. Service integration maintains a list of subscriptions in the topic space and matches each publication against that list. When a new publication matches one or more subscriptions in the topic space, service integration delivers a copy of the publication to each subscriber; if necessary, service integration can queue the publication message until the subscriber is ready to receive it. When the new publication does not match any subscription, service integration discards the publication.

Subscribers can receive topics published in a remote bus, as long as a connection between the buses is configured. We can configure a bus to connect to, and exchange messages with, other messaging networks. To do this, configure a foreign bus connection. A foreign bus connection encapsulates information related to the remote messaging network, such as the type of the foreign bus and whether messaging applications are allowed to send messages to the foreign bus.

To connect topic space destinations in neighboring buses, you configure topic space mappings when creating a foreign bus connection. Each entry in the mapping maps a local topic space destination to a topic space in the foreign bus. Then, any subscribers to topics on the topic space in the local bus can receive messages published on those topics in the topic space in the foreign bus. Publish/subscribe applications create producers and subscriptions to topic spaces in their local bus rather than the foreign bus (unlike point-to-point applications and queue destinations). We must configure the topic space mappings so that the messages that the applications publish are routed correctly.

In the following figure, a subscriber in Bus 1 can receive messages published in Bus 2. A topic space mapping in Bus 1 enables publications from publishers attached to Topic space 2 in Bus 2 to flow to subscriptions attached to Topic space 1 in Bus 1.

Figure 1. Publish/subscribe messaging across Bus 1 and Bus 2

If subscriptions exist in both buses and publishers can publish from either bus, a topic space mapping is required in both buses to enable publications to flow between all publishers and subscribers in the two buses.

When connecting topic spaces in more than two buses, there is no restriction on how multiple buses can be connected. However, there is a restriction on how their topic spaces are connected using topic space mappings. For guidance on how to create topic space mappings, see Configure topic space mappings between service integration buses.

The names of the local and foreign topic spaces do not have to match, but the names of the topics in the local and foreign buses do have to match.

A network of buses can contain loops in its topology, as shown in Figure 2. Interconnected topic spaces must follow a hierarchical tree formation. This tree can then be overlaid on the underlying bus topology by using topic space mappings, as shown in Figure 2. It is not permitted for a set of interconnected topic spaces to form a loop across multiple buses, as shown in Figure 3.

Figure 2. Network of buses with topic spaces connected correctly

Figure 3. Network of buses with topic spaces connected incorrectly

The correct example in Figure 2 shows that messages published in Bus 2 are automatically flowed through Bus 1 to Bus 3, if Bus 3 has a suitable subscription for those messages. We create a mapping from the topic space in Bus 1 to the topic space in Bus 2, and another mapping from the topic space in Bus 3 to the topic space in Bus 1.

If we also created a mapping from the topic space in Bus 2 to the topic space in Bus 3, as shown in Figure 3, you would create a loop and published messages might enter an indefinite loop and be transmitted continually around the three buses.

If an additional subscription for the messages exists in Bus 2 and a publisher is also connected to Bus 3, topic space mappings are required in the reverse direction to allow messages to flow to all subscriptions in the system, as shown in Figure 4.

Figure 4. Network of buses with topic space mappings in both directions