|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
Integration Patterns in the Wild
July 20, 2006
|DDD - Diagram Driven Design|
|What Does It Mean to Use Messaging?|
|A Chapter a Day...|
|Clouds and Integration Patterns at JavaOne|
|My First Google Wave Robot|
|Into the Clouds on New Acid|
|Design Patterns: More than meets the eye|
|Reflecting on Enterprise Integration Patterns|
|Google Gears Live From Japan|
|Double-Dipping: OOPSLA and Colorado Software Summit|
|Enterprise Mashup Summit|
|Facebook Developer Garage|
|Mashups Tools Market|
|Mashups == EAI 2.0?|
I just returned from an exciting speaking tour with talks in San Francisco (Burton Catalyst), Antwerpen (SpringOne), and Barcelona (TheServerSide Java Symposium Europe). After 5 talks in 3 cities, stays in 6 cities, and segments by car, train, and 4 different airlines it feels good to be back home.
Speaking at conferences is a great opportunity to catch up with what is going on in the community, usually over a pint of beer. Hanging out with Bruce Snyder, James Strachan, Ross Mason, John Davies, and others reminded me that our integration patterns have been embraced by a fair number of commercial as well as open source projects. In my eyes this is really the best indicator of success for a pattern language (and the best indicator of happiness for the author). Latin – a dead language used mostly by doctors to sound more knowledgeable – is not a good model for a pattern language. You want a language that is alive and actually used by a broad group of people. Talking to a few folks who did embrace our language motivated me to take a quick survey of the places where our patterns pop up.
Quite a while ago I blogged about my experiments implementing the patterns in our book as executable components. At the time I concluded that it was interesting (and fun) to be able to quickly compose a running messaging system using the vocabulary defined in the book: I wired a Splitter to a Router, followed by an Aggregator, and used a Wire Tap to log the results. While patterns themselves are not executable components, there is nothing wrong with developing components whose essence is a pattern, rendered onto a specific platform.
While my toolkit is largely of educational value, the guys from LogicBlaze took things a step further. Apache ServiceMix is an Enterprise Service Bus (ESB) that combines the functionality of a Service Oriented Architecture (SOA) and an Event Driven Architecture (EDA) to create an agile, enterprise ESB. The framework supplies a few sets of preconfigured JBI components. One of them implements a set of patterns from our book. You'll find a Content-based Router, a Wire Tap, a Splitter, and many more. The components are configured via XML files. For example, a Content-based Router can be configured using the following configuration:
<eip:content-based-router service="router" endpoint="endpoint"> <eip:rules> <eip:routing-rule> <eip:predicate> <eip:xpath-predicate xpath="count(/items) = 1" /> </eip:predicate> <eip:target> <eip:exchange-target uri="http://test/pipeline/oneitem" /> </eip:target> </eip:routing-rule> <eip:routing-rule> <eip:target> <eip:exchange-target service="recipients" /> </eip:target> </eip:routing-rule </eip:rules> </eip:content-based-router>
The configuration specifies multiple potential routing destinations and an XPath expression that determines when to use this destination. The last destination has an optional XPath predicate. If it is not specified, the destination becomes the default destination. In the above example messages that have a single item are routed to a specific endpoint while all other messages are routed to a service. We should try and implement the coffee shop example that I built from my toolkit using these components.
Another popular open source ESB is Mule. Mule champion Ross Mason (as seen on the right) realized early on that using a standard vocabulary to explain the Mule Architecture makes a lot of sense, especially for an open source product. The spirit of open source is to share experience in an open and accessible way very much like patterns do. So he chose to highlight Mule's architectural properties through our pattern language: you'll find Channels, Transactional Endpoints, Transformers, Routers and so on. Of course it helps that this vocabulary is shared with the common definition of an Enterprise Service Bus (ESB). As it turns out that this is not complete coincidence either...
When Dave set out to write a book that finally explains what an ESB really is (well, let's say it is the most serious attempt up to that point) he knew that patterns are a great tool to explain architectural principles in a technology neutral way. This is particularly relevant for an ESB, which uses largely existing technologies, but composes those technologies into a cohesive architectural style. Soon it became clear that ESB – the book should list patterns to highlight the main architectural features. The book not only defines a verbal pattern language on top of our language but also adopted the notion of a visual language, analogous to our icons. One of the nicest features of the book is the tear-out card at the back of the book that describes the visual pattern language. Maybe we should add something like that to our book.
But the connection between our book and Sonic does not stop there. Rumor has it that the new service pack release 7.0.1 will include our Loan Broker example. The ThinkTecture guys used the same example for the Microsoft Indigo (now WCF) design reviews. A typo in one of my e-mails motivated Ross to consider writing a Lone broker example that implements a dating service.
A little closer to home we have the whitepaper Integration Patterns with BizTalk 2004 that explains how to implement some of the key patterns on top of the BizTalk platform. Once again, the ever popular Loan Broker serves as the example application.
I believe the earliest adopter of our pattern language was Matthew Oskowis, who developed a Visio stencil for our icons. Each stencil also contains the pattern text and the page number. Quite fancy!
As described in my rambling about Oopsla 2005 Grady Booch is planning to use patterns in his work on the architecture handbook and included our book in his list of defining patterns books. I am very proud :-)
During his time with the Microsoft Patterns and Practices Group Ward Cunningham created patternshare.org, a site that compiles patterns from multiple authors. The purpose is to make it easier to find a pattern and also to provide stable URLs to reference patterns. The site currently hosts pattern summaries by Martin Fowler, Eric Evans, our integration patterns and others. All content is available under the Creative Commons license, which in essence allows free reuse as long a the source is referenced.
Unfortunately, the collaboration is not always as friendly and collaborative as the aforementioned examples. It is my goal to own (and read or at least peruse) every pertinent book in the field of EAI, messaging, SOA, etc. Sometimes I am surprised to come across work that "borrows" significantly from our work without us ever having been contacted by the "authors". I don't want to mention the specific books here (my motto is "buy from the source!") but there are two books in particular that contain a chapter each about integration patterns, adopting our icons and pattern descriptions. I think these works are largely a result of some authors still not embracing the spirit of the pattern community. Pattern authors have a sincere motivation to share knowledge and promote the community as a whole. We talk about new book projects, share review drafts and bounce ideas back and forth. This benefits the works, the community, and the authors. It always feels odd to see a book that touches on our patterns without the authors having taken advantage of this pattern author community. Sadly, it is also often reflected in the quality of the respective publication.
Luckily the friendly collaboration far outweighs the pattern poaching so I can only encourage people to share their work openly. You'll meet great people, not to mention the satisfaction you receive that your work actually has an impact and makes developers' lives at least a little easier and more enjoyable.
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is a software architect with Google. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.
|© 2010 • All rights reserved.|