Title: RE: [provision] Conversational flow.
Hey all!
Long time no speak! I just dusted off the spec and have been catching up on all the fun.
Differentiating on protocol vs. execution is confusing and there doesn't seem to be a need to.
Hmm, if I supply a requestId on a "sync" call that gets converted to "async" and the provider returns the supplied requestId, will I know that it was converted to "async"?
Cheers,
-Sandy
-----Original Message-----
From: Gary P Cole [mailto:]
Sent: Thu 4/21/2005 3:02 PM
To:
Subject: Re: [provision] Conversational flow.
Gary P Cole wrote:
> Bohren, Jeffrey wrote:
>
>> In the conversational flow you imply a difference between "Orderly
>> Alteration" and "Outstanding Request" that simply are not true. Using
>> SOAP/HTTP as the transport a multi-threaded client could have several
>> outstanding requests with needing to use request IDs. Your text and
>> diagrams imply otherswise. The distinction should not be between
>> sequential
>> and parallel requests, but between synchronous and asynchronous request.
>> Synchronous requests can be issued in parallel and do not necessitate a
>> request ID unless issued over an asycnhronous protocol (which
>> SOAP/HTTP is
>> not).
>>
>>
> Assuming that I understand you correctly, I agree that the synchronous
> or asynchronous nature of the protocol exchange is the key (in
> combination with executionMode). However, I need a little help.
>
> We already use the words "synchronous" and "asynchronous" to describe
> execution modes:
> - synchronous means that the provider *operates before responding*.
> - asynchronous means that the provider *responds before operating*.
> It gets one step weirder when the requestor does not specify
> executionMode
> and the *provider decides* that an operation must be executed
> asynchronously.
>
> I'd rather not re-use the words "synchronous" and "asynchronous" to
> mean something else unless I can clearly define their meanings and can
> clearly distinguish them from execution modes. (That is why I
> previously used the terms "blocking" and "non-blocking", although that
> explanation wasn't exactly right either.)
>
> Perhaps we can define special terms like "protocol-synchronous" and
> "protocol-asynchronous". I'd just need to be able to clearly define
> what these mean.
>
> Or perhaps we can enumerate the combinations of
> protocol-synchronous/protocol-asynchronous and
> execution-synchronous/execution-asynchronous and distinguish those
> situations that require requestID from those that do not. I'll take
> another look at the text you proposed for Conversational flow (in spec
> issue #9) and take a swing at this.
Sorry, Jeff, you already said it:
If the transport mechanism used for the conversion is a synchronous
request-response
mechanism (such as SOAP/HTTP) the SPML request ID MAY be omitted.
This is true because
1) As long as the protocol exchange is synchronous, the requestor can
match the response to the request without a requestID.
2) We've already specified that if the requestor omits requestID and the
provider executes the operation asynchronously, the provider must
generate a requestID and return the generated requestID in its response.
Is this correct?
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
