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
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 8 Jun 2006 08:13:38 -0400
"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 06/08/2006 04:01:48 AM:
> Some feedback – sorry for not sending this earlier.
> These should be interpreted as mere requests
for clarification in
> case I missed something…;-)
>
> -Jacques
>
> 1- The CS can be carried on the back-channel
of a wsrm:
> MakeConnection, and the CSR on a separate request (in same direction
> as wsrm:MakeConnection). So it is crucial that both are correlated
> independently from the underlying protocol. This correlation is
> needed because of the need to correlate an accept with an offer, and
> also because the RMS must be able to associate the new seq ID (in
> CSR) with the address intended by the CS (which is aligned with the
> address in wsrm:MakeConnection.)
> 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?
> 2- in an in-out exchange with (rel in / rel out),
and anonymous
> ReplyTo for the request (in), and in case the in message fails and
> is resent by the RMS-client, then the sender of the out message (the
> RMS-server) must provide enough endpoint info to get the message
> delivered to the endpoint (behind RMD-client) as the back-channel
is
> not enough (would stop at the RMD-client, at least in
> implementations I am aware of).
> Apparently the same anon URI template as used
in MakeConnection need
> be used in the ReplyTo for the request. If that is the case, that
> would deserve to be mentioned.
> 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?
> 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.
> 4- If MakeConnection supports both a seq ID and
an Address argts,
> then I assume both need be supported by any implementation, for
> interoperability. SO it looks like this is where the two previous
> proposals merged here.
> As much as I had sympathy for the ID-based proposal,
it appears that
> the Address alone is sufficient here (even in case of offered
> sequence) so I am questioning the need for both here...
> that makes the implementation more complex than
with any of the two
> previous proposals. In particular, what is the use case for using
> both seq ID and endpoint Addr under a MakeConnection call ?
Obviously, in general, I agree that the Address alone
is sufficient
but since I'm not sure Paul will have a chance to
answer this before
the call let me try to read his mind...
There are a couple of use-cases that the ID-based
approach is designed
for: first, and possibly the most important,
is the case where the
outgoing message can not be modified to use the URI
template instead
of anonymous - perhaps wsa:ReplyTo is already signed.
In these cases
the RMD-client only has the RM SeqID at its disposal
for correlation.
This, however, does place certain restrictions on
how RM can be used.
For example, it (usually) limits you to one endpoint
per RM sequence
and if the Sequence is closed down prematurely, you're
stuck - the
RMS-server will not be allowed to create a new one
to continue.
The other cases I've heard for using the ID in the
MakeConnection
(with and w/o the Address) is simply for a more focused
retrieval.
Its possible that the RMD-client is only interested
in messages
related to just one (out of possibly many) active
sequences so this
provides a mechanism to allow that focused/specialized
retrieval.
thanks
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]