Re: [ws-rx] Re: Comment on WSDL spec: use of Anonymous Element

Alastair, I think I addressed these in response to your other note. 
-Doug




Alastair Green <alastair.green@choreology.com> 
Sent by: public-ws-addressing-request@w3.org
08/08/2006 11:42 AM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, 
ws-rx@lists.oasis-open.org
Subject
Re: [ws-rx] Re: Comment on WSDL spec: use of Anonymous Element






Chris,

Redoing part of WS-A in RM creates difficulty in WS-A WSDL (start of 
thread). Raises question: Why won't standard WS-A anon facility work?

You have to say something about where you reply to. If you want the reply 
to come on the back-channel then WS-A has a way of saying that (and you 
get that by default).

If you say there is no reply, then you are saying: don't send a response. 
But MC precisely invites a response. How is a WS-A implementation supposed 
to understand (without being RM aware) that reply=none really means 
(functionally) reply=anon? I perceive unnecessary layering tangle. WS-A 
layer now expected to hold HTTP response for app, even though told that 
there is no response.

Researching further, I don't understand why an RM-specific alternative to 
reply=anon has been introduced for the "address" case, but not for the 
"sequence" case. 

I believe regular "use back channel" feature of WS-A can be used, and the 
RM layer can handle RM "sessions", in both cases.

Does my example of sequence case indicate expected behaviour? Would it be 
wrong to say MC/reply=anon with sequence case?

First part of long message addresses Doug's points about the 
application-level set-up message: I don't understand the relevance of that 
type of message.

Alastair



Christopher B Ferris wrote: 

Alastair, 

Is this a long and drawn out manner of stating that when a message is a 
true oneway (e.g. no 
response is expected) then the wsa:ReplyTo should be the WS-A none URI 
rather than 
simply leaving it absent and hence falling trap to the "if not present, 
default to anon" gotcha? 

I guess I am not seeing an issue here, although I guess it would be fine 
if we recommended or required 
that the MakeConnection wsa:ReplyTo MAP carry the WS-A none URI. 

Cheers, 

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295 

public-ws-addressing-request@w3.org wrote on 08/08/2006 07:06:32 AM:

