RE: [ws-rx] i061 proposal / directions

[Doug Davis <dug@us.ibm.com>]

"Gilbert Pilz" <Gilbert.Pilz@bea.com>
wrote on 01/18/2006 03:15:52 PM:

> I would rebut that the majority of existing SOAP deployments are 
> using SOAP 1.1 and that SOAP 1.1 is likely to be with us for many
> years to come. I understand that you need to lead specifications a
> little towards the future, but I think most people would agree that
> discounting SOAP 1.1 is leading a little too far.
>  
> W/regards to current interop of the WS-RM 1.0;
I would like to know 
> if there was a specific test case in which the AS is doing one-way
> SOAP 1.1/HTTP and the RMS specifies the anonymous URI in the AcksTo
> element of the CreateSequence message?

Yes there were tests that had one-ways with and w/o
anon AcksTo.

> I'm not saying that WS-RM should be specifically
constrained by WS-I
> BP 1.1. I'm saying that there is general confusion in the standards
> around the existence of a back-channel for SOAP 1.1/HTTP. It 
> follows, therefore, that there are (and will be for some time) 
> inconsistencies in SOAP implementations with regards to a back-
> channel for one-way operations. As conscientious authors we need to
> take this into account and point out that there are cases in which
> the use of the anonymous URI for AcksTo could result in the 
> inability to obtain acknowledgements.

If an RMS uses it then it knows how to handle the
http backchannel
for acks.  If the RMD accepts it then it knows
how to use it
too. If neither side faults on its use then I don't
see the issue.
As Chris said, the RMD is always free to fault on
its use and an
RMS is always free to use a non-anonymous URI.  Both
sides actually
have a lot of control here.  My proposal simply
states what both
sides can expect if it is used - if they don't like
it they don't
have to use it - but at least its written down what
people should
expect.

> W/regards to WS-Polling; I think it is too heavyweight
for the 
> problem at hand.

WS-Polling is a generic mechanism - if the only thing
people
cared about were Acks then I might agree with you
but I don't think
each spec that might run into a firewall issue should
design
their own way of retrieving information.  One
generic solution
should cover them all - and WS-Polling does that.

> - g
> 
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Tuesday, January 17, 2006 3:43 PM
> To: Gilbert Pilz
> Cc: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i061 proposal / directions

