- From: Alastair Green <alastair.green@choreology.com>
- Date: Wed, 09 Aug 2006 08:29:42 +0100
- To: Doug Davis <dug@us.ibm.com>
- CC: public-ws-addressing@w3.org, ws-rx@lists.oasis-open.org
- Message-ID: <44D98EE6.3040209@choreology.com>
Hi Doug,
Thanks for your detailed response. For me at least this is clarifying.
Point by point:.
A. You view MC as passing an EPR. But it's a very odd EPR.
1) It is constrained to the address (has no way of communicating ref
params). You maintain that we can and must pass be able to pass ref
params. How, where? There are two possible elements in
wsrm:MakeConnection -- wsrm:Identifier and wsrm:Address. Where is the
space for reference parameters in wsrm:Address?
2) It means: "use the transport response".
3) It is computable from a subset (the UUID), and it is therefore not
necessary to pass it in its entirety. Or to put it another way,
precisely because we can't pass a full EPR, we only need to pass a UUID.
All comments to the effect: the UUID alone is not sufficient, is
irrelevant etc, are rendered moot by point 3).
If the URI equals well-known constant A, suffixed by variable UUID, then
it is absolutely unnecessary to pass A, and only necessary to pass UUID.
To put this another way: MakeConnection is not really an RM mechanism,
it is an application mechanism. RM is defining something that
WS-Addressing really ought to define. The channel can be used to send
application messages of any description.
Overall, I think the mental model "pass an EPR, and then receive
communication back to that EPR" does not match what is in the spec. What
the spec actually says is: send me a reply to this request (where the
reply may simply be a receipt ack). The correlation or addressing is
given by the transport response. (Which is why, ultimately, the
connection identifier/UUID, however carried, is unnecessary: it is
purely application context, which RM is giving house room to.)
B. "The UUID does not identify the subscription, it identifies the
stream of messages from producer to consumer". Actually the UUID
identifies a channel whose scope/ meaning is application-defined. It is
an app-level context. Creating more complicated application examples
doesn't clarify -- it just adds redundant detail.
C. If "UUID" is the identity of the "stream", and the stream is
constructed by two application parties, then the use of UUID is a way of
ensuring that the parties aren't lazy, but the UU bit is not necessary.
It's a BUID -- bilaterally unique ID. Secondary point.
D. I said that the publisher needs to know that all traffic on this
stream is related to the passage of the content relating to this
subscription. In the context of RM, traffic establishing sequence etc is
indeed related to the passage of the content relating to this
subscription. I did not say "traffic which is application data only, and
has nothing to do with RM context or apparatus". In other words, we are
violently agreeing.
E. How can anon=required refer to the set up message? WS-Addressing has
no concept of a message that passes by out-of-band (application) means
the need to respond on the back-channel. That is a process which cannot
be specified by WS-A means: it requires RM-level specification, or an
amendment to WS-Addressing.
F. I take reference to CloseSequence (which embeds Identifier) to mean:
"Yes, it's true that sequence Identifier is a proxy for UUID
(application stream identity). Yes, it's true that the RM URI plays no
part in the sequence case".
G. The [destination endpoint] splits into wsa:To (the address) and
wsa:ReferenceParameters. Putting the UUID in the address is not "just
like normal EPRs". It is precisely unlike normal EPRs, which put the
routing/contextualization in another element, and keep the address for
the transport-level address.
H. I think that you and Chris are straining far too hard to deny that MC
induces responses. Each and every MC invites a response. The response
may be empty (the ack alone). So what? By this "physical" means (solicit
message, solicit message, solicit message) we create a logical stream of
"message, message".
I. Example 1b. Where is the wsa:To? It defaults to the anonymous URI,
like wsa:ReplyTo. No need to state on the wire.
J. Example 2b. How did ConnectionIdentifier get into the message?
Because the sender of the back-channel response read the MC element, and
found the sub-element ConnectionIdentiifier ... and reflected it back.
Just like reflecting back the sequence Identifier.
K. An RM header called Connection Identifier is no more a reference
parameter than sequence Identifier. The app needs to establish a
non-opaque context for the stream or relationship. This is analogous to
passing transaction context id explicitly in WS-Coordination Register.
L. To must equal ReplyTo legal because this is a one-way. If [reply
endpoint] = none URI, then true. Thus far, [reply endpoint] was
defaulted to anon URI, so not true. But see response to Chris and Paul
re [reply endpoint] = none.
Thanks again,
Alastair
Doug Davis wrote:
>
> Alastair Green <alastair.green@choreology.com> wrote on 08/08/2006
> 07:06:32 AM:
>
> It seems like your responses are getting longer :-)
> I think there are some basic misunderstandings around the use of
> MakeConnection.
> Hopefully, this will clear it up. The biggest thing you need to
> understand
> is the MakeConnection is a one-way and the message that flows back on the
> back-channel _IS NOT_ a response to the MakeConnection. See below.
>
> > 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.
>
> Message 1 does not establish a UUID, it hands an EPR over to the
> service. This is very very important. This is no different than
> any other kind of EPR whether it be a replyTo or the EPR for some
> async message to be sent later. The fact that the EPR just happens
> to have the RManonURI+UUID in its wsa:Address field is irrelevant
> until the transport layer of the soap stack tries to actually
> send a message to that EPR. And this should be the same for
> anon as well as none URIs.
> I'm tempted to stop here because I think you misunderstood :-) but
> alas I'll keep going...
>
> > 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".
>
> No. If I sent you a subscribe and said send the events to:
> http://dug.ibm.com/
> would you say that the identity of this subscription is this
> URL? No. This just happens to be the address that we want
> messages sent to. There could be lots of subscriptions using
> this URL. The identity of the subscription has nothing to do with
> the EPR passed in.
>
> > 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.
>
> No - the UUID has nothing to do with it. The UUID is only used
> by the part of the soap stack dealing with the transmission of the
> message over the wire - and more specifically only used when trying
> to correlate messages with a MakeConnection. The subscription itself
> should not do ANYTHING with this UUID. The UUID is part of a URL
> that, to the subscription, is basically opaque. As with the dealing
> of EPR in most cases, the only time we really care about the wsa:Address
> is when we're about to put it on the wire. The use of the RManonURI
> is meant to be the exact same w.r.t. this.
>
> Actually, from now one we should stop using the word UUID since the
> UUID alone is meaningless. What's important is the _entire_ URL,
> the UUID just happens to be part of it. When the MakeConnection
> comes in we need to find messages targeted to the full URL so
> extracting the UUID is not needed and buys people nothing.
>
> > 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.
>
> This is only partially true. While the exact mechanism thru which the
> _EPR_ is exchanged is up to the client/server to decide. RM is
> pretty clear that the way we pass things around is by using an EPR
> and NOT just a URL. We need to allow for reference params. But,
> we NEVER suggest that the UUID can be pulled out and used on its own.
>
> > [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>
>
> Again, big _NO_ :-) the uuid is not the subscription identity.
>
> > 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.]
>
> This part is true - what's really important is that the
> URL is unique per destination (as seen and needed by the
> destination). We used a UUID to help ensure uniqueness.
>
> > * * *
> >
> > 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,
>
> Nope - it knows to look for messages targeted to this URL. Odds are
> they are related to the subscription, yes, but I need to make it
> very clear that the MakeConnection is NOT asking for messages
> related to any specific application but rather asking for messages
> that the transport layer of the soap stack has deemed as targeted
> to a particular URL. This is very very very important as we move
> foward in this discussion. This is why the example talks about how
> any message (e.g. another CreateSequence) may flow. This gives
> the receiver of the MakeConnection the exact same freedom it would
> have if the subscriber had passed in a real EPR.
>
> > 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.
>
> Nope. WSAW anon=required impact the message exchange that carried the
> EPR with the RManon+UUID URL. WSAW anon=required would prevent us
> from using any other URL than anon - which means we could not use the
> RManonURI to indicated that we'll poll for the messages targeted
> to 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.
>
> I would point out that it doesn't need to carry the Sequence header
> but could in fact be a CloseSequence.
>
> > 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?
>
> It carries it because its part of the wsa:To header - just like
> normal EPRs.
>
> > 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.
>
> I don't honestly think the replyTo on the MakeConnection means anything
> since its a one-way and since there is no reply message defined there
> is no message to worry about. I need to remind you that MakeConnection
> is _NOT_ asking for a response or even asking for a message. It is
> simply establishing a connection and identifying who is making the
> connection. This is the exact reason we swtiched the name of the
> operation from GetMessage to MakeConnection.
>
> Let me reiterate, the MakeConnection is establishing a connection and
> identifying who the initator of that connection is. This allows the
> receiver of this message to then use the empty transport-specific
> back-channel to carry any message it believes is destined to that
> endpoint. So, this is why I don't think the replyTo matters - it
> would not be used no matter what its value. The replyTo is the location
> of where responses are sent - there is no response to worry about.
> Any message that may be sent back on the wire IS NOT a response to
> MakeConnection.
>
> > 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.
>
> I disagree. Anon alone isn't sufficient. As you've pointed out before,
> if WSA had made the anon uri something like anon?UUID, and allow
> for each anon URI to be uniquely identified but still carry the same
> semantics, then RM wouldn't need to do it. But as of now, since the
> wsa:Address field of an EPR is meant to be the 'identity' of the endpoint
> then using the generic anon URL in cases where the thing that implicitly
> gave it its uniqueness (by binding it to the socket) is lost, we need
> some other mechanism why which we can reestablish the correlation.
> So, RM had to invent its own anon URI scheme.
>
> > We can illustrate all of this by placing three examples side by side:
> >
> > * * *
> >
> > 1. Example using sequence Identifier: MakeConnection and reply [as
> per CD 04]
> > 2. Example using hypothetical connection identifier: MakeConnection
> > and reply [as it could be, simplified]
> > 3. Example using current Address [as per CD 04]
> >
> > 1a. Example using sequence Identifier: MakeConnection
> >
> > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
> > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"
> > xmlns:wsa="http://www.w3.org/2005/08/addressing">
> > <S:Header>
> > <wsa:MessageID>http://example.org/subscriptionService/
> > guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
> >
> <wsa:Action>http://docs.oasis-open.org/wsrx/wsrm/200608/MakeConnection
> > </wsa:Action>
> > <wsa:To>http://example.org/subscriptionService</wsa:To>
> > <!-- absent wsa:ReplyTo is equivalent to:
> > <wsa:ReplyTo>
> >
> <wsa:Address>http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous
> > </wsa:Address>
> > </wsa:ReplyTo>
>
> Irrelevant - but ok.
>
> > -->
> > </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>
>
> Did I miss it? Where is the wsa:To??? I'll assume its anon.
>
> > <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>
>
> If you mean this to be the same thing as the RManonURI+UUID then
> ok, but I'm a bit lost.
>
> > </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>
>
> Again, what's the wsa:To? In our world it better be the RManonURI+UUID.
> How did this ConnectionIdentifier get into the message? What it a ref-p
> on the original EPR? if so you've now backed into well defined ref-p's.
> Bad :-)
>
> > </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. -->
>
> Nope - MakeConnection is a one-way. This is not a response in the WSA
> sense so the ReplyTo->To rules do not apply.
>
> > 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
Received on Wednesday, 9 August 2006 07:30:20 UTC