Publishing and subscribing with a WebSphere MQ network: example

This topic gives an example of business reasons for creating a publish/subscriber broker profile.

Defining a broker profile is the first step towards enabling subscribers on the service integration bus to receive the same publication messages as subscribers for a message broker in a WebSphere® MQ network, that is, WebSphere Event Broker or Message Broker. This allows these two separate publish and subscribe domains to appear as a single entity.

Imagine that 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 Web site and run other business applications, so their IT systems are based on WebSphere Application Server using the service integration bus, while FootballFansData do not have any other business applications, and use established WebSphere MQ messaging technology and the WebSphere Event Broker for their publish/subscribe requirements.

Figure 1. Two separate businesses that publish information to their respective audiences.
This figure is described in the surrounding text.

The diagram above shows the two separate businesses – GolfStats 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 subscriber(s) subscribing to “sports//." – (//. indicates all sports information). Similarly a third party supplier for FootballFansData publishes information to the WebSphere Event Broker on the topic “sports/football" which is received by an Event Broker subscriber application listing all "sports/#" (Event Broker syntax for all sports information).

Recently GolfStats and FootballFansData have merged, and the new management wish 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 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 Application Server WebSphere MQ link and a publish/subscribe broker profile.

The actions to achieve this are:

  1. Identify a messaging engine (for example, named LINK_ME) on the GolfStats service integration bus that will act as the link messaging engine to connect to the WebSphere MQ network.
  2. Identify a WebSphere MQ queue manager (for example, named QM_GATEWAY) on the FootballFansData systems that will act as the gateway queue manager to connect to the service integration bus.
  3. Configure a WebSphere MQ link on LINK_ME to enable point-to-point messages to be exchanged between the service integration bus and the WebSphere MQ network.
  4. Define a publish/subscribe broker profile on the WebSphere MQ link that states the name of the message broker in the WebSphere MQ network on which WebSphere Event Broker is running, named QM_ONE in this example.
  5. Define a topic mapping under the publish/subscribe broker profile in order 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.

After this has been done, and the WebSphere Application Server on which the LINK_ME is hosted has been restarted, messages will 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 below 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 separate businesses with one of them publishing to the other.
This figure is described in the surrounding text.

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 that 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.




Related concepts
Publishing and subscribing with a WebSphere MQ network
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=cjc0005a_
File name: cjc0005a_.html