OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]