Asynchronous Calls Using Web Services

In the samples shown in Chapter 5, "Connectivity with XML Web Services, Part 1," and Chapter 6, "Connectivity with XML Web Services, Part 2," some of the .NET proxy code that was generated contains some asynchronous style calls. For example, by using either Microsoft Visual Studio .NET or the WSDL tool, if a method named GetRecommendations is exposed by the Web service, two methods named BeginGetRecommendations and EndGetRecommendations are created in the proxy file. These methods give the .NET client the ability to make asynchronous types of calls by using Web services.

The Sample Code

A sample has been created to best demonstrate this asynchronous callback using Web services. This sample code can be found in the C:\Interoperability\Samples\Point\WebServices\Async directory. This directory contains two subdirectories. One contains the Java Web service (JavaWebService) that will be called; the other contains the .NET client code (dotNETClient).

The Java Web service code is exactly the same as the sample shown in Chapter 5. As with the sample in Chapter 5, the Java Web service code in this chapter implements two methods: GetRecommendations and SellStocks . The GetRecommendations method performs the same operation of returning some sample stock recommendations, but in this chapter's code, we'll introduce a small delay before the method returns. To do this, a private method named simulateDelay is used. This method simulates the type of delay a production system might experience (for example, if operating under a heavy load).

The .NET client is a small application built using Windows Forms. This small sample allows you to select whether to call the Java-based Web service by using a standard method call (as you saw in Chapters 5 and 6) or by using an asynchronous callback. When the Web service is called, the user can observe the effect it has on the calling application.

To test, build both the Java Web service and the .NET client by using the supplied scripts. Run the Java Web service so that it's waiting for requests from the client. To do this, enter start ant run from a command prompt in the JavaWebService subdirectory. When this is done, run the .NET sample client by entering nant run from a command prompt in the dotNETClient directory.

The .NET client shows the two available options for calling the Java Web service, as depicted in Figure 8.1. Ensure that the No Callback option is checked and click the Call Web Service button.

Figure 8.1: The asynchronous .NET Windows Forms sample.

The status bar will change to indicate that the Web service is being called. After a preset amount of time (10,000 milliseconds , which is determined by the simulateDelay call in the Java Web service), the result will be returned to the client, as shown in Figure 8.2.

Figure 8.2: The result, returned back to the client.

The key observation from this demo is that although the Web service is being called, the .NET client is essentially "frozen." Rerun the same test, but this time try moving or closing the window while the Web service is being called. You should find that this isn't possible ”and that the client appears to "hang" until the result is returned. This happens because the call to the Web service is a blocking call, made via the same thread as the client itself. Until the Web service is returned, the application cannot continue.

Return to the sample, and this time select the With Async Callback option, as shown in Figure 8.3. Click the Call Web Service button, as you did before.

Figure 8.3: The Windows Forms client running asynchronously.

As with the previous test, the client makes the call to the Web service, which will return a value after some time. This time, however, observe how the client application is much more usable. The window can be moved around the screen and even closed while the Web service is being called. Once the Web service returns a value, a message similar to that with the previous test is displayed, indicating the number of recommendations.

In the second example, the call to the Web service is handled by a different thread (which is nonblocking) than the one that controls the update of the window. When this second thread receives a result from the Web service, a callback is raised. This callback runs the code to display the result onscreen.

This type of threading operation isn't something new with Web services or interoperability. Multithreaded Microsoft Windows clients have been around for some time. The point is that the code required to implement this threading and callback is automatically generated and handled by the proxy file ”leaving very little for the developer to do in order to achieve this asynchronous approach.

How the Callback Works

Looking through the sample code, you can see how this callback mechanism works. The form itself (AsyncForm.cs) implements a method named button1_Click , which is called when the user clicks the Call Web Service button. This method verifies which of the check boxes are selected. If the No Callback check box is selected, the Web service is called by using a regular approach:

 service.GetRecommendations(); 

On the other hand, if the Async Callback check box is selected, a slightly different approach is taken. First, callback and state objects are defined:

 AsyncCallback callback = new AsyncCallback(this.ShowResults); Object state = new Object(); 

The AsyncCallback class is a delegate (think of this as a pointer to a method) from the System namespace. This delegate specifies which method will be called when the callback occurs. In this case, the method to be called is named ShowResults . The state isn't used in the sample, but it's there to access the last parameter of the call if required at some point in the future.

The final step in calling the Web service is to make the call and update the status bar:

 service.BeginGetRecommendations(callback,state); statusBar1.Text      = "Calling Async Web Service...  (This thread is running)"; 

Notice how the call is made to the BeginGetRecommendations method (and how the callback and state are passed). This method now completes, and the user is returned to the form and can interact with controls as usual.

When the Web service call completes, the callback executes the ShowResults method:

 private void ShowResults(IAsyncResult result) {     ArrayList recommendations = new          ArrayList(service.EndGetRecommendations(result).elements);     MessageBox.Show("Web Service has returned.  "         +recommendations.Count+" recommendations were returned.");     statusBar1.Text = "Ready"; } 

The incoming callback provides a parameter of type IAsyncResult . This parameter is used with the corresponding EndGetRecommendations method to obtain the result from the Web service proxy. Once this is done, the message and status bar can be displayed as appropriate.

Applicability of Callbacks in Client Applications

In the previous example, you saw how the Web service proxy generation for a .NET client allows calls to be made in an asynchronous fashion with little effort. This type of call works equally well with any Web service, and many of the Web services toolkits for Java support this type of operation. (If these toolkits don't support this type of operation, you can easily program the operation manually.)

Although this section has illustrated the concept of callbacks, the benefits of using this technique apply only in synchronous-style operations. For example, using the callback mechanism is helpful for allowing the user to perform another operation while a call to a Web service is made (as you saw in the sample), but the call to the Web service is still synchronous. It must still complete while the client is open and connected to the Web service. The client cannot go offline or disconnect from the network. Doing so would break the Web service call, and the callback would never be returned.

In addition, this type of callback is dependent on how long the Web service takes to complete. A client will benefit if the Web service takes a few seconds or minutes to return ”but this wait will lose its appeal if the Web service takes a week to return the required data.

Given these scenarios, we have to look beyond nonblocking callbacks and investigate other types of asynchronous communication ” especially those that focus on interoperability between the .NET and Java platforms. In particular, fire-and-forget asynchronous communication fits the bill. The first fire-and- forget technology that we'll look at is Microsoft Message Queuing (MSMQ).