BizTalk Server is often positioned as a means to create a hub-and-spoke architecture. However, the popularity of the hub-and-spoke architecture, the traditional model for enterprise application integration (EAI), is declining. More and more architects and CIOs are targeting SOA (service-oriented architecture), and its infrastructural incarnation: the enterprise service bus (ESB). Does BizTalk fit into this ESB picture?

Integration Architecture
Trends and hype like SOA, EDA (event-driven architecture), and BPM (business process management) put integration on top of the list for most CIOs and IT managers. While all these trends hold assumptions about the ideal architecture for distributed computing, the differences in architectural approaches are not as clear to decision makers. Add that to the rapid changes evolving in the Microsoft platform, and it is easy to see that BizTalk Server 2004 can be positioned in different ways in your integration architecture.

In this article we are going to look at two different approaches for integration architecture, and we will see how BizTalk Server 2004 fits into these concepts.

Hub-and-Spoke Architecture
The first dominant integration architecture that broke with the cumbersome point-to-point application integration model was the so-called hub-and-spoke architecture, often referred to as "message broker."

Hub-and-spoke architectures consist of a centralized hub that accepts requests from multiple applications that are connected to the centralized hub as spokes. The spokes are connected with the central hub through lightweight connectors, which are constructed and deployed on top of existing systems and applications. One of the key goals of the hub-and-spoke architecture with connectors is to leave the current systems untouched and unchanged as much as possible.

Inside the hub there are capabilities for requirements such as message transformation, validation, routing, and asynchronous message delivery. Furthermore, most hub-and-spoke-based EAI solutions provide process management functionality to orchestrate interapplication message exchanges, and an administration console to monitor and track the workings of the hub.

See Figure 1

This integration architecture is the more traditional approach to connecting systems, and has been widely adopted because of its strengths:

• It provides a focal point for applications and reduces the links between applications from n^² links to n links
• The hub provides a layer of insulation and functionality between the spokes, thus enabling spoke applications to be removed and replaced without other spokes being disrupted in any way
• Because of this simplification of connecting applications, the model offers lower total cost of ownership

Despite its indisputable advantages and merits, hub-and-spoke models are not as popular as they used to be. One major problem is that the centralized hub presents a single point of failure in the overall architecture. If the central hub goes down, not a single message can still be sent or received. Attempts to overcome this problem by clustering multiple implementations of the hub are often stranded on the complexity of the architecture and on the overhead in administration.

Another important reason for this decline is that most hub-and-spoke-based EAI products are monolithic, expensive systems (especially when multiple implementations are deployed), based on proprietary standards. With the emergence of SOA, which is heavily based on open standards and loosely coupled, constituent services, the time has come for a new dominant integration architecture: the enterprise service bus.

The ESB Architecture
The ESB is often characterized as the backbone upon which to build SOA. There are numerous articles and white papers about the ESB, and they all have the following elements in common when describing what the ESB is: an ESB is seen as a distributed services architecture based on Web services standards, which delivers messaging middleware, intelligent routing, and XML transformation in conjunction with a flexible security framework and a management infrastructure for configuring, deploying, and monitoring the services. A typical ESB architecture looks somewhat like Figure 2.

At the heart of the ESB architecture is the enterprise services bus, a collection of middleware services that provides integration capabilities. Applications are connected to this logical bus through smart connectors, which encapsulate system functionality and provide a layer of abstraction between bus and application. In this smart connector we may find typical capabilities such as transformation services and security services. Through the use of open communication standards, connectivity between bus and applications is established.

The aforementioned description points out that an ESB is more a logical concept than it is a product. There are some vendors claiming that ESB is a product, but this perception comes more from a traditional view of integration architecture, which is based on products instead of standards.

One way or another, experts and analysts unanimously agree that for those companies and organizations pursuing an SOA or an EDA, the shift towards an ESB-based infrastructure is a major step in this evolvement.

Hub-and-Spoke vs ESB
An ESB provides the same functionality as a "traditional" broker in a hub-and-spoke architecture. The pictures we have seen of both the hub-and-spoke architecture and the ESB architecture are also very much alike. 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 overbloating 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.