To activate and execute a process orchestration in your code, you must create an XLANG Schedule instance. Use a moniker to create a new XLANG Schedule instance or to reference an existing instance. A moniker is simply a name that is used to reference an object. It may include information to resolve the path to the component that you used to create the object. The moniker syntax to reference the XLANG Schedule is the following:
Set sked = GetObject(
The required segments for the moniker include the file path and the port name. The file path to the XLANG schedule file is also included, as shown in the example. The port name can also be specified after the file name, enabling you to access methods provided to that port through its binding to a COM component. The moniker syntax in the example refers to the CheckAccountStatus port. Listing 3 contains an excerpt of the XLANG Schedule references to this port.
Listing 3: This excerpt from the XLANG schedule contains the <header/>
information in the XML file, including lists of the ports, messages,
and rules associated with the schedule.
<port tag="0!10" name="CheckAccountStatus"/>
<message tag="4!3" name="Constants"/>
<message tag="4!17" name="AccountStatus_in"/>
<message tag="4!17" name="AccountStatus_out"/>
<message tag="4!41" name="CreditCheck_in"/>
<message tag="4!41" name="CreditCheck_out"/>
<rule tag="0!22" name="Check_Account_Status"/>
The moniker syntax also supports the inclusion of a host machine name, to specify the machine running the XLANG Scheduler Engine. The default for this value is localhost. The syntax also supports the inclusion of a group name, which specifies the COM+ application designated as the XLANG host. When blank, this option is set to the XLANG Scheduler COM+ component by default. The following syntax can be used to access the methods exposed by the port reference:
strResult = sked.AccountStatus(strCustomerID)
In this orchestration, the code would invoke the first action of the schedule instancewhich simply waits for a synchronous method call. When that call occurs, the schedule performs the customer account inquiry by creating an instance of the COM proxy component and calling that component's AccountStatus method. The proxy component's method calls the BTWebService application, invoking its CustomerAccountStatus method. The result is that you've integrated the sample Web service with BizTalk Orchestration, showing how you can use Web services to support orchestrated business processes. If the business processes or specific rules related to the customer account and credit inquiry example were to change, you could make those changes in the XLANG schedule diagram and recompile the schedule, which would apply the new processes, thus implementing the changes without modifying code.
The Future of XLANG
BizTalk Server does not yet support direct integration with the .NET framework or with Web services for port implementations, but that may change in the near future. Microsoft is developing a new version of XLANG (currently called XLANG/S), which will enable developers to write XLANG schedules using Visual Studio .NET. These schedules will compile to .NET assemblies, and manage schedule execution within the .NET framework. The key benefit of this new feature is that you can create more complex process logic within .NET applications than you can in the BizTalk Orchestration designer. Additionally, these changes should make XLANG and BizTalk Server friendlier for developers and will leverage the native Web services support available within .NET, enabling the extension BizTalk process automation applications to easily implement and be implemented by Web services applications. The changes coincide with the drafting of new XLANG specifications designed to better define business process automation for Web services, including support for transaction semantics that support long-running, complex business processes requiring transactional behavior.