The Global XML Web Services Architecture (GXA)

Orchestrating Web Services

Almost all non-trivial applications have a logical path of execution as well as implementation details. The logical path of execution, or the workflow of the application, often has a clear start point and a clear endpoint. Throughout the course of execution, work is performed on behalf of the client. With applications written in languages such as C#, the logical path of execution and the implementation details are intertwined within the same code base. However, there are advantages to separating the flow of an application and its implementation details.

By separating an application's workflow from the implementation details, a runtime environment is able to provide a set of services specific to an application's workflow. One such runtime environment is BizTalk Orchestration. Orchestration provides a framework for defining the flow of an application and the interaction with business components that provide the implementation details. Orchestration also provides a set of services that can be leveraged by your application's workflow.

One of the services provided by Orchestration is inherent support for multithreading. Orchestration allows you to define a fork and a matching join within your workflow. For example, suppose in order to process a purchase order, you need to get approval from three different departments. Instead of processing those three activities serially, Orchestration allows you to define a fork with three branches. Each of the three activities will be located on an individual branch of the fork. The Orchestration runtime will execute the three activities in parallel without the developer directly manipulating threads.

You can alter the behavior of the runtime by modifying the metadata associated with the join. The join can be defined as an AND or an OR. An AND will instruct the runtime not to proceed past the join until all branches complete, whereas an OR will continue past the join as soon as one of the branches completes.

Orchestration also provides a set of services for supporting long-running transactions. An instance of an Orchestration workflow is known as a schedule. A schedule might leverage Web services that have a high latency between the time that a request is made and the time the response is received. The degree of latency can adversely affect the number of schedules that can be running at any one point in time.

To help resolve this issue, BizTalk Orchestration provides a service known as hydration. If the server running the application becomes resource constrained, the Orchestration runtime has the ability to dehydrate some of the running schedules and then rehydrate them when server resources become less constrained. The runtime uses hints regarding the degree of latency provided from the developer to determine which schedules are the best candidates for dehydration.

Everything I have explained up to this point is available today. You can leverage Orchestration today to coordinate the workflow within your Web services as well as the applications that leverage your Web services by using BizTalk 2002 and the BizTalk .NET Framework Resource Kit. So why am I covering it in a chapter dedicated to future technologies? The reason is that BizTalk Orchestration is currently being overhauled to provide even tighter integration with ASP.NET-hosted Web services.

Developers caught a glimpse of the direction Microsoft is heading at the 2001 Professional Developers Conference with the release of the technical preview titled BizTalk Orchestration for Web Services. The future version of Orchestration will provide tight integration with the .NET framework and the ASP.NET runtime. In order to leverage BizTalk Orchestration today within a Web service, the Web service itself must explicitly communicate with the Orchestration runtime via well-known APIs. If a schedule invokes a Web service via a proxy generated by WSDL.exe, it must do so via a shim .NET component or via the COM interop layer.

In the technology preview, a workflow is able to expose itself as a Web service. In fact, the workflow itself is compiled into a .NET assembly and is executed by the CLR. If a schedule needs to be dehydrated, the Orchestration run time will leverage the ASP.NET Session Store. If a schedule needs to invoke a method exposed by a Web service, the WSDL.exe-generated proxy can be directly called from within the schedule.

The technical preview also introduced XLANG/s, a scriptable version of XLANG. Today schedules are created using Microsoft Visio and are persisted using an XML syntax called XLANG. In the future, you will be able to write schedules using the XLANG/s scripting language. In order to demonstrate the XLANG/s syntax, I will create a simple Web service that is similar to the Hello World application generated by Visual Studio .NET.

Recall that BizTalk Orchestration allows you to separate the Web service's workflow from the implementation details. In order to demonstrate this, I will separate the implementation of the Web service into three parts: one that defines the interface, one that defines the workflow, and one that defines the implementation details. First I will cover the code that defines the interface.

The following C# code contains the interface definition for the Web service:

using System; using System.Web.Services; namespace Interface {     public interface ISimpleWebService     {         [WebMethod]         string Hello(string name);     } }

The Web service exposes one Web method, Hello. The Hello Web method accepts a string containing the individual's name and returns a string containing the greeting.

Next I define the workflow using XLANG/s.

module SimpleExample {     // Import the namespace in which the Web service interface     // is defined.     using namespace Interface;     public service MyWebService     {         // Declare the messages that will be used by the Web service.         message ISimpleWebService.Hello<request> requestMessage;         message ISimpleWebService.Hello<response> responseMessage;         // Declare the ports that will be exported or imported         // by the Web service.         port export ISimpleWebService simpleWebService;                  // Define the implementation of the Web service.         body         {             // Listen for a request.             activate simpleWebService >> requestMessage;             // Construct the response message.             construct responseMessage             {                 responseMessage.RetResult =                  Implementation.Hello(requestMessage.name);             };             // Send the response message.             simpleWebService << responseMessage;         }     } }

As you can see, the XLANG/s syntax is rather explicit. I declare the request and response messages and also define when the request is received and when the response is sent. One of the benefits this model provides is that the workflow can extend beyond the scope of the Web method. With a traditional ASP.NET Web service, the execution of the Web method stops as soon as the response is sent to the client.

The XLANG/s document is compiled at run time. Therefore, I need to register the XLANG/s compiler within the Web service's web.config file.

<?xml version="1.0" encoding="utf-8" ?> <configuration>   <system.web>     <compilation defaultLanguage="c#" debug="true">       <compilers>         <compiler language="xs;xlangs" extension=".xs"          type="Microsoft.XLANGs.XLANGsCodeProvider, XLANGsCompiler,          Version=1.0.702.0, Culture=neutral,          PublicKeyToken=6464f78e20e2eac9" />       </compilers>     </compilation>   </system.web> </configuration>

The preceding web.config file registers the XLANG/s compiler with the ASP.NET runtime. When a document whose filename ends with an .xs extension is referenced or a code section with its language attribute set to either “xs” or “xlangs” is defined, the ASP.NET runtime will invoke the XLANG/s compiler.

The XLANG/s syntax defined previously was saved within a file named SimpleWebService.xs. Therefore, the following .asmx file is used to serve as the endpoint of the Web service:

<%@ WebService  %> <%@ Assembly src="/books/3/108/1/html/2/SimpleWebService.xs"%>

Finally I define the implementation. Recall that during the construction of the response message, I called the Hello static method exposed by the Implementation class. The following code defines the Implementation class:

using System; namespace SimpleExample {     public class Implementation     {         private Implementation()         {         }         static public string Hello(string name)         {             return "Hello " + name;         }     } }

The preceding example took considerably more code to implement the Web service without much perceived benefit. However, the benefit of the XLANG/s syntax would have been realized if the implementation required a more complex workflow and would be especially true if the Web service leveraged the services of the BizTalk Orchestration runtime, such as its native support for parallel execution of tasks.

In conclusion, you can leverage BizTalk Orchestration within your Web services today using BizTalk 2002 and the BizTalk .NET Framework Resource Kit. However, future versions will offer even tighter integration with .NET and the ASP.NET runtime. XLANG/s will provide an alternative for expressing the workflow of your Web service in addition to the Visio interface provided today.