Export (0) Print
Expand All

Message Routing Patterns

Message routing patterns define proven guidelines for routing a message to its target endpoint(s). Routing can be the result of static configuration, or it can be dynamically configured based on a number of criteria and using a number of methods.

The Message Router pattern determines the recipient of the message based on a set of conditions. For a detailed description of this pattern, see Message Router on the Enterprise Integration Patterns site.

The implementation of this pattern in the Itinerary Designer is a combination of the BizTalk ESB Toolkit itinerary routing service and a single content-based resolver. The itinerary routing service is responsible for promoting message routing properties in Microsoft BizTalk message context or for explicit routing of a message.

You can choose the itinerary routing service provided by the BizTalk ESB Toolkit as follows:

  • Define the itinerary routing service with a messaging extender to execute in a BizTalk pipeline using Itinerary Designer.
  • Define the itinerary routing service with an orchestration extender to execute as an orchestration using Itinerary Designer that performs routing using BizTalk send ports.

The resolver associated with the itinerary routing service determines the recipient of the message, based on the message content. You can choose from the resolvers that support content-based routing provided by the BizTalk ESB Toolkit, or you can implement your own resolver.

For an example of implementing this pattern in the BizTalk ESB Toolkit, see the following resources:

The Content-Based Router pattern determines the recipient of a message based on message content. For a detailed description of this pattern, see Content-Based Router on the Enterprise Integration Patterns site.

The implementation of this pattern in Itinerary Designer is a combination of the BizTalk ESB Toolkit itinerary routing service and a single content-based resolver. The itinerary routing service is responsible for promoting message routing properties in the BizTalk message context or for explicitly routing a message.

You can choose the itinerary routing service provided by the BizTalk ESB Toolkit as follows:

  • Define an itinerary routing service with a messaging extender to execute in a BizTalk pipeline using Itinerary Designer.
  • Define an itinerary routing service with an orchestration extender to execute as an orchestration using Itinerary Designer, which performs routing using BizTalk send ports.
  • Define an itinerary broker service with a broker messaging extender to execute in a BizTalk pipeline using Itinerary Designer.

The resolver associated with itinerary routing service determines the recipient of the message based on the message content. You can choose from the following resolvers that support content-based routing provided by the BizTalk ESB Toolkit:

  • XPATH resolver. By using this resolver, you can route message content using XPATH queries.
  • BRE resolver. By using this resolver, you can retrieve routing information from message content using the BizTalk Rules Engine.
  • Message Context resolver. By using this resolver, you can retrieve the content of a message from the BizTalk message context when it is associated with a BizTalk ESB Toolkit itinerary broker service.
    Ee236697.note(en-US,BTS.10).gifNote:
    Note: In addition to the preceding implementation scenarios, you can develop a custom content-based resolver and itinerary routing solution as a messaging-based or orchestration-based service. In this case, you may need to implement extenders for the BizTalk ESB Toolkit resolver and itinerary service to interoperate with the Itinerary Designer.

For example of this implementation, see the following resources:

The Routing Slip pattern describes a scenario in which a message must be routed through a series of components in a pre-defined order, which may not be known at the design time. For a detailed description of this pattern, see Routing Slip on the Enterprise Integration Patterns site.

The implementation of this pattern is provided by the BizTalk ESB Toolkit; its implementation depends on the type of client application that submits a message for itinerary-based processing:

  • Service proxy. With this type of application, configure the BizTalk ESB Toolkit on-ramp with the Itinerary Selector pipeline component and associate an itinerary resolver to select the appropriate BizTalk ESB Toolkit itinerary. The itinerary properties may be configured as static properties using ITINERARY resolver, or they can be configured as dynamic properties using BizTalk Rules Engine and BRI resolver.
  • Advanced client. With this type of application, configure the BizTalk ESB Toolkit on-ramp with the Itinerary Selector pipeline component and the ITINERARY-STATIC resolver. The client application sends a message with an itinerary reference header, which contains the itinerary name, version, and tracking identifier.
  • Adaptive client. With this type of application, the client application invokes the resolver service, which, in turn, identifies the itinerary reference by passing the client state as a request message. If the itinerary is resolved, the client application submits a message with itinerary references in the same way as in the preceding advanced client scenario.

For more information about implementing this pattern, see the following resources:

The Scatter-Gather pattern enables messages to be sent to multiple recipients and to aggregate their responses; this results in a single message. For a detailed description of this pattern, see Scatter-Gather on the Enterprise Integration Patterns site.

For an example of implementing this pattern, see the Scatter-Gather sample.

The Recipient List pattern addresses the scenario solution in which a message is routed to one or more recipients. The recipient list can be defined either statically (meaning it has a fixed list of recipients) or dynamically. For a detailed description of this pattern, see Recipient List on the Enterprise Integration Patterns site.

The implementation of this pattern in Itinerary Designer is a combination of the BizTalk ESB Toolkit itinerary routing service and multiple resolvers. The itinerary routing service is responsible for cloning a message and then using its BizTalk message context properties to explicitly route a message.

You can choose the itinerary routing service provided by the BizTalk ESB Toolkit as follows:

  • Define the itinerary routing service with a messaging extender to execute in the BizTalk pipeline using Itinerary Designer.
  • Define the itinerary routing service with a messaging extender to execute as an orchestration using Itinerary Designer, which performs routing using BizTalk send ports.

The resolver associated with itinerary routing service determines the recipient of the message based on the message content. You can choose the set of resolvers provided by the BizTalk ESB Toolkit to implement this scenario. For more information about implementing this pattern, see the following resource:

The Splitter pattern addresses the problem when a single message needs to be split into multiple messages. For a detailed description of this pattern, see Splitter on the Enterprise Integration Patterns site. For more information about implementing this pattern, see the following resource:


Community Additions

ADD
Show:
© 2015 Microsoft