Gregor's Ramblings

Free Gift with Subscription (Pattern)

APR 26, 2015

Gregor HohpeHi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also an Enterprise Strategist at AWS.
ALL RAMBLINGS  Architecture (12)  Cloud (10)  Conversations (8)  Design (26)  Events (27)  Gregor (4)  Integration (19)  Messaging (12)  Modeling (5)  Patterns (8)  Visualization (3)  WebServices (5)  Writing (12) 

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home:

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:

Conversation Patterns vs. Messaging Patterns

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.

What is in a name?

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.

More Conversation Patterns

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


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several books on architecture and architects.