OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Conversational flow.

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
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 

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.

In the mean time, if anybody's got a suggestion that might help me, I'm 
wide open.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]