Enterprise Service Bus (ESB) - What and Why?

What is Enterprise Service Bus (ESB)?

SCA foundation is built using ESB Infrasture layer to enable "Separation of Concerns" which facilitates the client to become free from knowing and implementing so many details, which the client would be forced to do otherwise.

Example: Let's assume there are two business processes BP-1 and BP-2 and we have a requirement saying that BP-1 should get called only when the value of a certain input variable is greater than 500 otherwise BP-2 should get called. Without ESB how would we do that? By stuffing that logic in the client code. We will check that variable at that end and call either of the two web services implementing BP-1 & BP-2 based on the value of the input variable under consideration.

With the help of ESB, we don't need to do that at client side. Actually ESB infrastructure forms another layer between the client and the actual Web Services and all such tasks are performed at ESB layer, which makes the implementation far more maintainable and stable.

Another example scenario can be where an input variable needs to be transformed before the service gets called and the service should accept only the transformed value. In addition the response may also need to be tranformed back to some other format before being given to the client. Let's say the client accepts only Pin Code numbers whereas the service requires the area name associated with Pin Code and not the raw pin code number. We can achieve all such transformations quite easily and effectively using the ESB Infrastructure.

Why ESB?

Well... There are quite a few reasons. Some of them are:-

• Virtualization - You don't require to maintain the URL of the actual Web Service. What you require is to know the URL of the ESB, which will act as the Web Service for the client. The ESB will route the request to the appropriate URL and return back the response to the client.
• Transformation - The data in the request can be tranformed easily and effectively before being set to the actual service and similarly the response can also be tranformed before reaching the client.
• Routing - The requests can be filtered at the ESB layer and based on the implemented Routing Rules they can be forwarded to the desired Web Service URLs. This routing can either be content-based or header-based. An example of content-based routing: an input variable is checked and let's say if that variable has a value '1' then the request will be forwarded to an external Web Service whereas the value of that input variable as '0' will route the request to an internal Web Service for faster performance or any other reason. Similarly an example of header-based routing: if the request is coming from '*.abc.com' frward it to an internal Web Service otherwise route to an external Web Service.
• Validations - ESB layer can be used to validate the request XML or response XML against selected XSDs. Validation based on an XSD is a relatively performance intensive task, so now the valiadtion can also be done against a 'Schematran (.sch files)' for better performance. SCH has also become a standard for Open-SOA now.
• Event Handling - At ESB level you can either subscribe to or raise business events. For example, let's say the business requirement is such that as soon as a new customer is added to the system, a business event should be raised for the creation of his/her email account. Using ESB Infrastructure you can easily create, raise, and publish that event which will eventually be received by the component responsible for Email Account creation.
• Interactions - Using ESB you can easily implement Synchronous or Asynchronous interactions between consumers and providers.
• Security Enforcements - In addition to the above advantages, the ESB layer can also be used to enforce security of various levels. Example: you may like to authenticate all the requests coming from a particular domain. You can easily do that using ESB. Far more advanced security measures can also be implemented quite easily using ESB.