icrosoft created BizTalk Server to address the applications and systems integration problems that businesses face. Redmond used XML as the common platform for data translation, process definition, and communication. The BizTalk Server consists of a number of data-mapping tools, communication and messaging tools, and adapters that support third-party product integration.

BizTalk Server supports the defining and changing of business processes through BizTalk Orchestration, which enables messaging and the integration of application components. BizTalk Server also supports the development of application logic, using an application design tool. To orchestrate processes, BizTalk uses XLANG, an XML-based language that can describe a business process sequence and the association and binding of application services to specific process elements.

BizTalk Orchestration Architecture
To orchestrate a process, you need to be able to aggregate software components mapped to individual processes, binding the components to process steps, and defining the rules and conditions that determine which component methods a business process must invoke and which action steps it should perform. You also need to be able to aggregate steps in a process, binding them together so they behave like transactions.

The BizTalk Orchestration Designer lets you design these detailed business processes and bind them to application services programmatically. The Designer is a Visio add-in that facilitates developing business process flow diagrams, called XLANG schedule drawings. The schedule drawings show the process flow and the specific actions that the process performs. The actions represent messages that the process must send or receive.

The XLANG schedule drawings also show named ports, which are specific locations that can send and receive messages to carry out the actions represented in the process flow. You map these ports to applications services, which can include COM components, Windows scripting components, Message Queuing services, and BizTalk Messaging services. XLANG schedule drawings also let you define how data flows from the business process inputs to various actions within the process. It also lets you specify parameter inputs to the process orchestration that can be passed on to other defined actions in the process.

To activate the orchestrated processes, you compile the XLANG schedule drawing into an XLANG schedule. The XLANG schedule is an XML-based representation of the orchestrated process that describes the interactions, the interaction sequence, and the binding of application services to the defined actions in the process.

The XLANG Scheduler Engine, a COM+ application service, manages the activation and execution of each instance of an XLANG schedule. The Scheduler Engine may invoke an XLANG schedule multiple times. Each invocation carries its own messages and data but follows the same business process flow, and is subject to the same decision trees and business rules as any other instance of that schedule.

One of the key benefits of using BizTalk Orchestration is the ability to automate long-running, asynchronous processes using loosely coupled applications across various platforms. As Web services applications become ubiquitous across multiple platforms, they are ideal candidates for aggregation in support of orchestrated business processes.Suppose you have a business rule that requires a process to make a customer account history inquiry prior to placing a sales order. If the inquiry determines that the customer’s account is current, a synchronous request inquiry will be made to the credit bureau to get a current credit rating and the sales order can be processed. If the customer’s account is delinquent, the credit bureau inquiry is bypassed and the sales order is rejected. I’ll use this scenario to demonstrate how you can leverage BizTalk Orchestration and Web services to develop a flexible application to perform this type of customer account inquiry.

The task is to create an XLANG schedule drawing that represents all the parts of the business process (see Figure 1). In this scenario, payment terms are granted to customers based on both their account histories with that business and on their credit ratings (determined by a credit bureau’s service to which the business subscribes). To access the account history information the process must query the accounts receivable records?but the order entry system resides on one platform and the accounting systems are on another. For this scenario, you need to include two specific actions in the XLANG schedule: one that represents the customer account history inquiry and another that represents the credit report inquiry.

	Figure 1 | Click here to get a close-up view of the XLANG schedule drawing.

The process first performs the customer account inquiry, which returns a value that shows whether the customer’s account with the business is current or delinquent. In the XLANG schedule drawing, you use a Decision shape to represent a condition to be evaluated at run time. In this case, you want to evaluate the customer account inquiry result to determine the next step in the process. Once you evaluate the result, you can apply a business rule that states that if the customer account inquiry returns “Current”, the XLANG schedule should invoke the customer credit inquiry action, which initiates the credit check process. The orchestrated process ends after the credit check is performed. However, if the customer account inquiry action returns a “Delinquent” response, the orchestrated process ends immediately?without proceeding to the credit check process.

Basically, the logic is:

           If customer account = "Current" 	Perform credit check processElse	Stop

After developing the business process flow into an XLANG schedule drawing, you must associate the application services with the business process steps to automate the orchestration. You make these associations by defining ports, which are named locations to which messages are sent or from which messages are received. You then use these port implementations to process messages mapped from specific business process actions to the ports themselves. BizTalk Server lets you map ports to COM components, Windows Scripting components, and messages services, including BizTalk Messaging and Message Queuing. However, it does not yet support the mapping ports directly to XML-based Web services. To invoke Web services within a process orchestration, you must map a port to a COM-based proxy client for the Web service, and then use that COM component to call the Web service and implement the message processing.

