Re: [ws-rx] Re: Comment on WSDL spec: use of Anonymous Element

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