sync vs async webservices

Discussion in 'Java' started by barbara guidi, Jun 11, 2010.

  1. 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
     
    barbara guidi, Jun 11, 2010
    #1
    1. Advertising

  2. In article
    <>,
    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?


    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>
     
    John B. Matthews, Jun 12, 2010
    #2
    1. Advertising

  3. barbara guidi

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jun 12, 2010
    #3
  4. On Jun 12, 4:29 am, Arne Vajhøj <> 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?
     
    barbara guidi, Jun 14, 2010
    #4
  5. On Mon, 14 Jun 2010 00:10:21 -0700, barbara guidi wrote:

    > On Jun 12, 4:29 am, Arne Vajhøj <> 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 |
     
    Martin Gregorie, Jun 14, 2010
    #5
  6. On 14/06/2010 08:10, barbara guidi wrote:
    > On Jun 12, 4:29 am, Arne Vajhøj<> 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
     
    RedGrittyBrick, Jun 14, 2010
    #6
  7. In article
    <>,
    barbara guidi <> 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>
     
    John B. Matthews, Jun 14, 2010
    #7
  8. barbara guidi

    Arne Vajhøj Guest

    On 14-06-2010 03:10, barbara guidi wrote:
    > On Jun 12, 4:29 am, Arne Vajhøj<> 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
     
    Arne Vajhøj, Jun 15, 2010
    #8
  9. 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<> 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
     
    Arne Vajhøj, Jun 15, 2010
    #9
  10. 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
     
    RedGrittyBrick, Jun 15, 2010
    #10
  11. barbara guidi

    New Java 456 Guest

    Someone else mentioned it... async is when you issue call in separate
    thread (or callback mechanism such as NIO socket). There's one of the
    web client frameworks which supports this I think.

    The more common design for your goal is to use a message queue. But
    the callback webservice it probably just as good. Maybe better. Your
    callback is async in the dictionary meaning but not in the normal
    jargon of SW dev.

    Queues are mostly used for the impedance mismatch where one service/
    server is super slow relative to the other. This sounds like it may be
    what you have going on anyways. Is your slow part 5 seconds or 5
    minutes? If its 5 seconds then maybe you can speed it up plus you can
    probably just block on the sync call without having to do the callback
    webservice.

    So, you need some way to relate each initiated call to each callback.
    GUID. correlation id. etc. And some failure handling code in the case
    the callback never comes. Everyone hates not getting a callback.
     
    New Java 456, Jun 15, 2010
    #11
  12. On 15-06-2010 05:07, RedGrittyBrick wrote:
    > 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.


    It is definitely used.

    For internet usage then HTTP may be required to get through
    various firewalls.

    Some developers have never looked into message queues.

    But for an intranet solution I would still prefer message
    queue over HTTP callback for this type of scenario.

    Arne
     
    Arne Vajhøj, Jun 16, 2010
    #12
  13. Arne Vajhøj wrote:
    > 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<> 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.

    [ SNIP ]

    That's a useful distinction (the one you made several posts back in the
    quoting above). There's low-level and high-level involved here. For our
    purposes the relevant difference is, I believe, the one you pointed out:
    does the caller wait for the "real" response? This is the high-level
    picture. No need to talk about HTTP or JMS or threads or intermediate
    acks at all, which is all lower-level.

    AHS
    --
    Software sucks because users demand it to.
    -- Nathan Myhrvold
     
    Arved Sandstrom, Jun 16, 2010
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Niv
    Replies:
    9
    Views:
    829
    Mike Treseler
    Jan 5, 2006
  2. Sundar

    sync/async serial comm..

    Sundar, Nov 21, 2006, in forum: C Programming
    Replies:
    3
    Views:
    506
    osmium
    Nov 21, 2006
  3. Angus
    Replies:
    3
    Views:
    352
    Ian Collins
    Nov 5, 2006
  4. Trans
    Replies:
    2
    Views:
    485
    Trans
    Dec 12, 2005
  5. Rm Rm

    http post is async or sync?

    Rm Rm, Jan 4, 2008, in forum: Ruby
    Replies:
    4
    Views:
    125
    Paul Stickney
    Jan 7, 2008
Loading...

Share This Page