RE: [ws-rx] [i089] comments on joint proposal

[Doug Davis <dug@us.ibm.com>]

"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.  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.

> …
> > From an editorial viewpoint, it is better
to extract the anon URI 
> > template description from section 3.7 so that it is clear its
use is
> > not restricted to MakeConnection. 
> 
> Yes I agree that the URI template is meant to be used in more places
> than just the MakeConnection element - otherwise no messages would
be 
> targetted to it  :-)   but wsa:ReplyTo isn't the only place,
its just 
> probably the most common.  I'd be ok with suggested modifications
to 
> the text to make that clear but I thought it was by not specifically
> limiting it to wsa:ReplyTo.  As for its location - doesn't it
seem like 
> keeping it with the MakeConnection text is best since those two go
> hand-in-hand? 
>  
> How about renaming 3.7 “ Managing [or coping
with] non-addressable 
> endpoints” ?

I can go for that.

> > 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.  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.  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.

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.

thanks
-Doug