Re: Comment on WSDL spec: use of Anonymous Element

[Paul Fremantle <paul@wso2.com>]

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, public-ws-addressing-request@w3.org,
>> ws-rx@lists.oasis-open.org, abbieb@nortel.com, aclark@novell.com,
>> akira.tanaka.pr@hitachi.com, aleyfer@actional.com,
>> anash@reactivity.com, andreas.bjarlestam@ericsson.com,
>> anil.edakkunni@soa.com, anil.john@jhuapl.edu,
>> Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS,
>> asakala@iona.com, ash@rainingdata.com, ashok.malhotra@oracle.com,
>> asirveda@microsoft.com, atarashi@sv.nec-labs.com, atmanes@gmail.com,
>> audet@nortel.com, barreto@adobe.com, bhakti.mehta@sun.com,
>> blake.dournaee@intel.com, bob.freund@hitachisoftware.com,
>> bob.sunday@pwgsc.gc.ca, b.eckenfels@seeburger.de,
>> carolina.canales@ericsson.com, chamikara@wso2.com,
>> chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS,
>> chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS,
>> Christopher.Kurt@microsoft.com, chris.hipson@bt.com, "'von Riegen,
>> Claus'" <claus.von.riegen@sap.com>, coevans@microsoft.com,
>> cunningham_david@bah.com, dan@actional.com, "'Burdett, David'"
>> <david.burdett@sap.com>, dconnelly@openapplications.org, Diane
>> Jordan/Raleigh/IBM@IBMUS, dkmin@konkuk.ac.kr, dleshc@tibco.com,
>> dmoberg@us.axway.com, dnickull@adobe.com, "'David Orchard'"
>> <dorchard@bea.com>, doug.bunting@sun.com,
>> eisaku.nishiyama.dd@hitachi.com, email@cbvenkat.net,
>> eoghan.glynn@iona.com, Eric.Newcomer@iona.com,
>> eric.rajkovic@oracle.com, eric.wells@hitachisoftware.com,
>> ganga.sah@oracle.com, gatfora@uk.ibm.com, gboschi@sonicsoftware.com,
>> gdaniels@sonicsoftware.com, "'Gilbert Pilz'" <Gilbert.Pilz@bea.com>,
>> girish.juneja@intel.com, gregcarp@microsoft.com,
>> greg.pavlik@oracle.com, hbenmalek@us.fujitsu.com,
>> heiko.braun@jboss.com, ian.c.jones@bt.com, ian_robinson@uk.ibm.com,
>> james.speer@capgemini.com, jamie.clark@oasis-open.org,
>> jdurand@us.fujitsu.com, jeff.mischkinsky@oracle.com,
>> jekanaya@cs.indiana.edu, Jiri.Tejkl@systinet.com, jjchoe@tmax.co.kr,
>> jkchoi@methodi.com, jmarsh@microsoft.com,
>> joeri.van_cleynenbreugel@alcatel.be, john.gotze@oasis-open.org,
>> john.kemp@nokia.com, joseph.2.waller@bt.com, junghc@nca.or.kr,
>> jypyon@nca.or.kr, k-seki@da.jp.nec.com, kcyee@cecid.hku.hk,
>> kiwasa@jp.fujitsu.com, lburch@novell.com, lily.liu@webmethods.com,
>> "'Lei Jin'" <ljin@bea.com>, machi@nca.or.kr, "'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>, mary.mcrae@oasis-open.org,
>> matsuki.yoshino.pw@hitachi.com, mckierna@uk.ibm.com,
>> mgoodner@microsoft.com, mhb@itst.dk, "'Bechauf, Michael'"
>> <michael.bechauf@sap.com>, mike.grogan@sun.com, millwood@uk.ibm.com,
>> mlovett@uk.ibm.com, mlyons@layer7tech.com, mschenecker@e2open.com,
>> mwang@tibco.com, nickr@enosis.com, nilo.mitra@ericsson.com,
>> nobuyuki.yamamoto.vw@hitachi.com, Ondrej.Hrebicek@microsoft.com,
>> paul@wso2.com, pauld@mitre.org, paul.cotton@microsoft.com,
>> paul.knight@nortel.com, peter.furniss@erebor.co.uk,
>> peter_niblett@uk.ibm.com, pete.wenzel@sun.com,
>> prateek.mishra@oracle.com, pyendluri@webmethods.com, Richard
>> Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org, sada@jp.fujitsu.com,
>> "'Patil, Sanjay'" <sanjay.patil@sap.com>, sanka@wso2.com,
>> scayron@acord.org, Scott Hinkelman/Austin/IBM@IBMUS,
>> shengsong.ni@oracle.com, shivajee@tibco.com, srcarter@novell.com,
>> stefanba@microsoft.com, "'Rossmanith, Stefan'"
>> <stefan.rossmanith@sap.com>, "'Winkler, Steve'"
>> <steve.winkler@sap.com>, sumit.gupta@oracle.com,
>> tboubez@layer7tech.com, tejeswar.das@iona.com,
>> thomas.erl@soasystems.com, thomas.t.bui@boeing.com,
>> timothy@drummondgroup.com, toby.considine@unc.edu, tom@coastin.com,
>> "'Yalcinalp, Umit'" <umit.yalcinalp@sap.com>, vfurman@webmethods.com,
>> "'Shipkowitz, Vicki'" <vicki.shipkowitz@sap.com>,
>> vikas@sonoasystems.com, "'Videlov, Vladimir'"
>> <vladimir.videlov@sap.com>, Martin Chapman <martin.chapman@oracle.com>
>> 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:public-ws-addressing@w3.org>,
>> _ws-rx@lists.oasis-open.org_ <mailto:ws-rx@lists.oasis-open.org>
>> 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