Enterprise Service Bus
An Enterprise Service Bus (ESB) can have either a traditional hub-and-spoke architecture or a distributed, peer-to-peer architecture. Hub-and-Spoke systems are easy to administer but difficult to scale, since as processes are added the hub becomes a communication bottleneck. Most ESB’s are based on a peer-to-peer architecture allow hardware resources scattered across the network to be effectively utilized to balance load and scale the number of processes running concurrently.
According to definition in Wikipedia, An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary
ESB provides the same functionality as a “traditional” broker in a hub-and-spoke architecture. The key difference however is that the capabilities in an ESB are themselves SOA-based, since they are spread out across the bus in a distributed fashion, and the capabilities are hosted in separately deployable service containers. This is a fundamental difference in architecture.
The distributed nature of the ESB Services allows for the selective deployment of integration broker functionality exactly where you need it, with no additional overheads where it’s not needed. The ESB container model allows for the independent scalability of integration components, which are plugged into your SOA as event-driven services on an as-needed basis.
Now what is SOA? Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. SOA seems to have its roots in how Business people view IT. They tend to view IT in terms of business functions they support and tend to break it along the verticals like Ordering, Manufacturing, Delivery, Customer Relationship management etc. According to them these functions talk to each other in order do the work. (Wikipedia)
Enterprise Service Bus (ESB) provides an infrastructure to implement this SOA concept. Instead of going back again to point to point integration to implement SOA, ESBs extend knowledge gained in EAI work that simplifies the integration and flexible use of business components. ESBs facilitate standards based integration but are not limited only to do a web services based integration e.g. the messages are not required to use only http protocol for communication. A service consumer can send his request using http protocol but the service provider provides data using JMS. The ESBs make this communication possible. In general, they support message based transport like in EAI and also provide describe and discover facility for service provider and service consumer.
references:
http://en.wikipedia.org/wiki/Enterprise_service_bus
http://software.intel.com/en-us/articles/soa-esb-what-is-all-this/
http://dotnet.sys-con.com/node/121831?page=0,0