Book Review: Enterprise Integration Patterns

I’ve just finished reading ‘Enterprise Integration Patterns’ by Gregor Hohpe and Bobby Woolf for the second time. I first read it when it was published back in 2004. At the time I was struggling with web application architecture, and so it wasn’t directly relevant to my work. I guess I took away some idea of how messaging systems could work, but mostly my thoughts were, ‘that’s interesting, I wonder who uses it’. I came to read it second time because I’m responsible for architecting an enterprise integration architecture, so now it’s directly relevant to my work.

Whatever you may think about EIP, its influence has been huge. I don’t think anyone can have an intelligent discussion about integration architecture without referencing it. It defined the vocabulary for a lot of SOA and if you read anything by the SOA industry gurus, you will constantly encounter citations from this book.

It’s pretty clear how Hohpe and Woolf think you should do enterprise integration; because although Chapter 2 describes various integration styles; File Transfer, Shared Database, Remote Procedure Invocation; the rest of the book is about messaging and messaging only. Indeed, that is probably the book’s most important legacy. EIP is one of the key reasons that messaging has now become the default style of enterprise integration.

So why do Hohpe and Woolf think that messaging is the answer? Like pretty much anything to do with software it’s all about coupling, or rather avoiding coupling. Of course this includes logical coupling; not making one application have to care about the internals of another; but you can achieve that with web services. What messaging gives us is temporal decoupling; by making all our integration asynchronous we no longer need all our components to be available all the time. Introducing a service bus and publish/subscribe messaging also removes the need for our applications to even care where the other components are, or even if there are any to communicate with.

The first three chapters are essential reading for anyone building business applications. Chapter 1 describes the integration issues that face many large organisations and describes how messaging might be used to to glue disparate applications together. Chapter 2 describes alternatives to messaging as explained above and why you shouldn’t use them. Chapter 3 introduces basic messaging concepts including channels, messages, pipes and filters, routing, transformation and endpoints. Together they are probably the best explanation of why you should use messaging and how to get started that you will find anywhere.

EIP is a patterns book. This means that it’s primary purpose is to define a vocabulary. However, in defining the vocabulary Hohpe and Woolf also provide a comprehensive cookbook of solutions to common integration patterns. Like all patterns books, you often think, ‘I’ve done that myself’, but now you have a name for it, know the alternatives and possible problems before you start. Being a patterns book also means that it can be a bit tedious to read from cover to cover. Each pattern has to stand independently and has the same layout: A name, an icon, the context, a problem statement, forces acting on it, a solution including a sketch and related patterns. This makes it excellent as a reference work, but leaves something to be desired if you are expecting more of a narrative. But even if you don’t fancy tackling all 600+ pages of patterns, I would still recommend anyone building business software to read the first three chapters.

The icons for the patterns are a great visual vocabulary, but having said that I haven’t seen them very widely used. It’s a shame because they are quite pretty. You can download a Visio template for them here. Here’s a completely meaningless EIP style diagram I just stuck together:

My only other criticism of the book is that the technology it describes is now five years out of date. In the same way that Martin Fowler’s ‘Patterns of Enterprise Application Architecture’ sometimes reads like a specification for NHibernate, EIP often reads like a description of NServiceBus or MassTransit. As a keen MassTransit user, I often read a pattern only to think, ‘well, MassTransit covers that one, I don’t have to worry about it’. Many of the patterns have been further refined in the meantime and you can’t talk about messaging these days without some reference to the Command Query Responsibility Segregation pattern. For that reason, you shouldn’t read this book in isolation, but rather as a foundation for further investigation.