> Doug, Paul --
> 
> I'm going to try to address both your comments. if I can summarize 
> Paul's it was: what's the big deal about [reply endpoint] when 
> MakeConnection is "one-way"?. 
> 
> Given RX timescales you may want to treat these remarks as "early 
> public review".
> 
> * * *
> 
> Doug's message 1 is an application-level set-up call which 
> establishes common understanding of the UUID. This type of message 
> is exemplified by that shown in the CD example Step 1, unless I have
> completely misunderstood.
> 
> In that example, a subscriber, who cannot listen, sends a subscribe 
> message to a publisher, saying something like "subscribe me for 
> topics A, B, C. The identity of this subscription request is UUID 
> X". Thereafter, the publisher knows that X equals "subscription for 
> topics A, B, C".
> 
> Assertion 1 (please correct me if I am wrong): The format, content 
> etc of this type of message (and its manner of transmission) are 
> entirely application-specific. It may or may not require an 
> acknowledgement. It could be sent by carrier pigeon, or by fax. The 
> subscribe message, if sent as SOAP-with-Addressing, might receive a 
> reply, or might not receive a reply, and if it did, it might receive
> it anon or addressable. There are no RM rules that apply to this 
> message. There are only application rules. It cannot do its job 
> usefully unless it passes the UUID: that is all we can say.
> 
> Assertion 2. At present there is an RM rule which says: "the 
> mutually understood UUID must be reflected in the [destination 
> endpoint] according to an RM URI scheme". There are no RM rules to 
> say whether the connection UUID, during the course of establishing 
> mutual understanding, travels alone, embedded in a URI, in a body 
> element or a header element. These are all matters of bilateral 
> agreement at an app level between (in this case) the 
> consumer/subscriber and the producer/publisher.
> 
> [The example is potentially a bit misleading in this respect. 
> 
> The use of the full "anon-URI?id={uuid}" value in the <targetEPR/>, 
> and the use of the element name "targetEPR" make one think 
> "addressing", when one would be better off thinking "subscription 
> identity" (at an app level). The example set-up message would work 
> perfectly well if it read:
> 
> <S:Body>
>     <!-- subscription details --> 
>     <SubscriptionIdentity>{uuid}</SubscriptionIdentity>
> </S:Body>
> 
> Btw, given that the use of MakeConnection requires a prior 
> understanding between two parties of the connection identity, there 
> seems no reason why {uuid} has to be a UUID. It does need to be 
> bilaterally unambiguous.]
> 
> * * *
> 
> Message 2 is MakeConnection. If the subscriber sends a 
> MakeConnection, specifying UUID X, then the publisher knows it is 
> dealing with traffic relating to subscription X, i.e. for topics A, 
> B and C. At an application level, we assume that the contract 
> thereafter is: start reliably communicating a stream of messages, 
> relating to topics A, B and C, therefore implying sequence creation 
> etc, until something causes the stream to close. 
> 
> So the subscriber will repeatedly send MakeConnection, citing the 
> UUID X, read the HTTP response, and handle the response as if it 
> were an inbound RM/RM-app message.
> 
> The exchange that RM defines (rather than illustrates) is the 
> MakeConnection, back-call-on-the-connection one. It's this exchange 
> that I am discussing. MakeConnection is the message affected by the 
> WSAW anon=required discussion, as I see it.
> 
> [While it is probably helpful for diagnostic reasons to repeat the 
> UUID back to the sender of MakeConnection in the [destination 
> endpoint], it is actually redundant, as the HTTP Response is 
> automatically and uniquely correlated with the HTTP Request. This 
> might lead one to the conclusion that the simple solution would have
> been: send UUID on MakeConnection, and then respond to it on the 
> anonymous back-channel without reflection of UUID in any form 
> However, this would reduce the symmetry with the Sequence identified
> use of MakeConnection, see comments later]
> 
> * * *
> 
> There are two modes in which this exchange can work (reflecting the 
> joint proposal, as I understand it):
> 
> a) Send response as part of a sequence that already exists
> b) Use response to create a new sequence, etc
> 
> This is relevant to answering Paul F's question, relating to the 
> significance of ReplyTo.
> 
> If there is a sequence, then the sequence Identifier is a 
> correlation synonym for the UUID. The reply message may be sent on 
> the back-channel; it must carry the wsrm:Identifier (as a separate 
> header element), it need not carry the UUID.
> 
> If there is no sequence, then the reply message must carry or imply 
> the UUID. (I'm going to assume that carrying the UUID is better than
> implying it.) The question is how?
> 
> Looking at these two cases, it is striking that both 
> 
> a) require a response on the back-channel,
> b) need to carry an identifier (one of the sequence, one of the 
> "connection"/"session")
> 
> Doug's comment that there is no wsa:ReplyTo on the MakeConnection, 
> that it is "one way", is relevant here. In fact there is no such 
> thing (in the XML infoset) as a non-existent [reply endpoint]. If 
> wsa:ReplyTo is absent, then it is inferred to be the anon-URI. The 
> only way you can stop that inference is to set the [reply endpoint] 
> to none or to a "real address". I don't think you want to do either 
> of those things, in this context.
> 
> With these points in mind, I think it is worth looking again at my 
> previous postings. 
> 
> The orthodox way of saying "respond on the back-channel" is setting 
> [reply endpoint] to anon. This can be done explicitly or by 
> inference from absence.
> 
> I think there has to be a good reason to invent a new way of 
> expressing this semantic. Doing so has repercussions (see the 
> original starting point of this thread, re WSA W anon/required). The
> (very valuable) use case of MakeConnection does not require an 
> alternate mechnanism for stating the back channel semantic. 
> 
> We can illustrate all of this by placing three examples side by side:
> 
> * * *
> 
> 1. Example using sequence Identifier: MakeConnection and reply [as per 
CD 04]
> 2. Example using hypothetical connection identifier: MakeConnection 
> and reply [as it could be, simplified]
> 3. Example using current Address [as per CD 04]
> 
> 1a. Example using sequence Identifier: MakeConnection
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>         <wsa:Action>
http://docs.oasis-open.org/wsrx/wsrm/200608/MakeConnection
> </wsa:Action>
>         <wsa:To>http://example.org/subscriptionService</wsa:To>
> <!-- absent wsa:ReplyTo is equivalent to: 
>         <wsa:ReplyTo>
>             <wsa:Address>
http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous
> </wsa:Address>
>         </wsa:ReplyTo>
> -->
>     </S:Header>
>     <S:Body>
>         <wsrm:MakeConnection> 
>             <wsrm:Identifier>http://Business456.
> com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier>
>         </wsrm:MakeConnection> 
>     </S:Body>
> </S:Envelope>
> 
> 1b. Example using sequence Identifier: reply to MakeConnection
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>         <wsa:RelatesTo>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>         <wsa:ReplyTo><wsa:Address>http://example.org/subscriptionService
> </wsa:Address></wsa:ReplyTo>
>         <wsa:Action>http://example.com/subscriptionService/publish
> </wsa:Action>
>         <wsrm:Sequence>
>             <wsrm:Identifier>http://Business456.
> com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier>
>             <wsrm:MessageNumber>1</wsrm:MessageNumber>
>         </wsrm:Sequence>
>     </S:Header>
>     <S:Body>
>         <!-- Publication re A, B or C -->
>     </S:Body>
> </S:Envelope>
> 
> 2a. Example using hypothetical connection identifier: MakeConnection
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>         <wsa:Action>
http://docs.oasis-open.org/wsrx/wsrm/200608/MakeConnection
> </wsa:Action>
>         <wsa:To>http://example.org/subscriptionService</wsa:To>
> <!-- absent wsa:ReplyTo is equivalent to: 
>         <wsa:ReplyTo>
>             <wsa:Address>
http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous
> </wsa:Address>
>         </wsa:ReplyTo>
> -->
>     </S:Header>
>     <S:Body>
>         <wsrm:MakeConnection> 
>             <wsrm:ConnectionIdentifier>http://Business456.com/
> SubscribeTopics/Stream/7457</wsrm:ConnectionIdentifier>
>         </wsrm:MakeConnection> 
>     </S:Body>
> </S:Envelope>
> 
> 2b. Example using hypothetical connection identifier: reply to 
> MakeConnection (CreateSequence)
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>         <wsa:RelatesTo>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>         <wsa:Action>
http://docs.oasis-open-org/wsrx/wsrm/200608/CreateSequence
> </wsa:Action>
>         <wsa:ReplyTo>http://example.org/subscriptionService
</wsa:ReplyTo>
>         <wsrm:ConnectionIdentifier>
>             http://Business456.com/SubscribeTopics/Stream/7457
>         </wsrm:ConnectionIdentifier> 
>     </S:Header>
>     <S:Body>
>         <wsrm:CreateSequence>
>             <wsrm:AcksTo>
>                 <wsa:Address>http://example.org/subscriptionService
> </wsa:Address>
>             </wsrm:AcksTo>
>         </wsrm:CreateSequence>
>     </S:Body>
> </S:Envelope>
> 
> 3a. Example using wsrm:Address: MakeConnection
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>         <wsa:Action>
http://docs.oasis-open.org/wsrx/wsrm/200608/MakeConnection
> </wsa:Action>
>         <wsa:To>http://example.org/subscriptionService</wsa:To>
> <!-- absent wsa:ReplyTo is equivalent to: 
>         <wsa:ReplyTo>
>             <wsa:Address>
http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous
> </wsa:Address>
>         </wsa:ReplyTo>
> -->
>     </S:Header>
>     <S:Body>
>         <wsrm:MakeConnection> 
>             <wsrm:Address>
>                 http://docs.oasis-open.
> org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000
>             </wsrm:Address>
>         </wsrm:MakeConnection> 
>     </S:Body>
> </S:Envelope>
> 
> 3b. Example using wsrm:Address: reply to MakeConnection (CreateSequence)
> 
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
>             xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
>             xmlns:wsa="http://www.w3.org/2005/08/addressing">
>     <S:Header>
>         <wsa:MessageID>http://example.org/subscriptionService/
> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>         <wsa:RelatesTo>http://example.org/subscriptionService/
> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>         <wsa:Action>
http://docs.oasis-open-org/wsrx/wsrm/200608/CreateSequence
> </wsa:Action>
>         <wsa:To>
> 
> <!-- I believe this is WS-A illegal: reply To must equal request 
> ReplyTo/Address. --> 
> 
>             http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous?
> id=550e8400-e29b-11d4-a716-446655440000
>         </wsa:To>
>         <wsa:ReplyTo>http://example.org/subscriptionService
</wsa:ReplyTo>
>     </S:Header>
>     <S:Body>
>         <wsrm:CreateSequence>
>             <wsrm:AcksTo>
>                 <wsa:Address>http://example.org/subscriptionService
> </wsa:Address>
>             </wsrm:AcksTo>
>         </wsrm:CreateSequence>
>     </S:Body>
> </S:Envelope>
> 
> Yours,
> 
> Alastair
> 
> Doug Davis wrote: 
> 
> Alastair, 
>   I think you're mixing up the messages a bit.  There are two messages 
> at play: 
> 1 - the message containing the EPR to send subsequent messages to. 
>     In some cases this message will have the EPR in its wsa:ReplyTo 
>     header, but it could also be placed someplace else depending 
>     on its use.  And it is this EPR that needs to be tagged as the 
>     polling one (ie. it has the RM anon URI). 
>     This message will contain application specific data in the Body 
>     so your suggestion of placing some UUID in there will not work. 
>     This gets back to the necessity to keep all info about where to 
>     send messages encapsulated into whatever EPR we want to be tagged 
>     as the polling one. 
> 
> 2 - the MakeConnection message. 
>     This message does not have a wsa:ReplyTo, its a one-way.  This 
>     message does contain a Body which is the correlation info used 
>     by the receiver of this message to find an appropriate message 
>     to send back.  So, basically the stuff in the Body must match 
>     the EPR from message 1.  And given that in some cases the only 
>     thing remaining from the EPR in message 1 is the serialized 
>     version of it, we must be able to find messages based solely 
>     on what's in the outgoing message itself.  Which means the 
>     wsa:To field.  Again, ref-p's are bad for this purpose. :-) 
> 
> HTH 
> 
> thanks 
> -Doug 
> 
> 
> 
> Alastair Green <alastair.green@choreology.com> wrote on 08/07/2006 
> 02:02:55 PM:
> 
> > 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 theapp 
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
> > 
> >