Building blocks of an Application Integration Framework

Based on my experience working with Mule ESB and Spring Integration, and reading about Open ESB and Service MIX, I realized that they are all based in almost the same concepts and ideas, ideas that come mainly from the book Enterprise Integration Patterns and its companion web site http://www.eaipatterns.com/

I’ll try to introduce here the main elements that constitute this integration frameworks (and ESBs) with main focus on the ones I know the most, Mule and Spring Integration but without implementation specifics.

I won’t get into details defining what an Integration Framework or an ESB are, as it’s not the point of this post. I’ll just say that they allow heterogeneous applications to communicate with one another, and that’s the basic concept.

For the next explanations I will refer to the Integration System in general as ESB although they are not necessarily the same.

Here is a diagram from the EIP web site that shows the different elements I’m explaining later:

The main element is of course the Message. It’s what we want to send across from one system to another. Inside the ESB the messages are usually normalized and encapsulated in a framework specific message, that normally carries the payload of the message and meta-information headers. The message can suffer multiple transformations through the ESB.

A basic interface for a Message in an ESB could be something like:


interface Message<T> {
    T getPayload()
    Object getHeader(String key)
    void addHeader(String key,Object value)
}




The Transformers are in charge of transforming the messages. The transformation can be easy things like adding new headers to the message to more complex stuff like tottally changing the content format of the payload (for example from an XML Soap payload to an Email message). Transformer can be chained to apply more than one transformation to a message, but as a good practice each transformer should just do one only transformation.

A basic Transformer interface would be something like:


interface Transformer{
    Message transform(Message message);
}


The message channels are of course very important elements. Message channels are the links through which the messages pass in their way from one point to the next. Messages are sent to channels which transport them across the different stages in the ESB.
The two most common divisions of channels are synchronous and asynchronous channels. A Channel will usually have two methods one for sending messages, and one for polling for messages


interface Channel{
    void send(Message message);
    Message receive();
}


The Endpoints (also refered to as gateways). The endpoints can be as the connectors, or adapters, that plug the ESB to the outside systems and protocols to enable the communication. There are normally two type of endpoints. In-Endpoints for allow external systems to connect to the ESB and Out-Endpoints to allow the ESB to connect to the external systems.
In-Endpoints have the mission of taking the incoming messages, normalizing it into ESB messages and puting it into the ESB flow.
Out-Endpoint take the message from the ESB flow, strip the ESB message information into the payload and message type understood by the out system and send the message out (of course it can wait for a response and process it further).

Endpoint implementation is specific to the kind of application they want to connect to. For example a In-Endpoint for tcp would be totally different from an In-Endpoint for file systems. The tcp probably would create a Listening server socket and wait for conections, and the file system one would probably poll some folder looking for files.

However they both most convert their messages into an ESB Message and put it in the ESB flow. So a simple interface for and endpoint would be like:


interface Endpoint{
    /**
    * This method will take the Original message as a parameter(for example a InputStream
    *from a socket) wrap it in a ESB Message and put it into the ESB flow.
    */
    void send(Object object);
    /**
    * This method will receive the ESB Message from the ESB, strip the correct payload and
    *return it for it to be send to the external System
    */
    Object receive();
}



Filters and Routers control the flow in a ESB. A filter allows or stops Messages for being further processed based on arbitrary rules. A Router redirects Messages to different channels depending on arbitrary rules.

A simple Filter Base Class would be:


class Filter {
    public void filter(Message message){
        if(accept(message)){
            nextChannel.send(message);
        }
        else{
            discardChannel.send(message);
        }
    }
    protected abstract boolean accept(message);
}


A simple Router Base Class would be like


class Router {
    public void route(Message message){
        getNextChannelForMessage(message).send(message);
    }
    protected abstract Channel getNextChannelForMessage(message);
}



That’s it. These are the main building blocks on which an integration solution is built, of course there is a lot to learn from here. For more detailed information refer to the great projects Spring Integration,and Mule ESB, as well as the book Enterprise Integration Patterns
previously mentioned