Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > sync vs async webservices

Reply
Thread Tools

sync vs async webservices

 
 
barbara guidi
Guest
Posts: n/a
 
      06-11-2010
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
 
Reply With Quote
 
 
 
 
John B. Matthews
Guest
Posts: n/a
 
      06-12-2010
In article
<(E-Mail Removed)>,
barbara guidi <(E-Mail Removed)> 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>
 
Reply With Quote
 
 
 
 
Arne Vajhj
Guest
Posts: n/a
 
      06-12-2010
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

 
Reply With Quote
 
barbara guidi
Guest
Posts: n/a
 
      06-14-2010
On Jun 12, 4:29*am, Arne Vajhj <(E-Mail Removed)> 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?
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      06-14-2010
On Mon, 14 Jun 2010 00:10:21 -0700, barbara guidi wrote:

> On Jun 12, 4:29*am, Arne Vajhøj <(E-Mail Removed)> 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 |
 
Reply With Quote
 
RedGrittyBrick
Guest
Posts: n/a
 
      06-14-2010
On 14/06/2010 08:10, barbara guidi wrote:
> On Jun 12, 4:29 am, Arne Vajhøj<(E-Mail Removed)> 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
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      06-14-2010
In article
<(E-Mail Removed)>,
barbara guidi <(E-Mail Removed)> 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>
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      06-15-2010
On 14-06-2010 03:10, barbara guidi wrote:
> On Jun 12, 4:29 am, Arne Vajhj<(E-Mail Removed)> 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
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      06-15-2010
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<(E-Mail Removed)> 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
 
Reply With Quote
 
RedGrittyBrick
Guest
Posts: n/a
 
      06-15-2010
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Newbie: async mode dedicated versus async mode interactive!! Pink_Floyd Cisco 4 06-16-2006 12:16 AM
Generic controlling sync/async reset Niv VHDL 9 01-05-2006 10:33 PM
sync.rb difference between Sync::UN, Sync::EX and Sync::SH Trans Ruby 2 12-12-2005 02:43 PM
Async webservice call in async webpage (.Net 2.0) does not return Steven ASP .Net Web Services 0 11-30-2005 01:06 AM
Basic question regarding sync and async serial interfaces... Ed Simmons Cisco 6 08-01-2004 03:13 AM



Advertisments