This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I'm not sure if this question has been asked earlier on this forum...pardon me! Here's my question...
Axis2 provides a clean way of generating and invoking asynchronous web services. Let's say I have implemented an axis2 asynchronous web service (axis2 internally uses WS-Addressing to provide this asynchrony) on Tomcat. Now, will a non-axis2 client implemented using C#.NET or C++ etc be able to send a request to my web service on one thread, continue doing its work, and process the response sent by my web service using another thread? I'm guessing it must be possible since WS-Addressing is a standard.
Am I right here? What about the other way round? I mean, if I have a non-axis2 web service on tomcat that uses WS-Addressing, will an axis2 client be able to talk to my web service asynchronously?
Originally posted by Ajeya Krishnamurthy: Now, will a non-axis2 client implemented using C#.NET or C++ etc be able to send a request to my web service on one thread, continue doing its work, and process the response sent by my web service using another thread? I'm guessing it must be possible since WS-Addressing is a standard.
Just because its possible doesn't mean you should count on it. And just because something is a standard doesn't mean that it is widely supported.
WS-Addressing basically gives you a standardized way of providing a "return address". As much as SOAP may try to ignore it, most SOAP messages travel over HTTP. On HTTP a "return address" can only work if there is a web server accepting requests for it. So for WS-Addressing to work over HTTP there must be a web server that is capable of processing the SOAP request that carries the "returned response" and that server has to know how to get it back to the original client. In practical terms that usually implies that the original "web service client" is also a "web service" capable of processing the SOAP request carrying the "returned response". Furthermore firewalls on the HTTP path can interfere with WS-Addressing. Most firewalls are configured so that the "web serivce client" can reach out to the "web service" to send its SOAP request in an HTTP request and obtain the SOAP response in the HTTP response. That same firewall will also block any attempt of the "web service" to contact the "web service client" later - unless it has been configured to trust that particular web service server (something most network administrators don't like doing as it opens up holes in their defense net, increasing their network's attack surface).
So unless you have complete control over both ends of the conversation AND the path in between, WS-Addressing isn't something that can be counted on to work. You may have to complicate things further to get things to work (single point server, its position within the network, ultimate receiver resolution and transport, etc.).
process the response sent by my web service using another thread?[/QB]
The fact is that the client can achieve asynchronicity without using asynchronous web services. This is what happens when you use Axis2 "In-Out asynchronous, synchronous HTTP as two-way transport". Basically you set up a callback (object) for another thread to use once the SOAP response is available, then you launch that separate thread to perform the blocking web service call; once that call completes that thread uses the callback (object) to process the response. This is what the Axis2 client method call.invokeNonBlocking can already do. Web Services Messaging with Apache Axis2: Concepts and Techniques
Of course there are plenty of services that cannot keep the HTTP connection open long enough to completely process the payload of a SOAP request. In that case it may make sense to design the exchange to take place in two or three phases. The initial SOAP request would start (or queue) processing but the SOAP response would then return a correlation identifier. That correlation identifier could then be used in another SOAP request to determine the status of the "processing". Once the "processing" is complete the correlation identifier is used in another SOAP request to obtain the "processing result" in the final SOAP response. You may want to install a message handler that bounces all requests that don't use a correlation identifier that is on the "pass correlation identifier short list" (e.g. a status request removes the ID from the list for 10 seconds) to protect yourself somewhat from unruly clients that insist on polling you too fast. Request/reply operations with polling is less likely to run into problems with firewalls because it is always the client who is doing the requesting.