Enterprise Integration Patterns: Designing, Building, And Deploying Messaging Solutions By Gregor Hohpe And Bobby Woolf

Over the weekend, I finally finished reading Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by coauthors Gregor Hohpe and Bobby Woolf. I've been reading this 700-page tome since the beginning of February. And, while there were two chapters at the end that I skimmed, I basically read it from cover to cover. And, as crazy as this may sound, I found this book to be thrilling! Even as someone who has almost no experience with message queues, I thought that the writing in this book was clear, approachable, and very consumable. Published 15-years ago, the content of the book lacks references to any of the "new hawtness", such as Amazon's Lambda Functions. But, the patterns come off as timeless; and, I'm sure that they are just as applicable in 2018 as they were in 2003.

The book is composed primarily of flow / interaction diagrams and prose describing various messaging patterns and system architectures. There is also some sample code accompanying many of the design patterns. But, unlike most technical books, where the sample code drives the concepts home, I actually felt like I got very little value out of the code snippets in Enterprise Integration Patterns. I attribute this to my complete lack of experience with message queues.

But, I also attribute this to the relative sophistication of the messaging solutions in the book. While the book tries not to tie itself to any particular messaging technology, all of the technologies that it does use are large Enterprise solutions, complete with GUI (Graphical User Interface) tools and in-built functionality for several of the design patterns. As such, it was hard to reconcile the code in the book against my own mental model for calling Amazon's Simple Queue Service (SQS) with little more than a polling HTTP request. The level of tooling sophistication in the book is just far greater than anything I've seen anyone use in my own sphere of experience.

As such, I focused primarily on the concepts of messaging and I am trusting that I will be able to overlay the applicable patterns on whatever technology I end up using. I know that at work, we will be using Apache's Kafka in our microservices architecture. And, from what I know so far about Kafka (which is honestly very little), it seems that all of the right ingredients for messaging are present.

While reading the book, I kept thinking back to a wonderful talk by Rich Hickey titled, "Simple Made Easy". In his talk, Hickey states that you should be using message queues extensively in order to keep applications "simple" and to prevent different processes from becoming tightly coupled:

I think Enterprise Integration Patterns really codified just how extensive the term "extensively" could be. The book opens-up with a brief walk-through of an Order processing system that sells Widgets and Gadgets. And, by the time the walk-through is done, the authors have outlined an architecture with something like a dozen message queues covering splitters, aggregators, translators, content-based routers, point-to-point communication, publish-and-subscribe events, channel adaptors, content enrichers, and "process manager" abstractions.

To be frank, the Widgets and Gadgets example was extremely intimidating - their intro chapter was far more robust and advanced than anything I've actually built myself. But, I'm happy to say that as I continued reading through the book, more and more of the original example started to make sense.

If I had one complaint about the book, it's that I walked away not really understanding how all of these various points-of-interaction get implemented. For example, if I have to create a "message translator" that alters the structure of a message, where do I do that? Is that part of the messaging infrastructure itself? Or, is that a microservice that I build and deploy? Or, could I implement something like that as an AWS Lambda Function?

I believe that the answer to all of these questions is, "Yes." Meaning, it could be any or all of these approaches, depending on the technology that you choose. From reading the book, I got the sense that the giant "enterprise messaging" solutions actually have some of these capabilities built right into the core product - solutions where you can build message translators with a drag-n-drop GUI tool. But, of course, if I only have Amazon's SQS, then I think it's up to me - as the developer - to build a service that pops messages off of one queue, creates a new message with the desired structure, and then pushes that new message onto another queue.

Now that I've read Enterprise Integration Patterns (EIP), I feel like I want to go back and re-read RabbitMQ: Patterns For Applications by Derick Bailey. From what I recall, Bailey did an excellent job of distilling the EIP concepts down into lessons that are geared specifically for RabbitMQ. And, now that I have a lot more of the messaging theory crammed in my little brain box, I think re-reading a discussion on a technology-specific implementation will really help bring some of the finer points together.

There's no doubt that deploying one service is easier than deploying two services that communicate over a message queue. But, the reality is, more and more application architectures are moving in that direction. And, now that we have so much processing-on-demand available to us, I believe design patterns for messaging are only going to become more important. As such, I recommend taking a look at Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. No doubt, it's a massive book. But, even if you just look at the patterns and let them marinate in the back of your mind, I think there's much value to be had.

Short link: https://bennadel.com/go/3423

Reader Comments

Abu Davis Jul 15, 2019 at 9:05 AM

1 Comments

Good article, thanks for sharing. Middleware integration always has been a very interesting topic; sometimes not a bad idea to be the man-in-the-middle :P

Ben Nadel Jul 15, 2019 at 9:11 AM

15,674 Comments

@Abu,

Yeah, this is really a topic that I need to start using more. Right now, it's been largely theoretical for me.

Oh my chickens, this post is old!

Hit me up on Twitter if you want to discuss it further.