[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 >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. 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]