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
|