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: barbara guidi on 11 Jun 2010 18:58 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? Thanks Barbara
From: John B. Matthews on 11 Jun 2010 22:00 In article <5459f047-9efe-4ef8-8a3f-5ab4159d1e57(a)y4g2000yqy.googlegroups.com>, barbara guidi <barbara.gm.86(a)gmail.com> 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? I have little experience in this area, but your scenario seems typical. In this example that compares synchronous and asynchronous web services, the caller must either poll the callee or provide a suitable service endpoint for the return trip: <http://java.sun.com/blueprints/webservices/using/webservbp3.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arne Vajhøj on 11 Jun 2010 22:29 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). Arne
From: barbara guidi on 14 Jun 2010 03:10 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). > > Arne 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. 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?
From: Martin Gregorie on 14 Jun 2010 07:51
On Mon, 14 Jun 2010 00:10:21 -0700, 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). >> >> Arne > > 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. > > 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? The usual meaning is that 'synchronous' i/o or communication describes the case of a program issuing a request and waiting for a response before it does anything else. An example is the use of a Reader class: the request is the program calling a read() method and the response is the method returning the requested data. 'asynchronous' i/o or comms is where the program issues the request and gets on with something else until the response arrives. Traditionally a reading program would issue a read to fill a buffer while it processes the last buffer. When that is complete it waits for the current buffer to fill, swaps buffer references and repeats the same set of actions. A more current example might be a server organised round a listener which dispatches worker threads to deal with incoming messages as they arrive. A worker thread will deal with a message, send a reply and then either terminate or return itself to a pool of idle workers. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |