Enterprise Integration Patterns

I picked up a copy of Enterprise Integration Patterns and I’ve really been enjoying it. In the coming weeks, I’ll be exploring the patterns presented in this text along with code samples.


Enterprise software integration sounds, on the surface, like a nightmarish hellscape that one would avoid at all costs. Which, in a way, it is. Unfortunately, there are a number of ways in which the wise developer can find themselves in this very situation. The EIP text does a great job of illustrating this in the first couple of chapters - which I honestly found illuminating. Here are a few examples of how an enterprise can end up with disconnected and disjoint systems:

  • Acquisition of another company
  • Independent technology choices from business units
  • Legacy vendor lock + incremental technology improvement
  • Supplier system integration
  • etc

Each of the above, through no particular fault, can lead to a potentially messy integration situation. The EIP text describes an example of a single common business process - updating a customer address - that may need to notify several different pieces of technology within the organization.

As can be implied from the name, the authors believe messaging systems to be the best compromise between flexibility and efficiency for most situations. Regardless of that, I think they are an interesting type of system to study. The concepts of data flow, pipes, and filters translate into many other software development situations, large and small.

Follow Along At Home

For the EIP series of posts, I’ll be using RabbitMQ as my message system of choice. I chose RabbitMQ because I have worked with it before, it’s broadly supported (AMQP clients are available for many languages), and it was available on Arch in the AUR. For the client code, I’ll be using Groovy - because I like it :-)

Install RabbitMQ as described in their excellent documentation, changing any defaults that you need. Be sure to make note of port number or credential changes you make so you can make similar changes to the sample client code.

I would absolutely recommend enabling RabbitMQ’s management plugin. This plugin exposes a web interface for inspecting queues and exchanges, as well as inserting messages, inspecting client connections, and more. It ships with RabbitMQ by default, so you just need to enable it:

# rabbitmq-plugins enable rabbitmq_management

For the client side of things, I’ve added a section to the blog-snippets repository on GitHub.

For this post..

For this post we’ll just do some very basic exploration to get a feel for using RabbitMQ with Groovy.

First, once you’ve got RabbitMQ installed and running, add a queue named ‘eip-one’. This queue should be marked transient, meaning it will be purged when the server restarts, and auto-delete should be false.

Adding a queue

If auto-delete is specified, the queue will be deleted once a client has connected and then all clients have disconnected. This means a single test-run would nuke the queue - not what we need for our purposes.

With this queue in place, the sample code for ‘HelloClients’ can be ran. You’ll see some activity in the queue monitor (and a flood to standard out):

Queue activity

For the HelloClients sample to run, be sure the Main::main method looks something like this:

static void main(String[] args) {
    logger.info("Starting HelloSample")
    HelloSample sample = new HelloSample()

In the sample code referenced above, I’ve used a QueueingConsumer instance. In future samples, I will be subclassing DefaultConsumer for better control over the behavior. This also provides an event-based structure rather than the polling seen here.