Enterprise Integration PatternsConversation Patterns


Conversation Patterns

Previous Previous   Next Next

Conversations between Loosely Coupled Systems

Work in progress. Last update: Nov 2016

Loosely coupled distributed systems prefer to communicate via Messaging. In many cases, though, sending a single message is not enough for systems to communicate in a meaningful way: a request expects a response; a certificate exchange is needed for authentication first; an order message is supposed to be followed by a payment message. Such sequences of related message exchanges form Conversations between participants. Conversations are ubiquitous in system design: web services engage in orchestrations, REST services provide referrals or use HATEOAS to offer subsequent interactions, low-level networking protocols route messages and discover services. Conversations also occur in real world: coworkers exchange requests and availability indications to find a suitable meeting time, vendors issue offers to be followed by orders, shipments, and payments.

Designing robust conversations is no simple task, though: the conversation has to deal with lost messages, participants' state getting out of sync, timeouts, and lots of other annoying stuff happening in distributed systems protocols that occur over unreliable networks. Many developers have a 1000-page TCP/IP tome on the shelf, but are quietly happy that someone else figured all this stuff out for them. Conversations quickly sneak up on developers, though, even when things start out pretty simple: a basic Asynchronous Request-Response interaction may want to re-send the request if no response is received within a specific time window. Doing so may result in a duplicate response being received in case the original response was simply delayed, The requestor now has to track the state of the conversation to detect and ignore duplicate responses. The requestor likely also shouldn't send indefinite retry messages as this may overburden the system. Quickly the simple sending of a message turned up a number of considerations that govern how multiple messages can be exchanged as part of the conversation.

EIP 2: Conversation Patterns

Conversation patterns help developers design robust interchanges between loosely coupled components just like Messaging Patterns did for stateless message exchanges. Just as before, each design pattern represents a "mind-sized" chunk of information that not only describes a solution but also the trade-offs and forces that drive towards this solution. An informal pattern sketch captures the essence of the conversation. A precise protocol specification is given in the real-life example implementations.

Conversation Patterns build on and complement Messaging Patterns, revealing that Enterprise Integration Patterns consist of more than just messaging patterns: Conversation Patterns are set to become Volume 2 of the "Enterprise Integration Patterns" series. Both pattern languages have a different base vocabulary that allows tackling different kinds of design problems. For example, the introduction of conversation state in EIP Vol. 2 allows the discussion of error handling or resource management, something that the messaging patterns in EIP Vol. 1 weren't able to do.

Comparing conversation and messaging patterns

Whereas messaging patterns follow the flow of a message through a series of components, conversation patterns take the complementary approach by following the stateful exchange of messages between components over time.

An Example: Subscriptions

A simple example highlights the different viewpoint that messaging and conversation patterns take.

Comparing conversation and messaging patterns

A Publish-Subscribe Channel, shown on the left, is a basic messaging pattern that describes how messages are routed to a set of subscribers. The pattern looks at a single message to be distributed across multiple subscribers, discussing how each subscriber receiving a copy of the messages makes adding new subscribers side-effect free. A related conversation patterns, takes a completely different viewpoint: it looks at how a single subscriber receives notification messages over time, tacitly assuming that multiple subscribers can do so at the same time. Instead, this patterns discusses the flow of messages over time and raises questions such as how long the flow of messages continues, leading to considerations like a Lease that can expire if not renewed.

The Pattern Language

A pattern language is more than just a collection of patterns: it structures the patterns and guides the developer towards a meaningful solution (see [POSA5]). The Conversation Patterns language is separated into foundational patterns, which deal with technical aspects, such as finding a conversation partner, and application-level patterns, which achieve higher-level goals, such as managing resources or negotiating an agreement. Both depend on a common vocabulary to describe and compose conversations.

The foundational patterns roughly follow the life cycle of setting up a conversation:

  • Discovery: Before services can interact, they have to find one or more conversation partners.
  • Starting a Conversation: Once the conversation partners are known, a conversation has to be established, including authentication, handshaking, and negotiating conversation parameters.
  • Basic Conversations take place between two participants and a small number of message types. They establish a core vocabulary for the description of more complex conversations.
  • Intermediaries are simple conversations that have messages flow through a third party.

Based on these foundational conversation patterns, we can tackle common distributed system problems at the application level, organized by type of consideration:

  • Resource Management: Acquiring resources from a service represents a form of coupling: if the requestor disappears unexpectedly, the resource provider continues to hold unneeded resources. Resource management patterns deal with resource allocation and deallocation in loosely coupled systems.
  • Ensuring Consistency: Things don't always go according to plan in distributed systems where messages can be duplicated and lost, or conversation partners may disappear altogether. These patterns deal with error conditions and help participants reach a consistent state.
  • Reaching Agreement: Most business situations depend on multiple independent parties reaching an agreement through offers, counter-offers, negotiations and deals.

All patterns are listed in the Table of Contents.

Real Life Conversations

Conversations between components resemble conversations in real life because real life is inherently unreliable and asynchronous. Humans have therefore learned to interact by exchanging asynchronous messages, such as leaving a voice mail, mailing a letter, or sending an email, which form part of a conversation. Such conversations serve an overarching purpose, such as negotiating a deal or determining a place for dinner and can span hours, days, or even months. Human conversations have to deal with many of the same issues as distributed systems do, including duplicate messages ("I really need that TPS report"), messages crossing in transit ("Ignore this notice if you've already sent your payment"), and coordinating multiple independent resources ("You got the money? You got the goods?"). Therefore, one can learn a good bit about distributed system design from real life.

Want to keep up-to-date? Follow My Blog.
Want to read more in depth? Check out My Articles.
Want to see me live? See where I am speaking next.

Table of Contents
Loosely Coupled Systems
Describing Conversations
Hypermedia State
Conversation Vocabulary
Dynamic Discovery
Advertise Availability
Consult Directory
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Asynchronous Request-Response
Request-Response with Retry
Quick Acknowledgment
Load Balancer
Managing Distributed Systems
Resource Management
Incremental State Build-up
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement