ESBs and Microsoft

Day four at TechEd and spent this morning in a session on "Developing the Next Generation ESB on the Microsoft Platform" which was a case study of sorts of a project donw at Kaiser Permanente.

They (three speakers shared the podium) started the talk with a discussion of just what is an Enterprise Service Bus? A 2006 survey found the following characteristics as most important:

Message Broker

Message Transformation Service

Message Validation

Message-Oriented Middleware

The Microsoft speaker then noted that given this list Microsoft will not come out with an "ESB product" because they feel their products are already a superset of the tools required with BizTalk, VS, MSMQ, SQL Server, Host Integration Server, and MOM, along with the guidance they are putting out.

What was interesting about the talk, highlighted by Brian Loesgen, was that for this particular solution that can be used to literally connect thousands of applications, they created a Core ESB Engine that features an envelope (schema) that specified at the meta data level the kind of message entering the ESB as well as what needed to be done with it. From there they dynamically performed both mapping and runtime endpoint resolution (routing). In other words the architecture supported adding new maps and new endpoints without recompiling or redeploying any part of the ESB. In addition they developed a message oriented approach to exception handling whereby developers publish exception messages and handlers (for example SharePoint) subscribe to them. This allows for highly targeted process-specific handlers to be created for custom exception recovery operations.

The final speaker from Kaiser highlighted the client and server integration modules (CIM and SIM) that they use to provide abstraction for clients and servers with regards to policy, location, management, security, etc. The CIM is analgous to our Service Agent Framework while the SIM is used for interoperability as well since they support both SOAP invocation of services as well as the use of BizTalk adapters and other custom mechanisms. He also briefly showed their management console they can use to monitor services and develop SLAs.

Now obviously an organization could build an ESB in this way and the architecture seems more than solid. The problem, and why an organization might be driven to adopt another vendor, is that this solution was developed with the help both of Microsoft and a systems integrator at I'm sure a significant cost in terms of time and money. For smaller organizations or those that can't invest the time required to develop such a solution going to these lengths is not really an option.