On Jun 29, 2006, at 1:47 PM, Ignacio Silva-Lepe wrote:
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
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?
Yes. The system service would be a transport listener which would
pick up the callback invocation off of a wire. The callback
invocation would be sent from the proxy injected into the target as
described below. Do you think it would help if we outlined several of
scenarios, e.g. a stateless callback done in the same composite, a
stateless callback done across remote boundaries, a stateful callback
done in the same composite, and a stateful callback done across
remote boundaries? I was thinking we could sketch out what happens
and then map it down to the core.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
