Enterprise Integration Patterns: Book Review

Updated 19 October 2020

The book “Enterprise Integration Patterns” was published in 2004. Written by Gregor Hohpe and Bobby Woolf, it was initially conceived as an academic paper. It was then refined and expanded into a very large, hardback book.

Enterprise integration is the sharing of data or commands between different applications. In some enterprises, there might be dozens, if not hundreds of applications, that all must be connected, for the business to operate - HR systems, finance databases, just to name a couple.

The idea of the book is that enterprise integration problems can be solved using messaging.

By using asynchronous messaging as a backbone or “channel”, integration becomes a series of asynchronous messages between applications.

These messages can be used to trigger events, track processes or transform data.

But the book is over 15 years old now. Is it still useful today?

Why messaging?

“there are no simple answers for enterprise integration”

The premise of the book is covered in the first chapter: Solving Integration Problems Using Patterns.

Hohpe and Woolf saw the big ball of spaghetti. Even back in the early 2000s they understood that most companies run many applications and need to connect them together, and that it’s tough to do this.

Fast-forward to today, and companies are are running ever more applications, connecting to cloud services and storing data in SaaS products. In other words, the problem still exists, and is growing.

The book suggests that when we connect applications in a synchronous way, such as by using technologies like Web services, we enforce tight coupling between them.

This means that a synchronous interaction can bind two components so closely together, that a failure in one application will cause a severe problem for the other. These tightly-coupled interactions make things, according to the book, “brittle, hard-to-maintain and poorly scalable”.

Instead, asynchronous interactions, the book argues, are more flexible and loose. It talks about the advantages and disadvantages of using this approach, and then suggests a set of patterns that you can apply to the problems you’re trying to solve.

A page from the Enterprise Integration Patterns book on Canonical Data Model — The infamous Canonical Data Model pattern

Learning the background

One of the best parts of the book is how it sets the scene first.

If you’re new to integration architecture, you can easily get lost in the terminology, and unable to find a decent explanation of what people are talking about. Most sources just dive into technical tools, without spending any time to cover the background or explain the reasons why we do what we do.

This is one of the strengths of this book.

It starts with a few introductory chapters on integration and messaging, and then the remainder of the book is largely presented as a list of patterns. So you get to first understand the problem, before diving into the solutions.

The first sections give a good introduction, along with an business scenario as an example, which explains the problems around enterprise integration. It also covers the possible approaches to integration (File Transfer, Shared Database, RPC, Messaging) before settling on messaging for the rest of the book.

Later, when each pattern is introduced, the authors explain the problem it’s trying to solve, giving a detailed explanation and then some sample code. (But remember this book was published in 2004, so don’t expect any modern Java, like Spring!)

Enterprise Integration Patterns

And then, the book introduces patterns, one-by-one.

An enterprise integration pattern is an abstract solution which can be applied to the problem of how to connect two applications together.

The inside back cover of Enterprise Integration Patterns — The back of the book includes a pattern reference guide

In the book, you learn basic patterns about messaging itself, like:

Message Channel - this is the “thing” that carries messages. For example: an address or queue on a message broker, like ActiveMQ Artemis, or a Destination in JMS.
Message - a way of wrapping a unit of data to send between applications. For example: a message that you place on a JMS queue.

And then you learn about patterns for processing messages, like:

Splitter - a way of processing a message that contains multiple elements. For example: processing multiple lines in a CSV using Apache Camel’s Splitter component.
Message Translator - how to allow systems to communicate using messaging, even when the systems use different data formats. For example: mapping between Java POJOs using Apache Camel’s Dozer component.

In all, there are over 60 patterns in the book.

Who is this book for?

I think that you will get a lot of value out of this book if:

You’re a developer who wants to learn about integration or retrain into the area, especially if you are learning Apache Camel
You’re working with, or learning Apache Camel (or Red Hat Fuse, or Talend ESB), or a message broker like ActiveMQ or RabbitMQ
You are an application architect, looking at how to share data between two applications
You are new to messaging, and you want to understand what’s possible, and why people would choose to use message queues
You are an enterprise architect, looking to understand how other people have solved the same problems that you have
You are a systems administrator, managing message brokers and infrastructure, and you want to understand how and why messaging is used

The good parts

So, onto the pros and cons of Enterprise Integration Patterns. Why should you buy it?

HTTP/synchronous style was popular for a while, but now messaging is finding favour again (Kafka, Event-Driven Architecture). The techniques in this book are semi-timeless and can be applied to problems, 15 years on from publication.
You should absolutely buy this book if you’re going to be working with Apache Camel. You will appreciate much more how Camel works, and what it’s capable of.
The book encourages loose coupling, which is a great school of thought for application architecture, and there are lots of patterns in the book to help you achieve this.
It’s a good introduction to messaging and thinking asynchronously. It will be especially useful if you’re a new enterprise developer, and you might not have covered messaging in your university degree.

The not so good parts

15 years is a long time in computing so it’s not “cutting-edge”. Some patterns in the book have evolved since publication, and there are also some clear out-of-date references. The book was published around the time of peak SOAP, so it includes references to related concepts like WS-ReliableMessaging, which we probably wouldn’t think of implementing now.
The book mandates messaging. This might be obvious, given the subtitle of the book is “Designing, Building, and Deploying Messaging Solutions”. But modern integration isn’t just about asynchronous messaging. We have REST and gRPC APIs now, which aren’t the solution to everything, but are a firm part of the integration mix.
Canonical Data Model - this is mentioned throughout. Whoops! This was a bit of an architects’ dream, from the days of centrally-planned architectures. In my experience, it was never practically implemented. How do you make updates to a canonical schema without upsetting everybody? See: Conway’s Law.

Verdict

Score: ⭐⭐⭐⭐ (4 out of 5)

If you are an integration architect, especially if you are architecting solutions with Apache Camel, I strongly recommend this book.

Although you probably won’t find the code samples useful, the patterns in this book are close to timeless, and can still be applied to problems over 15 years later.

A word of warning though: This book carries a hefty price tag!

But make no mistake, this is a comprehensive book. In my edition, it runs to almost 700 pages. It’s not a book to read cover-to-cover, but a book to dip into and use as a reference.

It sits in a prime position on my bookshelf and I think it’s essential!

Have you read the book? What did you think? Feel free to drop your comments below.