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: New Java 456 on 15 Jun 2010 13:47 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.
From: Arne Vajhøj on 15 Jun 2010 21:54 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
From: Arved Sandstrom on 16 Jun 2010 05:29
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<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. [ 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 |