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.
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.
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:
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).
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:
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:
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.