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:]
> Sent: Thursday, September 01, 2005 11:44 AM
> To: Lei Jin
> Cc: Christopher B Ferris;
> 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:]
> >>Sent: Thursday, August 25, 2005 1:59 PM
> >>To: Lei Jin
> >>Cc: Anish Karmarkar; Marc Goodner;
> >>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:
> >>blog: http://webpages.charter.net/chrisfer/blog.html
> >>phone: +1 508 377 9295
> >>
> >>"Lei Jin" <> 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:]
> >>>>Sent: Thursday, August 25, 2005 10:24 AM
> >>>>To: Lei Jin
> >>>>Cc: Marc Goodner; ; 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:]
> >>>>> *Sent:* Tuesday, August 23, 2005 3:16 PM
> >>>>> *To:* ; 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
> >>>>>
> >>>>
> >>
>
