Wherever you read about SOA, you see specific mention about ESB. Enterprise Service Bus(ESB) is primarily used for the following:
3. Service Orchestration
4. Service Monitoring
I have seen architects suggest ESB for SOA implementation. This, however, is not right. ESB is not used to implement SOA. ESB is another enabler for SOA implementation. One is recommended not go for ESB if you think that it does not fit in your current systems.
When will you go for an ESB? ESB, as the name suggests, is typically for an enterprise and is used to connect and co-ordinate services. Without services, it would just be a bus. It is thoroughly a technical solution and is the plumbing that you put in place to connect applications. It is no value to business if there are no systems that connect to each other. If you do not have too many systems to connect, and already have a direct connection, then it is best to stick with it than to invest in a middleware.
ESB is an integral part of the road map for SOA adoption. Couple of ways you can get started with ESB:
1. Inserting in to environments where there are services defined but are directly connected. Especially in cases where the connectivity is defined with third party systems. Implementing ESB here would help in terms of increasing flexibility and reduce management overhead and costs.
2. Implementing ESB so as to define additional services, reuse existing services and increase agility
In the long run, it is also good to have a reference architecture which will mandate the use of ESB.
Now that I have listed both sides of ESBs role in SOA, let me also list out some advantages and disadvantages.
1. Flexibility and easy to implement requirement changes
2. More of configuration than coding
3. Security control
5. Easy to integrate existing sytems
1. Standardization of message
2. Introduction of extra layer resulting in increased latency due
3. Useless unless there is plan for adoption of SOA
Paul Fremantle in his write up about ESB quotes:
The single most important aspect of SOA is ownership. The point of a service provider – in real life as well as IT – is that they take full ownership of the problem domain. When I get into a taxi in London or New York, I have a base expectation that the taxi driver speaks English and knows how to get where I want to go. If I have to step into a taxi with a phrase book and map and manage my own route then the Taxi service isn’t offering me a properly encapsulated service.
It is time to reclaim the idea of an ESB to what it should be, a distributed network of services which are universally accessible using standard protocols and well defined interfaces.