Paul,
I don't think that the behaviour I describe (where RM knowledge
intrudes into a WS-Addressing implementation of a core WS-Addressing
feature) is acceptable. This is a composition/layering problem.
WS-A impl must now apply special rules (as I have described) if it
encounters a message with [reply ep] = none which happens to be a WS-RM
message called MakeConnection. Do you agree with that statement?
If so, how would you go about creating a freestanding WS-A Core
implementation that is RM-unaware?
WS-TX decided to make all one-ways have [reply ep] = none, to make
clear that its notification messages are indeed "one way". I don't see
any problem with that.
However, these MakeConnection messages are not the same. They induce,
in the broad, the back channel behaviour created by use of anon. But
they are subtly different, in that the response may just be an ack.
There is no well-known URI to represent that behaviour, at present (or
at least, the RM one is not being used).
At best, this is an RM extension to WS-Addressing, and it should layer
cleanly on the WS-Addressing core behaviour.
Alastair
Paul Fremantle wrote:
Alastair
I don't think there's anything wrong with [reply= none]. On the other
hand, I don't expect to have to put [reply=none] on every one-way
interaction I make. I don't believe there is anything wrong with the
current situation.
Paul
Alastair Green wrote:
Chris, Paul:
*What's wrong with [reply endpoint = none]?
*1. None URI means "no response expected", implies transport ack only.
Contents of transport response body would reasonably be ignored by a
WS-A implementation.
2. WS-A receiver of [reply endpoint] = None URI will not stall for an
application handoff or for application response: it will pass the
inbound message, and immediately ack the sender, and lose all context
(transport response, message id correlation information).
3. RM would be asking WS-A implementations to stop natural, generic
behaviours 1. and 2., and become aware of RM.
4. None URI means ack only. Anon means SOAP envelope in the transport
response, always. New URI needed to mean: "May be SOAP, may be ack".
Receiver of new URI (APAO below) knows to stall for application
release before acking (empty response body) or SOAPing (full response
body).
*
**Alternatives
*
1. We can't use [reply endpoint] = anon (the default) because the WS-A
SOAP Binding limits this to cases where there is always a SOAP
envelope in the transport response (ack only forbidden). I believe
this is the /only/ obstacle. Everything else is proceeding from that
WS-A limitation. (If this perceived limitation does not exist, then I
would see no reason not to use anon URI.)
2. Create a special URI, as anticipated by the WS-A SOAP Binding, that
means: "Transport response can either be message or ack-alone".
3. Call this special URI .../anonymous/permittingAckOnly (APAO). [Not
a good name, a strawman]
4. Send MakeConnection/ReplyTo/Address=APAO. Allow ref-params in the
normal manner. (Ref params can't be handled with current solution).
5. Permit MakeConnection to contain a sequence Identifier, if desired,
(as per current solution).
6. Allow for an extension element in MC, if the app wants to identify
the conversation. The identity of the conversation only has to be
unambiguous between the application parties, so UUID is bound to be
right, but not always needed. The type of the identification is an app
issue. If you don't like that, permit MC to contain a connection
identifier, type is UUID (closest to current solution).
7. Decide who's going to own the special APAO URI. It really should be
WS-Addressing, as this is a general, app-level requirement. RM is
permitting an /application /behaviour (the message stream is
application content, which may, in the RM context, be bracketed by
some RM set-up and tear-down, as it happens).
8. If process/timescales force RM to "stand in" for WS-Addressing,
then this means worrying about impact on WS-A implementations (which
is where this started from for me). See above re implications for WS-A
implementations of use of none URI
Alastair
Christopher B Ferris wrote:
Alastair,
I don't think that MakeConnection "invites a response"... rather, it
opens up the back-channel
(when transmitted over a protocol such as HTTP that has an inherent
back-channel) for the
transmission of a message.
I think that there is a difference... a large one at that.
A SOAP Response is entirely different than a protocol response
message. In the context
of a oneway message, carried over a protocol such as HTTP, there is a
response message
that may not carry a SOAP envelope in its entity body. It is a
protocol-level response, not necessarily
a SOAP level-response. The fact that we are exploiting this is what
MakeConnection is all about.
As Paul indicated, I would be happy if we suggested that WS-A none
URI be specified as the
ReplyTo address, but frankly, I think that that is something for the
WS-A WG to work out.
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
Alastair Green <alastair.green@choreology.com> wrote on 08/08/2006
11:42:10 AM:
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
[asper 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) be
|