RE: [ws-rx] Proposal for i012

["Lei Jin" <ljin@bea.com>]

Anish/Marc:

  I don't think it's accurate to say that I'm pointing to a single
scenario where anonymous AcksTo cannot be used.  The gist of this is
that BP1.1 mandates that "For one-way operations, an INSTANCE MUST NOT
return a HTTP response that contains an envelope. Specifically, the HTTP
response entity-body must be empty."  Therefore, to return an
ackownledgement SOAP envelope on top of a one-way MEP will be
non-interoperable.  Any BP compliant implementation can decide to close
a http connection after sending back a successful http response code.
In this case, the acknowledgement cannot flow back on the http response
channel. 

  In my example, I used an intermediary to illustrate the problem.
However, the same problem exists even if there is no intermediary
involved.  A processing handler before the RM handler can always close a
http connection in a one-way MEP.

Lei

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Thursday, September 01, 2005 11:44 AM
> To: Lei Jin
> Cc: Christopher B Ferris; ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Proposal for i012
> 
> 
> Isn't this conflating a reply with an Ack? Which can be 
> different. I tend to agree with Marc's view that you are 
> pointing to a scenario 
> where anon AcksTo cannot be used -- in which case don't use it.
> 
> I hope I'm not missing some subtlety that you are getting at.
> 
> 
> But there is another issue (which perhaps needs to be raised 
> separately): what 'anon' address means for AcksTo EPR is not defined 
> anywhere.
> 
> WS-Addressing Core [1] and section 2.1 says the following 
> about 'anon':
> 
> "Some endpoints cannot be located with a meaningful IRI; this URI is 
> used to allow such endpoints to send and receive messages. 
> The precise 
> meaning of this URI is defined by the binding of Addressing to a 
> specific protocol."
> 
> WS-Addressing SOAP binding [2] defines what the 'anon' address means 
> when used with ReplyTo and FaultTo in SOAP and SOAP/HTTP binding. It 
> does not say anything about what it means when used in other headers 
> such as AcksTo.
> 
> This is easily fixed by adding a stmt similar to WS-Addressing SOAP 
> binding. Something like:
> 
> "When "http://www.w3.org/2005/08/addressing/anonymous"; is 
> specified as 
> the address of the wsrm:AcksTo EPR, the underlying SOAP 
> protocol binding 
> provides a channel to the specified endpoint. Any underlying protocol 
> binding supporting the SOAP request-response message exchange pattern 
> provides such a channel. For instance, the SOAP 1.2 HTTP binding[SOAP 
> 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response."
> 
> OR we could ask the WS-Addressing WG to fix their SOAP binding to 
> include not just ReplyTo and FaultTo EPRs but any EPR when 
> used in the 
> context of SOAP/HTTP binding.
> 
> Thoughts?
> 
> -Anish
> --
> 
> [1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
> [2] http://www.w3.org/TR/2005/CR-ws-addr-soap-20050817/
> 
> Lei Jin wrote:
> > I probably should explain this better.  I am proposing that an 
> > AckRequested block can be sent standalone in the message body.  In 
> > this case, it is a request/response message.  And a 
> > SequenceAcknowledgement is sent in response to this 
> message.  If you 
> > specify an anonymous URI for the ReplyTo of the 
> AckRequested message, 
> > then the SequenceAcknowledgement can be sent back on the 
> http response 
> > channel.
> > 
> > I guess we could use a different message element than AckRequested, 
> > but I was just trying to reuse an existing construct.
> > 
> > Lei
> > 
> > 
> >>-----Original Message-----
> >>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> >>Sent: Thursday, August 25, 2005 1:59 PM
> >>To: Lei Jin
> >>Cc: Anish Karmarkar; Marc Goodner; ws-rx@lists.oasis-open.org
> >>Subject: RE: [ws-rx] Proposal for i012
> >>
> >>
> >>Lei,
> >>
> >>AckRequested is not request/response. I don't see how this
> >>helps at all. 
> >>
> >>Cheers,
> >>
> >>Christopher Ferris
> >>STSM, Emerging e-business Industry Architecture
> >>email: chrisfer@us.ibm.com
> >>blog: http://webpages.charter.net/chrisfer/blog.html
> >>phone: +1 508 377 9295
> >>
> >>"Lei Jin" <ljin@bea.com> wrote on 08/25/2005 03:12:13 PM:
> >>
> >>
> >>>A request-response MEP used reliably is asynchronous and is
> >>
> >>basically
> >>
> >>>composed of two separate one-way MEPs.  Thus, there are really no
> >>>differences to the oneway case. (there is nothing normally flowing 
> >>>back on the http response)
> >>>
> >>>If there is an AcksTo address on the source side that is
> >>
> >>reachable from
> >>
> >>>the destination, then use that address.   Otherwise, use 
> >>
> >>the not-allowed
> >>
> >>>EPR for AcksTo which means you can retrieve the Acks through
> >>>AcksRequest messages.
> >>>
> >>>Lei
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> >>>>Sent: Thursday, August 25, 2005 10:24 AM
> >>>>To: Lei Jin
> >>>>Cc: Marc Goodner; ws-rx@lists.oasis-open.org; Christopher B Ferris
> >>>>Subject: Re: [ws-rx] Proposal for i012
> >>>>
> >>>>
> >>>>Hi Lei,
> >>>>
> >>>>How does your proposal address the scenario where:
> >>>>HTTP is being used, there aren't any intermediaries, it is a 
> >>>>request-response WSDL MEP, and the acks are to be sent
> >>
> >>using the HTTP
> >>
> >>>>response (backchannel).
> >>>>
> >>>>In such a case, what should the value of the [address] 
> property of 
> >>>>AcksTo EPR be?
> >>>>
> >>>>-Anish
> >>>>--
> >>>>
> >>>>Lei Jin wrote:
> >>>>
> >>>>>I disagree.  Here is a use case that shows a problem with
> >>>>
> >>>>an anonymous
> >>>>
> >>>>>AcksTo.
> >>>>>
> >>>>>Node A  --->  Intermediary ---> Node B
> >>>>>
> >>>>>Node A tries to send messages reliably to Node B.  For
> >>
> >>simplicity,
> >>
> >>>>>let's
> >>>>>assume these are all oneway messages.  Node A establishes a
> >>>>
> >>>>reliable
> >>>>
> >>>>>sequence with an anonymous AcksTo and starts to send messages.
> >>>>>The
> >>>>>messages first go through the Intermediary which has 
> >>
> >>B's WSDL and
> >>
> >>>>>figures out these are oneway messages.  So it decides to
> >>>>
> >>>>send back a
> >>>>
> >>>>>http 202 to A and close the connection before forwarding
> >>>>
> >>>>the message on
> >>>>
> >>>>>to Node B.  Now Node B gets the message and wants to send
> >>>>
> >>>>back an Ack
> >>>>
> >>>>>synchronously (due to the anonymous Ack).  But it can't
> >>>>
> >>>>send the Ack
> >>>>
> >>>>>since the connection between Node A and the Intermediary is
> >>>>
> >>>>already closed.
> >>>>
> >>>>>Basically the problem is that the introduction of
> >>
> >>anonymous AcksTo
> >>
> >>>>>converts a oneway MEP into a two-way MEP.  In order for it
> >>>>
> >>>>to work, all
> >>>>
> >>>>>intermediaries will need to be WSRM aware and keep
> >>>>
> >>>>connections open in
> >>>>
> >>>>>case synchronous acks need to be sent back.
> >>>>>
> >>>>>Proposal:
> >>>>>
> >>>>>* Specifically call out that the anonymous IRI is not
> >>
> >>to be used
> >>
> >>>>>in
> >>>>>AcksTo.
> >>>>>* AcksTo may take on the value of the "not allowed" IRI,
> >>>>> "_http://www.w3.org/@@@@/@@/addressing/none_";.  When 
> >>>>
> >>>>AcksTo takes on
> >>>>
> >>>>>this value, acknowledgement will only be sent back in
> >>
> >>response to
> >>
> >>>>>AckRequest messages.
> >>>>>
> >>>>>Lei
> >>>>>
> >>>>>
> >>>>>    -----Original Message-----
> >>>>>    *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> >>>>>    *Sent:* Tuesday, August 23, 2005 3:16 PM
> >>>>>    *To:* ws-rx@lists.oasis-open.org; Lei Jin;
> >>
> >>Christopher B Ferris
> >>
> >>>>>    *Subject:* [ws-rx] Proposal for i012
> >>>>>
> >>>>>    I believe Chris Ferris had made a similar proposal
> >>>>
> >>>>earlier but in
> >>>>
> >>>>>    the interest of a +1 and trying to move this along I'll
> >>>>
> >>>>make a more
> >>>>
> >>>>>    formal proposal.
> >>>>>
> >>>>>
> >>>>>
> >>>>>    Proposal:
> >>>>>
> >>>>>    WS-RM was designed to be used with WS-Addressing in
> >>
> >>which the
> >>
> >>>>>    behavior of the anonymous URI is defined as an address
> >>>>
> >>>>in an EPR.
> >>>>
> >>>>>    There is no requirement that the anonymous URI must
> >>
> >>be used and
> >>
> >>>>>    there are valid applications of it, therefore this
> >>>>
> >>>>issue should be
> >>>>
> >>>>>    closed with no action
> >>>>>
> >>>>
> >>
>