RE: [ws-rx] i089 Proposal 5 - Clarify impact of SOAP protocol binding in use

In addition to pointing out the scenarios and the 
requirements for the case of non-addressable clients, the specification would be 
expected to talk about the solution as well, which may be -

a> Pointing to another specification

b> Providing a solution in the 
specification

c> Mentioning that the solution is out-of-scope (for 
whatever reasons)

 

I am not sure about the perceived value of stating just the 
problem and not saying much about the solution.

 

Thoughts??

 

-- Sanjay

  

  
  From: Marc Goodner 
  [mailto:] 
Sent: Wednesday, Apr 26, 2006 12:02 
  PM
To: 
Subject: [ws-rx] 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/