WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using a WebSphere MQ link > Publish/subscribe messaging through a WebSphere MQ link
Publish/subscribe messaging through a WebSphere MQ link: example
A publish/subscribe bridge over a WebSphere MQ link enables subscribers on the service integration bus in WAS to receive the same published messages as subscribers in a WebSphere MQ network. The broker profile in WAS allows these two separate publish/subscribe domains to appear as a single entity.
Imagine there are two businesses "GolfStats Inc." and "FootballFansData Inc." that each provide a results and news service for different types of sporting event. Both pay third parties to collect sports information (for golf and football respectively) and publish this data to their IT systems. GolfStats and FootballFansData then charge members of the public a monthly fee in exchange for an application that runs on a desktop computer, which pops up the results as they become available.
GolfStats also use their IT system to host a website and run other business applications, so their IT systems are based on WAS and the service integration bus. However, FootballFansData do not have any other business applications, and they use WebSphere MQ messaging for their publish/subscribe requirements.
Figure 1. Two separate businesses that publish information to their respective audiences.
Figure 1 shows two separate businesses. GolfStats Inc has a third party that connects to their IT systems when a result becomes available and publishes information to a topic space on the topic "sports/golf", which is received by the subscribers subscribing to "sports//.". (//. in the syntax used by the publish/subscribe bridge indicates all sports information). Publish/subscribe messaging in GolfStats Inc is handled by a service integration bus.
Similarly a third party supplier for FootballFansData Inc publishes information to the WebSphere MQ network on the topic "sports/football", which is received by a subscriber application subscribing to "sports/#" (WebSphere MQ syntax for all sports information). Publish/subscribe messaging in FootballFansData Inc is handled by a WebSphere MQ queue manager, which would be viewed by WAS as a foreign bus,although the two systems are not currently connected.
Recently GolfStats and FootballFansData have merged, and the new management want to join the existing IT systems together in order to provide information about golf and football to both sets of customers. One option is to migrate all FootballFansData's IT systems to use the service integration bus. However, this approach requires significant capital investment, as well as upgrading the third party and customer application code to be able to connect to the system. A simpler alternative is to bridge between the two systems using the WebSphere MQ link and a broker profile.
The businesses take the following actions to bridge between the two systems:
- Identify a WebSphere MQ queue manager or (for WebSphere MQ for z/OS ) queue-sharing group, named (for example) QM_GATEWAY on the FootballFansData system, that will act as the gateway to connect to the WebSphere MQ network.
- Configure a Foreign bus connection for the GolfStats service integration bus to enable messages to be exchanged between the bus and the WebSphere MQ network.
- Define a broker profile on the WebSphere MQ link that states the name of the queue manager in the WebSphere MQ network where the messages are published, named QM_TWO in this example.
- Define a topic mapping associated with the broker profile to allow publications to flow between the service integration bus and the WebSphere MQ network. The mapping will be bidirectional on a topic of "sports//.", which allows all publications in the sports branch of the topic hierarchy to be transferred.
When these tasks have been completed, and the application server that hosts the GolfStats service integration bus has been restarted, messages begin to flow between the two systems. This enables the FootballFansData customers to receive information about golf, and the GolfStats customers to receive information about football. The diagram later in this section shows the logical path of a "golf" message published into the GolfStats IT system being received by a subscriber on the FootballFansData system.
Figure 2. Two linked businesses with one of them publishing to the other.
If GolfStats used the same topic space to publish information on the topic "business/financials" for internal consumption by staff, then these messages would not be routed to the WebSphere MQ network of FootballFansData because a topic mapping has not been created for this topic. This ensures the GolfStats team can limit the people who are able to receive these messages to people authorized to do so on the GolfStats system, and avoid unnecessary message traffic between the two systems.