[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Proposal for i012
Lei, Right. I did not mean to say that there was just one scenario. I agree that there are several cases/scenarios where 'anon' ack cannot be used. BP 1.1 one-way WSDL MEP is one of them. Here is the way I see it: 'anon' URL (at least the way it is defined and used for wsa:ReplyTo and wsa:FaultTo in the context of SOAP/HTTP binding) is used to point to (typically) a mechanism in the binding/transport that cannot have a meaningful URI. For example, to say that it is the HTTP Response. It is quite possible that the particular binding/transport in use may not facilitate such a back-channel for sending messages. In which case, one cannot use the 'anon' uri for AcksTo -- because there is no such thing available. BP 1.1 one-way operations is one of the cases where such a back channel does not exist (there are others). I think providing some cautionary wordings around this will be useful. But, there are cases where such a back channel is available and 'anon' is useful here. For example, when using SOAP/HTTP binding without a WSDL or when using SOAP/HTTP binding with a WSDL req-res MEP. There is also a lot of discussion going on around in-optional-out MEPs in WS-Addressing/XMLP WGs in the context of SOAP 1.2, which would allow such a back-channel. Do you disagree that there are usecases where 'anon' AcksTo is useful? Thx. -Anish -- Lei Jin wrote: > 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]