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

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

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Tue, 8 Aug 2006 11:33:44 -0500
To: Alastair Green <alastair.green@choreology.com>
Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, ws-rx@lists.oasis-open.org
Message-ID: <OF3A86EDE4.049B5F18-ON852571C4.005A1B3E-852571C4.005AF5F0@us.ibm.com>

<br><font size=2 face="sans-serif">Alastair,</font>
<br>
<br><font size=2 face="sans-serif">I don't think that MakeConnection &quot;invites
a response&quot;... rather, it opens up the back-channel</font>
<br><font size=2 face="sans-serif">(when transmitted over a protocol such
as HTTP that has an inherent back-channel) for the</font>
<br><font size=2 face="sans-serif">transmission of a message. </font>
<br>
<br><font size=2 face="sans-serif">I think that there is a difference...
a large one at that.</font>
<br>
<br><font size=2 face="sans-serif">A SOAP Response is entirely different
than a protocol response message. In the context</font>
<br><font size=2 face="sans-serif">of a oneway message, carried over a
protocol such as HTTP, there is a response message</font>
<br><font size=2 face="sans-serif">that may not carry a SOAP envelope in
its entity body. It is a protocol-level response, not necessarily</font>
<br><font size=2 face="sans-serif">a SOAP level-response. The fact that
we are exploiting this is what MakeConnection is all about.</font>
<br>
<br><font size=2 face="sans-serif">As Paul indicated, I would be happy
if we suggested that WS-A none URI be specified as the</font>
<br><font size=2 face="sans-serif">ReplyTo address, but frankly, I think
that that is something for the WS-A WG to work out.</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br>
<br><font size=2 face="sans-serif">Christopher Ferris<br>
STSM, Software Group Standards Strategy<br>
email: chrisfer@us.ibm.com<br>
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440<br>
phone: +1 508 377 9295</font>
<br>
<br><tt><font size=2>Alastair Green &lt;alastair.green@choreology.com&gt;
wrote on 08/08/2006 11:42:10 AM:<br>
<br>
&gt; Chris,<br>
&gt; <br>
&gt; Redoing part of WS-A in RM creates difficulty in WS-A WSDL (start
of<br>
&gt; thread). Raises question: Why won't standard WS-A anon facility work?<br>
&gt; <br>
&gt; You have to say something about where you reply to. If you want the
<br>
&gt; reply to come on the back-channel then WS-A has a way of saying that<br>
&gt; (and you get that by default).<br>
&gt; <br>
&gt; If you say there is no reply, then you are saying: don't send a <br>
&gt; response. But MC precisely invites a response. How is a WS-A <br>
&gt; implementation supposed to understand (without being RM aware) that
<br>
&gt; reply=none really means (functionally) reply=anon? I perceive <br>
&gt; unnecessary layering tangle. WS-A layer now expected to hold HTTP
<br>
&gt; response for app, even though told that there is no response.<br>
&gt; <br>
&gt; Researching further, I don't understand why an RM-specific <br>
&gt; alternative to reply=anon has been introduced for the &quot;address&quot;
<br>
&gt; case, but not for the &quot;sequence&quot; case. <br>
&gt; <br>
&gt; I believe regular &quot;use back channel&quot; feature of WS-A can
be used, <br>
&gt; and the RM layer can handle RM &quot;sessions&quot;, in both cases.<br>
&gt; <br>
&gt; Does my example of sequence case indicate expected behaviour? Would
<br>
&gt; it be wrong to say MC/reply=anon with sequence case?<br>
&gt; <br>
&gt; First part of long message addresses Doug's points about the <br>
&gt; application-level set-up message: I don't understand the relevance
<br>
&gt; of that type of message.<br>
&gt; <br>
&gt; Alastair<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Christopher B Ferris wrote: </font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Alastair, <br>
&gt; <br>
&gt; Is this a long and drawn out manner of stating that when a message
<br>
&gt; is a true oneway (e.g. no <br>
&gt; response is expected) then the wsa:ReplyTo should be the WS-A none
<br>
&gt; URI rather than <br>
&gt; simply leaving it absent and hence falling trap to the &quot;if not
<br>
&gt; present, default to anon&quot; gotcha? <br>
&gt; <br>
&gt; I guess I am not seeing an issue here, although I guess it would be
<br>
&gt; fine if we recommended or required <br>
&gt; that the MakeConnection wsa:ReplyTo MAP carry the WS-A none URI. <br>
&gt; <br>
&gt; Cheers, <br>
&gt; <br>
&gt; Christopher Ferris<br>
&gt; STSM, Software Group Standards Strategy<br>
&gt; email: chrisfer@us.ibm.com<br>
&gt; blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440<br>
&gt; phone: +1 508 377 9295 <br>
&gt; <br>
&gt; public-ws-addressing-request@w3.org wrote on 08/08/2006 07:06:32 AM:<br>
&gt; <br>
&gt; &gt; Doug, Paul --<br>
&gt; &gt; <br>
&gt; &gt; I'm going to try to address both your comments. if I can summarize
<br>
&gt; &gt; Paul's it was: what's the big deal about [reply endpoint] when
<br>
&gt; &gt; MakeConnection is &quot;one-way&quot;?. <br>
&gt; &gt; <br>
&gt; &gt; Given RX timescales you may want to treat these remarks as &quot;early
<br>
&gt; &gt; public review&quot;.<br>
&gt; &gt; <br>
&gt; &gt; * * *<br>
&gt; &gt; <br>
&gt; &gt; Doug's message 1 is an application-level set-up call which <br>
&gt; &gt; establishes common understanding of the UUID. This type of message
<br>
&gt; &gt; is exemplified by that shown in the CD example Step 1, unless
I have<br>
&gt; &gt; completely misunderstood.<br>
&gt; &gt; <br>
&gt; &gt; In that example, a subscriber, who cannot listen, sends a subscribe
<br>
&gt; &gt; message to a publisher, saying something like &quot;subscribe
me for <br>
&gt; &gt; topics A, B, C. The identity of this subscription request is
UUID <br>
&gt; &gt; X&quot;. Thereafter, the publisher knows that X equals &quot;subscription
for <br>
&gt; &gt; topics A, B, C&quot;.<br>
&gt; &gt; <br>
&gt; &gt; Assertion 1 (please correct me if I am wrong): The format, content
<br>
&gt; &gt; etc of this type of message (and its manner of transmission)
are <br>
&gt; &gt; entirely application-specific. It may or may not require an <br>
&gt; &gt; acknowledgement. It could be sent by carrier pigeon, or by fax.
The <br>
&gt; &gt; subscribe message, if sent as SOAP-with-Addressing, might receive
a <br>
&gt; &gt; reply, or might not receive a reply, and if it did, it might
receive<br>
&gt; &gt; it anon or addressable. There are no RM rules that apply to this
<br>
&gt; &gt; message. There are only application rules. It cannot do its job
<br>
&gt; &gt; usefully unless it passes the UUID: that is all we can say.<br>
&gt; &gt; <br>
&gt; &gt; Assertion 2. At present there is an RM rule which says: &quot;the
<br>
&gt; &gt; mutually understood UUID must be reflected in the [destination
<br>
&gt; &gt; endpoint] according to an RM URI scheme&quot;. There are no RM
rules to <br>
&gt; &gt; say whether the connection UUID, during the course of establishing
<br>
&gt; &gt; mutual understanding, travels alone, embedded in a URI, in a
body <br>
&gt; &gt; element or a header element. These are all matters of bilateral
<br>
&gt; &gt; agreement at an app level between (in this case) the <br>
&gt; &gt; consumer/subscriber and the producer/publisher.<br>
&gt; &gt; <br>
&gt; &gt; [The example is potentially a bit misleading in this respect.
<br>
&gt; &gt; <br>
&gt; &gt; The use of the full &quot;anon-URI?id={uuid}&quot; value in the
&lt;targetEPR/&gt;, <br>
&gt; &gt; and the use of the element name &quot;targetEPR&quot; make one
think <br>
&gt; &gt; &quot;addressing&quot;, when one would be better off thinking
&quot;subscription <br>
&gt; &gt; identity&quot; (at an app level). The example set-up message
would work <br>
&gt; &gt; perfectly well if it read:<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;!-- subscription details --&gt; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &lt;SubscriptionIdentity&gt;{uuid}&lt;/SubscriptionIdentity&gt;<br>
&gt; &gt; &lt;/S:Body&gt;<br>
&gt; &gt; <br>
&gt; &gt; Btw, given that the use of MakeConnection requires a prior <br>
&gt; &gt; understanding between two parties of the connection identity,
there <br>
&gt; &gt; seems no reason why {uuid} has to be a UUID. It does need to
be <br>
&gt; &gt; bilaterally unambiguous.]<br>
&gt; &gt; <br>
&gt; &gt; * * *<br>
&gt; &gt; <br>
&gt; &gt; Message 2 is MakeConnection. If the subscriber sends a <br>
&gt; &gt; MakeConnection, specifying UUID X, then the publisher knows it
is <br>
&gt; &gt; dealing with traffic relating to subscription X, i.e. for topics
A, <br>
&gt; &gt; B and C. At an application level, we assume that the contract
<br>
&gt; &gt; thereafter is: start reliably communicating a stream of messages,
<br>
&gt; &gt; relating to topics A, B and C, therefore implying sequence creation
<br>
&gt; &gt; etc, until something causes the stream to close. <br>
&gt; &gt; <br>
&gt; &gt; So the subscriber will repeatedly send MakeConnection, citing
the <br>
&gt; &gt; UUID X, read the HTTP response, and handle the response as if
it <br>
&gt; &gt; were an inbound RM/RM-app message.<br>
&gt; &gt; <br>
&gt; &gt; The exchange that RM defines (rather than illustrates) is the
<br>
&gt; &gt; MakeConnection, back-call-on-the-connection one. It's this exchange
<br>
&gt; &gt; that I am discussing. MakeConnection is the message affected
by the <br>
&gt; &gt; WSAW anon=required discussion, as I see it.<br>
&gt; &gt; <br>
&gt; &gt; [While it is probably helpful for diagnostic reasons to repeat
the <br>
&gt; &gt; UUID back to the sender of MakeConnection in the [destination
<br>
&gt; &gt; endpoint], it is actually redundant, as the HTTP Response is
<br>
&gt; &gt; automatically and uniquely correlated with the HTTP Request.
This <br>
&gt; &gt; might lead one to the conclusion that the simple solution would
have<br>
&gt; &gt; been: send UUID on MakeConnection, and then respond to it on
the <br>
&gt; &gt; anonymous back-channel without reflection of UUID in any form
<br>
&gt; &gt; However, this would reduce the symmetry with the Sequence identified<br>
&gt; &gt; use of MakeConnection, see comments later]<br>
&gt; &gt; <br>
&gt; &gt; * * *<br>
&gt; &gt; <br>
&gt; &gt; There are two modes in which this exchange can work (reflecting
the <br>
&gt; &gt; joint proposal, as I understand it):<br>
&gt; &gt; <br>
&gt; &gt; a) Send response as part of a sequence that already exists<br>
&gt; &gt; b) Use response to create a new sequence, etc<br>
&gt; &gt; <br>
&gt; &gt; This is relevant to answering Paul F's question, relating to
the <br>
&gt; &gt; significance of ReplyTo.<br>
&gt; &gt; <br>
&gt; &gt; If there is a sequence, then the sequence Identifier is a <br>
&gt; &gt; correlation synonym for the UUID. The reply message may be sent
on <br>
&gt; &gt; the back-channel; it must carry the wsrm:Identifier (as a separate
<br>
&gt; &gt; header element), it need not carry the UUID.<br>
&gt; &gt; <br>
&gt; &gt; If there is no sequence, then the reply message must carry or
imply <br>
&gt; &gt; the UUID. (I'm going to assume that carrying the UUID is better
than<br>
&gt; &gt; implying it.) The question is how?<br>
&gt; &gt; <br>
&gt; &gt; Looking at these two cases, it is striking that both <br>
&gt; &gt; <br>
&gt; &gt; a) require a response on the back-channel,<br>
&gt; &gt; b) need to carry an identifier (one of the sequence, one of the
<br>
&gt; &gt; &quot;connection&quot;/&quot;session&quot;)<br>
&gt; &gt; <br>
&gt; &gt; Doug's comment that there is no wsa:ReplyTo on the MakeConnection,
<br>
&gt; &gt; that it is &quot;one way&quot;, is relevant here. In fact there
is no such <br>
&gt; &gt; thing (in the XML infoset) as a non-existent [reply endpoint].
If <br>
&gt; &gt; wsa:ReplyTo is absent, then it is inferred to be the anon-URI.
The <br>
&gt; &gt; only way you can stop that inference is to set the [reply endpoint]
<br>
&gt; &gt; to none or to a &quot;real address&quot;. I don't think you want
to do either <br>
&gt; &gt; of those things, in this context.<br>
&gt; &gt; <br>
&gt; &gt; With these points in mind, I think it is worth looking again
at my <br>
&gt; &gt; previous postings. <br>
&gt; &gt; <br>
&gt; &gt; The orthodox way of saying &quot;respond on the back-channel&quot;
is setting <br>
&gt; &gt; [reply endpoint] to anon. This can be done explicitly or by <br>
&gt; &gt; inference from absence.<br>
&gt; &gt; <br>
&gt; &gt; I think there has to be a good reason to invent a new way of
<br>
&gt; &gt; expressing this semantic. Doing so has repercussions (see the
<br>
&gt; &gt; original starting point of this thread, re WSA W anon/required).
The<br>
&gt; &gt; (very valuable) use case of MakeConnection does not require an
<br>
&gt; &gt; alternate mechnanism for stating the back channel semantic. <br>
&gt; &gt; <br>
&gt; &gt; We can illustrate all of this by placing three examples side
by side:<br>
&gt; &gt; <br>
&gt; &gt; * * *<br>
&gt; &gt; <br>
&gt; &gt; 1. Example using sequence Identifier: MakeConnection and reply
[asper CD 04]<br>
&gt; &gt; 2. Example using hypothetical connection identifier: MakeConnection
<br>
&gt; &gt; and reply [as it could be, simplified]<br>
&gt; &gt; 3. Example using current Address [as per CD 04]<br>
&gt; &gt; <br>
&gt; &gt; 1a. Example using sequence Identifier: MakeConnection<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/MakeConnection<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:To&gt;http://example.org/subscriptionService&lt;/wsa:To&gt;<br>
&gt; &gt; &lt;!-- absent wsa:ReplyTo is equivalent to: &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Address&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/anonymous<br>
&gt; &gt; &lt;/wsa:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; --&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:MakeConnection&gt; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:Identifier&gt;http://Business456.<br>
&gt; &gt; com/SubscribeTopics/Sequence/7456-3278&lt;/wsrm:Identifier&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:MakeConnection&gt; <br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; 1b. Example using sequence Identifier: reply to MakeConnection<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:RelatesTo&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:RelatesTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;&lt;wsa:Address&gt;http://example.org/subscriptionService<br>
&gt; &gt; &lt;/wsa:Address&gt;&lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://example.com/subscriptionService/publish<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:Sequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:Identifier&gt;http://Business456.<br>
&gt; &gt; com/SubscribeTopics/Sequence/7456-3278&lt;/wsrm:Identifier&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:MessageNumber&gt;1&lt;/wsrm:MessageNumber&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:Sequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;!-- Publication re A, B or C
--&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; 2a. Example using hypothetical connection identifier: MakeConnection<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/MakeConnection<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:To&gt;http://example.org/subscriptionService&lt;/wsa:To&gt;<br>
&gt; &gt; &lt;!-- absent wsa:ReplyTo is equivalent to: &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Address&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/anonymous<br>
&gt; &gt; &lt;/wsa:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; --&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:MakeConnection&gt; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:ConnectionIdentifier&gt;http://Business456.com/<br>
&gt; &gt; SubscribeTopics/Stream/7457&lt;/wsrm:ConnectionIdentifier&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:MakeConnection&gt; <br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; 2b. Example using hypothetical connection identifier: reply to
<br>
&gt; &gt; MakeConnection (CreateSequence)<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:RelatesTo&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:RelatesTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://docs.oasis-open-<br>
&gt; org/wsrx/wsrm/200608/CreateSequence<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;http://example.org/subscriptionService&lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:ConnectionIdentifier&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://Business456.com/SubscribeTopics/Stream/7457<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:ConnectionIdentifier&gt;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:CreateSequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:AcksTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Address&gt;http://example.org/subscriptionService<br>
&gt; &gt; &lt;/wsa:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:AcksTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:CreateSequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; 3a. Example using wsrm:Address: MakeConnection<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/MakeConnection<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:To&gt;http://example.org/subscriptionService&lt;/wsa:To&gt;<br>
&gt; &gt; &lt;!-- absent wsa:ReplyTo is equivalent to: &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Address&gt;http://docs.oasis-open.<br>
&gt; org/wsrx/wsrm/200608/anonymous<br>
&gt; &gt; &lt;/wsa:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; --&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:MakeConnection&gt; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://docs.oasis-open.<br>
&gt; &gt; org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:MakeConnection&gt; <br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; 3b. Example using wsrm:Address: reply to MakeConnection (CreateSequence)<br>
&gt; &gt; <br>
&gt; &gt; &lt;S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsrm=&quot;http://docs.oasis-open.org/ws-rx/wsrm/200608&quot;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:wsa=&quot;http://www.w3.org/2005/08/addressing&quot;&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:MessageID&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e&lt;/wsa:MessageID&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:RelatesTo&gt;http://example.org/subscriptionService/<br>
&gt; &gt; guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e&lt;/wsa:RelatesTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Action&gt;http://docs.oasis-open-<br>
&gt; org/wsrx/wsrm/200608/CreateSequence<br>
&gt; &gt; &lt;/wsa:Action&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:To&gt;<br>
&gt; &gt; <br>
&gt; &gt; &lt;!-- I believe this is WS-A illegal: reply To must equal request
<br>
&gt; &gt; ReplyTo/Address. --&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
&gt; &gt; <br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous?<br>
&gt; &gt; id=550e8400-e29b-11d4-a716-446655440000<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsa:To&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:ReplyTo&gt;http://example.org/subscriptionService&lt;/wsa:ReplyTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Header&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;S:Body&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:CreateSequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsrm:AcksTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;wsa:Address&gt;http://example.org/subscriptionService<br>
&gt; &gt; &lt;/wsa:Address&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:AcksTo&gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/wsrm:CreateSequence&gt;<br>
&gt; &gt; &nbsp; &nbsp; &lt;/S:Body&gt;<br>
&gt; &gt; &lt;/S:Envelope&gt;<br>
&gt; &gt; <br>
&gt; &gt; Yours,<br>
&gt; &gt; <br>
&gt; &gt; Alastair<br>
&gt; &gt; <br>
&gt; &gt; Doug Davis wrote: <br>
&gt; &gt; <br>
&gt; &gt; Alastair, <br>
&gt; &gt; &nbsp; I think you're mixing up the messages a bit. &nbsp;There
are two messages <br>
&gt; &gt; at play: <br>
&gt; &gt; 1 - the message containing the EPR to send subsequent messages
to. &nbsp; <br>
&gt; &gt; &nbsp; &nbsp; In some cases this message will have the EPR in
its wsa:ReplyTo <br>
&gt; &gt; &nbsp; &nbsp; header, but it could also be placed someplace else
depending <br>
&gt; &gt; &nbsp; &nbsp; on its use. &nbsp;And it is this EPR that needs
to be tagged as the <br>
&gt; &gt; &nbsp; &nbsp; polling one (ie. it has the RM anon URI). <br>
&gt; &gt; &nbsp; &nbsp; This message will contain application specific
data in the Body <br>
&gt; &gt; &nbsp; &nbsp; so your suggestion of placing some UUID in there
will not work. <br>
&gt; &gt; &nbsp; &nbsp; This gets back to the necessity to keep all info
about where to <br>
&gt; &gt; &nbsp; &nbsp; send messages encapsulated into whatever EPR we
want to be tagged <br>
&gt; &gt; &nbsp; &nbsp; as the polling one. <br>
&gt; &gt; <br>
&gt; &gt; 2 - the MakeConnection message. <br>
&gt; &gt; &nbsp; &nbsp; This message does not have a wsa:ReplyTo, its a
one-way. &nbsp;This <br>
&gt; &gt; &nbsp; &nbsp; message does contain a Body which is the correlation
info used <br>
&gt; &gt; &nbsp; &nbsp; by the receiver of this message to find an appropriate
message <br>
&gt; &gt; &nbsp; &nbsp; to send back. &nbsp;So, basically the stuff in
the Body must match <br>
&gt; &gt; &nbsp; &nbsp; the EPR from message 1. &nbsp;And given that in
some cases the only <br>
&gt; &gt; &nbsp; &nbsp; thing remaining from the EPR in message 1 is the
serialized <br>
&gt; &gt; &nbsp; &nbsp; version of it, we must be able to find messages
based solely <br>
&gt; &gt; &nbsp; &nbsp; on what's in the outgoing message itself. &nbsp;Which
means the <br>
&gt; &gt; &nbsp; &nbsp; wsa:To field. &nbsp;Again, ref-p's are bad for
this purpose. :-) <br>
&gt; &gt; <br>
&gt; &gt; HTH <br>
&gt; &gt; <br>
&gt; &gt; thanks <br>
&gt; &gt; -Doug <br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; Alastair Green &lt;alastair.green@choreology.com&gt; wrote on
08/07/2006 <br>
&gt; &gt; 02:02:55 PM:<br>
&gt; &gt; <br>
&gt; &gt; &gt; Doug,<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; I think I'm connecting, if you'll pardon the pun. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 1. As I read WS-A, the [destination endpoint][address] must
be set <br>
&gt; &gt; &gt; to [reply endpoint][address] for a reply.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 2. If [reply endpoint] is omitted (as per the CD example),
then <br>
&gt; &gt; &gt; [reply endpoint] = anon, by default.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 3. If [destination endpoint] = &quot;anon-URI?id={uuid}&quot;,
then <br>
&gt; &gt; &gt; [destination endpoint] &lt;&gt; [reply endpoint][address]
(which was <br>
&gt; &gt; &gt; simple, unornamented anon-URI), which contradicts premise
1.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Does that make sense? If so, then I think you would need
to set <br>
&gt; &gt; &gt; [reply endpoint] to none, explicitly, to avoid that clash
(given <br>
&gt; &gt; &gt; RM's current approach). But this causes<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 4. The WS-A processor that sent MakeConnection to get very
confused.<br>
&gt; &gt; &gt; It wasn't expecting anything but an HTTP 200 series by way
of a <br>
&gt; &gt; &gt; response, but is about to get a full-scale SOAP message
bounding back.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; +++<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Further thoughts, which continue, in my mind, to question
the <br>
&gt; &gt; &gt; current RM approach, but which may ease the WSA W problem.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; a) You could have defined an extension element in the [reply
<br>
&gt; &gt; &gt; endpoint] for the UUID.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; b) Or, you could have chosen to send the UUID in the body
element.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; c) In either case, this could team up with setting [reply
<br>
&gt; &gt; endpoint] to anon. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; d) As in 3. above, you shouldn't then set response [destination
<br>
&gt; &gt; &gt; endpoint] to anon?id={uuid}.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; e) So, you need to set [reply endpoint] to anon, and set
<br>
&gt; &gt; &gt; [destination endpoint][address] to anon.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; f) which begs the question, where does the UUID go?<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; g) &nbsp;If you passed an extension element UUID, or a UUID
in the body <br>
&gt; &gt; &gt; element, and then passed it back as an extension element
in the anon<br>
&gt; &gt; &gt; EPR that should be OK, because you have followed the rules
for reply<br>
&gt; &gt; &gt; formulation with respect to the [destination endpoint][address]<br>
&gt; &gt; &gt; /[reference parameters]. The fact you have chosen to put
an <br>
&gt; &gt; &gt; extension element in the response is WS-A 3.3/3.4 legal,
as I read <br>
&gt; &gt; &gt; it. That's a higher-layer behaviour that does not contradict
WS-A <br>
&gt; &gt; &gt; base behaviour, which is constrained.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; +++<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Why is g) not viable in your view? The processors that need
to <br>
&gt; &gt; &gt; understand the body/extension UUID element are the RM senders
and <br>
&gt; &gt; &gt; responders (not the WS-A processors, which passively pass
on the <br>
&gt; &gt; &gt; UUID to the RM receiver of MakeConnection, and pass on the
extension<br>
&gt; &gt; &gt; element to the RM receiver of the response). <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; In other words, the awareness of RM-ness that is demanded
in <br>
&gt; &gt; &gt; formulating MakeConnection, and in replying to it, resides
in the <br>
&gt; &gt; &gt; same place, and at the same level, as in the current (CD)
solution.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; The difference being: that the MakeConnection is now a regular
<br>
&gt; &gt; &gt; [reply endpoint] = anon. At which point special WSAW rules
are not needed.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; I don't see any lesser or greater problem with intermediaries,
<br>
&gt; &gt; &gt; onward transmission etc than would apply with the current
solution, <br>
&gt; &gt; &gt; if that is a concern. On this point, I think I may be missing
<br>
&gt; &gt; &gt; something, or misunderstanding your area of concern?<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; So, to summarize:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; 1. asimple-non out, special, ornamented-anon back is a problem.<br>
&gt; &gt; &gt; 2. none out, anon back is a problem.<br>
&gt; &gt; &gt; 3. extension element UUID out, extension element UUID back,
is no <br>
&gt; &gt; &gt; different, in layer terms, than body UUID out, ornamented
address <br>
&gt; &gt; &gt; back, i.e. is not a problem.<br>
&gt; &gt; &gt; 4. anon out means no problem with anon = required.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; * * *<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; My last point was indeed completely beside the point of
your issue :<br>
&gt; &gt; &gt; -) -- it is an independent issue about WSAW, and a limitation
that <br>
&gt; &gt; &gt; the proposed syntax seems to impose by applying the flag
across all <br>
&gt; &gt; &gt; &quot;response endpoints&quot;. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Alastair<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Doug Davis wrote: <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Alastair, <br>
&gt; &gt; &gt; &nbsp; We did consider adding some extra metadata to the
EPR (outside of <br>
&gt; &gt; &gt; the wsa:Address and ref-p's), but there's a problem - this
metadata <br>
&gt; &gt; &gt; is not copied over into the response message - just the
wsa:Address <br>
&gt; &gt; &gt; and ref-p's are. &nbsp;This means that any data placed elsewhere
in the <br>
&gt; &gt; &gt; EPR is lost once the message is serialized. &nbsp;So unless
we assume the<br>
&gt; &gt; &gt; impl can hold on to the original EPR for the entire message
path <br>
&gt; &gt; &gt; (which we can't in distributed systems), the identity part
must be <br>
&gt; &gt; &gt; in either the address or ref-p's. &nbsp;And, as you said,
ref-p's aren't <br>
&gt; &gt; &gt; good for this. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &nbsp; What's interesting about your anon?unique-id example
is that that <br>
&gt; &gt; &gt; solution might work very nicely (we talked about this in
the past) -<br>
&gt; &gt; &gt; but as you said it would require WSA to say anon URIs 'start
<br>
&gt; &gt; &gt; with...' - and WSA is closed :-( <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &nbsp; I got a bit lost on your last point - it almost sounded
like a <br>
&gt; &gt; &gt; complaint about the current WSA WSDL spec instead of my
issue - &nbsp;or <br>
&gt; &gt; &gt; did I not follow it? <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &nbsp; I noticed that on the agenda for tomorrow's WSA call
(I think its <br>
&gt; &gt; &gt; tomorrow) is a CR issue that mentioned how this wording
in the WSDL <br>
&gt; &gt; &gt; spec prevents the use of &quot;none&quot;. &nbsp;I can't
help but think that both <br>
&gt; &gt; &gt; issues (mine and the other CR issue) would be solved nicely
if the <br>
&gt; &gt; &gt; wording were turned around a bit and said something about
how this <br>
&gt; &gt; &gt; flag indicates whether or not the endpoint supports addressable
<br>
&gt; &gt; &gt; endpoints in the response EPRs. &nbsp;Not sure of the exact
wording, but <br>
&gt; &gt; &gt; if instead of taking about specific URIs (like anon and
none) it <br>
&gt; &gt; &gt; talked about whether the endpoint supported the notion of
creating <br>
&gt; &gt; &gt; it own connections to the EPR then it wouldn't need to get
into the <br>
&gt; &gt; &gt; business of listing all of the URIs that are valid. &nbsp;And
I think it <br>
&gt; &gt; &gt; would relay the exact same information. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; thanks <br>
&gt; &gt; &gt; -Doug <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Alastair Green &lt;alastair.green@choreology.com&gt; <br>
&gt; &gt; &gt; 08/04/2006 10:57 AM <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; To <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Doug Davis/Raleigh/IBM@IBMUS <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; cc <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; public-ws-addressing@w3.org, public-ws-addressing-request@w3.org,
<br>
&gt; &gt; &gt; ws-rx@lists.oasis-open.org, abbieb@nortel.com, aclark@novell.com,
<br>
&gt; &gt; &gt; akira.tanaka.pr@hitachi.com, aleyfer@actional.com, anash@reactivity.com,
<br>
&gt; &gt; &gt; andreas.bjarlestam@ericsson.com, anil.edakkunni@soa.com,
anil.<br>
&gt; &gt; john@jhuapl.edu<br>
&gt; &gt; &gt; , Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS,
<br>
&gt; &gt; &gt; asakala@iona.com, ash@rainingdata.com, ashok.malhotra@oracle.com,
<br>
&gt; &gt; &gt; asirveda@microsoft.com, atarashi@sv.nec-labs.com, atmanes@gmail.com,
<br>
&gt; &gt; &gt; audet@nortel.com, barreto@adobe.com, bhakti.mehta@sun.com,
blake.<br>
&gt; &gt; &gt; dournaee@intel.com, bob.freund@hitachisoftware.com, bob.sunday@pwgsc.gc.ca<br>
&gt; , <br>
&gt; &gt; &gt; b.eckenfels@seeburger.de, carolina.canales@ericsson.com,
<br>
&gt; chamikara@wso2.com<br>
&gt; &gt; , <br>
&gt; &gt; &gt; chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS,
<br>
&gt; &gt; &gt; chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS,
<br>
&gt; &gt; &gt; Christopher.Kurt@microsoft.com, chris.hipson@bt.com, &quot;'von
<br>
&gt; Riegen, Claus'&quot; <br>
&gt; &gt; &gt; &lt;claus.von.riegen@sap.com&gt;, coevans@microsoft.com,
<br>
&gt; cunningham_david@bah.com<br>
&gt; &gt; , <br>
&gt; &gt; &gt; dan@actional.com, &quot;'Burdett, David'&quot; &lt;david.burdett@sap.com&gt;,
<br>
&gt; &gt; &gt; dconnelly@openapplications.org, Diane Jordan/Raleigh/IBM@IBMUS,
<br>
&gt; &gt; &gt; dkmin@konkuk.ac.kr, dleshc@tibco.com, dmoberg@us.axway.com,
<br>
&gt; &gt; dnickull@adobe.com<br>
&gt; &gt; &gt; , &quot;'David Orchard'&quot; &lt;dorchard@bea.com&gt;,
doug.bunting@sun.com, <br>
&gt; &gt; &gt; eisaku.nishiyama.dd@hitachi.com, email@cbvenkat.net, eoghan.glynn@iona.com<br>
&gt; , <br>
&gt; &gt; &gt; Eric.Newcomer@iona.com, eric.rajkovic@oracle.com, eric.<br>
&gt; &gt; &gt; wells@hitachisoftware.com, ganga.sah@oracle.com, gatfora@uk.ibm.com,
<br>
&gt; &gt; &gt; gboschi@sonicsoftware.com, gdaniels@sonicsoftware.com, &quot;'Gilbert
Pilz'&quot; <br>
&gt; &gt; &gt; &lt;Gilbert.Pilz@bea.com&gt;, girish.juneja@intel.com, gregcarp@microsoft.com,
<br>
&gt; &gt; &gt; greg.pavlik@oracle.com, hbenmalek@us.fujitsu.com, heiko.braun@jboss.com,
<br>
&gt; &gt; &gt; ian.c.jones@bt.com, ian_robinson@uk.ibm.com, james.speer@capgemini.com,
<br>
&gt; &gt; &gt; jamie.clark@oasis-open.org, jdurand@us.fujitsu.com, jeff.<br>
&gt; &gt; &gt; mischkinsky@oracle.com, jekanaya@cs.indiana.edu, Jiri.Tejkl@systinet.com,
<br>
&gt; &gt; &gt; jjchoe@tmax.co.kr, jkchoi@methodi.com, jmarsh@microsoft.com,
joeri.<br>
&gt; &gt; &gt; van_cleynenbreugel@alcatel.be, john.gotze@oasis-open.org,
john.<br>
&gt; &gt; kemp@nokia.com<br>
&gt; &gt; &gt; , joseph.2.waller@bt.com, junghc@nca.or.kr, jypyon@nca.or.kr,
k-<br>
&gt; &gt; &gt; seki@da.jp.nec.com, kcyee@cecid.hku.hk, kiwasa@jp.fujitsu.com,
<br>
&gt; &gt; &gt; lburch@novell.com, lily.liu@webmethods.com, &quot;'Lei Jin'&quot;
&lt;ljin@bea.com&gt;, <br>
&gt; &gt; &gt; machi@nca.or.kr, &quot;'Mark Little'&quot; &lt;mark.little@jboss.com&gt;,
<br>
&gt; &gt; &gt; &quot;'Schenecker, Mark'&quot; &lt;mark.schenecker@sap.com&gt;,
&quot;'de Boer, Martijn'&quot; <br>
&gt; &gt; &gt; &lt;martijn.de.boer@sap.com&gt;, &quot;'Raepple, Martin'&quot;
&lt;martin.raepple@sap.com&gt;, <br>
&gt; &gt; &gt; mary.mcrae@oasis-open.org, matsuki.yoshino.pw@hitachi.com,
<br>
&gt; &gt; mckierna@uk.ibm.com<br>
&gt; &gt; &gt; , mgoodner@microsoft.com, mhb@itst.dk, &quot;'Bechauf, Michael'&quot;
<br>
&gt; &gt; &gt; &lt;michael.bechauf@sap.com&gt;, mike.grogan@sun.com, millwood@uk.ibm.com,
<br>
&gt; &gt; &gt; mlovett@uk.ibm.com, mlyons@layer7tech.com, mschenecker@e2open.com,
<br>
&gt; &gt; &gt; mwang@tibco.com, nickr@enosis.com, nilo.mitra@ericsson.com,
<br>
&gt; &gt; &gt; nobuyuki.yamamoto.vw@hitachi.com, Ondrej.Hrebicek@microsoft.com,
<br>
&gt; &gt; paul@wso2.com<br>
&gt; &gt; &gt; , pauld@mitre.org, paul.cotton@microsoft.com, paul.knight@nortel.com,
<br>
&gt; &gt; &gt; peter.furniss@erebor.co.uk, peter_niblett@uk.ibm.com, pete.wenzel@sun.com<br>
&gt; , <br>
&gt; &gt; &gt; prateek.mishra@oracle.com, pyendluri@webmethods.com, Richard
<br>
&gt; &gt; &gt; Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org, sada@jp.fujitsu.com,<br>
&gt; &gt; &gt; &quot;'Patil, Sanjay'&quot; &lt;sanjay.patil@sap.com&gt;,
sanka@wso2.com, <br>
&gt; scayron@acord.org<br>
&gt; &gt; &gt; , Scott Hinkelman/Austin/IBM@IBMUS, shengsong.ni@oracle.com,
<br>
&gt; &gt; &gt; shivajee@tibco.com, srcarter@novell.com, stefanba@microsoft.com,
<br>
&gt; &gt; &gt; &quot;'Rossmanith, Stefan'&quot; &lt;stefan.rossmanith@sap.com&gt;,
&quot;'Winkler, Steve'&quot; <br>
&gt; &gt; &gt; &lt;steve.winkler@sap.com&gt;, sumit.gupta@oracle.com, tboubez@layer7tech.com,
<br>
&gt; &gt; &gt; tejeswar.das@iona.com, thomas.erl@soasystems.com, thomas.t.bui@boeing.com<br>
&gt; , <br>
&gt; &gt; &gt; timothy@drummondgroup.com, toby.considine@unc.edu, tom@coastin.com,
<br>
&gt; &gt; &gt; &quot;'Yalcinalp, Umit'&quot; &lt;umit.yalcinalp@sap.com&gt;,
vfurman@webmethods.com<br>
&gt; &gt; &gt; , &quot;'Shipkowitz, Vicki'&quot; &lt;vicki.shipkowitz@sap.com&gt;,
vikas@sonoasystems.com<br>
&gt; &gt; &gt; , &quot;'Videlov, Vladimir'&quot; &lt;vladimir.videlov@sap.com&gt;,
Martin Chapman <br>
&gt; &gt; &gt; &lt;martin.chapman@oracle.com&gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Subject <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Re: Comment on WSDL spec: use of Anonymous Element <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Hi Doug,<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Comments interspersed:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Doug Davis wrote: <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Alastair, <br>
&gt; &gt; &gt; &nbsp;There are a couple of different things at play here.
First, sorry <br>
&gt; &gt; &gt; about the long cc-list but the wsrx mailing list still doesn't
<br>
&gt; &gt; &gt; appear to work so I need to include the entire wsrx team
manually :-( <br>
&gt; &gt; &gt; I thought my mail client was going to expire when I just
did &quot;reply all&quot;. <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; In a non-anonymous world the wsa:Address field represents
both the <br>
&gt; &gt; &gt; fact that the destination can access connections and it
identifies <br>
&gt; &gt; &gt; the party. &nbsp;And I think that makes sense. &nbsp;There
is no reason to not<br>
&gt; &gt; &gt; have a single URI do that (let's not get into the 'identity'
issue <br>
&gt; &gt; &gt; w.r.t. ref-p's &nbsp;:-). &nbsp; So, if we then switch over
to the anonymous <br>
&gt; &gt; &gt; case, IMO, I don't believe the implementation should need
to change </font></tt>
<br><tt><font size=2>&gt; &gt; &gt; w.r.t. the purpose of this URI. <br>
&gt; &gt; &gt; Here's what I don't understand. In the non-anon case an
EPR (address<br>
&gt; &gt; &gt; + stuff) is used to target. In the anon case, so far as
I can tell, <br>
&gt; &gt; &gt; there is nothing in WS-A to stop the same &quot;full EPR&quot;
(address + <br>
&gt; &gt; &gt; stuff) be
Received on Tuesday, 8 August 2006 16:34:20 GMT

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