sync vs async webservices
in [Java Programming]
|
Prev: 10 MAXIMO positions in Austin, TX.,- duration 6+ months - Interviews over Phone
Next: My first attempt at java code fails. OK, why please?
From: RedGrittyBrick on 14 Jun 2010 11:32 On 14/06/2010 08:10, barbara guidi wrote: > On Jun 12, 4:29 am, Arne Vajhøj<a...(a)vajhoej.dk> wrote: >> On 11-06-2010 18:58, barbara guidi wrote: >> >> >> >>> I was "politely asked" to write a document but the argument is not >>> related to my background. >>> So I'd like to understand something that I'm not really catching >>> before writing something wrong, so any help would be really >>> appreciated. >> >>> Consider this scenario: >>> - a caller invoke a WS >>> - the callee send a response just to make the caller aware that its >>> request has been acquired and could be processed, so it doesn't reply >>> with the final result >>> - the callee send the result when the request has been processed, by >>> the invocation of a WS exposed on the caller side >> >>> The question is: is this a typical >>> asynchronous WS, OR is it an >>> asynchronous interaction/dialogue mimic/process, having a synchronous >>> WS as request? Or are the two statements both correct? >> >> Usually when the term "asynchroneous web service" is used they >> are talking about the client side API meaning that the caller >> calls something that send the request, continues and the >> response is processed by something else when it arrives. >> What you describe is something I would call web service with >> a callback. >> >> But I don't think the terms are so well-defined, so you could >> use "asynchroneous web service" for what you describe. >> >> BTW, for what you describe, then message queue instead of HTTP >> as transport may make more sense (if possible). > > First, thank you and John for your answers. > > You said that the term asynchronous web service is used when the > client sends a request and then continue. In the link John posted: > "With asynchronous services, the client invokes the service but does > not -- or cannot -- wait for the response.". But nothing is said about > an intermediate response. So I would assume that the ws has just an > input and no output. But this is not clear to me. If the web-service uses HTTP as it's transport layer, and so far as I know the majority do, then all client requests will wait for and receive a response†. It may be that this response only indicates that the client's request has been accepted for later processing and gives no indication of the final outcome of the request. I have worked with web-services which follow this model, to discover the final outcome the client application has to periodically poll a separate, but related web-service, to see if there are messages awaiting collection. The contents of these messages indicate the final outcome of the original request. The final outcome may be an error message saying that the request was rejected. > Is there any formal term/definition to differentiate the client side > ws invocation depending on the fact it has an output, as in the > described scenario, or not? All web service invocations have an output. At the very least the client needs to know that it's message has been received or that a remote procedure has actually been invoked. See <http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#synchronous> which says the term synchronous is used *informally* and that message exchange patterns may be arbitrarily complex. I would not try to force everything that is not round or square into either round or square holes. †Obviously, timeouts apply for abnormal conditions such as communications infrastructure failures. -- RGB
From: John B. Matthews on 14 Jun 2010 11:33 In article <63bf5bcb-16e9-4fa2-9cc8-354c088a4888(a)j4g2000yqh.googlegroups.com>, barbara guidi <barbara.gm.86(a)gmail.com> wrote: [...] > You said that the term asynchronous web service is used when the > client sends a request and then continue. In the link John posted: > "With asynchronous services, the client invokes the service but does > not -- or cannot -- wait for the response.". But nothing is said > about an intermediate response. So I would assume that the ws has > just an input and no output. But this is not clear to me. > > Is there any formal term/definition to differentiate the client side > ws invocation depending on the fact it has an output, as in the > described scenario, or not? I'm not sure it's dispositive, but the Java API for XML Web Services (JAX-WS) [1] reference implementation [2] includes an interface Response<T> for asynchronous operations. The interface, which derives from java.util.concurrent.Future<T> [3], may be apropos. I came across this simple example [4] that includes helpful tutorial links. [1]<http://en.wikipedia.org/wiki/Java_API_for_XML_Web_Services> [2]<http://jax-ws.dev.java.net/> [3]<http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html> [4]<http://stackoverflow.com/questions/3026751> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arne Vajhøj on 14 Jun 2010 21:42 On 14-06-2010 03:10, barbara guidi wrote: > On Jun 12, 4:29 am, Arne Vajh�j<a...(a)vajhoej.dk> wrote: >> On 11-06-2010 18:58, barbara guidi wrote: >> >> >> >>> I was "politely asked" to write a document but the argument is not >>> related to my background. >>> So I'd like to understand something that I'm not really catching >>> before writing something wrong, so any help would be really >>> appreciated. >> >>> Consider this scenario: >>> - a caller invoke a WS >>> - the callee send a response just to make the caller aware that its >>> request has been acquired and could be processed, so it doesn't reply >>> with the final result >>> - the callee send the result when the request has been processed, by >>> the invocation of a WS exposed on the caller side >> >>> The question is: is this a typical asynchronous WS, OR is it an >>> asynchronous interaction/dialogue mimic/process, having a synchronous >>> WS as request? Or are the two statements both correct? >> >> Usually when the term "asynchroneous web service" is used they >> are talking about the client side API meaning that the caller >> calls something that send the request, continues and the >> response is processed by something else when it arrives. >> What you describe is something I would call web service with >> a callback. >> >> But I don't think the terms are so well-defined, so you could >> use "asynchroneous web service" for what you describe. >> >> BTW, for what you describe, then message queue instead of HTTP >> as transport may make more sense (if possible). > You said that the term asynchronous web service is used when the > client sends a request and then continue. In the link John posted: > "With asynchronous services, the client invokes the service but does > not -- or cannot -- wait for the response.". But nothing is said about > an intermediate response. So I would assume that the ws has just an > input and no output. But this is not clear to me. At least what I am talking about is: - asynch API - synch interaction with web service meaning that: - the calling code initiates the send - the calling code continues running - something waits for the response - when the response arrives then something process that Arne
From: Arne Vajhøj on 14 Jun 2010 21:47 On 14-06-2010 11:32, RedGrittyBrick wrote: > On 14/06/2010 08:10, barbara guidi wrote: >> On Jun 12, 4:29 am, Arne Vajhøj<a...(a)vajhoej.dk> wrote: >>> On 11-06-2010 18:58, barbara guidi wrote: >>>> I was "politely asked" to write a document but the argument is not >>>> related to my background. >>>> So I'd like to understand something that I'm not really catching >>>> before writing something wrong, so any help would be really >>>> appreciated. >>> >>>> Consider this scenario: >>>> - a caller invoke a WS >>>> - the callee send a response just to make the caller aware that its >>>> request has been acquired and could be processed, so it doesn't reply >>>> with the final result >>>> - the callee send the result when the request has been processed, by >>>> the invocation of a WS exposed on the caller side >>> >>>> The question is: is this a typical >>>> asynchronous WS, OR is it an >>>> asynchronous interaction/dialogue mimic/process, having a synchronous >>>> WS as request? Or are the two statements both correct? >>> >>> Usually when the term "asynchroneous web service" is used they >>> are talking about the client side API meaning that the caller >>> calls something that send the request, continues and the >>> response is processed by something else when it arrives. >>> What you describe is something I would call web service with >>> a callback. >>> >>> But I don't think the terms are so well-defined, so you could >>> use "asynchroneous web service" for what you describe. >>> >>> BTW, for what you describe, then message queue instead of HTTP >>> as transport may make more sense (if possible). >> >> First, thank you and John for your answers. >> >> You said that the term asynchronous web service is used when the >> client sends a request and then continue. In the link John posted: >> "With asynchronous services, the client invokes the service but does >> not -- or cannot -- wait for the response.". But nothing is said about >> an intermediate response. So I would assume that the ws has just an >> input and no output. But this is not clear to me. > > If the web-service uses HTTP as it's transport layer, and so far as I > know the majority do, then all client requests will wait for and receive > a response†. But that is in the interaction between the client and the server. The API between the app code and the web service library does not need to follow this model. You could have a thread wait for the response. Or you could use NIO. These techniques may not be that common in Java, but in other technologies they are very common. If you generate a web service stub in .NET then you get generated both a normal synch API and an asynch API. > It may be that this response only indicates that the client's request > has been accepted for later processing and gives no indication of the > final outcome of the request. > > I have worked with web-services which follow this model, to discover the > final outcome the client application has to periodically poll a > separate, but related web-service, to see if there are messages awaiting > collection. The contents of these messages indicate the final outcome of > the original request. The final outcome may be an error message saying > that the request was rejected. This is asynch at a different level. And it can be done. But it is not natural for the HTTP protocol. It is natural for message queues. Arne
From: RedGrittyBrick on 15 Jun 2010 05:07
On 15/06/2010 02:47, Arne Vajhøj wrote: > On 14-06-2010 11:32, RedGrittyBrick wrote: >> I have worked with web-services which follow this model, to discover the >> final outcome the client application has to periodically poll a >> separate, but related web-service, to see if there are messages awaiting >> collection. The contents of these messages indicate the final outcome of >> the original request. The final outcome may be an error message saying >> that the request was rejected. > > This is asynch at a different level. > > And it can be done. > > But it is not natural for the HTTP protocol. > It is the message exchange pattern I've seen used by government agencies in a couple of different countries for different projects. In one case for a EU-wide initiative. This leads me to think that this pattern might be quite widely used. -- RGB |