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


Chris and Doug:
 
   If I understand you correctly, you are saying if an RMS implements RM, then it can be reasonably expected to check for backchannel even in case of oneway, otherwise, it should not ever send an anonymous AcksTo on sequence creation.  By the same reasoning, if an RMD implements RM, then it can be reasonably expected to send ack through a backchannel even if it's oneway, otherwise, it could've rejected the sequence creation request.  I think these are reasonable assumptions.
 
  However, my problem with this is with intermediaries.  You cannot expect all intermediaries that carry your message will support RM and understand how to handle backchannel correctly.  In the real world, there will be intermediaries that conform to BP1.1 (despite how you think it's wrong) and not allow a SOAP envelope to come back on a oneway http invocation.  Again, I'm not arguing whether that's the right approach, but just that I think it's rather likely that this is going to happen given how confused even we, as spec authors, are over this issue.  Thus, I contend it's useful to point out this potential problem and advise accordingly in the spec.
 
Lei
 
  


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Tuesday, January 24, 2006 5:43 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal / directions


Gil,

Please see my response below.

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/23/2006 06:41:27 PM:

> [text sizes changed to make them readable]

>  
> Doug said:
> 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.

> I'm a little confused by this statement. In my mental model of this
> issue, the use of the anonymous URI in the AcksTo EPR is only a
> problem in cases where the AS/RMS subsequently "uses the sequence to
> engage in"* message exchanges for which there is no backchannel (e.
> g. one-way operations using a SOAP/HTTP implementation which does
> not put SOAP envelopes in the HTTP response). If the AS/RMS uses the
> sequence for messages conforming to a synchronous "send a SOAP
> request over HTTP, wait for the SOAP reply in the HTTP response"
> pattern there is no problem because there is a backchannel for
> acknowledgements to return upon. Thus it seems unnecessarily
> restrictive for an RMS to forgo all uses of the anonymous URI for
> the AcksTo EPR simply because it "knows" that, in some cases, there
> is no SOAP backchannel.


Who says there's no backchannel? I think that you presume that the
WS-I BP constraint that there be no SOAP envelope in the entity
body of the HTTP response message to a oneway WSDL will live to see
tomorrow? I certainly hope not. IMO, that would be a horrendous
mistake.

>  
> * Note; when I say "uses the sequence to engage in" I am implying  
> that every message that carries a SOAP header with the same <wsrm:
> Identifier> is part of some logical application-level abstraction
> and that all the messages with that identifier will conform to the


Why must they conform to the same interaction pattern? That seems
unnecessarily restrictive.

> same interaction pattern. I know that this does not match your model
> of independent, intermediary RMS/RMD pairs that carry all "traffic
> that is to be transmitted reliably" between two clusters of services.

>  
>
>  

> All of this still begs the question of how someone implementing an
> RMS or an RMD "knows" that the use of the anonymous URI in the
> AcksTo EPR might be problematic? The only thing we say about the


It knows whether IT can receive messages on the "backchannel". That's
all it needs to know. If the RMD can't handle that, it will fault on
Sequence creation.

> AcksTo EPR in the current spec is (lines 262-264 of wsrm-1.1-spec-cd-02) is:

> Implementations MUST NOT use an endpoint reference in the AcksTo
> element that would prevent the sending of Sequence Acknowledgements
> back to the RM Source. For example, using the WS-Addressing "none"
> IRI would make it impossible for the RM Destination to ever send
> Sequence Acknowledgements.

> The proposal listed here (http://docs.oasis-open.org/ws-
> rx/issues/ReliableMessagingIssues.xml#i061) does not mention the
> possibility that there may not be a SOAP backchannel for the
> acknowledgements to flow back on. I'm wondering how we expect a


Can we get over this inane restriction of the WS-I BP already?

As I have said repeatedly, the use of the HTTP response flow to
carry SeqAcks is AN IMPORTANT USE CASE FOR MANY CUSTOMERS, certainly
many whom I have spoken to. Why on earth would we NOT seek to satisfy
such an important requirement? The WS-I BP MADE A MISTAKE when they
said that the HTTP response to a oneway WSDL could not carry a SOAP
envelope. It's that simple. They didn't (despite my protestations)
anticipate the advent of SOAP extensions such as WS-RM.

> developer to know precisely when and where the use of the anonymous
> URI in the AcksTo EPR might be problematic when our spec says
> nothing about the subject?

>  
> - g
>  


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