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 04:37:01 PM:
> > 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.

I'm still a bit lost. I see two scenarios here:
1 - WSA headers are not used at all.  In this
case adding the text you
    suggested doesn't make any sense to
me because it manadates that 
    people use WSA headers - which goes
against this scenario.
2 - WSA headers are used.  In this case normal
WSA rules apply and
    the request MUST carry a msgID and the
response MUST carry the
    relatesTo.  Which means the text
you propose would be duplicating
    what WSA says - do we really need to
do that?
Another interesting point about your proposed text
is that I'm not
100% sure an impl can assume that the implicit correlation
provided
by the underlying protocol is always correct.  When
WSA headers are
not used then I think you can probably assume that
the response and
request are related - however, when WSA headers are
used you can not
make this assumption.  For example, the response
could simply be
an Ack and not the real response.  This means
that when WSA headers
are being used the client MUST examine those headers
to know for sure
what kind of response message it got - 'cause if it
doesn't have a
relatesTo then its not the response it was looking
for.  So, I guess 
I disagree with the implied protocol correlation your
text seems to 
be suggesting.

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

Understood and I didn't mean to imply the 'out' message
was sent using RM.
I wasn't clear - sorry.

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

So, change the 'RMS' above to 'client transport layer'
and I think
the problem still exists.  Even w/o RM in the
picture how does the
transport layer of the impl hand back an anonymous
response to the
correct client application?  I still claim that
there is some kind
of correlation going on - whether its because the
app and the transport
are co-located or because of some other mechanism
- I believe the same
method can be used when RM is turned on.

To me an implementation should not make any connection
between how
a message is delivered and how it is then correlated
back to
the correct destination.  Continuing on the WSA
comments from above,
when WSA is being used (which I hope is all the time
:-) I believe
an implementation needs to use those headers to properly
route each
message.  It can/should not assume much (if anything)
about the exact
transport mechanism on which the message was carried
- this becomes
even more important when RM is turned on and we need
to resend
responses - impls can no longer make the kinds of
implicit correlations
that you've suggested above.  As a result when
a message comes into
the client it should be examined as a new/independent
message and
routing done based on its WSA headers - regardless
of whether it came
in over the same protocol back-channel that carried
the request
or whether it came back via some other mechanism.
And to me RM becomes
just another one of those transport mechanisms. 

But again, I don't see this as an RM/polling issue
but more of a
WSA issue.  RM just magnifies these new requirements.

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

In this new WSA-enabled world, I don't think so.
 
> > 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.

Have you considered doing this:
<wsa:ReplyTo>
  <wsa:Address> anonymous </wsa:Address>
  <wsa:ReferenceParameters>
    <urn:myTo> http://localhost/services/StockQuoteResponse
</urn:myTo>
  </wsa:ReferenceParameters>
</wsa:ReplyTo>

Since the minter of the wsa:ReplyTo is smart enough
to know that
it needs to use the anonymous URI it can then be smart
enough
to stick in the real async URI, as a ref-p, that it
would like to have 
used if it lives in an async environment.  It
can then look for this
ref-p as a header on the reply and use it in its routing.
 This
solves it at the WSA level (which is where I think
the problem is
anyway), and works with and w/o RM.  I don't
think rel-in/non-rel-out
needs to be banned - however, I would point out that
simply because
its not banned doesn't mean that everyone needs to
support it either.
That's an impl choice - but the spec should allow
for both.

thanks
-Doug