[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 >> 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]