Orchestration Patterns with BizTalk Server : Process Abstraction and Orchestrated Task Services

These logical ports are bound after deployment to physical ports, such as Web services, and it is that binding that will establish the link between the logical design and the physical transport layer. In addition, it is possible to bind more than one physical receive location to a single physical receive port, which enables service invocation in more than one way.

There are several methods by which a BizTalk-hosted orchestration can be invoked:

• bind it through the BizTalk administration tool

• expose the orchestration as a service

• direct-bound messaging through the MessageBox

• start the orchestration via an asynchronous operation (invoking the orchestration from another already-running orchestration)

• call the orchestration using a synchronous operation (invoking the orchestration from another already-running orchestration)

Calling one orchestration from another orchestration will put additional load on the BizTalk infrastructure because additional subscriptions are created in the background. This may or may not be a problem depending on factors such as what the other processes are doing, the current processing volume, and so on. Calling the orchestration via a service means that you are further adding to the overhead of the service call.

Direct-bound messaging through the MessageBox is an approach whereby you use the administrative tooling to bind an orchestration to a receive port. Even though it feels like you are hard wiring them together, behind the scenes, you are just creating a subscription link. The publish-and-subscribe mechanism works by creating and filling these subscriptions. When a new message arrives in the MessageBox, a message agent looks for subscribers and sends the message to any endpoints that have subscriptions. Subscriptions may have been set up in several ways, including:

• binding an orchestration to a receive port

• having a correlated receive waiting for a message

• creating a send port with a filter condition that matches something about the message (type, receive point, value of a routable property, etc.)

Direct binding through the MessageBox allows you to implement loosely coupled solutions in BizTalk by leveraging the underlying publish-and-subscribe mechanism. If a service needs to send a message to another service, rather than doing it directly, it publishes a message to the MessageBox with a metadata key or message property. An appropriate subscriber will then pick up that message based on the common metadata.

Conceptually, this is a state machine. A message with a certain state is published, and any process that is listening for that state picks up the message. This can also be considered an application of the Event-Driven Messaging pattern, where the publication of a message is considered an event, and when a subscriber picks it up, that subscriber is effectively the event handler.

This architectural approach promotes the decomposition of processes into stateless sub-processes, thereby reinforcing the Functional Decomposition pattern and several other patterns that apply to service-orientation when carrying out the separation of concerns.

Orchestrated Task Service Contracts

BizTalk Server supports the creation of orchestrated task service contracts. The part of the contract most emphasized within BizTalk orchestrations is the data model. For example, when defining Web services, we are primarily concerned with XML schemas, instead of XML schemas plus WSDL definitions.

The reasoning behind this is to support a broader range of transport protocols beyond SOAP and HTTP, and allow for the application of the Canonical Schema pattern on a consistent basis as part of the design and development of orchestrations.

Canonical Schema ensures that common schemas are standardized. In BizTalk Server, standardized XML schemas can be positioned to dictate how messages are processed because it requires that XML schemas be developed prior to being mapped and consumed by the orchestration engine. BizTalk provides a built-in schema editor that can be used to design and maintain standardized schema definitions.

Orchestration participants can be required to apply Canonical Schema together with Schema Centralization in order to share standardized schemas with services pulled into the automation of a given business process. In compliance with Schema Centralization , XML messages obtained from the receive pipeline or services must conform to the same XML schemas used in the business process design.

You can simply add an existing XML schema definition file to your BizTalk project and bind XML Schema types to incoming and outgoing ports to designate them as the messages that flow through the orchestration.

Let’s briefly cover how you can incorporate Web service contracts with XML schemas using BizTalk and Visual Studio tools.

You can import WSDL contracts through the Add Web Reference feature of Visual Studio. In this case, you can choose to keep the service endpoint location from the WSDL definition, or you can substitute a URL and other service binding information.

If you choose to deploy your BizTalk orchestration as a Web service (effectively creating an orchestrated task service), the BizTalk deployment tools rely on a separate Web services publishing tool to create the Web service in code. You can either select the Web Service Publishing Wizard from the Tools menu in Visual Studio or you can run it directly from the BizTalk Server group in the Start menu.

The wizard publishes an ASMX service that receives messages and passes them on to the BizTalk orchestration engine. The operations from the published port are converted into operations on the published service. The operation name remains as the name of the method decorated with the WebMethod or OperationContract attributes. The schema type of the port from the orchestration turns into the method’s parameter. Visual Studio can also retrieve the ASMX service’s WSDL contract and generate the proxy classes to consume the service.

BizTalk further provides the ability to validate incoming and outgoing messages against XML schemas before they are processed by the orchestration. This goes beyond the capabilities of ASMX or WCF and allows for the application of Validation Abstraction so that targeted validation logic can be applied to optimize runtime processing.

The WCF DataContractSerializer has some basic message validation capabilities via attributes that are attached to service operations. However, none of them enforce schema constructs as particles, nor do they enforce element cardinality or additional element content or specialized schema constructs, such as xsd:choice. These limitations will inhibit the extent to which you can apply Canonical Schema , as you may not be able to use all of the features you want from the XML Schema Definition Language.

If your orchestrated services process messages that contain this type of content, the XMLReceivePipeline for the ReceiveLocation allows you to specify which schemas to use for validation. Validating outgoing messages requires a custom Message Inspector, which can be built with Visual Studio.

WS-* Support

Although BizTalk Server represents a significantly scoped and, at times, all encompassing platform, there are opportunities to leverage its support for open industry standards in order to gain a measure of platform independence.

The entire BizTalk architecture embraces XML at its core. You can publish orchestrations as ASMX Web services using the BizTalk Web service Publishing Tool. It is up to you to ensure compliance of resulting service contracts to the design standards you are applying to all services within a given service inventory (as per the requirements of the Standardized Service Contract principle) and any further standards you may be working with (such as WS-I BasicProfile, for example).

Having an orchestration published as a Web service allows you to leverage other Web service industry standards supported by BizTalk, including:

• MTOM

• WS-Policy

• WS-Policy Attachments

• WS-Metadata Exchange

• SOAP (including Message Security Username Token Profile 1.0, X.509 Token Profile 1.0, and Kerberos Token Profile 1.1)

• WS-Addressing

• WS-SecureConversation

• WS-Trust

• WS-ReliableMessaging

• WS-AtomicTransaction

• WS-Coordination

Support for several of these industry standards resulted from the integration of WCF with BizTalk Server 2006. The WCF Adapter for BizTalk 2006 R2 allowed orchestrations to send or receive messages via all standard or custom WCF bindings.