108 of 115 people found the following review helpful
on October 29, 2003
To do justice in reviewing this book, I should depict every single pattern and give you multiple examples on how it would apply to your job as a Project Manager, Software Architect, Technical Lead or a Developer. That would be a 500-page book all by itself. In short, this is one great book. The first book to actually take a complex and ever growing topic such as MOM, Message Oriented Middleware, and give you its benefits and the best practices/patterns all in one book.
The author starts by giving the reader the top reasons why messaging should be chosen for the next project:
1) Remote communication
2) Platform/Language Integration
3) Asynchronous communication
4) Variable timing
6) Reliable Communication
7) Disconnected operation
9) Thread Management
The author goes into detail on each of these reasons. These reasons would convince any software architect, but the author goes even further than that and reiterates the benefits of each of these reasons and elaborates on them thru out the book.
Chapter 3 of the book starts by breaking up a messaging system into its main components and briefly explaining each one:
1) Message Channel
3) Pipes and Filers
4) Message Router
5) Message Translator
6) Message Endpoint
Each of these high level topics is then broken down and various patterns are shown for each section. Just like the GoF book, the reader can simply go the desired section and read the patterns that are associated with that "subsystem"
Each section is then followed by a full-blown example, which to me is priceless. The examples are shown using the most popular middleware vendors such as TIBCO, IBM, Microsoft, Web Methods, SeeBeyond and a couple JMS vendors. The examples show the similarities and differences in implementation but clearly show how EACH pattern that was just covered in the previous section applies to the example.
Having worked with many of the MOM vendors covered in this book, Chapter 7, Message Routing, is my favorite chapter. The author breaks down this topic into 14 different patterns:
i) Pipes and Filers
ii) Message Router
iii) Content-Based router
iv) Message Filter
v) Dynamic Router
vi) Recipient List
x) Composed Message Processor
xii) Routing Slip
xiii) Process Manager
xiv) Message Broker
The chances are, not many of us need to write a MOM due to the fact that there are many vendors out there that are doing that already! But one could certainly use this section for education purposes, and/or use it a checklist of "nice-to-haves" when shopping around for a MOM vendor. By reading the book, you can figure out what "features" apply to you, your application and your enterprise, and take that list and see which vendor has implemented that feature.
In summary, Gregor Hohpe and Bobby Woolf have done a fantastic job depicting a very complex topic. I have made a place for this book right next to the original GoF Design Patterns book.
42 of 44 people found the following review helpful
on July 5, 2004
I had been waiting for this book for several years. There are many good books on software architecture using synchronous communication, but nothing on asynchronous communication --- the typical scheme when connecting existing applications. This is surprising since the underlying products (MQ, MSMQ, WebMethods, Vitria, etc.) have been around for a while, some for more than 10 years, and the techniques have become increasingly well understood by the practitioners. There are even some books on the individual products --- several on MQ for example --- but nothing more general about how to use messaging, message routing, and message transformation to build a larger system.
This is the book I had been waiting for. Furthermore the authors have avoided the usual three pitfalls of technical books: it is well organized, it well written, and it is deep treatment, not at all superficial.
The book is organized into 65 patterns (in the manner of the classic _Design Patterns_). Each pattern shows one typical problem in integrating applications, and how it is solved. Each pattern gives enough implementation details so it is clear how it would work, and an example or two so it is clear how it works in practice. For example the Message Expiration pattern addresses the problem of "How can a sender of a message indicate when a message should be considered stale and thus shouldn't be processed?"
The writing in this book is clear. For example "A Message Expiration is like the expiration date on a milk carton. After that date, you shouldn't drink the milk." The authors have also invented icons for each of their patterns. Their icon language allows a integration architecture to be visuallized in a way that UML does not provide.
Amongst the 11 pattern-describing chapters are 3 "interludes", chapter-length examples that explain a problem, show how patterns can combined to solve it, and then provide implementations in different technologies (JMS, .Net, TIBCO, MSMQ, etc.).
My only beef with this book is that it is long and dense: almost 700 pages. I bought it in late December 2003 and I am only finishing it now. But it is hard to say what should have been cut. Certainly none of the patterns are unnecessary, and the decription of each feels like about the right length. The interludes are also useful for seeing how the patterns fit together. So maybe this book just needs to be 700 pages.
24 of 25 people found the following review helpful
on March 29, 2004
This a book about enterprise integration solutions, authors claim that they are technology neutral, it is true. In the examples and implementations, they chose 3 most popular messaging frameworks to illustrate the patterns. However, they are pretty biased toward messaging as the "better" solution to enterprise integration strategy. It may have a lot of edges over the other approaches, sometimes it is just easy to use a simple wrapper/facade to do the integration. But I guess authors really intend to push their messaging solutions as the subtitle indicates.
Having said that, this is an excellent book of message pattern language, which I believe is the first one introducing the interesting topic. The books touches from the architectural patterns, e.g., messaging bus, pipe and filters, to common design patterns, e.g., publish/subscribe, request/reply, to some patterns that most MOMs provide as integrated solutions, e.g., durable subscriber, message filter, message expiration etc. With all these patterns at hand, a system architect would be able to craft a messaging pattern-oriented enterprise integration architecture by applying the appropriate patterns compositely.
The book would be better if authors describe some patterns implementation in more detail. E.g., it would be interesting to see how the message expiration is implemented, does the message contain a timer or the message channel monitor each individual message from start up? How does the channel interact with the message and check the expiry? Guaranteed delivery is another example. I know most of these implementation details only interest MOM developers, whereas pattern users are only interested in how and when to apply the patterns, but now that the book is about patterns themselves, implementation details would be appreciated.
Since all the patterns introduced in the book form a messaging pattern language, knowing each pattern's strength and limitation under the context, scope and different forces, and how it interacts with other patterns to form a bigger(composite) pattern are essential to grasp the pattern language. A collaboration diagram to show each pattern's transition/migration/composition to each other would be helpful.
14 of 14 people found the following review helpful
on December 21, 2003
Enterprise Integration Patterns is part of Addison-Wesley's new Martin Fowler Signature Series, which Fowler's Patterns of Enterprise Application Architecture (PoEAA) is also a part of. I was very satisfied with PoEAA and the same can be said about Enterprise Integration Patterns. It has the potential to become a classic.
The authors' writing style is a pleasure to read -- no ambiguous statements, no unnecessary babbling. The book is structured to suit both cover-to-cover reading and a "dive-in" approach for situations where you're looking for a solution to a particular problem. After an introduction to the field of enterprise integration, and a discussion of why the book concentrates on the messaging integration style in particular, the reader is given a hierarchical catalog of patterns revolving around a small set of "core" patterns. The book's coverage is in my opinion very well scoped.
I must also praise the look of the book; besides the layout being familiar from prior works and the proven pattern catalog structuring, the authors have used graphics very efficiently. Not only the authors define a vocabulary for integration patterns, but they have also come up with an expressive visual language for illustrating the patterns using simple notations that can be easily drawn without CASE tools.
I found only two downsides for this book. First, the title can be slightly misleading as the book focuses on messaging as an integration style and only briefly mentions alternatives such as RPC, file transfer, and shared databases. However, I don't know a single person who doesn't read the back cover before buying a book, so I wouldn't count this as a big issue. Furthermore, the reason for focusing on messaging is thoroughly argued in the book. The second downside is the code examples, which are presented using varying languages and products and seem somehow disconnected from the text.
In summary, Enterprise Integration Patterns is a great book. It's worth reading and re-reading if you're working with systems integration projects or writing integration software yourself. Yet another book that makes me think, "I wish I had it back then..."
11 of 11 people found the following review helpful
on December 19, 2005
Deserves to take place in the great line up of GoF, POSA1, POSA2, EAA, Core Security Patterns (other "patterns" books omitted intentionally).
I have done Messaging and message based integration before, but this book takes essentially what is an art form and makes a science out of it.
First it starts with 4 different styles of integration (File based, Shared Database, RPC, Messaging) and discusses them intelligently giving their advantages and disadvantages.
Then it gets in to the major aspects/ pieces of Message based integration (Message, Channel, Routing, Transformation, End Points, System Management etc). It again discusses them as patterns and develops a good vocabulary of the messaging domain.
Then comes the meat where for each aspect of Messaging, it gives about 8 to 15 specific patterns, names them, shows their pros and cons, gives the trade off and intelligently discusses their usage. As part of the examples it draws example from JMS/ TIBCO/ MSMQ etc. Priceless.
What I loved about this book is how it makes you rethink everything you may have been doing before in software architecture/ integration using technologies such as Web Services, JMS, J2EE etc.
For example, many would not have fully groked MDBs as "event driven", "competing", "transactional" message consumers, that are suited for "Point to Point" integration. Yes I know every body uses them but do you really understand the implications for transaction scope and threading? . Or Polling message consumers have their advantages ?
Good discussion on relate standards and technologies included (Web Services, Axis Implementation, WS-*, SOAP etc)
Buy this guys and may be enterprise integration would be less messy.
28 of 33 people found the following review helpful
on April 29, 2009
This review is for the kindle version of the book.
So far, the book has been an excellent discussion on integration patterns in general and messaging in particular. I would likely give the text version of the book a 4 or a 5 on content.
Unfortunately, the Kindle version suffers from some formatting flaws which bring the rating down a bit.
- The table of contents does not link directly to it's contents.
- Sidebar panels and examples (of which there are many) are almost unreadable because they are formatted in a such a way that the text flows off the page. One must select the text with the thumbstick and scroll back and forth to read it.
Hopefully, Addison-Wesley will correct the errors.
8 of 8 people found the following review helpful
on October 26, 2003
I am working in the integration team of a big organization in Israel and we are setting up a very large scale and complex , Service Oriented, EAI project which focuses on routing and security of messages between a huge variety of systems on lots of protocols.
I've been scouting the net for months looking for material on how to set up a good EAI project and what patterns, architecures, software and language environments are suitable for us. And I must say that no site compares to eai patterns. Most of the info you'll find on the net comes from some eai vendor and is all full of publicity stuff and biased opinions. what I love about eai patterns, is that it gives you all the information you need to set up a great and complex EAI router\mapper\anything without the need for any particular product. And it also shows you implementations with common eai and techologies. There is no other source which really defines the patterns and terminologies of EAI, in a global way without relation to any particular product like eai patterns. Over here at work we printed out the entire site on the mainframe printer and we use it as our guide. But now we could just get the book and have it in a much more compact manner. The only problem here is that stuff like EAI patterns and technologies get updated so fast that there is no chance the book will cover everything you need and you will probably have to look up for more on the net. But there certainly isn't a better way to get into EAI in my opinion, than buying this wonderful book. This is the EAI Bible. Great job by the authors. 5 Stars!
6 of 6 people found the following review helpful
on November 7, 2003
I highly recommend this book because it offers solutions for many of the problems in enterprise software integration. I was able to participate in the on-line group reviewing the patterns. The authors were humble in receiving feedback and persistent in their desire to identify useful patterns with meaningful examples.
I am using these patterns at my present company designing in-house middleware solutions. The book is not just patterns, but a Pattern Language of Messaging for anyone needing to work in middleware. This will be a great reference for years to come!
4 of 4 people found the following review helpful
on July 24, 2005
This book could really be titled "Everything You Wanted to Know About Message-Based EAI, But Were Afraid To Ask". It's a very comprehensive book, which goes beyond mere patterns to introduce the reader to a wide range of topics in the world of messaging. It forms a strong and useful counterpart to the many more general books on architecture patterns, for example Martin Fowler's "Enterprise Architecture Patterns" in the same series.
The book is very accessible, written and illustrated clearly and assuming very little initial knowledge. However it will also provide value to the experienced messaging developer, formalising his or her knowledge and suggesting new ways of using messaging to solve different problems. I particularly like the way that Hohpe and Woolfe lay out each pattern using language and visual styles to naturally delimit the sections of the pattern, rather than using lots of sub-headings. This increases the readability significantly.
Several books on patterns talk about a "pattern language", the idea of describing a complete design in terms of named patterns for the architectural form of each component. However this is one of the first books I have read which really adopt this idea - the authors have created a new visual language, which they first use to describe basic patterns in terms of basic message constructs, and then describe more complex patterns and solutions using the icons for the intermediate patterns. Best of all you can download a Visio stencil from the website and start using and extending the pattern language yourself.
The book is remarkably technology-agnostic, providing many examples in both .NET and Java forms, and with a fair sprinkling of other technologies, for example using proprietary EAI tools such as Tibco. I have certainly seen and used some of these patterns in older file-based integration schemes, and I suspect many of them work for Web Services too. As such the book has a much better claim to be a true "patterns" book than one wedded solely to a single technology base.
Each group of pattern descriptions is followed by a detailed "practical example" section which shows how one or more messaging technologies can implement the preceding patterns to solve real problems. There aren't any real "antipatterns" in the book, but the book is realistic about when a given technology or pattern should not be used, which is just as valuable.
If I have a complaint it's a minor one, that the book is too long. Including the multiple introductions, it runs to over 700 pages. Dipping in and out my read through has taken many months. Like many patterns books, in an attempt to keep each description self-contained you find by half-way through that some basic things are being repeated regularly. A more "normalised" structure might have been better. Also, although most of the book is very readable, a couple of chapters by "guest" authors, including the final one on Web Service standards, take a more academic tone.
That said, this is an excellent book, which can be read from cover to cover, or stands as a general-purpose reference, and I strongly recommend it.
3 of 3 people found the following review helpful
on November 2, 2008
Deciding on the best solution for an integration problem often involves difficult discussions between architects and implementors each of whom may hold a widely differing point of view. Gregor Hohpe and Bobby Woolf have provided a marvelous reference that clearly depicts and explains the messaging pattern choices to be considered along with their respective merits. Being able to match the problem with these patterns and authoritatively illuminate and quickly settle design team discussions fully justifies having this reference near at hand.
When viewing all the forces on a pattern over the longer term, the right solution will often require a bit of additional design and implementation effort vis-a-vis the quickest (or entrenched) solution. By communicating, discussing, and applying widely-understood patterns the overall construction and maintenance costs for integration can certainly be reduced.
One real example of a much better implementation that resulted from this book was the application of the Claim Check pattern to pass a token representing a large PDF document in the message, rather than encode and embed the document itself. The book explains the pattern clearly, and the implementation was not only easier to work with (because the message payload was much smaller), but the solution has subsequently become a better fit with Enterprise Service Bus (ESB) middleware since the XML for the transaction and its metadata can be rapidly transformed without being burdened by passing the bulky PDF data within the message.
Another example was solved by using the book's detailed explanation of the Correlation Identifier pattern to facilitate the redesign of an legacy transaction message. The existing application had embedded the correlation identifier in the business message which limited the implementation to a single asynchronous message exchange. By following the book's recommendation to persist the correlation identifier outside of the business message, the application could be more readily integrated using standard messaging ESB middleware tools and became reusable in environments that required more than one messaging hop.
In both of these examples, the book served both to educate the participates on the relevant patterns and then served as a "referee" to move the discussion towards a standard and extendable solution. Without the benefit of this book as an authoritative reference, it would have been very difficult to introduce new flexible and agile messaging-based architectural solutions.