[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for i012
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 > >>>>> > >>>> > >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]