Hands-On: Architecting Asynchronous Web Services
Learn how best to deliver guaranteed two-way (asynchronous) communications that will confirm transactions, update databases and otherwise make sure both ends of the web service are in synch. IDN has gathered some of the best and most up-to-date resources (code sets, techniques, advice) available on how your fellow developers are addressing the issue of asynchronous web services communications.
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.
Document-style SOAP support SOAP RPC/Encoded interface "personality" to complement the native document interface. Multiple Transports (HTTP, JMS) and Protection of data via access control lists; uses WS-Security's mechanism for username / password token representation.
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
Aside, from XSpace, in this story IDN has gathered some of the best and most up-to-date 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.
In an excellent article entitled "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.
More Asynchronous Web Services Resources
IBM Solution Architect Holt Adams provides developers a step-by-step paper on "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.
Co-developer of Microsoft's Soap Toolkit 1.0 Matt Powell provides .NET developers insights on asynchronous services with "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 Invokeand ServiceCallback functions.
Simply titled, "Asynchronous 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.
Members of the Apache Software Foundation (ASF) are likely to include native support for asynchronous I/O on the list of features for the next major release (Apache 3.0) of the Open Source web server platform -- if not before, according to an interview with ASF Chairman Roy Fielding in the Open Source e-news portal Open Enterprise Trends. Read the OET story here.
This paper on "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.
Kate Gregory, a founding partner of Gregory Consulting Limited, in a recent 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.