For this article, I use a sample Web service to demonstrate integrating Web services in a BizTalk Orchestration. These WebMethods help to demonstrate the process orchestration integration with Web services by performing simple functions to validate a customer ID input parameter. Listing 1 shows the code for the WebMethods of the BTWebService sample application.

           Listing 1: The BTWebService sample application includes WebMethods for
performing a customer credit check and for performing a customer account
history inquiry.
	[WebMethod]	public string CustomerAccountStatus(string strCustomerID)	{   		const string strIDFirstCharacter = "1";		if (strCustomerID.StartsWith(strIDFirstCharacter))		{			return "Delinquent";		}		else		{			return "Current";		}	}	[WebMethod]	public string CheckCustomerCredit(string strCustomerID)	{		const int intIDLength = 5;		if (strCustomerID.Length < intIDLength)		{			return "Denied";		}		else		{			return "Approved";		}	}

To integrate these Web services into the BizTalk Orchestration process, you need a COM component. Listing 2 shows the code for a VB COM component that serves as a proxy for the BTWebService and its methods. The component uses the Microsoft SOAP Type Library to invoke the Web service methods for the customer account inquiry and the customer credit check.

           Listing 2: The BTWebServiceProxy component serves as a COM-based proxy for
the BTWebService application. The VB component includes one class with two
public methods, and implements the Microsoft SOAP Type Library to invoke
the Web service.
	Option Explicit	Const WebServiceURL As String = 	    		"http://localhost/BTWebService/CreditCheck.asmx?wsdl"	Public Function CreditCheck(strCustomerID As String) As String    		Dim soapProxy As SoapClient        		Set soapProxy = New SoapClient    		soapProxy.mssoapinit WebServiceURL        		CreditCheck = soapProxy.CheckCustomerCredit(strCustomerID)        		Set soapProxy = Nothing	End Function	Public Function AccountStatus(strCustomerID As String) As String    		Dim soapProxy As SoapClient        		Set soapProxy = New SoapClient    		soapProxy.mssoapinit WebServiceURL        		AccountStatus = soapProxy.CustomerAccountStatus(strCustomerID)    		Set soapProxy = Nothing	End Function

After the Web service proxy component is in place, you can configure the application service within the BizTalk Orchestration Designer. To do so, select the COM component option from the implementation toolbar in the BizTalk Orchestration designer, and drag and drop it onto the XLANG schedule drawing. That initiates the COM Component Binding Wizard and takes you through the steps required to create a port associated with the implementation component you've selected. You'll need to select a name for the port and select the XLANG Scheduler Engine settings for this port. These settings determine whether the XLANG Scheduler Engine will control the activation and execution of your component.

	Figure 2 | Click here to get a close-up view of the COM component binding wizard.

Next you select a COM component and a class to implement, along with the methods to invoke for the class (see Figure 2). Advanced port configuration options include security configuration, transaction support, and state management. These options let you tailor the application service to support the process scenario at hand, including the requirements for handling unexpected errors, transactional behaviors, and implementing specific security requirements for the integrated systems environment.

	Figure 3 | Click here to get a close-up view of the Method communication wizard.

To complete the XLANG schedule drawing you must map the messages associated with the actions in the business process to the available ports in your process orchestration. To do this, use the connector tool in the Orchestration designer to associate an action with a specific port. Making a connection initiates the Method Communication Wizard. First, you must select whether the XLANG schedule instance will automatically initiate the method call, or if the instance should wait for the method call to be initiated. This is an important step, because to invoke a process orchestration from an external application using input parameters (such as the customer ID in the scenario previously outlined) you must configure the XLANG schedule to wait for the synchronous method call to be initiated. The final step is to select the method to be used in mapping the action step in the business process to the port for message processing (see Figure 3).

	Figure 4 | Click here to get a close-up view of a compiled XLANG schedule file.

After completing the mapping for each action in the process orchestration, you can compile the XLANG schedule drawing file (.skv) into an XLANG schedule file (.skx). To compile the schedule, select the Make option from the File menu in the BizTalk Orchestration Designer. The XLANG schedule file contains an XML representation of the port bindings to the implementation components and messaging specifications for the exposed methods. Figure 4 shows a view of the compiled XLANG schedule file.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(   "sked:///c:XLANGCustomerAccountStatus.skx/"_	&	CheckAccountStatus")

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 

information in the XML file, including lists of the ports, messages,
and rules associated with the schedule.
																				

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 instance?which 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.