sync vs async webservices

[barbara guidi]

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

 

[John B. Matthews]

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>

 

[Arne Vajhøj]

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

 

[barbara guidi]

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?

 

[Martin Gregorie]

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.

 

[RedGrittyBrick]

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.

 

[John B. Matthews]

[...]

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>

 

[Arne Vajhøj]

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]

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

 

[RedGrittyBrick]

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.

 

[New Java 456]

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.

 

[Arne Vajhøj]

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

 

[Arved Sandstrom]

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