ESB Prospects
Despite all the attention paid to the ESB concept lately, there is some other movement in the integration market that appears to move away from the ESB/hub-and-spoke concept. This movement appears to move away from the concept of a central entity that integrates the other entities. Some experts argue that with the general adoption of the WS-* specifications (also called wizees, a set of open Web service standards that are part of the Web Services Architecture), the ESB will become obsolete, and the endpoints will be independent of any central entity responsible for the integration. As soon as most systems and platforms support the WS-* specifications, the need for a central piece of middleware to supply the major integration tasks could disappear. The different services in such an architecture act more in a peer-to-peer mode, as opposed to the more client-server mode behavior we see in an ESB architecture. Some argue that SOA has the philosophy to expose the endpoints as equal and free members of the IT landscape. Each endpoint is visible and addressable. Endpoints can enforce security or transactions by providing a usage policy (WS-Policy) that contains corresponding assertions.

BizTalk Server 2004 has an adapter available for the WSE 2.0, the Web Service Enhancements. WSE 2.0 is Microsoft's second version of their "SOA SDK," and it offers support for the WS-Security, WS-SecureConversation, WS-Policy, and WS-Addressing (among others) specifications through .NET classes and tools. By using this adapter, support for a wide range of WS-* specifications can be added to any BizTalk 2004 implementation.

However, we are still at a point where most systems and platforms do not support the WS-* specifications; this makes it hard to pursue a peer-to-peer-like architecture based on standards. So even in the scenario where there is a preference for the WS-* specifications, an ESB may still come handy as a temporary solution to provide the capabilities that can also be found in the WS-* specifications.

Conclusion
The answer to the question of whether or not there is an ESB solution based on Microsoft technologies depends on your definition of what an ESB is. Even the people promoting ESBs as the new silver bullet are not unanimous on whether an ESB is a product or whether it is an architectural style. Some people feel that the combination of BizTalk and Web services is in fact a superset of an ESB. Based on the definition in this article, it is not truly an ESB since a majority of the functionality is deployed as a unit instead of being compartmentalized into discrete applications.

However, the extensive support for Web service standards in the 2004 version of BizTalk makes it a good step towards becoming Microsoft's implementation of the ESB concept and capabilities. Although purists may still point out that the capabilities of BizTalk are not separately deployable service containers, using BizTalk as the backbone for an integration architecture can turn out to be a future-proof choice. You are not implementing a full-blown ESB, but for the Microsoft platform it is as good an ESB as it gets. Besides that, a decision to use the extensive support of open standards and the WS-* specification support BizTalk offers (through the WSE 2.0 adapter) is always a good choice.