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

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