This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I head read a tutorial about invoking a Web Service asynchronously, and seen there are two approaches to accomplish this from an API point of view :
As a programmatic [API] point of view, this is well understood, but my question is about the Socket layer of the asynchronous web service invocation.
My imagination for it, is that, a client sends a request, and the server (may) take(s) a lot of time to process the request. In this time, the socket connection is not closed, but when the server finishes processing, it sends the response back to the client over the same socket connection, where the whatever JAX-WS classes catch it and passes it to the Callback classes.
Is my understanding of asynchronous web services correct ??
This matter is further complicated by the fact that JAX-WS has an asynchronous client model, which is what you described with your "imagination".
To enumerate the available options:
The invocation do not return until the operation has finished processing.
Asynchronous one-way invocation
Also called "fire-and-forget". The request is sent to the web service but no response will be given. The client can continue to execute despite the request not having finished being processed, because the client does not need to wait for a result. When using a HTTP binding, there will be a confirmation that the request has reached the server, which the client must wait for.
The web service is still a regular, synchronous web service. The difference is on the client side, where a request is sent and and a special thread is dispatched to await the result. The client can learn about the result either by a special object being called back when a result is available or by polling a response-object to examine if the operation has completed an a response is available.
In both cases, a timeout can be specified that limits the time the client waits for a result.
The client will never be called back, or need to poll, the web service - everything regarding the asynchronous invocation is taken care of on the client side.
Asynchronous web service.
The web service is asynchronous and supplies an operation with which clients can submit a task to the service.
There are two different ways by which clients can obtain the result of a task:
The web service supplies another operation which the clients can invoke to check if a task has been processed, supplying a correlation identifier of some kind that tells the service which task the client wants to know about.
The clients must provide a service which will be invoked by the web service to which the client submitted a task when the task has been processed.
A lot of text , hope things are more clear!
Joined: Jul 15, 2006
Thanks Ivan for the wonderful explanation . You saved me a lot of time searching and reading.
So most the asynchronous Web Service implementation lies on the developer for the web service.