To distill the document:
- The author believes ESB is a transitionary stage not a product.
- The author believes the functionality of an ESB is offered by Microsoft in superset of functionality.
I see the ESB as offering the following features:
- Standards based broker
- Publish and Subscribe Queues (including publish once)
- Gauranteed Delivery
- Data Transformation
- Access Control
- Service Mappings
- Service Registry
- Data Caching
- BPM hooks
- Intelligent Routing (Workflow)
- Audting/Error logging
- Monitoring
I have a slide on this but am not sure I'm permitted to publish it online. The Enterprise Service Bus is an architectural pattern, as well as a product class.
From a functionality perspective I agree that Microsoft has the technology to deliver this list, Windows Communication Framework takes this even further.
I have to disagree with the authors point of view that ESB's are a transitionary stage and shouldn't be a product.
The ESB, even when federated with other service buses, provides all the value of a standard integration broker with the added advantage of standards support, but it goes further to provide abstracted functionality thats not system dependent including workflow capabilities, while centralizing service definition and auditing and logging. This is incredibly powerfull in a enterprise environment as it provides distribution and loose coupling for speed and agility while still centralizing for code reuse, standardization, monitoring, and most importantly, governance.
Lastly the ESB provides an opportunity to define a standard colloquial business languange, which can act as an intermediary translator between system specific terminology. This purposes to save tremendous translation work as new and existing systems only ever must be integrated to one "language" rather than the language of each system it must be integrated too.
Because of this abstraction of functionaliy, and centralization of services and governance enterprises can get the optimal ROI for their SOA efforts.
Product stacks fitted into the ESB umbrella are key players in to realize value on this front, as they can provide comprehensive offerings and can extend them to add further value. If each component operates and connects based on standards the component becomes a commodity and the vendor will need to embrace this and look for ways to differentiate by providing further value. Predictive analysis, out-of-the box services, and service throughput analysis are some areas for such value add.
Product stacks also can simplify setup, installation, and maintance to assist in reducing TCO of SOA.
While Microsoft has the peices to create a strong ESB stack it disappoints meet to see this paper miss the mark, rather than suggest Microsoft ESB construction.
