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
|