----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 10, 2006 10:19 AM
Subject: Re: Support for callbacks
<snip/>
5. Also, Ignacio, could you also detail more on if you think
TargetInvoker's need a non-blocking invoke method and why there may be
different ones for Remote and Local?
Having a separate (non-blocking) invoke would allow the decision on
how to handle asynchrony to be delegated to the invoker which may
have a better sense of how to do it. For instance, an external service
invoker (or however it is called these days) can just return upon return
of a call on Axis2's non-blocking invoke, but a Pojo invoker would need
to ask the work manager to handle the asynchrony. I do realize that this
is different from how async is handled for one-ways, but perhaps one-ways
could be handled this way as well ... :-)
This, in addition to the fact that this invoke cannot return a result value.
As for different invokers for remote and local, I just mean that, just as
for
forward invocations there are different types of invokers (e.g., external
service vs pojo invokers), so there need to be for callbacks. I may have
been overreacting to the fact that the wire invocation handler (W in slide 2
and not shown in slide 5) will need to have the appropriate kind depending
on whether it is a remote or local callback. How W gets its invocation
handler may be a similar mechanism to how a foward invocation handler
gets it.
I'll think about 1 a bit more since these are just some initial thoughts
having gone through the slides. Perhaps we can iterate through some ideas
on the list and I'll be on IRC tomorrow too? Once we start getting a
basic flow, perhaps we could potentially put things in a sequence diagram
to see how things flow, which will also help us to see areas we can
divide up to work on.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