> 
> I would point out that the SOAP1.2 specification actually REQUIRES
> that there be a SOAP 
> envelope in both the request AND response flows of the SOAP/HTTP 
> binding for the 
> Request Response MEP. There is no formally defined oneway MEP 
> defined for SOAP1.2 
> and the XMLP WG is actually pursuing a strategy of amending the 
> Request Response 
> MEP such that the response SOAP envelope is optional, rather than
> define a new MEP for 
> oneway. 
> 
> I would also point out that in all cases of interop of the WS-
> Reliable Messaging spec, prior to 
> submission to this TC, implementations were interoperably exchanging
> oneway messages 
> with acks on the HTTP response flow. I am unaware of any 
> implementations that were unable 
> to do this. 
> 
> I understand that many current SOAP stacks that offer WS-I BP 
> conformance do not 
> send a SOAP envelope in the response to a WSDL input only operation,
> however, I don't think 
> that we should necessarily be constrained by that. 
> 
> Additionally, regardless of whether the RM spec says that an AcksTo
> that carries the anon 
> URI means that SeqAcks flow on the HTTP response flow does not 
> require that an implementation 
> actually support that mode of operation. An RMD should be free (IMO)
> to decline a 
> CS with an AcksTo of the anonymous URI if in fact it cannot support
> sending SeqAcks on the 
> response to a oneway WSDL operation. As for the RMS, it would not
> send a CS with an AcksTo 
> specifying the anonymous URI if it was unprepared to handle SOAP 
> envelopes sent in the 
> HTTP response to a WSDL oneway (unless it was a very confused 
> implementation:-) 
> 
> I think it is fine if the spec might include a caveat that indicated
> that use of the anonymous URI 
> in AcksTo might not be supported in all implementations, but 
> personally, I would think that 
> the spec is fine as it stands. 
> 
> There is no spoon, Neo. 
> 
> Finally, it is not in the scope of the TC to specify a polling 
> mechanism. If someone is in need 
> of one of these, Doug has published one here: 
> 
>         http://www.w3.org/Submission/ws-polling/
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 01/17/2006
06:15:56 PM:
> 
> > My main objection to the current proposal is that it requires
the
> > existence of a back-channel along the entire message path between
the
> > RMS and the RMD. I think most of us are aware of the sturm und
drang
> > around this issue (BP 1.1 says you don't have a back-channel
[1], WS-A
> > is currently entertaining a definition of "one way over
SOAP 1.1" that
> > precludes a back-channel [2], the WS-Addressing [3] and WS-Description
> > [4] WG's have each asked the XMLP WG to define a one-way SOAP
MEP and
> > corresponding HTTP binding that may include a back-channel, etc.)
> > 
> > Considering that the various specifications in this area are
still in
> > flux, I don't think we can presume any uniformity of implementations
(in
> > regards to one-way messages using SOAP 1.1) any time soon. That
being
> > the case I think it's a very bad idea for WS-RM to specify behavior
that
> > presupposes the existence of a back-channel in the case of one-way
SOAP
> > 1.1/HTTP.
> > 
> > Its important to stress that I'm raising this argument as a *practical*
> > matter. I'm not making any arguments about how one-way SOAP 1.1/HTTP
> > *should* behave (nor do I think it is the function of the WS-RM
TC to
> > consider such arguments). I'm simply noting that, as of today,
you can't
> > make assumptions about how the underlying SOAP/HTTP stack will
behave
> > with regards to one-way messages and back-channels.
> > 
> > I think that we should do the following instead:
> > 
> > 1.) Note the circumstances under which the use of the anonymous
URI for
> > AcksTo may result in the inability of the RMS to receive
> > acknowledgments.
> > 
> > 2.) Specify a mechanism (synchronous polling via an empty SOAP
body and
> > an AckRequested header?) that allows the RMS to get the acknowledgements
> > in cases where (1) pertains.
> > 
> > I'll be sending out a more formal proposal for this tomorrow.
> > 
> > - g
> > 
> > [1]
> > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#One-Way_Op
> > erations
> > 
> > [2]
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/att-008
> > 0/ws-addr-wsdlProposedRevision1.62.html#wsdl11oneway
> > 
> > [3]
> > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0003.ht
> > ml
> > 
> > [4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0060.html
> > 
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > > Sent: Monday, January 16, 2006 9:47 PM
> > > To: Yalcinalp, Umit; Patil, Sanjay; Doug Davis
> > > Cc: ws-rx@lists.oasis-open.org
> > > Subject: [ws-rx] i061 proposal / directions
> > > 
> > > Retitled to indicate topic better.
> > > 
> > > The proposal is in the issue list already. Not sure if there
> > > has been any updates to this one or not, I don't recall
any.
> > > 
> > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i061
> > > 
> > > 
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/members/mrgoodner/
> > > 
> > > -----Original Message-----
> > > From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> > > Sent: Monday, January 16, 2006 5:24 PM
> > > To: Patil, Sanjay; Marc Goodner; Doug Davis
> > > Cc: ws-rx@lists.oasis-open.org
> > > Subject: RE: [ws-rx] Proposed list of issues for discussion
> > > on the 1/19 conf-call
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > > > Sent: Monday, Jan 16, 2006 4:58 PM
> > > > To: Marc Goodner; Doug Davis; ws-rx@lists.oasis-open.org
> > > > Subject: RE: [ws-rx] Proposed list of issues for discussion
on the 
> > > > 1/19 conf-call
> > > > 
> > > > 
> > > > Hi Marc,
> > > > 
> > > > I don't remember having seen a clear and specific proposal
on this 
> > > > issue yet. If I may have missed it, could you please
point 
> > > me to the 
> > > > same.
> > > > 
> > > > The current proposal in the issue text is more of a
> > > discussion of the 
> > > > matter and alludes to different alternatives. For example,
the 
> > > > proposal as it stands suggests two ways of deciding
when to use a 
> > > > backchannel (in the case where the AcksTo EPR has anon
> > > value) - a> EPR 
> > > > comparison, and
> > > > b> correlation with sequence identifier. 
> > > > 
> > > > The proposal also assumes a particular disposition
of the WS-I BP 
> > > > compliance issue about using a SOAP response on the
backchannel for 
> > > > one-way messages. I am not sure if the entire TC has
agreed to this.
> > > 
> > > +1. 
> > > 
> > > Based on my experience/discussions in WS-A, it is not clear
> > > to me whether there is yet a universal agreement to allowing
> > > anonymous Acks on the backchannel since it will require
a 
> > > SOAP envelope on the HTTP response just to be able to include
> > > protocol headers. 
> > > 
> > > If the idea is to agree on this behaviour in this tc and
push 
> > > the requirement elsewhere, that is an approach. Whatever
we 
> > > do, however, we need to make sure that the protocol 
> > > requirements are "allowed" to be expressed since
the stack 
> > > /the specs need to compose together. Even if we may decide
to 
> > > break/extend the rules here, if it is prevented by the 
> > > baseline specs it will not be desirable. Hence, we can not
> > > avoid taking WS-A/XMLP into account eventually. 
> > > 
> > > > 
> > > > I feel that the group needs to further discuss this
issue on the 
> > > > mailing list first.
> > > 
> > > >I am quite willing to approach the WS-A WG chair with
a  formal 
> > > >requirement coming from the WS-RX TC once we discuss
and  formulate 
> > > >succinctly our needs.
> > > > 
> > > > Thanks,
> > > > Sanjay
> > > 
> > > --umit
> > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > > > Sent: Monday, Jan 16, 2006 16:18 PM
> > > > > To: Patil, Sanjay; Doug Davis; ws-rx@lists.oasis-open.org
> > > > > Subject: RE: [ws-rx] Proposed list of issues for
> > > discussion on the 
> > > > > 1/19 conf-call
> > > > > 
> > > > > When are we going to take on i061? Doug had a
specific 
> > > proposal for 
> > > > > that one some time ago that did not depend on
waiting on 
> > > another TC 
> > > > > or WG. My understanding is that Addressing was
waiting on 
> > > XP. That 
> > > > > seems indirect enough that we shouldn't hold our
breath, 
> > > should we 
> > > > > move on?
> > > > > 
> > > > > Marc Goodner
> > > > > Technical Diplomat
> > > > > Microsoft Corporation
> > > > > Tel: (425) 703-1903
> > > > > Blog: http://spaces.msn.com/members/mrgoodner/
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > > > > Sent: Monday, January 16, 2006 3:19 PM
> > > > > To: Doug Davis; ws-rx@lists.oasis-open.org
> > > > > Subject: RE: [ws-rx] Proposed list of issues for
> > > discussion on the 
> > > > > 1/19 conf-call
> > > > > 
> > > > >  
> > > > > You are right. i085 (proposed-01 on 1/12 conf-call)
was 
> > > resolved on 
> > > > > the last call itself.
> > > > >  
> > > > > Here is the updated proposed list of issues (i085
> > > replaced by i082):
> > > > > 
> > > > > a> i082 Level of "response message"
unclear, for SequenceResponse
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i082
> > > > > 
> > > > > b> i086 Alternative approach for MaxMessage
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i086
> > > > > 
> > > > > c> i087 Acknowledgement Interval in CreateSequenceResponse
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i087
> > > > > 
> > > > > d> i075 Case of multiple RM Policies and DAs
within an RMD scope
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i075
> > > > > 
> > > > > e> i083 Tom Rutt Fault Messages for Terminated
Sequence
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i083
> > > > >  
> > > > > 
> > > > > 
> > > > > ________________________________
> > > > > 
> > > > >    From: Doug Davis [mailto:dug@us.ibm.com]
> > > > >    Sent: Monday, Jan 16, 2006 12:39
PM
> > > > >    To: ws-rx@lists.oasis-open.org
> > > > >    Subject: Re: [ws-rx] Proposed list
of issues for 
> > > discussion on the 
> > > > > 1/19 conf-call
> > > > >    
> > > > >    
> > > > > 
> > > > >    I might be remembering incorrectly
but I thought we adopted the 
> > > > > proposal for i085 already (and I think the notes
refelect that as 
> > > > > well).
> > > > > 
> > > > >    -Doug
> > > > >    
> > > > >    
> > > > >    
> > > > >    
> > > > >    "Patil, Sanjay" <sanjay.patil@sap.com>
> > > > > 
> > > > >    01/16/2006 03:32 PM
> > > > > 
> > > > >       
> > > > >       To
> > > > >       <ws-rx@lists.oasis-open.org>
> > > > >       cc
> > > > >       
> > > > >       Subject
> > > > >       [ws-rx] Proposed list of
issues for discussion on the
> > > > > 1/19 conf-call
> > > > > 
> > > > >       
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >    The first three issues below are
essentially the ones that we 
> > > > > accepted on the last call (1/12). The issues list
is 
> > > currently being 
> > > > > updated and therefore the URLs for these three
issues may become 
> > > > > active some time later today!
> > > > > 
> > > > >    Thanks, 
> > > > >    Sanjay
> > > > > 
> > > > >    A> i085 CloseSequence element
is inconsistent
> > > > >    
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i085
> > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > es.xml#i08
> > > > > 5>  
> > > > > 
> > > > >    B> i086 Alternative approach for
MaxMessage
> > > > >    
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i086
> > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > es.xml#i08
> > > > > 6>  
> > > > > 
> > > > >    C> i087 Acknowledgement Interval
in CreateSequenceResponse
> > > > >    
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i087
> > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > es.xml#i08
> > > > > 7>  
> > > > > 
> > > > >    D> i075 Case of multiple RM Policies
and DAs within an RMD scope
> > > > > 
> > > > >    
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i075
> > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > es.xml#i07
> > > > > 5>  
> > > > > 
> > > > >    E> i083 Tom Rutt    
   Fault Messages for Terminated Sequence 
> > > > >    
> > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i083
> > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > es.xml#i08
> > > > > 3>  
> > > > > 
> > > > > 
> > > > 
> > >