Distributed ESB - The Bus is the Network
This entry comes from a discussion I was involved in with a group looking to build a widely distributed ESB. The question started out around how to have a distributed NMR (Normalized Message Router) in Open ESB. But the real meat of the conversation was around how to communicate between geographically discrete nodes in an enterprise spanning ESB. If you don't know about Open ESB, you can get all the information you need at http://open-esb.org.
A lot of ESB implementations solve the distribution problem by using a JMS solution as the message store. By using JMS, you get message persistence and the ability to have any node that can connect to the JMS server pick up the message and process it. On the surface this looks like a solid solution. And in some cases it is. Especially in cases where the ESB is mostly local and owned by a single organization (maybe even a single business unit).
The problem arises when you need to have an ESB solution that spans organizational or geographic boundaries. One of the biggest problems in JMS (and MOM solutions in general) is the fact that there is no defined wire protocol. All JMS clients require the use of the appropriate client libraries in order to interact with the JMS server. They also require that specific well-known ports are open outside the firewall. The particular ports vary depending upon which JMS vendors are used. When you have nodes distributed all over the globe and owned by different business units and organizations, this can be quite problematic. Each node must have all of the client libraries required by all of the JMS providers used in all of the other nodes that may potentially be communicated with.It is also necessary to know all of the ports that all of these JMS servers are listening on.
Ouch.
So when implementing a widely distributed ESB, what is really needed is a generic wire protocol to use to exchange messages between nodes in different silos (business units, organizations, networks, or maybe even different continents). One potential candidate would be HTTP. HTTP is a simple, well defined protocol used on standard TCP/IP networks. It doesn't require any specific client libraries in order to publish or receive a message.And there is a single well known port to connect to (mostly).
This is the point in the conversation where the group we were talking to brought up the fact that HTTP is a request/response protocol whereas JMS is not. Much of the communication across a widely distributed ESB is asynchronous (actually from a practical standpoint ALL communication across a widely distributed ESB should be asynchronous). So it would seem that HTTP is not a very good choice in this case.
I would respectfully have to disagree.
The communication we are talking about is between ESB nodes; not an external service consumer and the ESB. When a message is sent from one ESB node to another, the only response the target node needs to make is an acknowledgment that the message has been received (or a no-op if you don't care). When the remote node is finished processing the message, it will initiate a new communication with the original ESB node and send the response. There needs to be a correlation id associated with the message in order for the original node to complete the process the remote request was part of.
This is not fundamentally different than the case with JMS. There are two ways to get a response with a JMS message. You can set up a temporary destination as the reply queue or you can have a well known destination from which a response is read. In the former case, the temporary destination is used as a synchronous response. In the later, the message needs a correlation id in order to be associated with the asynchronous request. For all intents and purposes, this is the same as the HTTP case described above.
In many cases these calls to external ESB nodes (service calls) are orchestrated by something like BPEL. Using BPEL makes the use of correlation Ids easy and supports long running processes.It isn't required that BPEL is used. But it is one of the options and has built in support for message correlation.
I am not sure that the group we talked to walked away from the conversation 100% convinced. But I think that after they have time to digest things and internalize them. They will agree that it is a viable option.
Relating all of this back to Open ESB, the nice thing is that there is a choice. You can configure your external calls to use any type of communication you want. I will talk more about that in an upcoming entry.
