Architecture of the Microsoft ESB Guidance

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The Microsoft ESB Guidance consists of a series of interoperating components that support and implement a loosely coupled messaging environment that makes it easier to build message-based enterprise applications. The services and components fall naturally into the following six categories:

  • Web services. These expose internal services such as itinerary processing, exception management, resolution of endpoints and maps, BizTalk operations, UDDI interoperation, and transformation of message content.
  • Itinerary services. These include agents for performing transformations and message delivery. You can create custom services that participate in Itinerary processing.
  • Itinerary on-ramps. These receive external messages using either SOAP or Windows Communication Foundation (WCF). On-ramps expose the itinerary SOAP header and perform itinerary processing; they use the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  • On-ramps. These receive external messages in a range of formats and transports, such as HTTP, JMS, WMQ, FTP, Flat File, and XML. They are typical BizTalk receive locations that optionally use the Microsoft ESB Guidance interop pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  • Off-ramps. These implement send ports for the delivery of messages using formats and transports such as SOAP, WCF, JMS, WMQ, FTP, HTTP, Flat File, XML, or any other custom formats. They are typical BizTalk send ports that optionally use the Microsoft ESB Guidance interop pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  • Exception Management Framework. This includes the exception Web service, the exception management API, and components that enrich, process, and pass exception details to the ESB Management Portal.
  • ESB Management Portal. This provides registry provisioning, exception mediation, alert notification, and analytics.

Many of these components and services rely on features implemented by BizTalk Server 2006 R2, such as the Orchestration, Transformation, and Business Rules engines and the Message Box database. Figure 1 shows a schematic view of the categories; the components and services typically occurring within each category; and the core BizTalk system components used by the Microsoft ESB Guidance.

Ff650241.259a24ef-097a-4b5a-bd53-248468eebb43(en-us,PandP.10).png

Figure 1
The architecture and components of the Microsoft ESB Guidance

How the ESB Works

The Microsoft ESB Guidance accepts inbound messages and operates on them, perhaps (but not always) by performing processes such as transformation, delivery, or any other custom defined process. To specify the operations required, the core processing components require message to contain associated instructions or metadata that define the processes to apply and the tasks to execute with the message content.

This approach provides loose coupling between services, meaning that the ESB does not require prior knowledge of the specific processing for each message. It just has to know what the possible range of processes is and how to apply each process. The wide range of options for specifying the available processes and the mapping between the processes and the instructions within messages provides a flexible mechanism for configuring and adjusting behavior, without requiring changes to code and redeployment of components.

Design Patterns

The architecture that ESB uses, where processes deposit messages in the Message Box database and subscribers pick them up based on a processing instruction in the message, effectively implements the state-machine design pattern. In addition, the ESB implements and exposes its core functionality in a services-oriented manner, including to external applications through a set of core Web services.

This loosely coupled approach to designing BizTalk and ESB-based applications yields highly scalable solutions and has become an industry-accepted best practice.