Understanding Message Flow
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.
This section explains how messages flow through the ESB generated by the Microsoft ESB Guidance. It discusses the overall message flow and provides a detailed description of the ESB Itinerary SOAP header that determines the processing for the message.
A typical life cycle for a message that originates from outside of the ESB, and goes through BizTalk for delivery to another service is the following:
- An Itinerary Web service on-ramp receives the message.
- A pipeline component sets the message context properties, using values of component properties or metadata contained in the itinerary SOAP headers.
- The ESB delivers the message to the BizTalk Message Box database.
- Based on the ESB metadata context properties of the message, a subscriber picks up the message. Subscribers could be either of the following:
- Intermediaries, such as orchestrations
- Off-ramps provided with the guidance
As an alternative to a message arriving through an itinerary on-ramp, a BizTalk application may create a message and publish it to the Message Box database through the following process:
- A component within a BizTalk orchestration creates a message.
- The component populates the ESB metadata context properties in the message.
- The ESB sends the message through a direct-bound port to the Message Box database.
One of the core features of the Microsoft ESB Guidance is the provision of itinerary services (itinerary on-ramps) that simplify the development of enterprise-level messaging applications, extend the capabilities of BizTalk, and reduce the maintenance overhead of maintaining a large number of static send ports and other endpoints.
The ESB Itinerary services accept messages that contain an associated itinerary SOAP header. This header contains a list of services to execute for the message and the metadata required to resolve the endpoints for each of these services. For example, one service may be a custom "routing" service. The resolution instructions associated with it may instruct the service to perform a UDDI, WS-MetadataExchange, or Business Rules Engine (BRE) lookup for information about a specific target endpoint to which it will route the message.
The list of services to execute (which can contain routing, transformation, and custom messaging or orchestration details), in addition to associated resolution instructions, defines the itinerary for the message. By using the itinerary services, clients can specify the services to execute (itinerary steps), the execution order, and the resolution strategy without requiring administrative input or prior configuration of routing details and send ports.
The itinerary services support dynamic routing using the dynamic resolution mechanism of the ESB and direct transformations that do not require the message to pass through the BizTalk Message Box database.
When an itinerary service receives a message, it extracts the itinerary steps, validates them, and populates a context property of the message with the itinerary information. Services, messaging pipelines, orchestrations, and code in a BizTalk application can then access the itinerary stored in the message context, obtain details of the current step, and advance the itinerary to the next step. This causes the next service defined in the itinerary to process the message.
For information about the ESB dynamic resolution mechanism, transformations, itinerary processing, and message creation, see Key Scenarios and Development Tasks.
The Microsoft ESB Guidance sets the following promoted properties for each message submitted through the Itinerary Web Service on-ramp. The schema named System-Properties.xsd defines these properties, which the Itinerary API applies:
- ItineraryHeader. This property contains all the itinerary information and a list of itinerary services to be invoked through sequence of itinerary steps. The Itinerary API uses this property internally.
- ServiceName. This property contains the name of the current itinerary service to process.
- ServiceState. This property contains the current itinerary service state and can be Pending, Complete, or Active. All services subscribe to an itinerary step that has the value Pending for the ServiceState property.
- ServiceType. This property defines the type of the itinerary step (Messaging or Orchestration).
- IsRequestResponse. This property defines the messaging type (one-way or request-response).
The Itinerary service performs execution of the itinerary steps it two different ways, depending on the value of the ServiceType property:
- When the ServiceType property is Messaging, Itinerary pipeline components provided with the Microsoft ESB Guidance execute the itinerary step. Developers can extend this process using a custom pipeline and the Itinerary API.
- When the ServiceType property is Orchestration, an orchestration activated through subscription to itinerary context properties executes the itinerary step.
When an Itinerary service processes an itinerary step, the service is responsible for advancing the itinerary and dispatching the message with a new itinerary context for further processing using the BizTalk publish-subscribe functionality. An itinerary service has full control of the itinerary in the message context and can advance to the appropriate step based on its internal logic and the message content.
The itinerary processing mechanism supports composition of both messaging and orchestration itinerary steps within a single itinerary. Developers can also define custom itinerary services and configure custom itinerary steps.
For more information about itineraries, see Installing and Running the Itinerary On-Ramp Sample.
For more information about custom itinerary services and custom itinerary steps, see Creating a Custom Itinerary Service.