Enterprise Service Bus (ES is an integration platform that facilitates the integration of various systems/applications using a common communication backbone and a set of available platform services.

The resources could be a Java/J2EE application, a .NET application, Web Service, Message Queue, FTP server, databases such as Oracle, etc.

In large organizations it is often the case that applications have been  built over time to serve specific business needs and use different technologies (j2ee,.net, etc). You are faced with a challenge of "talking" to these different resources and providing a new set of services (tied to some business need of course). You could roll up your sleeves and write code to do all of this. Or you could take the help of a ESB product that provides you an umbrella under which you can implement your new service(s).

Let me come up with a mock business scenario:

• Talk to a J2EE application and get the status of inventory for a certain product. This is via a EJB interface (stateless session bean).
• Talk to a .NET application to find out current vendors, who we have contracted with, to purchase products.
• Send an email approval request to a requisition manager and wait for his approval before proceeding with the purchase.
• Once approved, send the order to vendor-A via ftp. Vendor-A loves FTP and comma delimited text file formats. So we need to transform the message to their needs.
• Monitor recepit of a file from vendor-A which says "yes we received the order...we expect to ship it on blah date". 
• Send an XML document with transaction details (via Web Services) to the payment processing system to approve payment for this order.
• We need to make sure everything is audited. 
• One last thing....only authorized users can perform these steps. Integrate with the cooporate LDAP server for authentication needs.

Well in the real world there is probably more to it, but you begin to get the idea. Now lets map out what we are up against from a technical point of view:

• The entire process is a workflow with clearly defined tasks happening along the way. So we need a way to describe the business process and orchestrate the entire flow.
• The workflow has a manual task in there (manager approval). So this is a asynchronous workflow that can take many days to execute.
• Distributed applications and technologies (j2ee, .net). 
• Different communication mechanisms (web services, EJB/RMI, FTP, email). 
• Data transformation is required at various steps.
• Security. Only authorized individuals can use this system. How do we interoperate the different security mechanisms used.

It is entirely possible for us to build this from scratch. But it is a significant effort. Why not use a ESB framework that facilitates this. An ESB framework provides many of these infrastructure services so that we may concentrate on implementing the business process.


 An ESB framework supports:

• An SOA based architecture to build services.
• A reliable messaging backbone (or bus) via which the various resources can communicate. Earlier I listed some types of resources. They were all external to the ESB. You could also have resources internal to the ESB, like specific business components residing inside.
• A message routing mechanism so that messages flow from one resource to the other. No more direct resource to resource links (via code).
• Content based routing. 
• Data transformation. Change one XML document to another XML doc with different schema or from XML to a comma delimited text file.
• Provides adapters which deal with talking to resources, thereby saving you the trouble of writing resource specific code.
• Adapters also perform marshalling and unmarshalling of data between the resource and the message bus.
• A business process modeling language and runtime to manage business workflows (BPEL).
• Transactional services.
• Security.
• Supports open standards such as Web Services (SOAP, WSDL, UDDI).
• Supports various communication mechanisms such as FTP, Secure FTP, CORBA. RMI, REST, HTTP, SSL, SMTP, etc.
• Some ESB's will also provide support for SOA Governance. This allows enforcing and tracking service usage.

When do you need an ESB? If your application topology (and requirements) starts looking like the diagram above (minus the integration bus of course) then you need one.