Scott Kurz wrote:
Simon,
On Tue, Feb 10, 2009 at 4:03 AM, Simon Nash <[email protected]
<mailto:[email protected]>> wrote:
Scott Kurz wrote:
I thought it was useful to point out that was specifically a
problem w/ a callback over binding.sca, as the proxy set up for
a binding.ws <http://binding.ws> <http://binding.ws> (axis2)
callback should be able to call back to the right client today,
right?
It shouldn't make any difference what the binding is. In all cases
the callback address is taken from the incoming message when the
proxy is created and injected, and this address is hard-wired into
the proxy. For a composite-scoped component, this will be the
callback address for whichever client did the first invocation on
the component, when the composite-scoped component implementation
instance was created. Subsequent invocations will not create and
reinject a new proxy.
I agree that it shouldn't make any difference what the binding is, and
also agree that the callback proxy would only be injected the first time
a composite-scoped impl was invoked.
I'm just saying that ideally the already-injected proxy would be able to
do a late resolution of the actual endpoint. I believe this is how,
say, the binding-ws-axis2 binding works (it looks at some WSA header on
the incoming message and dynamically determines the callback endpoint)
and also how I believe the JMS binding should work.
The magic needed to do late resolution successfully is way too
deep to cover any but the simplest cases.
For binding-ws-axis2, the callback endpoint from the input message
is resolved at the time the proxy is created, not at the time the
proxy is called. This approach is used for all binding types.
Deferring the resolution to when the callback is invoked could
work in very simple cases when the input message is still in
the thread context at the time the callback is invoked, for
example:
A calls B
B calls back to A
B returns back to A
It doesn't work in scenarios like the following:
A calls B
B returns back to A
C calls B
B calls back to A
The second case is a perfectly valid use of asynchronous
callbacks, and it can't work unless the proxy is fully
resolved to an endpoint (A) when the call from A to B is
dispatched.
So that's why I was arguing: isn't just this a limitation of the
current binding.sca implementation?
The above scenario is not affected by which bindings are
used. The principle that early resolution is needed applies
in all cases.
Simon
Scott
