Enterprise Service Bus

A very important component of the Service Oriented Architecture (SOA) is Enterprise Service Bus (ESB). ESB is used as a diamond bullet to clean up the enterprise integration spaghetti.

The following are some of the important reasons for using an ESB :

1. Why ESB :

Enterprise Service Bus based solutions are very reliable & robust specially in product development , application development, BFSI domain etc., only the thing is enterprises would have to set up teams to manage the ESB and deal with the governance around the ESB usage

2. ESB and Business Process:

This is one of the major features that attract people to ESB. As a result, the business process gets into the ESB. The ESB now contains the critical business logic of the enterprise, apart from being just an integration backbone. This makes the whole system extra complex with business logic spread all over.

3. Other ESB approaches :

The use of ESB results in a vendor lock-in. Business processes is almost always coupled, using vendor specific languages and products.

Performance is another area where more dollars are spent.

Application performance hit with ESB is significant and requires considerable amount of money to scale. Sometimes, simple transformations that can be done easily with a programming language get implemented as an XSLT transformation.

Some of the ESB products do provide good performance but more money is spent on scaling the infrastructure, without even a thought about the acceptable performance limit. In general, it’s acceptable for domain processes to start running in minutes or even hours. However, with the advent of ESB in the system, the tolerance for the process execution time by enterprise CIOs gets reduced to milliseconds and seconds.

ESB does come with pre-packaged adapters or transformers that may or may not be useful in the project. Hence, occasionally, there is a need for development of custom adapters or data-transformers to be used with ESB, which is an additional effort or learning curve for the development team that is already burdened with strict timelines.

Mostly out-of-box adapters are not useful to the project, the licensing cost for these adapters is an unwanted expense.

Is ESB Useless:

No, as I said in the beginning ESB is not a diamond bullet.

It assists the project in meeting the data transformation and communication requirements. It is a good candidate for dealing with disparate protocols (FTP, IIOP, and SOAP) between the interacting systems.

Most of the times it is preferred to have text based protocols (SOAP or HTTP) between services, which makes the system more manageable.

How do we handle Integration Mess:

Through business modeling we can prevent integration mess. SOA has capabilities to handle it.
As we all know, traditional software models and the business domain is the one that best meets the business requirements. Why can’t we extend this to SOA?

Just model the business interactions between services. If that is spaghetti, so be it. The business itself is running with so many interactions.

If a clean up is required, then the change should originate from the business domain. This business domain change will percolate down and would warrant a change in the SOA model.
I feel that this idea of modeling the business chaos among the services is very much in line with the philosophy of SOA, which promotes the alignment of software systems to the business needs.
ESB alone cannot cleanup the problems that originate in the business domain.

Manageability:

Manageability of the solution or system post-implementation is critical to any client. Although we model the business domain spaghetti in our system, it is critical that the spaghetti be manageable.
Monitoring and control interfaces to manage the complex interactions are essential.
Sometimes this needs a single point of control, and management necessitates the use of an ESB rather than the need to integrate various services.