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] i061 proposal / directions


Shirley you can't be serious by stating "all cases of interop of WS-ReliableMessaging spec were interoperably exchanging oneway messages" proves interop in anything other than trivial scenarios.  Those were not interop scenarios, they were bare bones proof of concepts.  They certainly weren't testing SOAP intermediary behaviour, as SOAP intermediaries have been ruled out of scope by the powers that be for every specification and every interop event.  And I bet if we tried to introduce a SOAP intermediary in this group to test the anon acksTo behaviour, somebody would jump up and down and say "we're testing WS-RX, not testing SOAP intermediaries".

 

Secondly, XMLP WG has not decided formally whether it will amed Req Response rather than introduce one-way mep.  It is very possible that that WG may not be able to do that change to the existing MEP.  But so what?  If people are doing one-way messages all over the place, then it shouldn't be that hard to write it down in a spec.   This really gets down to a very simple question of specifying behaviour in the face of intermediaries.  That is, assuming you want to write things down in specs rather than "just have them work" with magic pixie dust.

 

Riddle me this: MUST a SOAP intermediary wait for the status code and HTTP response body from the next node before it can respond to the first?   Does the answer depend upon whether a WSDL one-way or req-resp is specified for the SOAP request?  In other words, is it ever legal for a SOAP intermediary to respond with 202 and an empty response body for a WSDL one-way without waiting for the next node?   If you say it may be legal to respond with 202 and empty response (and that MUST should be a SHOULD or MAY), then anon acksTo is problematic.  If you say it is never legal for intermediary to respond without waiting for next node, then anon acksTo is not a problem.  But I seriously wonder about real world implementation conformance to that MUST.

 

Cheers,

Dave

 

 


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



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