Introduction

While synchronous communication using Web services became the main means of integrating heterogeneous applications among the early adopters of Web services technology, the SOAP 1.2 specification highlights support for asynchronous Web services integration. Asynchronous application-to-application communication is rapidly gaining popularity in the industry. This chapter explores different means of building asynchronous interactions between Java and .NET.

Asynchronous Web Services Strategies

From the design standpoint, the focus is on two main strategiesautomatic callback and response polling. There is, of course, a third scenario where a calling system does not expect anything back after submitting a request, which is fairly straightforward to implement. In starting to develop a Web services sample, it becomes obvious that in the simplest case the actual Web service does not have to change much and does not need to know that it is invoked asynchronously. As a matter of fact, with the response polling strategy, it is entirely up to the client to decide whether the invocation should be synchronous or asynchronous. In a more complicated scenariothat is, with an automatic callback strategythere is some preparation involved on the service side to send a callback notification as soon as the request is processed. The Web service consumer has to listen for the incoming callback. The goal is to understand what underlying technologies are available to build asynchronous Java EE-.NET communications. The interoperability examples built reflect the Service Oriented Architecture (SOA) that encompasses coarse-grained Java EE and .NET Web services. These services are integrated in an asynchronous manner and address how to develop an automatic callback to a .NET Web service, automatic callback to a Java EE Web service, polling .NET Web service, and polling Java Web service.

Asynchronous Web Services Support in Java EE

Implementing asynchronous Web services in Java primarily revolves around document-oriented processing and Java messaging. A Web service consumer sends a request as an XML document. A Web service provider queues requests using a messaging system, processing them asynchronously. The messaging system, that is, a JMS-based system, acts as a middleman between the Web service endpoint, such as Servlet, listening to incoming requests on a well-known port and a business tier processing the request. Once the request has been processed, the response is either sent back to the client if the architecture is based on a callback strategy or a client periodically checks the status of a request in the case of a polling strategy. In the given example a document-oriented Web service is implemented. However, the use of messaging is avoided, and instead Java Proxy and .NET Façade techniques are explored. Messaging is discussed in the next chapter.

Asynchronous Web Services Support in .NET

The .NET Framework has built-in support for asynchronous development including asynchronous Web service communication. Two main strategies, response polling and callback, are supported out of the box by the .NET Framework. A WSDL of a published Web service is used to generate a proxy class for a Web service. This proxy, used by the Web service consumer, contains not only the Web service method, but also two extensions to that method such as a begin method and an end method. It is up to the Web service consumer to then invoke the Web service method asynchronously.

Achieving asynchrony outside of the Web services realm is based on the Delegate pattern. The Delegate component acts as a key enabler for asynchronous communication. A Delegate takes the same parameters as the method invoked asynchronously. The main trick with the Delegate is that the compiler extends the Delegate with two methods, BeginInvoke and EndInvoke. The purpose of the BeginInvoke method is to initiate the asynchronous call, whereas EndInvoke is called to obtain the result once the call processing is over. A thread pool is utilized behind the scene to process asynchronous calls on separate threads. So rather than invoking a method directly, a call is made on a Delegate's BeginInvoke method and at the end invoke EndInvoke.

This is a highlight of Java and .NET asynchronous Web service support. The two models have hardly anything in common. Nevertheless asynchronous Web service communication can be built successfully across the two platforms. The next generation of Web services will be able to leverage the SOAP 1.2 specification that simplifies asynchronous Web services communication.

Asynchronous Web Services with SOAP 1.2

SOAP messages are often transferred asynchronously using HTTP as the transport binding. It is important to notice that examples in this chapter are based on the HTTP binding in SOAP 1.1. Today, most asynchronous Web services are implemented by separating the request and response portions of an HTTP transaction as if they were two different transactionsin essence, making two synchronous request-response calls. In the first round, a client sends a request and gets back an acknowledgement along with an ID to be able to track the status of the response. Refer to Figure 8-1.

Figure 8-1. Client requesting an ID from a Web services endpoint

On the second round, the client receives the response as a callback and sends an acknowledgement back to the server. See Figure 8-2.

Figure 8-2. Response and acknowledgement in a Web service

SOAP 1.2 conveniently introduces new HTTP status codes. Specifically, status code 202 indicates that the HTTP response may optionally contain the SOAP response. Status code 204 indicates that the HTTP response does not contain the SOAP response. Once .NET and Java EE support SOAP 1.2, it will be possible to implement interoperable one-way messaging across Java EE and .NET using HTTP as the transport protocol.

As this chapter delves into the mechanics of implementing asynchronous Java EE and .NET integration and uses Sun's Web services Development Kit (WSDK), the Microsoft Visual Studio .NET, and the Microsoft .NET Framework.

Business Scenario Overview

The code demonstration for this chapter continues using the WS-I Sample Application defined as a sample Supply Chain Management application. The Replenish Stock use case of the WS-I Supply Chain application represents asynchronous communication between the Warehouse and the Manufacturer. In a nutshell, the Replenish Stock use case represents two main sub-systemsthe Retailer and the Manufacturing systems. The scenario starts with the Warehouse component of the Retailer system initiating a call to the Manufacturing system by submitting a Purchase Order to process. The Manufacturing system then asynchronously processes the request. With the automatic callback strategy, the Manufacturing system submits the results once the processing is over, while with the polling strategy, the Warehouse component explicitly polls for a response.

Asynchronous Communication Techniques

To build asynchronous communication across Java and .NET, a layer of abstraction is needed to overcome incompatibilities of underlying platform support for asynchronous Web services communication. One can design this layer of indirection on either the .NET or Java side of the communication channel, depending on expertise level and overall system requirements. This chapter explores a few main techniques to build interoperable Web services. With the first technique the .NET Façade pattern is introduced, which hides complexity of asynchronous .NET processing. The façade is responsible for passing a request to be processed asynchronously and generating a callback or responding to the client polling requests. The second technique introduces the Asynchronous Java Proxy pattern and is a way to build a layer of abstraction on Java side. The asynchronous computation occurs between the proxy and its worker thread that initiates the Web service request. The actual Web service call is performed synchronously. The chapter also explores threading as a technique to asynchronous communication in Java and .NET. Benefits of the first technique encompass a fair degree of transparency on the Java side, whereas there is more work to be done on the .NET side. With the Asynchronous Java Proxy technique, extra work has to be done in the Java side but not in the .NET. As the chapter builds individual scenarios, complexity and workarounds of Java EE and .NET APIs are discussed, as asynchronous support on one platform does not guarantee interoperability with another platform. The chapter starts with building the Replenish Stock scenario with the .NET Façade pattern technique to implement the automatic callback strategy and .NET Façade.