Alistair,
> If you say there is no reply, then you are saying:
don't send a
> response.
Again, the SOAP-level is distinct from
the transfer/transport-level. They are NOT at all related.
It is only that many assume that they
are, when in fact, they are not.
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Alastair Green <>
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:
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> 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 <> 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 <>
> > > 08/04/2006 10:57 AM
> > >
> > > To
> > >
> > > Doug Davis/Raleigh/IBM@IBMUS
> > >
> > > cc
> > >
> > > , ,
> > > , , ,
> > > , , ,
> > > , ,
anil.
> >
> > > , , Anthony Nadalin/Austin/IBM@IBMUS,
> > > , , ,
> > > , , ,
> > > , , ,
blake.
> > > , ,
> ,
> > > , ,
>
> > ,
> > > , Charles Levay/Raleigh/IBM@IBMUS,
> > > , Christopher B Ferris/Waltham/IBM@IBMUS,
> > > , , "'von
> Riegen, Claus'"
> > > <>, ,
>
> > ,
> > > , "'Burdett, David'" <>,
> > > , Diane Jordan/Raleigh/IBM@IBMUS,
> > > , , ,
> >
> > > , "'David Orchard'" <>,
,
> > > , ,
> ,
> > > , , eric.
> > > , , ,
> > > , , "'Gilbert
Pilz'"
> > > <>, , ,
> > > , , ,
> > > , , ,
> > > , , jeff.
> > > , , ,
> > > , , ,
joeri.
> > > , ,
john.
> >
> > > , , , ,
k-
> > > , , ,
> > > , , "'Lei Jin'"
<>,
> > > , "'Mark Little'" <>,
> > > "'Schenecker, Mark'" <>,
"'de Boer, Martijn'"
> > > <>, "'Raepple, Martin'"
<>,
> > > , ,
> >
> > > , , , "'Bechauf, Michael'"
> > > <>, , ,
> > > , , ,
> > > , , ,
> > > , ,
> >
> > > , , , ,
> > > , ,
> ,
> > > , , Richard
> > > Salz/Cambridge/IBM@IBMUS, , ,
> > > "'Patil, Sanjay'" <>,
,
>
> > > , Scott Hinkelman/Austin/IBM@IBMUS, ,
> > > , , ,
> > > "'Rossmanith, Stefan'" <>,
"'Winkler, Steve'"
> > > <>, , ,
> > > , ,
> ,
> > > , , ,
> > > "'Yalcinalp, Umit'" <>,
> > > , "'Shipkowitz, Vicki'" <>,
> > > , "'Videlov, Vladimir'" <>,
Martin Chapman
> > > <>
> > >
> > > Subject
> > >
> > > Re: Comment on WSDL spec: use of Anonymous Element
> > >
> > >
> > >
> > >
> > > Hi Doug,
> > >
> > > Comments interspersed:
> > >
> > > Doug Davis wrote:
> > >
> > > Alastair,
> > > There are a couple of different things at play here.
First, sorry
> > > about the long cc-list but the wsrx mailing list still doesn't
> > > appear to work so I need to include the entire wsrx team
manually :-(
> > > I thought my mail client was going to expire when I just
did "reply all".
> > >
> > > In a non-anonymous world the wsa:Address field represents
both the
> > > fact that the destination can access connections and it
identifies
> > > the party. And I think that makes sense. There
is no reason to not
> > > have a single URI do that (let's not get into the 'identity'
issue
> > > w.r.t. ref-p's :-). So, if we then switch over
to the anonymous
> > > case, IMO, I don't believe the implementation should need
to change
> > > w.r.t. the purpose of this URI.
> > > Here's what I don't understand. In the non-anon case an
EPR (address
> > > + stuff) is used to target. In the anon case, so far as
I can tell,
> > > there is nothing in WS-A to stop the same "full EPR"
(address +
> > > stuff) being used to target the reply.
> > >
> > > If one pursues this, what you intuitively want is: callback
EPR =
> > > {address = anon URI, ref-param[0] = identity}.
> > >
> > > But ref-params are opaque. Not what you want. (Although
I can't see
> > > how to stop an app contract, e.g. RM, specifying that we'll
use a
> > > mutually-known type for a ref-param, and make its presence
mandatory
> > > for certain messages).
> > >
> > > Assume that ref-param is not good. Why not add an RM extension
> > > element to the EPR? This retains the identity lexeme within
the EPR.
> > > A WS-A impl should be happy to insert and extract such extension
> > > elements, even if it hasn't a clue what they mean.
> > >
> > > In the simple WS-Addr anon use-case the URI still indicates
both
> > > things - whether or not (and 'not' in this case) the destination
> > > will accept a connection, and it also indicates the identity
- sort
> > > of. The identity is implicitly defined by the fact
that it is tied
> > > to the connection on which the request came in on. If
we did what
> > > you're suggesting and add a second header then, IMO, RM
would
> > > require quite a big change to people's soap processor. I
think WS-
> > > Addr did a really good thing by keeping everything people
need to
> > > know with a single structure - the EPR. Even with
the introduction
> > > of the anonymous URI (which could very easily have been
introduced
> > > in a much less cleaner fashion), most of the SOAP processor
doesn't
> > > really need to know what the specific value of the wsa:Address
> > > element is until it tries to actually send the message over
the wire.
> > > So, if we then switch over the MakeConnection use-case,
I think RM
> > > did the right thing by using the same mechanism WS-Addr
did - keep
> > > everything within a single EPR.
> > > OK, but I think you may be conflating "a single EPR"
with "the
> > > address element of a single EPR".
> > >
> > > This allows for most of the SOAP processor to be totally
unaware of
> > > the actually transport mechanism until (or close to) the
time the
> > > message is serialized on the wire. If there were additional
headers
> > > to carry this information then existing WS-Addr logic of
mapping a
> > > wsa:ReplyTo over to a wsa:To + ref-p headers when constructing
a
> > > response might need to also change. There's also lots
of other use-
> > > cases where the logic to handle the RM code isn't on the
same
> > > machine doing this WS-Addr mapping so if its not aware of
RM at all
> > > it wouldn't even know to include some special bit on the
outgoing
> > > message (either in the message or in the soap processor's
metadata
> > > about the message) to indicate that MakeConnection will
be used.
> > > Things are just a whole lot easier if everything is encapsulated
in
> > > a single EPR, and more specifically in the wsa:Address field.
Which
> > > is exactly how WS-Addr anon works today.
> > > Hmm, back to the conflation. I can't see anything in the
WS-Addr
> > > spec that prevents use of ref params, metadata or extensibility
> > > elements within an anon EPR. Here, you want to use
the special
> > > value of [address], and put an application-defined type/value
in the
> > > rest of the EPR. That would fit your requirement to "keep
it in the EPR".
> > > I don't think loosening the wording makes thing indeterminate
- it
> > > still requires a URI with the proper semantics, but it allows
for
> > > the composition of other specifications that may defined
their own.
> > > And, IMO, as long as they are consistent with WS-Addr's
definition
> > > of anon, from a WS-Addr perspective, then how they choose
to add
> > > additional semantics is up to them.
> > > I'm not convinced. I think you are layer-violating -- introducing
> > > precisely the problem that you are trying to avoid.
> > >
> > > At the SOAP processing level this message is full of arcane
headers
> > > of unknown meaning. At the WS-A processor level, these are
> > > commonplace headers with well-defined meanings, which may
contain
> > > some arcane app ref params and extension elements of unknown
meaning.
> > >
> > > [reply endpoint][address] = anon URI means: "send a
response on the
> > > back-channel". At the last minute the WS-A processor
whacks the
> > > arcana (ref-params, metadata and extensibility elements)
into the
> > > header and whisks them off on the response. Receiving WS-A
processor
> > > gives the arcana to the app, for which they are meaningful
(for
> > > routing or correlation or whatever).
> > >
> > > This works because the WS-A receiver can look at well-known,
> > > expected endpoint [reply endpoint] and can find the well-known,
> > > expected anon URI -- and need think no further. Anon URI
= use
> > back channel.
> > >
> > > If the URI is different (anon-URI?tum-ti-tum-ti-tum) then
the WS-A
> > > processor has to assume that it's something special. In
fact, it's
> > > going to try to address it as a "real address",
surely? Only the RM
> > > layer knows that "?<string>" is irrelevant
to back-channel choice.
> > >
> > > I can think of three ways of getting around this:
> > >
> > > 1) Amend WS-Addressing Core to say: the distinguished URI
is "any
> > > URI which begins with the following distinguished string".
> > >
> > > 2) Amend WS-Addressing Core to say: the following distinguished
> > > metadata element or additional property means: whatever
the content
> > > of [address], use the back-channel.
> > >
> > > 3) Put an extension element in the EPR that is routing data
at
> theapp level.
> > >
> > > 1) & 2) involve amending WS-Addressing, which doesn't
seem like a
> > great idea.
> > >
> > > 3) Involves no change to WS-Addressing.
> > >
> > > If the WSDL says: anon is required, then what is the value
inserted
> > > on the wire for [reply endpoint][address]? If more definition
is
> > > required to establish that, then we seem to be losing the
low-level,
> > > generic capability WS-Addressing has defined. That's what
I meant by
> > > indeterminacy.
> > >
> > >
> > > In talking about this with Chris Ferris, he mentioned
another
> > > alternative... instead of saying "MUST", perhaps
the text related to
> > > the wsaw:Anon flag could simply say "SHOULD".
This clearly
> > > indicates that WS-Addr's anon URI is the URI of choice,
but if there
> > > are good reasons for using some other one then the processor
will
> > > allow those as well.
> > > Let me raise another point about the WSAW wording. It talks
about
> > > "response endpoints" in the plural. Will the required,
etc apply to
> > > all endpoints which can be responded to, i.e. [from e],
[reply e],
> > > [fault e], or is it specific to each? It seems to imply
the former.
> > >
> > > If ths is so, then it precludes routing tricks like the
following
> > > (which is practically useful):
> > >
> > > [from endpoint] is my address if you need to send me a second
(e.g.
> > > repeated) response.
> > > [reply endpoint] = anon-URI, which is where to send your
first
> > > response, which we hope gets through.
> > >
> > > This feature allows retrying protocols to maximize use of
HTTP
> > > responses, but not be limited by them. I would like to be
able to
> > > express this as a contractual statement: this endpoint may
be anon,
> > > this one must not be: from/prohibited, reply/optional. I
have a use
> > > case in a customer business protocol for exactly this behaviour.
I
> > > think it's a useful optimization in other contexts.
> > >
> > > Yrs,
> > >
> > > Alastair
> > >
> > > thanks,
> > > -Doug
> > >
> >
> > >
> > > Alastair Green <>
> > > Sent by:
> > > 08/04/2006 06:59 AM
> > >
> > > To
> > >
> > > Doug Davis/Raleigh/IBM@IBMUS
> > >
> > > cc
> > >
> > > ,
> > >
> > > 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
> > >
> > >
