Chapter 10: Advanced BizTalk Orchestration Features

In this chapter, I'll show you the many advanced features of BizTalk Orchestration: orchestration transactions, XLANG Schedule throttling, orchestration correlation, Web services in BizTalk Orchestration, orchestration dehydration, and so on. You'll continue to update Bob's ASP as you explore these features, because Bob always wants to add to his application.

Using Web Services in BizTalk Orchestration

A Web service is an application or program that can be accessed through the Internet using the HTTP(S) protocol. The intriguing aspect of Web services is their ability to integrate applications running on different platforms in different locations. This benefit has been sought by many technologies in the past, such as DCOM, but they all faced a common challenge-each of them used a proprietary protocol to communicate with clients and servers.

Simple Object Access Protocol (SOAP) provides a standard way to access applications on a remote system. SOAP is a network protocol, and it has no programming model. It's merely a specification for how to invoke and receive the services of a remote system. With SOAP as the communication protocol between client and server, Web services have become easier than ever to use and implement. Web services can be also be integrated with BizTalk Orchestration. There are two ways of integrating the Web services and BizTalk Orchestration:

• Accessing Web services within an XLANG Schedule
  
  
• Exposing XLANG Schedules as Web services

I'll discuss each in turn.

Accessing Web Services Within XLANG Schedules

BizTalk Orchestration doesn't provide a way to invoke Web services directly. However, because it can call COM components, you can make BizTalk Orchestration access the Web service through a COM implementation shape



Figure 10-33. Accessing aWeb service from within an XLANG Schedule through

Bob wants to retrieve a list of quotes from the stock exchange so that he can use it to calculate the current market values for the portfolios of his mutual fund clients. He heard that the major stock exchanges have implemented something called aWeb service, which allows clients to request quotes through the Internet. He wants Mike to make their schedule capable of accessing this quote information through the Internet.

To enable the schedule to access the Web service, you need to develop a COM component that can access the Web service. The following code will create a SOAP client in Visual Basic:

Function QuoteServiceClient(doc As String) As String
Dim SoapClient As New MSSOAPLib.SoapClient
SoapClient.mssoapinit "http://w2kserver/QuoteService/QuoteService.wsdl",
"QuoteService", "QuoteServiceSoapPort"
QuoteServiceClient = SoapClient.ReceiveQuotes(doc)
End Function

You need to add "Microsoft SOAP Type library" to the VB project reference in order to access its functionality. First, you must instantiate a SoapClient object, since you are requesting the Web service as n client. Next, you need to initialize the SoapClient object with the Web Services Description Language (WSDL) file for the quote service. The WSDL file tells clients what methods and properties are available for service, and it also contains the data type for the parameter, and the result for the method calls. In other words, it's effectively a type library for the Web service.

To make a request for the Web service, you simply make a method call on the SoapClient object. All the work of generating a SOAP message and sending the message over to the other side are handled by the SoapClient object behind the scenes. With all the complex tasks being handled for you, you can simply call a method of the Web service as you do with a regular COM component.

Exposing XLANG Schedules As Web Services

XLANG Schedules can also be exposed as Web services to the outside, with help from a COM component. An XLANG Schedule is BizTalk Server technology, and it can't be directly exposed as aWeb service as a COM component can be. However, there is a BizTalk API that allows a COM component to start an XLANG Schedule. You can use such a COM component as a wrapper for the XLANG Schedule, which will provide the real service.

Suppose the Stock Exchange is using BizTalk Orchestration to provide the quote service, and it has decided to expose this quote service as aWeb service so that clients can request the stock quotes through the Internet (see Figure 10-34).



Figure 10-34. Exposing an XLANG Schedule as aWeb service through a COM component

Three steps are involved in exposing an XLANG Schedule as a service:

1. Create an orchestration that has entry points for programmatic access from external applications.
   
   
2. Create a COM component that can interface with the XLANG Schedule.
   
   
3. Create the WSDL and WSML files for this COM component, and expose these files to the Internet for clients to access.

Step 1: Create an Orchestration with Entry Points

Figure 10-35 shows the Quote Service schedule running on a stock exchange's BizTalk Server to provide the quote service.




Figure 10-35. An orchestration that provides a quote service for clients

An important aspect of this schedule is that it contains entry points for external applications to start and control its flow. There are two actions on the schedule: ReceiveTickers, which receives documents that contain stock tickers from clients, and RetrieveQuotes, which returns the quotes for each ticker in the document.

When you configure the Method Communication Wizard for both actions, you'll see the window in Figure 10-36.



Figure 10-36.Method Communication Wizard

In the earlier situations, you've selected the "Initiate a synchronous method call" option, because the schedule is really in control of the process flow in earlier examples. This isn't the case in the quote service, where the external application (the COM wrapper in this case) is in control of the process flow of the schedule. When you select "Wait for a synchronous method call" on the port, the schedule process flow will stop when it reaches this port, and it won't continue until an external program makes a call to the method that the port is connecting to. If you still feel unclear about this option, don't worry. Things will be clearer when you take a look at the COM wrapper for this schedule. That's where you'll see how you can control the flow of this schedule programmatically.

Step 2: Create a COM Component to Interface with the Schedule

The following code creates the COM wrapper that you'll expose as aWeb service shortly:

Public Function QuoteServiceController(Tickers As String) As String
Dim ssked_URL As String
Dim sked As Object

'set the URL for quote service schedule.
ssked_URL = "sked:///C:\Program Files\Microsoft BizTalk Server\
XLANG Scheduler\quoteservice.skx/QuoteServicePort"
'Load and start the schedule
Set sked = GetObject(ssked_URL)
'Provide Ticker document by calling the method on the port
sked.ReceiveTicker (Tickers)
'Retrieve the quote result by calling the method on the port
QuoteServiceController = sked.RetrieveQuotes()
End Function

There are four key points you should know about the preceding code:

• ssked_URL: This is the path for the schedule. Port reference (QuoteServicePort) is part of the path.
  
  
  
• set sked = GetObject(ssked_URL): The GetObject method takes one parameter - the path of the skx file for the schedule you want to load. After you call this method, you have a running schedule that can be referenced by the object sked.
  
  
  
• sked.ReceiveTicker (Tickers): Before this method is called, the schedule you've just started is waiting on the QuoteServicePort port. This is because you've configured the port to wait until someone else initiates the ReceiveTicker method. By calling the ReceiveTicker method and passing in the ticker document, the process flow of the schedule can now continue to the next action: RetrieveQuotes.
   
  
• sked.RetrieveQuotes: Before this method is called, the schedule waits at the QuoteServicePort port. The schedule can't continue until something calls the RetrieveQuotes method. The RetrieveQuotes method returns the quotes for the tickers, and the return value is then assigned to the return value of the QuoteServiceController function. The schedule is then finished after the method call is completed.

As you can see, if you didn't set the schedule to wait for the initiation of the method, the schedule wouldn't wait for the external application to provide input data, and it wouldn't extract the output data at the right moment.