You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@verizon.net> on 2006/06/28 16:13:08 UTC
Support for callbacks
I'd like to start working on providing support for callbacks, assuming the sandbox is a good place to do this. 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?
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. 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?
Re: Support for callbacks
Posted by Jeremy Boynes <jb...@apache.org>.
On 6/30/06, Ignacio Silva-Lepe <is...@verizon.net> wrote:
> Jim,
>
> Perhaps we could discuss this via a more immediate medium. How about IRC or
> phone? I am online today until 5pm EDT.
>
Ignacio, I've been following this thread with interest but won't be
able to get on IRC any time soon. Please could you continue this on
the list so that everyone in the community can follow along.
Thanks
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Jim,
Perhaps we could discuss this via a more immediate medium. How about IRC or
phone? I am online today until 5pm EDT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
Hi Ignacio,
Sorry about the delay...Comments inline. I've also added some
scenarios to the wiki so feel free to add your thoughts to them.
Jim
On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> Sorry about the disconnect, I was out Monday and yesterday. I'll be
> sure to
> attend the IRC chat tomorrow. In the meantime, some more quick
> comments.
>
> ----- Original Message ----- <snip/>
>
>>> If I understand correctly, would a system service transport use
>>> a low level
>>> communication mechanism, like a socket for instance? This does
>>> not seem like
>>> an appropriate approach for a local scenario,
>> Right, for the local scenario, I was thinking the callback
>> instance would be put on the thread local context and the proxy
>> would access it from there as opposed to going out over a socket
>> and back in through a listener. Basically, it would be an
>> optimization of the remote case. I think we can further optimize
>> things depending on scopes, e.g. if the callback scope is
>> "module", we could possibly avoid threadlocal storage and have
>> the proxy hold on to an instance directly.
>
> Pointing at the callback instance directly from the proxy would
> eliminate
> invocation chains and the ability to add interceptors to them,
> wouldn't it?
Yea the proxy should probably point back to the Component and not the
instance directly unless there is an optimized case where no
interceptors were present. Once the proxy points to Component, it can
call getInboundWire(String serviceName) which will return the
invocation chain that will dispatch to the correct instance. In the
case of an AtomicComponent, when the end of the chain is reached, the
target invoker will delegate to the scope container which will return
the right instance.
> Also, I'm not sure using a thread local in the core is a good idea
> if an
> intention is to allow the core to be embeddable in, for instance, a
> managed
> environment, as thread local does not necessarily mix well with thread
> pools.
>
Good point. I think a similar mechanism may be o.k. as long as we
clean up properly when the request ends or the thread is reclaimed
(e.g. in case of failure where the callback never hapens). Perhaps we
could use the WorkArea API for this? Were you thinking of something
in particular?
Jim
> <snip/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Hi Jim,
Sorry about the disconnect, I was out Monday and yesterday. I'll be sure to
attend the IRC chat tomorrow. In the meantime, some more quick comments.
----- Original Message -----
<snip/>
>> If I understand correctly, would a system service transport use a
>> low level
>> communication mechanism, like a socket for instance? This does not
>> seem like
>> an appropriate approach for a local scenario,
> Right, for the local scenario, I was thinking the callback instance
> would be put on the thread local context and the proxy would access
> it from there as opposed to going out over a socket and back in
> through a listener. Basically, it would be an optimization of the
> remote case. I think we can further optimize things depending on
> scopes, e.g. if the callback scope is "module", we could possibly
> avoid threadlocal storage and have the proxy hold on to an instance
> directly.
Pointing at the callback instance directly from the proxy would eliminate
invocation chains and the ability to add interceptors to them, wouldn't it?
Also, I'm not sure using a thread local in the core is a good idea if an
intention is to allow the core to be embeddable in, for instance, a managed
environment, as thread local does not necessarily mix well with thread
pools.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
I've started to add some rough scenarios to the wiki on this at:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios/
ConversationalSupport/
Hopefully we can fill them out with more detail such as interaction
diagrams, etc. I'm generally pretty loose on scenario "formats":
basically anything that is useful I think we should just add. For
those interested in adding use-cases or filling out the ones started,
please feel free to edit the wiki.
Jim
On Jul 1, 2006, at 1:15 AM, Jim Marino wrote:
> Hi Ignacio,
>
> Let's try IRC, perhaps Monday's chat? Other comments inline...
>
> On Jun 30, 2006, at 1:30 PM, Ignacio Silva-Lepe wrote:
>
>> Apologies Jeremy, didn't mean to exclude people, just trying
>> to expedite the discussion.
>>
>>>>>> 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.
>>
>> If I understand correctly, would a system service transport use a
>> low level
>> communication mechanism, like a socket for instance? This does not
>> seem like
>> an appropriate approach for a local scenario,
> Right, for the local scenario, I was thinking the callback instance
> would be put on the thread local context and the proxy would access
> it from there as opposed to going out over a socket and back in
> through a listener. Basically, it would be an optimization of the
> remote case. I think we can further optimize things depending on
> scopes, e.g. if the callback scope is "module", we could possibly
> avoid threadlocal storage and have the proxy hold on to an instance
> directly.
>> but I am really guessing about
>> how such a listener would pick up a callback invocation if it is
>> not via the
>> architected RuntimeWire/InvocationChain mechanism. On the other hand,
>> you do say the listener would pick up the callback invocation off
>> of a wire,
>> which I'm not sure I follow either.
> In the remote case, the target proxy would perform the invocation
> over a particular transport, which the listener would be listening
> on. The callback invocation would then be handled like any
> component invocation.
>
>> Admittedly, using a 'reverse' pair of invocation chains does not
>> seem like a
>> very orthodox approach, but given that the SCA architecture does
>> not define
>> separate reference and service elements for a callback (i.e.,
>> these seem to be
>> bundled into the forward reference and service only in reverse),
>> it looks like it is
>> up to the Tuscany architecture to supply a sensible design. As an
>> alternative,
>> a separate RuntimeWire instance could be introduced for a
>> callback, with
>> corresponding outbound and inbound ends, but this would not
>> correspond that
>> closely to its SCA counterpart.
> I think part of the problem may be that wires in SCA are
> bidirectional while in Java a "reference pointer" is
> unidirectional. We could look to try and model this with the
> approach you are proposing since it may be closer to the
> bidirectional nature of wires. Maybe on IRC we can come up with the
> scenarios and then outline the two approaches (we can post the
> transcript)? If we have difficulty on IRC due to the complexity of
> the topic, we may have to do a call and we could post to the list a
> summary of what was discussed.
>
>> My question about gotchas had more to do with trying to use a
>> WireInvocationHandler
>> (e.g., JDKOutboundInvocationHandler) as the object called by the
>> callback proxy
>> injected into the target.
> I'd like to talk about this more since I'm not sure I'm getting
> everything (email is difficult).
>> At first glance, this seems feasible, even if we are performing
>> an outbound invocation on an InboundWire and the corresponding
>> inbound invocation
>> of the client happens from an OutboundWire. Is this reversal the
>> reason why a transport
>> listener is a better approach in your mind Jim? One concern I have
>> (if I understand
>> the transport listener idea) is that it seems like a departure
>> from the current architecture.
> I'm not sure it is a departure as opposed to an "addition" that may
> be simpler to manage from a code perspective. It's kind of just
> how I thought initially about doing things but I think we should
> explore a bunch of approaches. My preference is if we can
> realistically model things to the spec then we should do it though.
>
>> That is, there is no such listener used in a forward invocation.
> I need to run out for a bit now, but let me think about it more and
> I will post a follow-up. Then, perhaps we can chat on IRC on Monday
> or set aside another time to do so?
>
> Jim
>
>>
>>>>
>>>>> 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.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
Hi Ignacio,
Let's try IRC, perhaps Monday's chat? Other comments inline...
On Jun 30, 2006, at 1:30 PM, Ignacio Silva-Lepe wrote:
> Apologies Jeremy, didn't mean to exclude people, just trying
> to expedite the discussion.
>
>>>>> 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.
>
> If I understand correctly, would a system service transport use a
> low level
> communication mechanism, like a socket for instance? This does not
> seem like
> an appropriate approach for a local scenario,
Right, for the local scenario, I was thinking the callback instance
would be put on the thread local context and the proxy would access
it from there as opposed to going out over a socket and back in
through a listener. Basically, it would be an optimization of the
remote case. I think we can further optimize things depending on
scopes, e.g. if the callback scope is "module", we could possibly
avoid threadlocal storage and have the proxy hold on to an instance
directly.
> but I am really guessing about
> how such a listener would pick up a callback invocation if it is
> not via the
> architected RuntimeWire/InvocationChain mechanism. On the other hand,
> you do say the listener would pick up the callback invocation off
> of a wire,
> which I'm not sure I follow either.
In the remote case, the target proxy would perform the invocation
over a particular transport, which the listener would be listening
on. The callback invocation would then be handled like any component
invocation.
> Admittedly, using a 'reverse' pair of invocation chains does not
> seem like a
> very orthodox approach, but given that the SCA architecture does
> not define
> separate reference and service elements for a callback (i.e., these
> seem to be
> bundled into the forward reference and service only in reverse), it
> looks like it is
> up to the Tuscany architecture to supply a sensible design. As an
> alternative,
> a separate RuntimeWire instance could be introduced for a callback,
> with
> corresponding outbound and inbound ends, but this would not
> correspond that
> closely to its SCA counterpart.
I think part of the problem may be that wires in SCA are
bidirectional while in Java a "reference pointer" is unidirectional.
We could look to try and model this with the approach you are
proposing since it may be closer to the bidirectional nature of
wires. Maybe on IRC we can come up with the scenarios and then
outline the two approaches (we can post the transcript)? If we have
difficulty on IRC due to the complexity of the topic, we may have to
do a call and we could post to the list a summary of what was discussed.
> My question about gotchas had more to do with trying to use a
> WireInvocationHandler
> (e.g., JDKOutboundInvocationHandler) as the object called by the
> callback proxy
> injected into the target.
I'd like to talk about this more since I'm not sure I'm getting
everything (email is difficult).
> At first glance, this seems feasible, even if we are performing
> an outbound invocation on an InboundWire and the corresponding
> inbound invocation
> of the client happens from an OutboundWire. Is this reversal the
> reason why a transport
> listener is a better approach in your mind Jim? One concern I have
> (if I understand
> the transport listener idea) is that it seems like a departure from
> the current architecture.
I'm not sure it is a departure as opposed to an "addition" that may
be simpler to manage from a code perspective. It's kind of just how
I thought initially about doing things but I think we should explore
a bunch of approaches. My preference is if we can realistically model
things to the spec then we should do it though.
> That is, there is no such listener used in a forward invocation.
I need to run out for a bit now, but let me think about it more and I
will post a follow-up. Then, perhaps we can chat on IRC on Monday or
set aside another time to do so?
Jim
>
>>>
>>>> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Apologies Jeremy, didn't mean to exclude people, just trying
to expedite the discussion.
>>>> 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.
If I understand correctly, would a system service transport use a low level
communication mechanism, like a socket for instance? This does not seem like
an appropriate approach for a local scenario, but I am really guessing about
how such a listener would pick up a callback invocation if it is not via the
architected RuntimeWire/InvocationChain mechanism. On the other hand,
you do say the listener would pick up the callback invocation off of a wire,
which I'm not sure I follow either.
Admittedly, using a 'reverse' pair of invocation chains does not seem like a
very orthodox approach, but given that the SCA architecture does not define
separate reference and service elements for a callback (i.e., these seem to
be
bundled into the forward reference and service only in reverse), it looks
like it is
up to the Tuscany architecture to supply a sensible design. As an
alternative,
a separate RuntimeWire instance could be introduced for a callback, with
corresponding outbound and inbound ends, but this would not correspond that
closely to its SCA counterpart.
My question about gotchas had more to do with trying to use a
WireInvocationHandler
(e.g., JDKOutboundInvocationHandler) as the object called by the callback
proxy
injected into the target. At first glance, this seems feasible, even if we
are performing
an outbound invocation on an InboundWire and the corresponding inbound
invocation
of the client happens from an OutboundWire. Is this reversal the reason why
a transport
listener is a better approach in your mind Jim? One concern I have (if I
understand
the transport listener idea) is that it seems like a departure from the
current architecture.
That is, there is no such listener used in a forward invocation.
>>
>>> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
On Jun 29, 2006, at 1:47 PM, Ignacio Silva-Lepe wrote:
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@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?
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org