Enterprise Service Bus (ESB): a critical part of SOA

SOA deployments could end up having large number of services and similar number of servers hosting these services. Such system would have many business process servers, coordinating the business activities using available services. It may also have several web/application servers and other systems to provide user interaction, etc, which communicate with various services hosted in the deployment. Such SOA deployment would look like the below diagram, where there are large number of components and even larger (possibly unmanageable) amount of interconnections.



Figure 1: A deployment with front end web servers, process servers running various business processes and set of servers with business systems (e.g. HR systems, inventory). Note that these business systems may be wrapped as services (e.g. web services).

It's obvious that an improvement is needed for such deployments. But, let's first consider the problems with this type of system. In this deployment, each and every component (service, BPMS, web server, etc) is directly connect with other components. So if we want to change one component (e.g. move a service to a different server), we have to reconfigure all the components connecting to that component. Another major problem is that, it is very difficult to get an idea about how different components are interconnected, once the system is deployed. We have to study the connections between each and every component (by examining their configurations, etc) to get a complete view on the system. Therefore, troubleshooting the deployment and introducing new components would be a tremendously painful process. Added to these complexities, we have very limited control over the messages passed between the components. For example, different components may react differently to failures and components may use different payload formats and other attributes.

So it is clear that we have a problem. One part of the problem is due to the large number of components making up the SOA deployment. We can't do much to prevent the number of components from growing, as it is a natural consequence of expanding the business units or organizations. But, of course, we can do a lot to better organize and manage the growing number of components, which I am hoping to discuss later. For now, let's consider the other part of the problem. That is the exponential increase of connections between components. There is a neat way of solving this problem, which addresses almost all the problems mentioned above and also provides lot more benefits. That is to use an Enterprise Service Bus (ESB) as the backbone of all the communications of the SOA deployment. The simple idea is:

(1) Do not make direct connections between components
(2) Connect all the components to an ESB (or to multiple ESBs)
(3) Configure the ESB to route messages between components

Again, there are no strict rules. Decisions like how many ESBs to use in a deployment, how to configure ESBs, whether a direct link is preferable in a particular situation, etc are mostly depend on the requirements of the deployment. Let's consider how we can construct above architecture using the WSO2 ESB. We can easily build this using the feature called proxy services, which acts as a virtual service hosted in the ESB. Once a proxy service is configured, it provides an endpoint similar to a real service, so that external parties can invoke it. But internally, the ESB can be configured to do whatever we want with the message. In this case, what we can do is to create proxy services for all the components in the SOA deployment and configure those proxy services to direct the messages to the actual services. Then we have to configure all the components to interact only with the proxy services defined in the ESB. So we effectively end up with the architecture mentioned in above 3 steps. SOA deployment after the introduction of the ESB is shown below.



Figure 2: SOA deployment after introducing an ESB. Note that two new components, an administrative server and a central log is added, which are difficult to support without this type of architecture.

So, how do we gain advantages over the previous deployment. In this architecture, all the interconnections are handled through the ESB. Therefore, if we want to relocate a component, it is simply a matter of changing the configuration of its proxy service. We don't have to touch any other components. The next problem is getting a detailed view about all the interconnections in the SOA deployment. In this architecture, all the messages are passed through the ESB. Using the ESB configuration, we can enable logging at all required points with necessary level of details. These details could be client address, target address, message type, etc. Then we can analyze these logs (with the support of visual tools) to get an in-depth knowledge about interactions in the SOA deployment. Next, we can easily impose constraints on message formats passing through the ESB. ESB can be configured to examine all or required set of incoming/outgoing messages and perform desired corrective actions on malformed messages. These actions may include reformatting the messages on-the-fly, dropping the message and sending an error message to the client, blocking the client and informing an administrative service, etc. This type of ESB based deployment also gives us more control over the errors and failures within different components of the SOA deployment. Different components may react differently to errors occurred while processing requests. But in this type of deployment, all those error messages (possibly in different formats) are sent to the ESB. So we can gain overall control of such failure situations and configure the ESB to take necessary actions. These could be one or combination of actions like redirecting the request to another similar component, temporarily block the failed component, sending an error message to the client, logging the error according to standardized format, etc. Whatever the actions are, they can be configured centrally with a clear view of the overall architecture, so that the SOA deployment reacts consistently and gracefully to failures.

Use of ESBs could provide much more advantages to SOA deployments than mentioned here. But if a SOA deployment is experiencing the problems addressed above, it is time to start evaluating how an ESB fits in to the picture.