Free Gift with Subscription (Pattern)

Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.

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

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:

Subscribe-Notify

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:

Context: the situation in which the pattern applies
Problem: what design problem the pattern addresses
Forces: the "heart" of the pattern -- why is the problem really a problem?
Sketch: an overview picture (not a specification) that expresses the "spirit" of the pattern solution
Solution: the resolution of the forces
Resulting Context: Implementation details and ramifications of applying the pattern solution

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?

A participant could try to aggregate as many individual messages into a larger message as possible, but most messaging systems have size limits for messages.
Large messages can overburden the receiver who has to parse the message -- an operation typically performed in memory. Especially parsing large XML messages, which are still in widespread use, tax the receiving system's memory and CPU resources.
The individual data to be transmitted may be time sensitive. Storing and aggregating it into a single message would reduce the data's value for the recipient.
The response data may not be a finite set of data but a continuous stream of data, which would make it impossible to know when to bundle up messages.

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 Subscriber initiates the conversation by sending a Subscribe message that expresses interest in receiving notification messages. The interest may be defined solely by the provider's address (and thus identity) or the Subscribe message can contain information as to what messages the Subscriber would like to receive, e.g. through a list of Topics.
The Provider waits for incoming Subscribe messages and subsequently delivers a stream of Notify messages to each Subscriber at the pace in which data becomes available or events occur.

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 subscriber sends a stop request in form of an Unsubscribe message.
The conversation uses a Lease (another conversation pattern), causing the conversation to stop after a deadline is reached without the subscriber renewing interest.
If the channel is connection-oriented (such as an HTTP connection), the provider stops sending messages after the subscriber stops accepting connections.
The provider notifies the subscriber of the end of the transmission.
The provider may simply stop sending messages, leaving the subscriber to realize this via a time-out condition.

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