Using Axis2 for Asynchronous Web Services

Posted by Craig Wickesser on Dec 14, 2007

Sections

Development,

Enterprise Architecture

Topics

SOA ,

Java ,

Web Services

Tags

Apache Axis

According to the Stack Comparison on the Apache Web Services Wiki, currently Apaches Axis 1.x and Axis2, Metro@GlassFish, and Oracle Application Server 10g provide asynchrony on the client and server.

Apache Axis2 is an open-source web services engine which allows for the invocation and implementation of web services using Java or C. One of the key features of Axis2 is its ability to provide synchronous and asynchronous interactions as explained by Rajith Attapattu,

Support for both asynchronous and synchronous interactions is a key requirement in web services as both styles have strong use-cases. Axis2 provides this flexibility at the transport layer by allowing responses asynchronously via the same transport or via a different transport. For example, if a request comes via HTTP and the processing is done asynchronously, the reply can be sent via HTTP or it could leverage a completely different transport, such as JMS.

In Eran Chinthaka's article, Develop asynchronous Web services with Axis2, he provides several examples of using the asynchronous APIs on the client and server side.

Using Axis2 there are two methods for invoking web services asynchronously. The first method described makes use of a Nonblocking API,

You can provide a nonblocking API to the client so it can hand over the request to the SOAP engine and continue with the other work. There's a callback object the client provides that's notified by the SOAP engine after the engine receives the response from the server. This approach is especially useful for interactive applications with GUIs.

In earlier versions of Axis2 a class named, Callback, which could be used as the callback mechanism for asynchronous messages or as a polling mechanism. This class has been deprecated as of Axis2 1.3 and has been replaced by a simple interface named, AxisCallback. This new interface allows for finer grained notifications during the asynchronous invocation of a service, but it does not provide the polling mechanism formerly found in the Callback class.

The second method for invoking web services asynchronously from the client side by way of the transport-level. Eran describes the transports provided by Axis2,

All the transports that can be used in a Web services invocation can be broadly categorized into two types of invocations:

• One-way transports provide a channel to either send or receive a message.
• Two-way transports can send and receive messages using the same channel.

A client has different options to use for a request-response interaction. The easiest way is to use a two-way transport like HTTP. But this approach doesn't use transport-level asynchrony. Clients can also use two one-way transports or two two-way transports. For example, you can use an SMTP channel to send the message and another SMTP channel to receive the response message. At the same time, you can use an HTTP channel to send the request, close it after the message has been sent, and use a different HTTP channel to receive the response. But for this approach to work, there should be a message correlation mechanism. Apache Axis2 uses the WS-Addressing specification for message correlation.

Axis2 makes it simple to use either transport mechanism, all that is required from the developer to enable two-way transports is to set the useSeparateListener flag on the client.

Besides providing asynchrony to the client side Apache Axis2 also provides asynchrony to the server side. Standard SOAP engines typically receive a request and respond to it all on the same thread. For similar reasons on the client side, it can be quite useful to make the processing and responding to a client request asynchronous on the server.

Axis2 employs a message receiver that takes care of the MEP and hands over the message to the request processing logic or the service implementation. During a synchronous invocation, the message receiver invokes the proper method in the service implementation class (assuming the service implementation is written in the Java language) and then sends the response in the same thread. But during an asynchronous invocation, this message receiver starts a new thread to invoke the service and send the notification to the client. The new thread is responsible for sending the response to the client and taking the response from the service implementation class.

To enable asynchrony on the server there are two methods which make it simple, either use a WSDL generator with the proper flag or configure the services.xml to use an AbstractInOutAsyncMessageReceiver.

Eran Chinthaka conludes his article,

Asynchronous invocations provide a great deal of flexibility for Web services users and for the people who write and host Web services. With more Web services becoming generally available and getting more complex at the same time, more applications are able to integrate those Web services into their applications. Because most of the final applications ultimately interact with users, the challenge is to provide a better user experience. Asynchronous Web services invocations provided in different levels, in both the client and server sides, can help realize some of these modern challenge

• Older >