Pattern Catalog

Next 

This pattern catalog describes 65 integration patterns, which we have been collecting since 2002. Our goal is to document technology-independent design guidance that helps developers and architects describe and develop robust integration solutions. The inspiration to document these patterns came when we struggled through multiple integration vendors' product documentation just to realize later that many of the concepts were quite similar.

What Are Enterprise Integration Patterns?

Enterprise integration is too complex to be solved with a simple 'cookbook' approach. Instead, patterns can provide guidance by documenting the kind of experience that usually lives only in architects' heads: they are accepted solutions to recurring problems within a given context. Patterns are abstract enough to apply to most integration technologies, but specific enough to provide hands-on guidance to designers and architects. Patterns also provide a vocabulary for developers to efficiently describe their solution.

Patterns are not 'invented'; they are harvested from repeated use in practice. If you have built integration solutions, it is likely that you have used some of these patterns, maybe in slight variations and maybe calling them by a different name. The purpose of this site is to present a coherent collection of relevant patterns that form an integration pattern language.

Who Can Use Enterprise Integration Patterns?

The patterns presented on this site help integration architects and developers design and implement integration solutions more rapidly and reliably. Most of the patterns assume some experience with asynchronous messaging architectures. However, the patterns are not tied to a specific implementation. These patterns help you design better solutions, whether you use EAI, SOA, or ESB platforms such as IBM WebSphere MQ, TIBCO, Vitria, SeeBeyond (now Sun), WebMethods, BizTalk, Sonic, Fiorano, Mule ESB, ActiveMQ etc., JMS-based messaging systems, MSMQ, Windows Communication Foundation (WCF), or Web service-based integration.

How Can You Use the Patterns?

Because we want to encourage widespread use of the pattern language we have provided a variety of ways to access them:

• Reference. A summary of each pattern from the book is available on this site.
• Read. Of course, the book Enterprise Integration Patterns (Addison-Wesley, ISBN 0321200683) contains the full catalog of patterns with a much more detailed discussion and examples -- over 700 pages worth of material.
• Read on-line. You can also read the full text on-line on Safari, which is a great option if you travel a lot or like to search the text. You'll have to be a Safari member to get full access.
• Design. You can create design documents using our icon language by downloading the Visio stencil or using the OmniGraffle stencil created by one of our readers.
• Reuse / Recreate. You are also welcome to build on top of what we have done or reuse the patterns in new contexts. We made the pattern name, icon, problem and solution statements, as well as the sketches (the diagram below the solution statement) available under the Creative Commons Attribution license. In brief, this license allows you share and use these passages as long as you give proper attribution. In our case, this would mean a link to the site and a reference to the book title and authors. If you have questions regarding this requirement, please contact us.
• Use Tools. A number of open-source frameworks, such as Mule, Apache Camel, or Spring Integration incorporate our patterns. Now you can not only think in integration patterns, but also to code in them!
• Teach. A number of professors use our material in lectures. If you are interested in getting access to material for academic purposes, please contact us.

What about SOA or ESB or Web Service Patterns?

Yes, enterprise integration (or "EAI" – shudder) has become a somewhat of a dirty word in the industry. We feel that this is partially the result of analysts and vendors having to come up with new terms every quarter to make you buy new stuff. Nevertheless, a lot of the problems we have to solve every day remain frustratingly similar. Because the patterns encapsulate design knowledge, this knowledge does not age nearly as quickly as a specific technology. Hey, the Gang of Four just celebrated their 10th anniversary. We are looking forward to ours…

• Web services specifications define standards-based implementation technologies for many of the patterns, but use the same architectural principles and guidelines. For example, WS-Addressing incorporates both a Correlation Identifier and a Return Address. For a more detailed treatise on the relationship between our patterns and Web Services standards see Sean Neville's excellent chapter in our book.
• Service-oriented architectures describe ways to build loosely-coupled systems composed from individual services. Because much of this loose coupling is a result of message-based communication between services, our patterns are extremely relevant in the SOA space.
• ESB (Enterprise Service Bus) is another hot buzzword in the industry. The core of a typical service bus incorporates messaging, routing, transformation, endpoints -- exactly the patterns documented in our book. In fact, the Enterprise Service Bus book by Dave Chappell extends our pattern language to the service bus.

Many ESB or SOA platforms already implement some of the patterns described in this book because the vendor recognized the recurring problem and incorporated the solution right into the package. We still describe these patterns for two reasons. First, not all packages implement the same set of patterns, so someone working with another package will still find the pattern useful. Second, despite the default implementation of the pattern in the platform, a description of the forces and alternatives is insightful for any architect or developer who is interested in EAI concepts beyond the specific package implementation. The patterns give you the "why" in addition to the "how".

Aren't There More Integration Patterns?

Despite the 700-odd pages, our book covers only a fraction of patterns (and the problems to be solved) in the enterprise integration space. We decided to start with relatively low-level patterns, most of which are based on the notion of asynchronous messaging. We have started to harvest many more patterns but are realizing (once again) how much work documenting these patterns really is. So please stay tuned.

The Patterns

We have identified 65 patterns so far. The Table of Contents lists the problems addressed by each pattern. We organized the patterns into the following categories:

• Integration Styles document different ways applications can be integrated. These patterns present somewhat of a historical account of integration technologies. All subsequent patterns follow the Messaging style.
• Channel Patterns describe the fundamental attributes of a messaging system. These patterns are implemented by most commercial messaging systems. This section focuses on the interrelationships between different features and highlights implementation trade-off made by different vendors.
• Message Construction Patterns describe the intent, form and content of the messages that travel across the messaging system. The base pattern for this section is the Message pattern.
• Routing Patterns discuss mechanisms to direct messages from a sender to the correct receiver. Message routing patterns consume messages from one channel and republish the message to another channel that is determined by a varying set of conditions. The message content is not modified. The patterns presented in this section are special cases of the Message Router base pattern.
• Transformation Patterns change the information content of a message. In many cases, a message format needs to be changed due to different data formats used by the sending and the receiving system. Data may have to be added, taken away or existing data may have to be rearranged. The base pattern for this section is the Message Translator.
• Endpoint Patterns describe the behavior of messaging system clients. They illustrate different ways in which applications can produce or consume messages.
• System Management Patterns provide the tools to keep a complex message-based system running. A message-based integration solution can process thousands or even millions of messages in a day. Messages are generated, routed, transformed and consumed. The solution has to deal with error conditions, performance bottlenecks and changes in the participating systems. Message management patterns address these requirements.

Be Part of the Community

We welcome your feedback at: info@enterpriseintegrationpatterns.com.

Stay informed! To receive notifications of updates to the site send an e-mail message to eaipatterns-announce-subscribe@yahoogroups.com. I send updates every once in a while to let you know what is new (very low traffic and no spam).

Contributors

The patterns on this site are the result of discussions involving numerous individuals. Kyle Brown (co-author of "Enterprise Java Programming for IBM WebSphere" and "The Design Patterns Smalltalk Companion"), John Crupi (co-author of "Core J2EE Patterns"), Martin Fowler (author of too many books to mention here), Rachel Reinitz, Mark Weitzel were part of the original discussions. Conrad D'Cruz, Sean Neville, Mike Rettig, Jonathan Simon ended up authoring examples, case studies and a chapter on the future of integration.

Colophon

This web site is rendered entirely from XML source files using XSL stylesheets. This approach separates content from presentation and allows me to create the table of contents and 'previous' and 'next' links automatically. In addition, it will allow me to render a PDF document from the same XML source using FOP. I use Ant to validate and transform the XML files and deploy them to this site. [What is a colophon?]