Work in progress. Last update: Jan 2017

This is a book about enterprise integration with a focus on conversations between loosely couped systems. Sadly, it cannot solve all your integration problems, but nor will any other book. Enterprise integration is too broad and deep an area to expect any book to give you step-by-step guidance or easy-to-follow recipes. However, this book helps you to more easily find a suitable integration solution without starting from scratch or reinventing the wheel. It does so by giving you a conceptual framework and intuitive vocabulary that documents recurring integration challenges and corresponding solutions, highlighting design trade-offs and implementation strategies.

This framework and vocabulary takes the form of a collection of design patterns, which, in unison, form a pattern language. Patterns are a popular and time-proven method to capture and convey design expertise in a technology-neutral way, allowing them to be applied to a wide range of implementation scenarios and products:

• ReST-based services
• Service-oriented Architectures
• Business-to-business (B2B) integrations exchanges
• Interactions based on BPML or BPEL workflows

Relationship to "Enterprise Integration Patterns 1 - Messaging Patterns"

This book is a continuation of the book Enterprise Integration Patterns (EIP 1). Astute readers of Volume 1 remarked that the title Enterprise Integration Patterns ([EIP]) promised a broader scope than the book delivered as it primarily covered asynchronous messaging patterns. Asynchronous messaging is a very elegant and scalable approach, but it is only a part of enterprise integration. At 700 pages, though, it was plenty enough for the first book.

Vol. 2 picks up where Vol. 1 left off and makes clear that "Enterprise Integration Patterns" requires more than one book. Whereas Vol. 1 concentrates on the flow of messages through a series of nodes, Vol. 2 focuses on stateful conversations between parties over time. It also describes the processes within the endpoints that participate in the conversation. Essentially, Vol. 2 moves "up the integration stack": Vol. 1 lays the foundation for reliable asynchronous messaging while Vol. 2 considers solutions on top of a messaging architecture.

While Vol. 2 clearly builds on Vol. 1, it is a still a self-contained book. The appendix contains a brief description of all patterns referenced from Vol. 1.

Who Should Read This Book

Just like Enterprise Integration Patterns 1, Vol. 2 aims to address a wide range of audiences. It does so by combining solid design guidance with an intuitive visual language and concrete examples. The following readers will benefit from Vol. 2:

• Integration Architects who design interchanges between systems. This book helps them design solutions that ensure consistency, robustness, and efficiency. They can also use the book's vocabulary to efficiently communicate designs to developers.
• Service Developers who build service interfaces that allow other components to access their functionality. This includes both Web services and RESTful services. These developers may use a wide variety of service frameworks like CXF, Windows Communication Foundation, or Node.js.
• Enterprise Architects who maintain the "big picture" view of software components and their interactions across the enterprise. This book gives them a consistent vocabulary and a graphical notation to describe and catalog solutions in a meaningful and technology-neutral way.
• Process Designers whose processes invariably interact with other processes or services. The patterns in this book help them design the endpoint processes that support messaging conversations.
• Business Analysts who design interaction flows. This book provides them with a technology-agnostic and approachable vocabulary, which nevertheless includes a precise translation to implementation.

What You Will Learn

This book focuses on interactions between systems within the context of enterprise integration or any other distributed system. You will learn how to design robust inter-system conversations by understanding the following:

• The elements of a conversation, including participant roles, message semantics, and the conversation protocol.
• Ways to precisely but intuitively describe conversations between systems.
• How to break down a complex conversation into smaller pieces and, vice versa, how to compose a complex interaction from basic ones.
• The trade-offs and pitfalls in conversation and protocol design.
• Conversations at different levels of abstractions, including foundational conversations and application-level conversations.

Solving Integration Problems With Patterns

Originating from city and building design, design patterns are a special structured format for documenting design knowledge. Ward Cunningham once famously described design patterns as mind-sized chunks of knowledge, or Chicken McNuggets for your mind. They are not precise specifications or copy-paste-able code recipes. Rather they are for human consumption (like the nuggets) and teach you about a specific design problem, the trade-offs in solving it, and a balanced solution.

Patterns are especially effective in areas where no simple "paint-by-numbers" approaches are available. Instead of trying to give step-by-step guidance, patterns capture expert knowledge by discussing a problem, weighing the different forces, presenting an optimal solution and elaborating on implementation considerations. Each pattern sums up the essence of the solution in a pattern sketch, following the original patterns in Christopher Alexander's book "A Pattern Language" [REF]. The choice of the term "sketch" is deliberate: a pattern does not deliver a blueprint, but a general solution to a problem. The fact that this solution can be implemented in a variety of tools or contexts makes up the strength of the pattern format.

In the early days of design patterns, people argued and philosophized a good bit about the format in which patterns should be documented. As elaborated in Enterprise Integration Patterns, I believe that the pattern content is what counts and the form should be such that it doesn't distract from the content. The pattrns in Vol. 2 therefore follow the same format as Vol. 1:

• Name
• Sketch
• Context
• Problem
• Forces
• Solution
• Results
• Next
• Sidebars
• Examples

The individual sections are not labeled because this would disrupt the flow and appear repetitive. Instead, common style elements and markers gently guide you through the pattern and allows you to identify important information with ease.

Where are the Icons?

The visual icon language, endearingly referred to as "Gregorgrams", was one of EIP 1's most successful features. Many integration patterns book have subsequently adopted the idea of an icon language. EIP 2 maintains the style of visually intuitive "sketches" for each pattern. However, conversations are not elements, but rather the lines between them. The pattern sketches therefore cannot be represented as single "icons" but have to convey a flow of messages.

To maintain the spirit of the pattern sketch, the diagrams depicting conversations are not precise specifications but use lose semantics in order to highlight the essence of the message interchange. Concrete and precise implementations, for example using BPMN, are described shown in the pattern examples and the interludes that show a collection of patterns being used in a concrete implementation.

What This Book Does Not Cover

Even in two volumes Enterprise Integration Patterns cannot cover everything there is to say about integration in the enterprise. For example, conversations are commonly supported by processes implemented inside the endpoints. Also, many enterprises are adopting event-driven communication models. Both areas certainly use recurring solutions that would benefit from being documented as patterns. A Vol. 3 or Vol. 4 might do so some day.

This book is also not an introduction or tutorial into specific integration technologies or tools, such as Swagger, WS-Choreography, etc, or process languages such as BPMN or BPEL. Examples and interludes do use BPMN to show a concrete and precise implementation of the patterns. For the details of the language, though, you should refer to one of the many great books.

How This Book Is Organized

Once it's written, we will know.