[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: i089 Proposal 5 - Clarify impact of SOAP protocol binding in use
All, I understand the reasoning that has led to the alternate
polling proposals to resolve issue 89. The two proposals on the table, alternates
I’ve heard discussed by others off list, the WS-Polling submission at the
W3C, etc. make it clear to me that there are a number of ways this problem
could be solved. Certainly to do a proper job of designing such a feature it
would require that we add another interop event to the schedule to test the
implementations of it before going to PR so there is a rather obvious schedule
implication. This indicates to me that polling is something that would better
be defined to work independently of but composable with RM. For the reasons
noted above I am not convinced that this is the proper forum to do that work
in. With that in mind I have gone back to consider the perceived
problems of the use of anonymous uri as stated in issue 89. The proposal below resolves
i089 be explaining the requirements of the underlying SOAP protocol binding to
make it clear there are cases where you need to be addressable or have a
mechanism (such as polling) in order to allow the messages to flow. Begin proposal: Insert after line 158 (as a new glossary terms): Bidirectional asynchronous communications: A SOAP protocol
binding used by two parties, the RM Source and RM Destination, which allows
each communicating party to initiate transmission of a message. This includes
scenarios where both parties are directly addressable and can initiate binding
connections or at least one party can initiate a binding connection that allows
messages to flow in either direction (e.g. polling). Bidirectional synchronous communications: A SOAP protocol
binding that provides a backchannel but the binding connection can only be
initiated by the RM Source. A common implementation pattern is the anonymous
uri as an address when used with the SOAP HTTP binding. Insert after line 187 (Protocol invariants section): The nature of the protocol is such that it requires
message to always flow from RM Source to RM Destination and from RM Destination
to RM Source. This places certain requirements on the SOAP transport binding in
use. For one-way application message exchange patterns the SOAP transport MUST
support either bidirectional synchronous communications or bidirectional
asynchronous communications. For two-way application message exchange patterns,
such as request-response, the SOAP transport binding in use MUST support
bidirectional asynchronous communications. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]