----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 29, 2006 12:18 PM
Subject: Re: Support for callbacks
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.
Not sure if I follow. Is the system transport service intended as an
alternative
for a reverse invocation chain pair?
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
