Hands-On: Building Asynchronous Web Services
One of the hottest topics around for early web service developers is how best to deliver guarantee two-way (asynchronous) communications that will confirm transactions, update databases or otherwise make sure both ends of the web service are in synch.
One notable tool is XSpace, a service that lets multiple peers in a web service applications asynchronously share data across the Internet, while still invoking aspects of the WS-Security tools for username and password. XSpace is designed as a simple, flexible, globally-accessible way to store and exchange data using SOAP envelopes.
Conceptually, with XSpace, SOAP envelopes are created by a client application and posted into a space, where they are stored with an associated key. Users can create their own spaces, and the keys are unique within a space.
The envelopes may then be retrieved at a later time using their respective keys. Key elements of XSpace are likely to be familiar to many web service developers, including:
You can learn more, and download the code at Xmethods. .
IDN has gathered some other resources (code sets, techniques, advice) available on how your fellow developers are addressing the issue of asynchronous web services communications.
Understanding Core Web Service Communications
Many of these techniques arise from the basic premise about one-way web services communications -- When calling a Web service, the initiating system actually send a message to the service and then receive another message as a response. The message is sent via the callService() method . [Another callService() method resource is available from Microsoft's MSDN.]
From this callService() method, the response message, or errors encountered during the interaction with the Web service, are attached to an object, called the result object. If you want to find the result of your query to the Web service, you need to analyze the result object.
More Asynchronous Web Services Resources
"Handling the result Object" , this WebReference.com column shows developers how to handle responses to web services calls through their ability to create and read result objects used in asynchronous communications. Special attention is paid to the contents of the result objects including error, id, raw, and value . Also, get
code listings .
"How to build a Web services architecture that handles requests and responses as separate transactions." Not WebSphere specific, the paper addresses SOAP/HTTP or SOAP/JMS communications. Holt specifically addresses 5 key areas of asynchronous troubleshooting, including:
- Defining a correlator and a mechanism for its exchange.
- Defining a reply-to address specifying where the response should be sent, and ensuring that the service provider is informed of this destination.
- The generation of a response by a service provider as a transaction separate from the request.
- The receipt of an asynchronous response by the client.
- The correlation of response with request by both the client and service provider
"Asynchronous Web Service Calls over HTTP with the .NET Framework." The paper, complete with code samples, describes three basic approaches for setting up asynchronous web services, including:
- Polling for Completion, which uses the IAsyncResult interface for a number of I/O operations;
- Using WaitHandles, which can be used to block the thread's current execution until one or more Web service calls complete; and
- Using Callbacks with Invoke and ServiceCallback functions.
"Asynchrous Web Service Programming" this article from Builder.com, and hosted at CNET is a basic tutorial on SOAP 1.2, HTTP and how best to use these protocols with RPC methods and JSPs. The author Tom Boulos states: Web services depend on several protocols. SOAP over HTTP currently is the predominant messaging protocol, and synchronous RPC is the main messaging pattern. This article presents core mechanisms for asynchronous messaging using current technologies, including SOAP 1.2 with HTTP bindings, SOAP over HTTP; session id for JSP-based, apps.
"Dependability in the Web Service Architecture" from the University of Kent (UK) at Canterbury puts forward a solution for safeguarding asynchronous web services based
on forward error recovery. This approach, the authors claim, enables dealing with dependability of composed Web services, and has no impact on the autonomy of the Web services, while exploiting their possible support for dependability. As an accompanying document to the abstract,
a PDF slide presentation of many of the concepts is also available.
EarthWeb column shows developers how to cope with slow line connections to keep your "waiting" asynchronous web service to drop a connection or otherwise create an error.