Application developed in the real world can be either a producer or a consumer. Senders (producers) produce messages and receivers (consumers) consume messages. An application may be both a producer and a consumer at the same time. In a SOA world, producers and consumers are loosely coupled with each other through virtual channels called publish and subscribe channels or point to point channels. These two distinct channel types are also called topics and queues.
The producer does not need to know which applications are receiving a message and the consumer does not need to know which applications are sending the data. The challenge is to design the model in such a way that it adhers to industry standards and complies with the rules of SOA. One such mechanism that is described in this post recommends use of ESB as a transport and routing channel and WS standards (WS-Addressing and WS-Base Notification) as carriers of the message information. Since, a pub-sub model is intended for a 1 to many broadcast of information, the emphasis should be to have a logic that can handle multiple subscribers and a provision that can allow any system to subscribe or unsubscribe in future without affecting any other systems. In pub-sub model, multiple consumers may register an interest with, or subscribe to, a topic. A producer sends a message on that topic and each subscriber receives a copy of that message. A message is typically composed of three basic parts: the headers, the properties and the message payload or body. The headers are used by both the messaging system and the application developer to provide information about things such as destination, fault-to destination, message type, expiration date etc. The properties and message payload may vary depending upon the format of the message and its content.
In every pub-sub model, there is an entity that generates the message. That entity is generally referred to as Notification Producer and the message that it generates is a notify message that is used to notify the subscribers of any changes. Since, the notification producer can generate any user-defined message, the message needs to be transported using an industry standard so that different subscribers can implement logic at their end to extract the information thay wish to use by understanding the format of the message. WS-Base Notification (http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf) is a standard that could be used to represent the information that needs to be sent to a subscriber. As it defines a standard format, it is easier for any subscriber to access the details.
It is not possible for a notification producer to carry the responsibility of managing the subscribers and topics. A subscriber may be interested in receiving only a subset of data while other subscribers may require entire data contained in a message. Also some information may be confidential and should be shared only with trusted subscribers. Masking that information before giving to a non-trusted subscriber requires additional logic. It is difficult for a notification producer to maintain a list of subscribers since at a given point of time new subscribers may join or existing subscribers may opt to leave. Also, broadcasting a message is not something a notification producer intends to perform especially, when some subscribers cannot receive message in a format generated by producer. For such subscribers there has to an intermediary who can transform message for them. The well known web services standards (WS-Addressing and WS-Base Notification) can help the intermediary to process the message and access the details it requires for transformation and routing. Any ESB with basic features can be used as an intermediary in such cases.