inline
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, June 08, 2006
12:59 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089]
comments on joint proposal
"Durand,
Jacques R." <JDurand@us.fujitsu.com> wrote on
06/08/2006 03:13:58 PM:
...
> > How is this correlation done? Is
wsa:RelatesTo relied upon? In any
> > case shouldn't this
> > be specified in wsrm as how it is done
is critical for interoperability?
>
> Yes the correlation would be done using
wsa:RelatesTo. Not sure we
> need to explicitly say this because this
would actually be true of
> any request/response exchange, not just the
CS. Just seems like
> general knowledge these days, no?
>
> Well… I think it is worth saying,
because that’s not the only way to
> do this correlation: e.g. the CSR could just
contain (ReplyTo) the
> same uuid-based anon URI as the MakeConnection
that fetched the CS.
> SO either that, or RelatesTo would need
be set by the sender of
> CSR. But using RelatesTo assumes that the CS
was sent with a wsa:
> MessageId in the first place. So it looks
like a bit of
> coordination is needed to achieve this
correlation one way or the other.
I'm a bit confused - if WSA is being used then the
CS will contain
a messageID and the CSR will contain a relatesTo
pointing back to the
CS's messageID.
But
there is no explicit requirement to use these wsa headers. Can’t we just
say “When the CSR message and the CS message cannot be correlated by their
use of the underlying protocol, then the wsa:RelatesTo header in the CSR
must refer to the CS message.”
If you want to do
correlation using some other
mechanism then I think you have an interop issue
since I doubt
anyone else will use something other than what WSA
says.
I don’t
want to – just saying that because the alternative exists, the spec must
be more prescriptive to make sure implementations remain interoperable.
…
> > 3- Now with an in-out exchange with (rel
in / non-rel out), the out
> > message is not mediated by any
RMD-client. How would this out
> > message be delivered to its endpoint, in
case the "in" message was
> > resent by RMS-client? It probably should
contain explicit endpoint
> > info (wsa:To?) but then how does the
server know when to add this,
> > while it would not have to if the in
message originated from the
> > sending endpoint vs. the RMS-client?
> > Are we saying that the anon URI template
should be understood
> > outside RM components? (doesn't that
fall under wsa scope, and
> > beyond wsrm scope?)
>
> Not sure I followed this but let me try...
> In the rel-in/non-rel-out case, if the
RMS-client resends the
> rel-in message then I would suspect that all
but one of those
> attempts would get back a 202 since all but
one are dups.
> In the one non-202 case if the replyTo was
anon then it would
> carry the response.
> OK, let me rephrase where I see a potential
issue with this use case:
> - “in” message was a
resend, i.e. over an HTTP request initiated by
> the RMS client.
> - “out” message (not using RM) is
sent over back-channel.
> - but this back-channel cannot be expected to
help transfer this
> “out” all the way back beyond the
RMS client to the endpoint that
> originated the “in”, as it would
in normal cases.
> - And the RM component on client side cannot
help doing the
> forwarding as the out is not using RM.
> - so the sender of the
“out” message must add enough endpoint
> destination info, which it must get from
somewhere. It can’t get it
> from a wsa:ReplyTo which is anon in the
“in”. Unless this ReplyTo is
> a uuid-based anon URI like in MakeConnection?
If yes that needs be
> understood outside RM…
I not sure yet if I get what you're saying :-)
but I think I might
be close. Given everything you said above,
let's say that the 1st
'in' message made it ok and the RMD sent the 'out'
message on the
back-channel.
The out
message is NOT sent reliably here… (not sent by RMD-server, and not
handled by any RM component on client side)
No polling needed. In
this case the 'in' message's
replyTo was anon, right? How did the RMS
give that 'out' message
back to the application that sent the 'in' ?
There must have
been some kind of correlation done - and I bet its
because of
one of two things: either the AS and RMS are
co-located, so no
real correlation is needed, or the connection
between the AS and
the RMS remained open and the RMS simply used that
connection's
back-channel.
Again
the RMS-client has no business handling that non-RM out message – no obligation
here. The problem would not exist if the out was using RM too.
If some other mechanism is
needed then that's something
that would need to be addressed by the
implementation. However,
this has nothing to do with polling at all.
This is more of a
WSA/anon issue. Remeber, if the client can
not deal with a
response message being targetted to 'anon' then it
should not
have used that in its replyTo.
Agree it
is not a polling issue – not really related to your proposal – a more
general question on whether the back-channel is sufficient to route back an “out”
message to its destination.
What it really sounds like you want
is for anon to actually be
two URIs, one that says "use the
back-channel" and one that
contains some service specific info like a normal
async URI
would contain (e.g.
http://.../services/StockQuoteResponse),
right? And an endpoint that needs that kind
of dual-purpose
URIs can do so by having the minter of the EPR add
whatever
ref-p's it needs to the EPR - after all, ref-p's
are there
to help in routing. But again, I don't think
this is a
RM/polling issue - its more of a WSA/anon issue.
Right –
not polling related. But unless we prohibit (rel in / non-rel out), I think it
is not clear how to get this out message back to its destination endpoint in
cases where resending took place.
Thanks
Jacques
thanks
-Doug