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 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
>
>
|