Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Publish/Subscribe Messaging Can Be Simple with WebSphere MQ

Combine publish/subscribe messaging, JMS, and WebSphere MQ to build powerful message-oriented applications simply.


advertisement
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.
  • Figure 1. A Basic Publish/Subscribe Setup: Publish/subscribe includes publishers, subscribers, and a queue manager.
  • 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.

Figure 1 shows a basic MQ publish/subscribe setup.

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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap