[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Comment on WSDL spec: use of Anonymous Element
Ok now I understand. But what I don't understand is why the ReplyTo is
important given that MakeConnection is a logical one-way.
Paul
Alastair Green wrote:
> Doug,
>
> I think I'm connecting, if you'll pardon the pun.
>
> 1. As I read WS-A, the [destination endpoint][address] must be set to
> [reply endpoint][address] for a reply.
>
> 2. If [reply endpoint] is omitted (as per the CD example), then [reply
> endpoint] = anon, by default.
>
> 3. If [destination endpoint] = "anon-URI?id={uuid}", then [destination
> endpoint] <> [reply endpoint][address] (which was simple, unornamented
> anon-URI), which contradicts premise 1.
>
> Does that make sense? If so, then I think you would need to set [reply
> endpoint] to none, explicitly, to avoid that clash (given RM's current
> approach). But this causes
>
> 4. The WS-A processor that sent MakeConnection to get very confused.
> It wasn't expecting anything but an HTTP 200 series by way of a
> response, but is about to get a full-scale SOAP message bounding back.
>
> +++
>
> Further thoughts, which continue, in my mind, to question the current
> RM approach, but which may ease the WSA W problem.
>
> a) You could have defined an extension element in the [reply endpoint]
> for the UUID.
>
> b) Or, you could have chosen to send the UUID in the body element.
>
> c) In either case, this could team up with setting [reply endpoint] to
> anon.
>
> d) As in 3. above, you shouldn't then set response [destination
> endpoint] to anon?id={uuid}.
>
> e) So, you need to set [reply endpoint] to anon, /and/ set
> [destination endpoint][address] to anon.
>
> f) which begs the question, where does the UUID go?
>
> g) If you passed an extension element UUID, or a UUID in the body
> element, and then passed it back as an extension element in the anon
> EPR that should be OK, because you have followed the rules for reply
> formulation with respect to the [destination
> endpoint][address]/[reference parameters]. The fact you have chosen to
> put an extension element in the response is WS-A 3.3/3.4 legal, as I
> read it. That's a higher-layer behaviour that does not contradict WS-A
> base behaviour, which is constrained.
>
> +++
>
> Why is g) not viable in your view? The processors that need to
> understand the body/extension UUID element are the RM senders and
> responders (not the WS-A processors, which passively pass on the UUID
> to the RM receiver of MakeConnection, and pass on the extension
> element to the RM receiver of the response).
>
> In other words, the awareness of RM-ness that is demanded in
> formulating MakeConnection, and in replying to it, resides in the same
> place, and at the same level, as in the current (CD) solution.
>
> The difference being: that the MakeConnection is now a regular [reply
> endpoint] = anon. At which point special WSAW rules are not needed.
>
> I don't see any lesser or greater problem with intermediaries, onward
> transmission etc than would apply with the current solution, if that
> is a concern. On this point, I think I may be missing something, or
> misunderstanding your area of concern?
>
> So, to summarize:
>
> 1. asimple-non out, special, ornamented-anon back is a problem.
> 2. none out, anon back is a problem.
> 3. extension element UUID out, extension element UUID back, is no
> different, in layer terms, than body UUID out, ornamented address
> back, i.e. is not a problem.
> 4. anon out means no problem with anon = required.
>
>
> * * *
>
> My last point was indeed completely beside the point of your issue :-)
> -- it is an independent issue about WSAW, and a limitation that the
> proposed syntax seems to impose by applying the flag across all
> "response endpoints".
>
> Alastair
>
> Doug Davis wrote:
>>
>> Alastair,
>> We did consider adding some extra metadata to the EPR (outside of
>> the wsa:Address and ref-p's), but there's a problem - this metadata
>> is not copied over into the response message - just the wsa:Address
>> and ref-p's are. This means that any data placed elsewhere in the
>> EPR is lost once the message is serialized. So unless we assume the
>> impl can hold on to the original EPR for the entire message path
>> (which we can't in distributed systems), the identity part must be in
>> either the address or ref-p's. And, as you said, ref-p's aren't good
>> for this.
>>
>> What's interesting about your anon?unique-id example is that that
>> solution might work very nicely (we talked about this in the past) -
>> but as you said it would require WSA to say anon URIs 'start with...'
>> - and WSA is closed :-(
>>
>> I got a bit lost on your last point - it almost sounded like a
>> complaint about the current WSA WSDL spec instead of my issue - or
>> did I not follow it?
>>
>> I noticed that on the agenda for tomorrow's WSA call (I think its
>> tomorrow) is a CR issue that mentioned how this wording in the WSDL
>> spec prevents the use of "none". I can't help but think that both
>> issues (mine and the other CR issue) would be solved nicely if the
>> wording were turned around a bit and said something about how this
>> flag indicates whether or not the endpoint supports addressable
>> endpoints in the response EPRs. Not sure of the exact wording, but
>> if instead of taking about specific URIs (like anon and none) it
>> talked about whether the endpoint supported the notion of creating it
>> own connections to the EPR then it wouldn't need to get into the
>> business of listing all of the URIs that are valid. And I think it
>> would relay the exact same information.
>>
>> thanks
>> -Doug
>>
>>
>>
>> *Alastair Green <alastair.green@choreology.com>*
>>
>> 08/04/2006 10:57 AM
>>
>>
>> To
>> Doug Davis/Raleigh/IBM@IBMUS
>> cc
>> public-ws-addressing@w3.org, [email protected],
>> ws-rx@lists.oasis-open.org, [email protected], [email protected],
>> akira.tanaka.pr@hitachi.com, [email protected],
>> anash@reactivity.com, [email protected],
>> anil.edakkunni@soa.com, [email protected],
>> Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS,
>> asakala@iona.com, [email protected], [email protected],
>> asirveda@microsoft.com, [email protected], [email protected],
>> audet@nortel.com, [email protected], [email protected],
>> blake.dournaee@intel.com, [email protected],
>> bob.sunday@pwgsc.gc.ca, [email protected],
>> carolina.canales@ericsson.com, [email protected],
>> chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS,
>> chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS,
>> Christopher.Kurt@microsoft.com, [email protected], "'von Riegen,
>> Claus'" <claus.von.riegen@sap.com>, [email protected],
>> cunningham_david@bah.com, [email protected], "'Burdett, David'"
>> <david.burdett@sap.com>, [email protected], Diane
>> Jordan/Raleigh/IBM@IBMUS, dkmin@konkuk.ac.kr, [email protected],
>> dmoberg@us.axway.com, [email protected], "'David Orchard'"
>> <dorchard@bea.com>, [email protected],
>> eisaku.nishiyama.dd@hitachi.com, [email protected],
>> eoghan.glynn@iona.com, [email protected],
>> eric.rajkovic@oracle.com, [email protected],
>> ganga.sah@oracle.com, [email protected], [email protected],
>> gdaniels@sonicsoftware.com, "'Gilbert Pilz'" <[email protected]>,
>> girish.juneja@intel.com, [email protected],
>> greg.pavlik@oracle.com, [email protected],
>> heiko.braun@jboss.com, [email protected], [email protected],
>> james.speer@capgemini.com, [email protected],
>> jdurand@us.fujitsu.com, [email protected],
>> jekanaya@cs.indiana.edu, [email protected], [email protected],
>> jkchoi@methodi.com, [email protected],
>> joeri.van_cleynenbreugel@alcatel.be, [email protected],
>> john.kemp@nokia.com, [email protected], [email protected],
>> jypyon@nca.or.kr, [email protected], [email protected],
>> kiwasa@jp.fujitsu.com, [email protected], [email protected],
>> "'Lei Jin'" <ljin@bea.com>, [email protected], "'Mark Little'"
>> <mark.little@jboss.com>, "'Schenecker, Mark'"
>> <mark.schenecker@sap.com>, "'de Boer, Martijn'"
>> <martijn.de.boer@sap.com>, "'Raepple, Martin'"
>> <martin.raepple@sap.com>, [email protected],
>> matsuki.yoshino.pw@hitachi.com, [email protected],
>> mgoodner@microsoft.com, [email protected], "'Bechauf, Michael'"
>> <michael.bechauf@sap.com>, [email protected], [email protected],
>> mlovett@uk.ibm.com, [email protected], [email protected],
>> mwang@tibco.com, [email protected], [email protected],
>> nobuyuki.yamamoto.vw@hitachi.com, [email protected],
>> paul@wso2.com, [email protected], [email protected],
>> paul.knight@nortel.com, [email protected],
>> peter_niblett@uk.ibm.com, [email protected],
>> prateek.mishra@oracle.com, [email protected], Richard
>> Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org, [email protected],
>> "'Patil, Sanjay'" <sanjay.patil@sap.com>, [email protected],
>> scayron@acord.org, Scott Hinkelman/Austin/IBM@IBMUS,
>> shengsong.ni@oracle.com, [email protected], [email protected],
>> stefanba@microsoft.com, "'Rossmanith, Stefan'"
>> <stefan.rossmanith@sap.com>, "'Winkler, Steve'"
>> <steve.winkler@sap.com>, [email protected],
>> tboubez@layer7tech.com, [email protected],
>> thomas.erl@soasystems.com, [email protected],
>> timothy@drummondgroup.com, [email protected], [email protected],
>> "'Yalcinalp, Umit'" <umit.yalcinalp@sap.com>, [email protected],
>> "'Shipkowitz, Vicki'" <vicki.shipkowitz@sap.com>,
>> vikas@sonoasystems.com, "'Videlov, Vladimir'"
>> <vladimir.videlov@sap.com>, Martin Chapman <[email protected]>
>> Subject
>> Re: Comment on WSDL spec: use of Anonymous Element
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Doug,
>>
>> Comments interspersed:
>>
>> Doug Davis wrote:
>>
>> Alastair,
>> There are a couple of different things at play here. First, sorry
>> about the long cc-list but the wsrx mailing list still doesn't appear
>> to work so I need to include the entire wsrx team manually :-(
>> I thought my mail client was going to expire when I just did "reply
>> all".
>>
>> In a non-anonymous world the wsa:Address field represents both the
>> fact that the destination can access connections and it identifies
>> the party. And I think that makes sense. There is no reason to not
>> have a single URI do that (let's not get into the 'identity' issue
>> w.r.t. ref-p's :-). So, if we then switch over to the anonymous
>> case, IMO, I don't believe the implementation should need to change
>> w.r.t. the purpose of this URI.
>> Here's what I don't understand. In the non-anon case an EPR (address
>> + stuff) is used to target. In the anon case, so far as I can tell,
>> there is nothing in WS-A to stop the same "full EPR" (address +
>> stuff) being used to target the reply.
>>
>> If one pursues this, what you intuitively want is: callback EPR =
>> {address = anon URI, ref-param[0] = identity}.
>>
>> But ref-params are opaque. Not what you want. (Although I can't see
>> how to stop an app contract, e.g. RM, specifying that we'll use a
>> mutually-known type for a ref-param, and make its presence mandatory
>> for certain messages).
>>
>> Assume that ref-param is not good. Why not add an RM extension
>> element to the EPR? This retains the identity lexeme within the EPR.
>> A WS-A impl should be happy to insert and extract such extension
>> elements, even if it hasn't a clue what they mean.
>>
>> In the simple WS-Addr anon use-case the URI still indicates both
>> things - whether or not (and 'not' in this case) the destination will
>> accept a connection, and it also indicates the identity - sort of.
>> The identity is implicitly defined by the fact that it is tied to
>> the connection on which the request came in on. If we did what
>> you're suggesting and add a second header then, IMO, RM would require
>> quite a big change to people's soap processor. I think WS-Addr did a
>> really good thing by keeping everything people need to know with a
>> single structure - the EPR. Even with the introduction of the
>> anonymous URI (which could very easily have been introduced in a much
>> less cleaner fashion), most of the SOAP processor doesn't really need
>> to know what the specific value of the wsa:Address element is until
>> it tries to actually send the message over the wire.
>> So, if we then switch over the MakeConnection use-case, I think RM
>> did the right thing by using the same mechanism WS-Addr did - keep
>> everything within a single EPR.
>> OK, but I think you may be conflating "a single EPR" with "the
>> address element of a single EPR".
>>
>> This allows for most of the SOAP processor to be totally unaware of
>> the actually transport mechanism until (or close to) the time the
>> message is serialized on the wire. If there were additional headers
>> to carry this information then existing WS-Addr logic of mapping a
>> wsa:ReplyTo over to a wsa:To + ref-p headers when constructing a
>> response might need to also change. There's also lots of other
>> use-cases where the logic to handle the RM code isn't on the same
>> machine doing this WS-Addr mapping so if its not aware of RM at all
>> it wouldn't even know to include some special bit on the outgoing
>> message (either in the message or in the soap processor's metadata
>> about the message) to indicate that MakeConnection will be used.
>> Things are just a whole lot easier if everything is encapsulated in
>> a single EPR, and more specifically in the wsa:Address field. Which
>> is exactly how WS-Addr anon works today.
>> Hmm, back to the conflation. I can't see anything in the WS-Addr spec
>> that prevents use of ref params, metadata or extensibility elements
>> within an anon EPR. Here, you want to use the special value of
>> [address], and put an application-defined type/value in the rest of
>> the EPR. That would fit your requirement to "keep it in the EPR".
>> I don't think loosening the wording makes thing indeterminate - it
>> still requires a URI with the proper semantics, but it allows for the
>> composition of other specifications that may defined their own. And,
>> IMO, as long as they are consistent with WS-Addr's definition of
>> anon, from a WS-Addr perspective, then how they choose to add
>> additional semantics is up to them.
>> I'm not convinced. I think you are layer-violating -- introducing
>> precisely the problem that you are trying to avoid.
>>
>> At the SOAP processing level this message is full of arcane headers
>> of unknown meaning. At the WS-A processor level, these are
>> commonplace headers with well-defined meanings, which may contain
>> some arcane app ref params and extension elements of unknown meaning.
>>
>> [reply endpoint][address] = anon URI means: "send a response on the
>> back-channel". At the last minute the WS-A processor whacks the
>> arcana (ref-params, metadata and extensibility elements) into the
>> header and whisks them off on the response. Receiving WS-A processor
>> gives the arcana to the app, for which they are meaningful (for
>> routing or correlation or whatever).
>>
>> This works because the WS-A receiver can look at well-known, expected
>> endpoint [reply endpoint] and can find the well-known, expected anon
>> URI -- and need think no further. Anon URI = use back channel.
>>
>> If the URI is different (anon-URI?tum-ti-tum-ti-tum) then the WS-A
>> processor has to assume that it's something special. In fact, it's
>> going to try to address it as a "real address", surely? Only the RM
>> layer knows that "?<string>" is irrelevant to back-channel choice.
>>
>> I can think of three ways of getting around this:
>>
>> 1) Amend WS-Addressing Core to say: the distinguished URI is "any URI
>> which begins with the following distinguished string".
>>
>> 2) Amend WS-Addressing Core to say: the following distinguished
>> metadata element or additional property means: whatever the content
>> of [address], use the back-channel.
>>
>> 3) Put an extension element in the EPR that is routing data at the
>> app level.
>>
>> 1) & 2) involve amending WS-Addressing, which doesn't seem like a
>> great idea.
>>
>> 3) Involves no change to WS-Addressing.
>>
>> If the WSDL says: anon is required, then what is the value inserted
>> on the wire for [reply endpoint][address]? If more definition is
>> required to establish that, then we seem to be losing the low-level,
>> generic capability WS-Addressing has defined. That's what I meant by
>> indeterminacy.
>>
>>
>> In talking about this with Chris Ferris, he mentioned another
>> alternative... instead of saying "MUST", perhaps the text related to
>> the wsaw:Anon flag could simply say "SHOULD". This clearly indicates
>> that WS-Addr's anon URI is the URI of choice, but if there are good
>> reasons for using some other one then the processor will allow those
>> as well.
>> Let me raise another point about the WSAW wording. It talks about
>> "response endpoints" in the plural. Will the required, etc apply to
>> all endpoints which can be responded to, i.e. [from e], [reply e],
>> [fault e], or is it specific to each? It seems to imply the former.
>>
>> If ths is so, then it precludes routing tricks like the following
>> (which is practically useful):
>>
>> [from endpoint] is my address if you need to send me a second (e.g.
>> repeated) response.
>> [reply endpoint] = anon-URI, which is where to send your first
>> response, which we hope gets through.
>>
>> This feature allows retrying protocols to maximize use of HTTP
>> responses, but not be limited by them. I would like to be able to
>> express this as a contractual statement: this endpoint may be anon,
>> this one must not be: from/prohibited, reply/optional. I have a use
>> case in a customer business protocol for exactly this behaviour. I
>> think it's a useful optimization in other contexts.
>>
>> Yrs,
>>
>> Alastair
>>
>> thanks,
>> -Doug
>>
>>
>> *Alastair Green **_<alastair.green@choreology.com>_*
>> <mailto:alastair.green@choreology.com>
>> Sent by: _public-ws-addressing-request@w3.org_
>> <mailto:public-ws-addressing-request@w3.org>
>>
>> 08/04/2006 06:59 AM
>>
>>
>> To
>> Doug Davis/Raleigh/IBM@IBMUS
>> cc
>> _public-ws-addressing@w3.org_ <mailto:[email protected]>,
>> _ws-rx@lists.oasis-open.org_ <mailto:[email protected]>
>> Subject
>> Re: Comment on WSDL spec: use of Anonymous Element
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Doug,
>>
>> This is probably a dumb question, but aren't you trying to change the
>> wrong spec?
>>
>> In RM you are using a single header property to indicate two things:
>> "we're doing back-channel here, and it's part of a logical connection,
>> identified thus".
>>
>> Why can't you separate the communication of these two semantics, by
>> using two properties:
>>
>> 1) wsa:ReplyTo = anonymous URI
>> 2) wsrm:MakeConnection = connection identity?
>>
>> 2) without 1) would be illegal.
>>
>> In your example posted on the WS-RX list, you state that [reply
>> endpoint] is not set because MakeConnection is a "one-way message". But
>> it's a message that usually/frequently expects a reply (at a WS-A
>> level). Unlike many other applications, a WS-RM MC sender will tolerate
>> an empty response (no SOAP in the HTTP body), but I don't think that
>> stops one viewing this as a utilization of the request-reply pattern
>> implied by use of reply-to.
>>
>> If you loosen the WSAW wording, then surely it becomes indeterminate.
>> What does "required" imply on the wire, thereafter?
>>
>> Alastair
>>
>> Doug Davis wrote:
>> >
>> > To elaborate a little on Bob's note [1], in the WSA WSDL spec, when
>> > talking about the various values for the Anonymous Element it lists:
>> >
>> > "optional": This value indicates that a response endpoint EPR in a
>> > request message MAY contain an anonymous URI as an address.
>> > "required":This value indicates that all response endpoint EPRs in a
>> > request message MUST always use anonymous URI as an address.
>> > If a response endpoint EPR does not contain the anonymous URI as an
>> > address value, then a predefined InvalidAddressingHeader fault defined
>> > in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP
>> > Binding] MUST be generated.
>> > "prohibited":This value indicates that any response EPRs in a request
>> > message MUST NOT use anonymous URI as an address.
>> > If a response endpoint EPR contains the anonymous URI as an address
>> > value, then a predefined InvalidAddressingHeader fault defined in Web
>> > Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding]
>> > MUST be generated.
>> >
>> >
>> > The problem comes up when another spec defines their own version of
>> > anonymous - like WS-RM does. It defines an anon URI which acts almost
>> > exactly like the WSA one in that it means "send it on the transport
>> > specific back-channel". However, if the wsaw:Anonymous element is set
>> > to "required" then the above text would seem to imply that regardless
>> > of whether or not the RM spec is supported by the endpoint, the client
>> > can never send a wsa:ReplyTo with anything other than WSA's anonymous.
>> > So the above text precludes another spec from ever extending WSA to
>> > define their own anon URI where from a WSA perspective its equivalent.
>> > If the text were loosened up a bit to not mention the WSA anon URI
>> > specifically, but rather something more generic like: "... MUST always
>> > use a URI implying the transport specific back-channel" then the use
>> > of the wsaw:Anonymous element would not preclude other specs defining
>> > their own anon URI and not violate the meaning of the wsaw:Anonymous.
>> >
>> > thanks
>> > -Doug
>> >
>> >
>> >
>> > [1]
>> >
>> _http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0009.html_
>>
>>
>>
>>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]