What is an ESB

The ESB term is confusing and perhaps over-hyped – but at its core – it is a messaging system (such as ActiveMQ, RabbitMQ or MQSeries) along with an integration framework such as Apache Camel or Mule – and it is a way to declaratively connect up web and other services.    So, if you had multiple web-services – you could write XML to query one, plug the results into another then insert the results into a database.    So, you can be rid of the ‘donkey’ work of generating Java classes from the WSDL using AXIS2 – then the code within your app to use the service, handle errors etc.

Also, it is a way to decouple the applications from their integrations – so e.g., when a new employee is hired, the HR app can post a message to the ESB, then the ESB can route it to all other interested apps, either the message itself or via a web-service call.  So the HR app is not concerned with who is interested in this info.  The other app – especially if it is called via a Web-Service call from the ESB, is not concerned about the HR app – thus they are ‘decoupled’.

Another use to allow a ‘service provider’ to upgrade their service to meet new requirements – but allow (via the ESB) older clients to keep using the same service.   The ESB would allow you to declaratively map/adapt the call from the old client to the new one – and vice-versa – i.e. the response could be mapped/adapted to the XML the older client is expecting.

So, you are not stuck with having to maintain multiple versions of a service.

Camel comes out of the box with about 80 connectors to end-points other than SOAP – HTML scraping e.g.   Mule has even more and even more third party ones.

Then, on top of all this, you can also use products that will allow you to declaratively setup and control business processes such as approvals etc.