Enterprise application INTEGRATION overview

So you have a bunch of applications all running on different environments and maybe even plan on building new ones. Now you need to find a way to communicate with each of these and possibly orchestrate them into some kind of a workflow. Or maybe you are just a nerd like me and find this stuff fascinating
There are a lot of great articles written on EAI. The goal of this series will be to try and organize the various pieces in one place, and provide some context. Then as we become more familiar with the various concepts, we can go through examples on implementing specific pieces.
Recommended Reading
In your research, you may have come across terms such as Service Oriented Architecture (SOA), Message Oriented Middleware (MOM), Enterprise Service Bus (ESB), and Business Process Management (BPM). I could bore you with some terribly generic description of these, or I could provide you with more informative links. Please note that while some of these links may point to vendor products, it does not necessarily constitute an endorsement of said product as it is not the intent of this article.

• Enterprise Application Integration - A good description of EAI and how an ESB would fit in.
• Defining SOA - A good overview to understanding the term.
• EAI Patterns - A lot of the topics that will be covered in this series hinges on understanding the information here.
• Enterprise Service Bus - Good article discussing ESB and providing brief descriptions on topics we will cover.
• What is a BPM - Again, I don't necessarily endorse the product, but the link gives a general understanding of what a BPM is.

Context
Hopefully the recommended reading section provides a good basis on understanding the concepts behind EAI. We'll try to put some context around the concepts with an example. A sample application might do something like this:

• Poll a directory for an xml file
• Split the file into records and put them on a queue to be processed externally
• Gather up all of the results and save them to a database
• Send a report out by email

Seems simple enough, so let's start coding. We already know the merits of design patterns in general, and the EAI patterns look like a good fit. Now we just need to implement them. Our application would consist of PollingConsumers, Splitters, Aggregators ... oh wait, what happens if our xml file gets picked up more than once. Better implement an Idempotent Receiver. Hmmm, and how do we keep track of where we are in the flow. I think we'll need a Wiretap. Almost forgot, we need to add some data to each record. We'll need to add a Content Enricher...
I think you get the point. Things can balloon quickly, and now we have a lot of work on our hands. But wait (insert terrible segway here).
Apache Camel
The good news is that we don't have to implement these patterns ourselves. Very nice people have already done it for us over at http://camel.apache.org. While others such as MuleSoft and Red Hat JBoss Fuse (based on Apache Camel also provide implementations, there is an important distinction between them.
Apache Camel is NOT an ESB. I really can't stress this enough. Apache Camel is a library that implements eai patterns to provide a routing and mediation engine. You just add a jar to your project no different than any other utility such as log4j, xalan, etc. Then you deploy your project, as you normally would, to a container such as:

• Standalone JVM
• Web Container such as Tomcat
• OSGi container such as Karaf.

Ok, I did lie a little. Apache Camel also provides the ability to build your routes through DSLs and comes with a large number of components to help you do your work. I just wanted to drive home the fact that it's just a library and not something that comes with its own container, database, and queueing system.
At this point, I recommend reading Camel In Action It's a bit outdated but still has some great information. For a more recent book, you could also take a look at Apache Camel Developers Cookbook
Enterprise Service Bus
This leads us to ESB. The term seems to have different definitions based on who you talk to. For me, an ESB is a routing and mediation engine that also provides:

• A container to run in
• A reliable message bus
• An IDE or suite of plugins to create routes in
• An integration platform that provides in-depth analysis and management of the containers.

As mentioned earlier, MuleSoft and Red Hat JBoss Fuse are examples of an ESB.
I told you before that Apache Camel is not an ESB, this is still true. But Apache Camel, running in a container such as Apache Karaf, using a reliable message bus such as ActiveMQ, and using Fuse Fabric would indeed meet the requirements of an ESB. In fact, its what Fuse is based on.
NOTE: As mentioned in one of the linked articles, an ESB is not a replacement for processes such as ETL or SpringBatch. Keep that in mind when determining how fine-grained you want to make your routes.
Business Process Management
Apache Camel, and ESBs such as MuleSoft and Fuse all have the ability to create workflows and orchestrations.
BPM Engines also create workflows and orchestrations. This causes a lot of confusion. Unfortunately, this topic is pretty in-depth and I will go into it in a future article. For now, think of ESB workflows as stateless, high volume, and no user interaction. Think of BPM workflows as stateful with the potential of user interaction.
Service Oriented Architecture
At the beginning of the article, we talked about having multiple applications running on various systems. This is where SOA comes in. By implementing all of these applications as services, we can then use our routing and mediation engine to talk to them.
When people think SOA, they generally think of web services, but it doesn't have to be that way. We could use Queues as in Message Oriented Middleware (MOM). The routing engine could put a message on a queue that the application is listening to. In a future article we will get into the implementation of a MoM Adapter.