|HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT|
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.
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.
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,
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:
Based on these foundational conversation patterns, we can tackle common distributed system problems at the application level, organized by type of consideration:
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.
|© 2003, 2016 • All rights reserved.|