Publish/Subscribe Messaging Can Be Simple with WebSphere MQ

essage-oriented middleware (MOM) decouples applications by allowing them to communicate using one of two messaging models: point-to-point messaging and publish/subscribe messaging. The models differ in fundamental ways, but neither requires applications to know the other’s implementation details.

Point-to-point messaging achieves only partial decoupling of applications, because you still need to know where to put messages. Publish/subscribe provides a higher degree of independence and reduces design complexity in many cases, but it requires more coding and configuration. Traditionally, MOM shops have opted for point-to-point messaging to avoid the more complex requirements of publish/subscribe.

Enter IBM WebSphere MQ (WMQ), Version 7. This latest release of WMQ aims to make coding and configuring publish/subscribe easier and more intuitive. A previous DevX article focused on the point-to-point messaging capabilities of WMQ. This article explains WMQ's publish/subscribe messaging.

Publish/Subscribe Messaging Overview

Publish/subscribe is the messaging-oriented equivalent of the object-oriented observer design pattern. In publish/subscribe messaging, a sender application creates a message containing the information it wants to send and assigns it a topic that denotes the subject of the information. This message is called a publication. WMQ receives the publication, recognizes the topic, and then distributes the publication to interested applications.

Specifically, WMQ publish/subscribe components include:

Publisher (information producer): This component generates messages (publications) under a certain subject (topic) and sends the publications to a WMQ queue manager. A publisher knows nothing about the recipient(s) of the information.

Subscriber (information consumer/receiver): This component registers interest in a certain topic(s) with a WMQ queue manager. It also specifies its subscription queue name; that is, the queue where it wants to receive the messages related to this topic. The subscriber knows nothing about the information publishers(s).

A publications router: This component passes messages from publishers to topic subscribers. Earlier WMQ versions required a broker component on top of a queue manager to enable publish/subscribe. The broker maintained topics and subscriptions, and it routed publications. In WMQ Version 7, IBM changed this approach significantly. The queue manager is now responsible for topics, subscriptions, and routing publications. Also, MQ Explorer for Version 7 allows you to create topics and subscriptions graphically.

A publish/subscribe system can have many publishers and many subscribers, and often, two or more queue managers communicating with one another. Also, an application can be both a publisher and a subscriber.

A Publish/Subscribe Scenario

Suppose a company sends notifications to its clients via email and Short Message Service (SMS) based on information received from various information providers (say, news and weather services). If the company adds another provider (say, for entertainment), it will have to configure the new provider to write messages to both SMS and email queues. Figure 2 shows the point-to-point implementation for this use case, and Figure 3 shows the publish/subscribe implementation.

Figure 2. Point-To-Point Implementation for This Use Case: Point-to-point messaging requires sender applications to know the queue names for all receiving applications.

Figure 3. Publish/Subscribe Implementation for This Use Case: The email and SMS applications subscribe to the topics generated by providers and automatically receive the information.

As you can see, publish/subscribe is less complex, and adding a new provider requires less effort. When the email and SMS applications subscribe to the topics generated by providers, they automatically receive the information. The providers know nothing about the email and SMS queues.