OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] i089 Proposal 5 - Clarify impact of SOAP protocol bindingin use


Sanjay,

To my eyes, Marc has suggested solutions in his proposal.  Supporting 
BAC for example.  Other solutions have been proposed.  I was recently 
reminded of Liberty's PAOS and WS-Transfer, as well the WS-Polling 
specification mentioned here a few times.

Agreement on /which/ solution will be used for a particular sequence or 
RMS / RMD pair may or may not need to happen prior to sending messages 
in that sequence.  For the BAC case, clearly nothing is necessary; the 
RMS won't use the anonymous URI.  I don't know enough about the other 
solutions and proposed solutions to say whether they require new 
extensibility points in our protocol.

More generally, "there be dragons" and "if it hurts, don't do that" are 
common statements in specifications.

thanx,
    doug

On 26/04/06 12:31, Patil, Sanjay wrote:
> 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:mgoodner@microsoft.com]
>     *Sent:* Wednesday, Apr 26, 2006 12:02 PM
>     *To:* ws-rx@lists.oasis-open.org
>     *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/
>
>      
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]