Another key difference is that an ESB architecture supports distributed operation and management, whereas the traditional hub-and-spoke architecture is based on central operation and management. Again, we see that the nature of the ESB is distributed, whereas the nature of the traditional approach is centralized. Advantages of the ESB architecture over the hub-and-spoke architecture are:

• The ESB is more scalable than the hub-and-spoke architecture. Through the ability to deploy separate integration services, scaling up and scaling out becomes easier.
• An ESB is based on open standards. EAI/hub-and-spoke solutions are generally based on proprietary standards.

Hub-and-Spoke
BizTalk Server can be utilized in two different ways in the more traditional hub-and-spoke model: it can serve as a spoke, by providing the integration connector capabilities for connecting systems with the central hub (which in turn can be implemented with another BizTalk Server, or with another technology), or it can serve as the central hub.

When serving as the spoke in the hub-and-spoke architecture, BizTalk's rich functionality for transformation, both at the transport and at the syntax level, can be utilized to expose applications that do not use open standards, but that use proprietary standards and protocols instead. In this scenario BizTalk is the connector that translates the proprietary protocol to the protocol that the hub is speaking.

The first two editions of BizTalk Server, the 2000 and 2002 versions, heavily promoted the use of the so-called BizTalk Framework (BTF), an XML dialect and SOAP extension that was proprietary for BizTalk. As a matter of fact, BizTalk was first released as a server product to implement the BTF specification. Microsoft's vision appeared to be that at both ends, and hub and spoke communicated through the BTF specification. The use of BTF would guarantee easy integration, which allowed for the use of lightweight connectors. It's perfectly clear that this vision has many similarities to the traditional hub-and-spoke model we just described.

BizTalk 2004 more or less abandoned the BTF focus, and introduced a whole different approach to integration: the use of open standards.

Enterprise Service Bus
BizTalk Server 2004 offers great possibilities for integrating with other platforms and systems, through the native support for communication protocols like HTTP, FTP, SOAP, and MSMQ, and by the availability of many adapters for the product. Imagine the scenario shown in Figure 3, where BizTalk provides the infrastructure for a message-oriented integration scenario.

It is interesting to see that external applications can be linked through either a Web service interface (a SOAP Wrapper for example, for encapsulating COM+/C++ objects and EJBs) or through one of the BizTalk adapters that are available via Microsoft or third-party adapter vendors.

The question is: Does Figure 3 represent an enterprise service bus? Does this make BizTalk Server 2004 Microsoft's flagship product for implementing an ESB then? The answer is: it depends on when you call a topology an ESB.

The functionality BizTalk offers cannot be separately deployed across the bus while working together in harmony as necessary, without having to deploy multiple instances of the full BizTalk product. BizTalk's functionality is delivered as an all-or-nothing package. If you just need the transformation functionality, you get all of the other functionality as well. This can easily lead to overbloated services within the service bus. Surely you can have BizTalk Server as one of the ESB services within the ESB itself (refer to Figure 2), but it is usually not cost-effective to deploy BizTalk Server to handle just a single integration requirement (See my article, "BizTalk Server 2004: Too Hot to Handle?" in the May 2005 issue of Web Services Journal). Overbloated services are a serious threat when opting for this scenario with BizTalk.

Certain BizTalk functions can be separated however, for instance: you can have a BizTalk Server acting as a process manager by executing orchestrations, and you can have a BizTalk Server handling all of the incoming and outgoing messages. Still, it holds all of the other capabilities of the product, e.g., the transformation, validation, and routing capabilities.

When Is an ESB an ESB?
Microsoft's view on the matter is that an ESB is a solution for delivering integration capabilities to the mass market at a low price point, based on open standards. From this perspective, they are indeed offering an ESB solution with BizTalk. Compared to other products and solutions out there, Microsoft is offering all required ESB integration capabilities for a fairly low price. However, all other vendors and independent analysts will argue that the monolithic nature of BizTalk, with regard to integration services, disqualifies it as an incarnation of the enterprise service bus.

Besides this distinction with regard to what exactly an ESB is, BizTalk Server 2004 offers the possibility of making the distinction between orchestration tasks and messaging tasks for a BizTalk Server. Simply stated, a BizTalk Server in a group can act as a messaging node, as a processing node, or as a combination of the two. This opens up the possibility of separately scaling the messaging cluster and the processing cluster as needed. Still, there is no possibility of deploying the transformation service or the monitoring service though, but at a higher level BizTalk can be seen as two separately deployable services: messaging and processing (orchestration).