W3C home > Mailing lists > Public > public-ws-addressing@w3.org > August 2006

Re: Comment on WSDL spec: use of Anonymous Element

From: Doug Davis <dug@us.ibm.com>
Date: Sun, 6 Aug 2006 18:52:03 -0400
To: Alastair Green <alastair.green@choreology.com>
Cc: 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 <drsecure@us.ibm.com>, 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 <ccl@us.ibm.com>, chouthri@sv.nec-labs.com, Christopher B Ferris <chrisfer@us.ibm.com>, 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 <drj@us.ibm.com>, 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>, Martin Chapman <martin.chapman@oracle.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, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, pyendluri@webmethods.com, Richard Salz <rsalz@us.ibm.com>, robin@oasis-open.org, sada@jp.fujitsu.com, "'Patil, Sanjay'" <sanjay.patil@sap.com>, sanka@wso2.com, scayron@acord.org, Scott Hinkelman <srh@us.ibm.com>, 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>, ws-rx@lists.oasis-open.org
Message-ID: <OFCE5E6682.1D9FC13B-ON852571C2.007C5CDB-852571C2.007D9BD7@us.ibm.com>
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> 
Sent by: public-ws-addressing-request@w3.org 
08/04/2006 06:59 AM 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
public-ws-addressing@w3.org, 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 
Received on Sunday, 6 August 2006 22:52:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:14 GMT