On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote:
I'd like to start working on providing support for callbacks,
assuming the sandbox is a good place to do this.
Great. In case you haven't seen it, we have some architecture slides
in the sandbox under jboynes/sca/doc in tuscany.architecture.v4. In
there is information on scopes and wires, among other things.
Currently, I am focusing on local, stateless callbacks to begin
with. Later, and assuming that conversational support is in place
(which I am also keen on contributing to) I can work on stateful
and remote callbacks.
The first basic issue I see is how to incorporate callbacks as
defined in the C&I spec in particular, and bi-directional
interfaces in general, into the Tuscany architecture. Depending on
how closely a RuntimeWire is supposed to correspond to an SCA wire,
it seems like one way to incorporate a callback is to extend
InboundWire to include an OutboundInvocationChain, and OutboundWire
to include an InboundInvocationChain. That is, a wire would include
a 'reverse' pair of invocation chain ends to account for a
callback.With that in place, it seems feasible to re-use
WireInvocationHandler and TargetInvoker in a similar fashion to
actually perform the callback invocation. Are there any subtle (or
not so subtle) gotchas in this that I am overlooking?
I was thinking there would be a couple of things: a system transport
service and a "conversational" scope container. The system transport
service would listen for callbacks. That service would dispatch and
invoke a component, which in turn would ask its scope container for
the component implementation instance to dispatch to. The
conversational scope container could have a pluggable persistent
store API (we could have a simple implementation which serialized to
disk and eventually used a journaling mechanism such as HOWL http://
howl.objectweb.org/).
Two other basic pieces are: (1) callback injection, and (2)
implementation of ServiceReference. Callback injection may be
simple enough and similar to reference injection for stateless
callbacks, but it'll get more interesting for stateful callbacks
(or stateful scopes), as it is not clear that a callback field or
method will remain valid for the duration of the component
instance, and may need to be re-injected.
Couldn't we use a proxy for this to avoid reinjection? In terms of
flow, it could possibly work as follows:
1. Client invokes, invocation is passed through a wire
2. Target is invoked. When the target is created (it could be at this
point or before), a callback proxy is injected. During the
invocation, a threadlocal context is set up which allows the proxy to
dispatch back.
3. Target calls the callback and an invocation is dispatched back
4. The listener on the client end receives the calback and dispatches
to the callback using a normal component invocation.
ServiceReference requires support for RequestContext and includes
support for sessions. Since neither of these seem to be
implemented, I could take a stab at implementing enough of
RequestContext to support ServiceReference, and I could stub out
support for sessions for now. On the other hand, ServiceReference
is not as critical as, say, the RuntimeWire issue, so I could do
without it at a very first try. Thoughts?
If it is ok with everyone, I'll create a JIRA to start with
stateless callbacks and can someone assign it to me?
I'll create the JIRA and get it over to you. Perhaps we could start
with outlining a couple of scenarios with progressive difficulty? In
order to get this all to work we will probably need to refactor some
of things such as the scope extensibility mechanisms. If we have some
scenarios, I can help with the refactoring.
Let me know if this works fr you and when you have more questions.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]