Re: [ws-rx] i089 Proposal 5 - Clarify impact of SOAP protocol binding inuse

[Matthew Lovett <MLOVETT@uk.ibm.com>]

Hi Marc,

I am concerned that this proposal doesn't
really address the heart of the issue, which is to ensure that the WS-RM
spec leads to interoperable implementations. We already know (from other
discussions on this list, and from interop events) that the Microsoft implementation
supports 2-way reliability over a bidirectional synchronous connection
[1]. That implementation seems to contradict the MUST in the final sentence
of the proposal. If that is the case, then this proposal seems a little
disingenuous.

If we fail to come up with an interoperable
way to do 2-way over bidirectional synchronous connections, then some of
the text in this proposal seems appropriate, but rather than use the 2
MUST terms, we should just note 2-way reliability over a bidirectional
synchronous connection is out of scope for this specification.

Thanks

Matt

[1] The implementation detail seems
to centre around retransmitting request messages until the reply is successfully
received and acked by the client. No-one has tried to come up with a decent
proposal for resolving i089 using this approach - as we have discussed
it doesn't seem to mesh with the usual operation of the RM protocol, only
supports simple MEPs, and requires the RMD and RMS to know what is going
on.

"Marc Goodner" <mgoodner@microsoft.com>
wrote on 26/04/2006 20:02:15:

> 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/ 
>