|HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT|
APR 26, 2015
Discussing the Google cloud Pub/Sub system in the last rambling reminded me that the Publish-Subscribe Channel pattern makes for a good example of the subtle but important difference between Messaging Patterns and Conversation Patterns. This comparison is timely as I picked up documenting Conversation Patterns again. It is even more timely as I am flying to Baltimore (via Newark) to speak at SATURN 2015, and also to participate in a workshop on microservices.
Publish-Subscribe Channel is a messaging pattern that explains how multiple subscribers each receive a copy of all messages published into this channel. The pattern concerns itself with message delivery and takes the viewpoint of a message traveling through the system via channels:
In contrast, Subscribe-Notify is a conversation pattern, which focuses on the flow of messages over time between a set of participants.
I use the same pattern form to document Conversation Patterns:
One of the best treatments of the role of the individual sections and how to combine them into a useful pattern can be found in Pattern-oriented Software Architecture Vol. 5: On Patterns and Pattern Languages. As always, there is an element of personal preferences in pattern formats. For example, Bobby and I prefer to keep the solution statement short, deferring much of the discussion into the resulting context. Other pattern authors may set a different emphasis
I show an abbreviated version of the Subscribe-Notify conversation pattern here -- the expanded versions will appear on this site some time this summer.
A participant wants to retrieve information from another participant.
How can one participant receive information from another participant if that information cannot easily be packaged into a single message?
The interested participant, or Subscriber, initiates a Subscribe-Notify conversation by sending a message to the Provider that expresses its interest in data the Provider can supply. The Provider subsequently keeps sending messages to the Subscriber until a stop condition is reached.
The Subscribe-Notify conversation involves the following participants:
The Subscribe-Notify conversation does not have a natural stopping point -- notification messages could continue indefinitely. Therefore, a stopping condition is needed. Typical stopping conditions include:
The conversation pattern discusses the solution from the viewpoint of the participants, which are named and exchange messages over time. The conversation sketch includes a time dimension, in our case running from top to bottom, whereas the sketch for the Publish-subscribe Channel only shows the flow of messages from left to right. In the abstract, the difference in the pattern languages can be exemplified by the difference in the sketches:
The Subscribe-Notify conversation pattern includes considerations related to unsubscribing or terminating the conversation. For example, a Lease automatically terminates a conversation if it is not renewed by the Lessor in a specified amount of time. The Publish-Subscribe Channel on the other hand simply assumes that subscribing and unsubscribing is a lower-level function of the messaging system and does not go into much detail on it as the message delivery is in the center of the discussion. Conversely, Subscribe-Notify does not show multiple Subscribers because each of them is engaged in a separate conversation.
Discussing the differences between the patterns got me thinking whether Subscribe-Notify is really a good name for the pattern. Synonym names I came across are Multi-responses or Streamed Responses. Picking the right name is not easy and can often help refine the pattern itself. Subscribe-Notify and Streamed Responses very much emphasize the aspect that messages are sent as data becomes available or events occur, implying that the solution of sending a single large messages is not practical at all. Multi-responses points towards a broader problem, which could include simply breaking a message down into smaller parts, e.g. to meet size restrictions. This could be done by a Splitter for example. I may consider splitting (pun intended) the two scenarios into separate patterns. For example, splitting one message in multiple parts has simpler and deterministic termination conditions than subscribing to a stream of events. Such subtle differences often help refine and harden the patterns.
Thinking of names, "Publish-Subscribe" is not the greatest name either. For one, participants have to subscribe first before they can receive published messages, so "Subscribe-Publish" may be more appropriate. Also, "Publish" is a per-message action, meaning the message source publishes every message while "Subscribe" is a meta-action that registers a subscriber once to receive published messages. From this view point, "Subscribe-Unsubscribe" is a more logical pair of terms. Pattern-oriented Software Architecture names the pattern Publisher-Subscriber, deriving from the roles of the participants, being more consistent. I am guessing "Pub-Sub" just made such a catchy name, that splitting hairs over the message semantics became a secondary consideration.
I am in the process of preparing the Conversation Pattern language for publication on this site. In the meantime you can get an overview in the Conversation Patterns Paper I workshopped at EuroPLoP 2008. Good that (good) patterns are timeless...
|© 2003-2021 • All rights reserved.|