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/