Re: Support for callbacks
Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM capabilities. However, we also need to manage stateful callbacks... We will need to spec the RM requirements with a magical policy or have some kind of constraint to validate the presence of the feature (spec issue I guess there). Quick clarification on what you call a stateful callback: Is a callback said to be stateful if the target of the callback needs to maintain state that will be influenced by the arrival of the callback? Or is a callback stateful if the source of the callback needs to deliver state to the target during the callback? Or both, I guess :) and I was thinking of persisting that state using a scope container that implements a mechanism similar to what is found in messaging systems like ActiveMQ (some type of identity-based store on the file system). What do you think? Sounds like a reasonable approach and fairly straightforward :) Is there a possibility of ordering constraints on the callbacks? This could put a crimp in the runtime if a failing callback was holding other things up. Reliable ordered delivery is going to be an interesting one :-) Does Celtix support or plan to support this? Well Celtix and similar projects implement WS-RM [0], but that only speaks to ordering and delivery of the wire messages really. Theres a thing called the Callback RM-Reply Pattern in the spec, it seems to just spec out how what the MEP looks like and the vocabulary of SOAP Headers to do the bookkeeping. It's probably better to state up front that ordering criteria MUST not be associated with callbacks. (Except of course that the callback must come after the call :D ). rgds --oh [0] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
- Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 13, 2006 7:34 AM Subject: Re: Support for callbacks On Jul 13, 2006, at 12:13 AM, Oisin Hurley wrote: Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM capabilities. However, we also need to manage stateful callbacks... I was also assuming that the binding would take care of reliability of original invocation and callback delivery. We will need to spec the RM requirements with a magical policy or have some kind of constraint to validate the presence of the feature (spec issue I guess there). Quick clarification on what you call a stateful callback: Is a callback said to be stateful if the target of the callback needs to maintain state that will be influenced by the arrival of the callback? Or is a callback stateful if the source of the callback needs to deliver state to the target during the callback? Or both, I guess :) I was thinking mostly one but it would actually be both since it is conversational (i.e. the callback could then call the original target). Stateful to me means that any state that was available in the client at the time of the invocation is also available at the time of the callback (also in the client). But if the source of the callback (i.e., the service) needs to deliver state to the target (i.e., the client), it seems to me that it could be delegated to the reliability mechanism. and I was thinking of persisting that state using a scope container that implements a mechanism similar to what is found in messaging systems like ActiveMQ (some type of identity-based store on the file system). What do you think? Sounds like a reasonable approach and fairly straightforward :) I've been looking a bit a journaling systems for this. Any pointers or help implementing would be much appreciated. Is there a possibility of ordering constraints on the callbacks? This could put a crimp in the runtime if a failing callback was holding other things up. Not sure what you refer to here. Do mean that the callbacks must arrive in the order that the invocations went out? This may be hard to achieve if we can't guarantee that the service replies in the order that the invocations arrive to it. If we can assume it does, then my (perhaps naive) thought is that ordered delivery of both invocations and callbacks would suffice. Of course, there's the possibility that ordered delivery may be too much of a holdup. Reliable ordered delivery is going to be an interesting one :-) Does Celtix support or plan to support this? Well Celtix and similar projects implement WS-RM [0], but that only speaks to ordering and delivery of the wire messages really. Theres a thing called the Callback RM-Reply Pattern in the spec, it seems to just spec out how what the MEP looks like and the vocabulary of SOAP Headers to do the bookkeeping. It's probably better to state up front that ordering criteria MUST not be associated with callbacks. (Except of course that the callback must come after the call :D ). Yes good point. In my (probably overly simplistic view) I was imaging conversational state to be managed by this store service in Tuscany but policies such as reliability and ordering being handled by the binding, at a lower level. The binding would also have to flow conversational ids in some form. Does this sound right to you? rgds --oh [0] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm - 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]
Re: Support for callbacks
Hey Oisin, Comments inline On Jul 12, 2006, at 4:15 PM, Oisin Hurley wrote: Hi Jim, I think we need to account for long-running conversations and server crashes. I was thinking this would involve persisting the instance and dealing with state (we made it serializable in the spec to support that case). I guess the best way to keep the source and target lifecycles decoupled is to maintain durable lists of callbacks-expected on the target and callbacks-to-be-delivered on the source. This should give some guarantee that you won't lose your work items during an emergency landing. If the underlying transport can give you some reliability QoS then you could expect it to do this work for you rather than the runtime having to do it. Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM capabilities. However, we also need to manage stateful callbacks, and I was thinking of persisting that state using a scope container that implements a mechanism similar to what is found in messaging systems like ActiveMQ (some type of identity-based store on the file system). What do you think? Is there a possibility of ordering constraints on the callbacks? This could put a crimp in the runtime if a failing callback was holding other things up. Reliable ordered delivery is going to be an interesting one :-) Does Celtix support or plan to support this? cheers --oh - 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]
Re: Support for callbacks
Hi guys, I won't be able to make IRC today but please feel free to go ahead and discuss conversations. I've looked at Igancio's slides (thanks, these are really extensive!) and I think adding the callback wire to the reference is a good way to start with and see where we get. I'll respond it more detail, but I think there are a number of things we have to work out: 1. How to dispatch to the correct callback instance. In the simple case when the callback interface is implemented by the client, we could have the TargetInvoker use PojoAtomicComponent.getInstance(), which delegates to a scope container, in this case a conversational one that could serialize and deserialize state if needed (or a stateless container if it is a stateless callback). In the remote case, the binding would be responsible for setting the correct conversation id in WorkContext from protocol specific information so that the scope container can determine the correct instance. The difficulty comes in when ServiceReference.setCallback() is used by a client to manually set the instance, in which case it is not the original client. We need to have some way to correlate back to the correct callback instance. We could model this in JavaAtomicComponent or we could perhaps do something where a dynamic component is created on the first cann to setCallback for a component type and instances are managed like any other component instance. I initially liked the former, but the problem is we will also impact scopes since we would need to have something like getCallbackInstance(..). If we could do it where callback invocations happen just like any other service invocation, I think we will be able to keep things simpler. 2. We need to get the host API supporting callbacks. The reference would use the host API to register itself as a listener with a binding as opposed to talking directly with the binding. This will allow us to decouple the callback infrastructure from particular bindings. Jeremy may have some thoughts on this. 3. We will need to have a conversational scope container and persistence service 4. I'd like to hook in Meeraj's work manager into this as well. 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? 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. Jim On Jul 8, 2006, at 6:51 AM, Jeremy Boynes wrote: On Jul 8, 2006, at 4:21 AM, Jim Marino wrote: Great. Sorry I was out on vacation Friday. One thing we may also want to look at is having the notion of priority queues. It's probably something we can add in. Who knows, Meeraj's implementation may already do that :-) We may also want to look at Jetty 6 as they have abstracted out the thread pooling mechanism. I was thinking we would eventually want to have Jetty as a transport system service and we may want to control thread pooling from the work manager service (not necessarily one pool for everything, but one place for configuration and management of all the pools). Jetty6 is one of the ones that does this and linking the two together would be a good way to go. In the context of an OSGi container, having Jetty and other transports a system services deployed in different composites seems like a way to have a really flexible runtime story. That's probably a different thread :-) -- Jeremy - 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]
Re: Support for callbacks
On Jul 10, 2006, at 7:19 AM, Jim Marino wrote: 2. We need to get the host API supporting callbacks. The reference would use the host API to register itself as a listener with a binding as opposed to talking directly with the binding. This will allow us to decouple the callback infrastructure from particular bindings. Jeremy may have some thoughts on this. I would have though that the reference would register with the binding rather than the host. After all the reference is bound on the outbound side so is coupled to the binding at that point; wouldn't the inbound side just be the reverse? The binding would need to use the host API to register its inbound transport and create an endpoint. This seems to be the same function it would be doing on the Service side for traditional inbound requests. Perhaps we should investigate merging the two functions. 3. We will need to have a conversational scope container and persistence service I take it those are independent services. 4. I'd like to hook in Meeraj's work manager into this as well. It's ready to go as soon as Geronimo publish the JSR237 API. I hope they can get a SNAPSHOT out today; it if looks like it it taking longer I may just copy it into our spec tree. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jul 10, 2006, at 7:40 AM, Jeremy Boynes wrote: On Jul 10, 2006, at 7:19 AM, Jim Marino wrote: 2. We need to get the host API supporting callbacks. The reference would use the host API to register itself as a listener with a binding as opposed to talking directly with the binding. This will allow us to decouple the callback infrastructure from particular bindings. Jeremy may have some thoughts on this. I would have though that the reference would register with the binding rather than the host. After all the reference is bound on the outbound side so is coupled to the binding at that point; wouldn't the inbound side just be the reverse? Wouldn't the reference (composite reference) use the host api to register with the binding transport? I may not have worded things clear enough. This way we separate the protocol binding and callback mechanisms from the particular transport (e.g. Jetty)? The binding would need to use the host API to register its inbound transport and create an endpoint. This seems to be the same function it would be doing on the Service side for traditional inbound requests. Perhaps we should investigate merging the two functions. Yes. 3. We will need to have a conversational scope container and persistence service I take it those are independent services. Yep. The persistence service I think can be a general thing for a lot of other purposes as well. 4. I'd like to hook in Meeraj's work manager into this as well. It's ready to go as soon as Geronimo publish the JSR237 API. I hope they can get a SNAPSHOT out today; it if looks like it it taking longer I may just copy it into our spec tree. Great. Thanks Meeraj! -- Jeremy - 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]
Re: Support for callbacks
Hi Jim, An inline comment on your first point. - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 10, 2006 10:19 AM Subject: Re: Support for callbacks Hi guys, I won't be able to make IRC today but please feel free to go ahead and discuss conversations. I've looked at Igancio's slides (thanks, these are really extensive!) and I think adding the callback wire to the reference is a good way to start with and see where we get. I'll respond it more detail, but I think there are a number of things we have to work out: 1. How to dispatch to the correct callback instance. In the simple case when the callback interface is implemented by the client, we could have the TargetInvoker use PojoAtomicComponent.getInstance(), which delegates to a scope container, in this case a conversational one that could serialize and deserialize state if needed (or a stateless container if it is a stateless callback). In the remote case, the binding would be responsible for setting the correct conversation id in WorkContext from protocol specific information so that the scope container can determine the correct instance. The difficulty comes in when ServiceReference.setCallback() is used by a client to manually set the instance, in which case it is not the original client. We need to have some way to correlate back to the correct callback instance. We could model this in JavaAtomicComponent or we could perhaps do something where a dynamic component is created on the first cann to setCallback for a component type and instances are managed like any other component instance. I initially liked the former, but the problem is we will also impact scopes since we would need to have something like getCallbackInstance(..). If we could do it where callback invocations happen just like any other service invocation, I think we will be able to keep things simpler. Perhaps I am missing something, but here are my thoughts on this case. First, my assumption is that by using setCallback the client is explicitly saying which actual object instance is to be called back, and so there is no need to deal with stateful/stateless, the callback object is right there. Second, I was assuming that the target invoker (the one that makes the non-blocking invoke on the transport in slide 4) would have access to the request context and thus be able to retrieve the callback object that way, at which point it could set it on the callback target invoker (C in slide 4), which in turn would be registered with the transport's callback (e.g., an Axis2 callback or a JMS MessageListener). This, for the remote case. For the local case, the callback target invoker (C in slide 2) should be able to also retrieve the callback object from the request context prior to invoking it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
Comments inline On Jul 10, 2006, at 1:39 PM, Ignacio Silva-Lepe wrote: Hi Jim, An inline comment on your first point. - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 10, 2006 10:19 AM Subject: Re: Support for callbacks Hi guys, I won't be able to make IRC today but please feel free to go ahead and discuss conversations. I've looked at Igancio's slides (thanks, these are really extensive!) and I think adding the callback wire to the reference is a good way to start with and see where we get. I'll respond it more detail, but I think there are a number of things we have to work out: 1. How to dispatch to the correct callback instance. In the simple case when the callback interface is implemented by the client, we could have the TargetInvoker use PojoAtomicComponent.getInstance(), which delegates to a scope container, in this case a conversational one that could serialize and deserialize state if needed (or a stateless container if it is a stateless callback). In the remote case, the binding would be responsible for setting the correct conversation id in WorkContext from protocol specific information so that the scope container can determine the correct instance. The difficulty comes in when ServiceReference.setCallback() is used by a client to manually set the instance, in which case it is not the original client. We need to have some way to correlate back to the correct callback instance. We could model this in JavaAtomicComponent or we could perhaps do something where a dynamic component is created on the first cann to setCallback for a component type and instances are managed like any other component instance. I initially liked the former, but the problem is we will also impact scopes since we would need to have something like getCallbackInstance(..). If we could do it where callback invocations happen just like any other service invocation, I think we will be able to keep things simpler. Perhaps I am missing something, but here are my thoughts on this case. First, my assumption is that by using setCallback the client is explicitly saying which actual object instance is to be called back, and so there is no need to deal with stateful/stateless, the callback object is right there. I think we need to account for long-running conversations and server crashes. I was thinking this would involve persisting the instance and dealing with state (we made it serializable in the spec to support that case). Second, I was assuming that the target invoker (the one that makes the non-blocking invoke on the transport in slide 4) would have access to the request context and thus be able to retrieve the callback object that way, at which point it could set it on the callback target invoker (C in slide 4), which in turn would be registered with the transport's callback (e.g., an Axis2 callback or a JMS MessageListener). This, for the remote case. For the local case, the callback target invoker (C in slide 2) should be able to also retrieve the callback object from the request context prior to invoking it. - 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]
Re: Support for callbacks
Great. Sorry I was out on vacation Friday. One thing we may also want to look at is having the notion of priority queues. It's probably something we can add in. We may also want to look at Jetty 6 as they have abstracted out the thread pooling mechanism. I was thinking we would eventually want to have Jetty as a transport system service and we may want to control thread pooling from the work manager service (not necessarily one pool for everything, but one place for configuration and management of all the pools). In the context of an OSGi container, having Jetty and other transports a system services deployed in different composites seems like a way to have a really flexible runtime story. Anyway, when you get a chance, submit your patch and we'll make sure it gets applied. Jim On Jul 7, 2006, at 12:13 PM, Meeraj Kunnumpurath wrote: Thanks Jim. I have had a discussion with Jeremy on this as well. Hopefully I should have something done by the weekend. M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 18:09 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Certainly. Feel free to jump in on anything you would like. Input on callbacks would be welcome as well. Jim On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: 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? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks 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
Re: Support for callbacks
Thanks you scared me - I thought I was going to have to figure out how to get them there ;-) Jim On Jul 7, 2006, at 1:54 PM, Ignacio Silva-Lepe wrote: Apologies for the false alarm, still getting used to the wiki. I have attached the slides there as well. - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 07, 2006 4:37 PM Subject: Re: Support for callbacks I am attaching a few slides that illustrate architectural scenarios for local and remote callbacks (did not see a simple way to add them to the wiki). - 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]
RE: Support for callbacks
Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: 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? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient
RE: Support for callbacks
Ok, Jeremy. Ta -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 14:33 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Meeraj, please do, this would be a good thing to have. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
I too think that having a work manager implementation that minimizes dependencies (e.g., Geronimo's) is a useful thing to have. Wrt using a work manager in the support for callbacks, we should just make sure that we are ok with the overall architecture first. At his point, it looks like the local case could use a work manager, but not necessarily the remote case. I am working on a couple of scenarios (of the technology kind, as Jim refers to them) that illustrate the main steps so that we can get a better idea of how the architecture can fit in support for callbacks in general. - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 07, 2006 9:32 AM Subject: Re: Support for callbacks On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Meeraj, please do, this would be a good thing to have. -- Jeremy - 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]
RE: Support for callbacks
Ignacio, I have a couple of questions. Sorry, I may be talking rubbish without any context. I think for local callbacks to happen asynchronously a work manager based approach may be appropriate. However, on other scenarios, wouldn't the callback implementation be specific to the binding. For example, with a JMS binding, it could be something using replyTo and correlation id headers. I think the key would be to define the right abstractions for callbacks in general and have binding specific realisations. Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. I would appreciate if you could point me to any more info on the callback discussion, if available, in addition to the email thread that has been running. Many thanks Meeraj -Original Message- From: Ignacio Silva-Lepe [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 14:57 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks I too think that having a work manager implementation that minimizes dependencies (e.g., Geronimo's) is a useful thing to have. Wrt using a work manager in the support for callbacks, we should just make sure that we are ok with the overall architecture first. At his point, it looks like the local case could use a work manager, but not necessarily the remote case. I am working on a couple of scenarios (of the technology kind, as Jim refers to them) that illustrate the main steps so that we can get a better idea of how the architecture can fit in support for callbacks in general. - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 07, 2006 9:32 AM Subject: Re: Support for callbacks On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Meeraj, please do, this would be a good thing to have. -- Jeremy - 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jul 7, 2006, at 6:56 AM, Ignacio Silva-Lepe wrote: I too think that having a work manager implementation that minimizes dependencies (e.g., Geronimo's) is a useful thing to have. Wrt using a work manager in the support for callbacks, we should just make sure that we are ok with the overall architecture first. At his point, it looks like the local case could use a work manager, but not necessarily the remote case. I am working on a couple of scenarios (of the technology kind, as Jim refers to them) that illustrate the main steps so that we can get a better idea of how the architecture can fit in support for callbacks in general. The scenarios there would be a good thing to have. The goal for the work manager is to have one central place in the server that coordinates the work that is being done rather than a collection of independent and potentially competing thread pools. Whether we use our own or one provided by the host environment would depend on whether it provided one we could use. For example, Tomcat manages thread pools inside its coyote connector and they are designed for dispatching http requests. When combined with other services that create work (requests) such as inbound JMS or our own local async there is the potential for physical thread starvation as each service dispatches independently. This also makes life harder for the administrator as they need to juggle the sizes of the different pools. Projects have started to make their thread pooling externalizable so that rather than manage the pool themselves they allow things that are using them to supply one; they just supply a default one. I would like to ensure that we do the same. That means than when we are hosted in another environment all work requests can be passed to it for scheduling on a thread and we get better integration and easier management. Depending on the transport we may not be able to do this fully. For example, if a JMS transport tightly manages its thread pool all JMS messages may be dispatched to its threads and not through the work manager. To me, that's an unfortunate limitation of that JMS implementation that we just need to accept (or choose a different one, or fix). So for the remote scenarios, we may not be using the work manager directly but I hope that we would be able to use it indirectly through integration with the inbound transports. Hope that makes sense. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jul 7, 2006, at 7:13 AM, Meeraj Kunnumpurath wrote: Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. It's going to depend on the app server :-( In J2EE1.4, app servers were required to provide a work manager to connectors through the javax.resource API; the one we are using from Geronimo is the one they use to support that. JSR-237 was not part of 1.4 although some of the major vendors did provide implementations; I am not sure how portable they are. I don't think we should provide a full implementation of 237 but something similar but lighter weight (for example, I don't think we will need remote work, we may not need transactional work). It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jul 7, 2006, at 7:37 AM, Meeraj Kunnumpurath wrote: Jeremy, Should this go into sca/core. Also, have you got any suggestions on what package this should go in? I would suggest putting the API in o.a.t.spi.services.work and the impl in o.a.t.core.services.work Work for you? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for callbacks
ok -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:46 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 7:37 AM, Meeraj Kunnumpurath wrote: Jeremy, Should this go into sca/core. Also, have you got any suggestions on what package this should go in? I would suggest putting the API in o.a.t.spi.services.work and the impl in o.a.t.core.services.work Work for you? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for callbacks
JSR-237 was not part of 1.4 True, I don't think it is part of JEE 5 either. Weblogic 9.1 does provide an implementation though. I don't think we should provide a full implementation of 237 I have an implementation that supports local work using concurrent utilities (Doug Lea), I can port it to use the Java 5 API. It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. I will have a look at the JCA work manager API and see what commonalities we can abstract. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:41 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 7:13 AM, Meeraj Kunnumpurath wrote: Also, we may find other use cases for using a work manager for deferred executions. Do we have any view on how the runtime can use a work manager from a managed environment when Tuscany is run in a managed environment. I think app servers that support work managers, may be making them available through the JNDI namespace or something else. It's going to depend on the app server :-( In J2EE1.4, app servers were required to provide a work manager to connectors through the javax.resource API; the one we are using from Geronimo is the one they use to support that. JSR-237 was not part of 1.4 although some of the major vendors did provide implementations; I am not sure how portable they are. I don't think we should provide a full implementation of 237 but something similar but lighter weight (for example, I don't think we will need remote work, we may not need transactional work). It would be good to make the API similar enough to javax.resource and 237 so that we can provide version that delegate through to implementations provided by a managed environment. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jul 7, 2006, at 9:04 AM, Meeraj Kunnumpurath wrote: Jeremy, Ok, having a brief look at the JCA work manager API, these are my thoughts 1. The high-level API are very similar, a manager and optional support for listeners for callbacks 2. There are subtle differences between the actual semantics of work allocation. JCA work manager supports both blocking (doWork), asynchronous (scheduleWork) , blocking start/asynchronous completion (startWork), whereas a JSR 237 it is always asynchronous (scheduleWork). JSR 237 supports a different semantic for blocking calls using wautForAll and waitForAny. Do you have any thoughts on what features you want to support in the API. We know we need async so that is probably the best place to start. If people need sync then they can support it with a blocking listener; if enough people need sync then we can add that to the API later (to allow passthrough to JCA which may be more efficient). Sound reasonable? -- Jeremy PS I'm on IRC if that helps (irc.freenode.net#tuscany) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for callbacks
That sounds ok. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 17:27 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 7, 2006, at 9:04 AM, Meeraj Kunnumpurath wrote: Jeremy, Ok, having a brief look at the JCA work manager API, these are my thoughts 1. The high-level API are very similar, a manager and optional support for listeners for callbacks 2. There are subtle differences between the actual semantics of work allocation. JCA work manager supports both blocking (doWork), asynchronous (scheduleWork) , blocking start/asynchronous completion (startWork), whereas a JSR 237 it is always asynchronous (scheduleWork). JSR 237 supports a different semantic for blocking calls using wautForAll and waitForAny. Do you have any thoughts on what features you want to support in the API. We know we need async so that is probably the best place to start. If people need sync then they can support it with a blocking listener; if enough people need sync then we can add that to the API later (to allow passthrough to JCA which may be more efficient). Sound reasonable? -- Jeremy PS I'm on IRC if that helps (irc.freenode.net#tuscany) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
Certainly. Feel free to jump in on anything you would like. Input on callbacks would be welcome as well. Jim On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: 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? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use
RE: Support for callbacks
Thanks Jim. I have had a discussion with Jeremy on this as well. Hopefully I should have something done by the weekend. M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 18:09 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Certainly. Feel free to jump in on anything you would like. Input on callbacks would be welcome as well. Jim On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: Jim, Are you ok for me to start looking at the work manager implementation? Once I get a better understanding around the requirements of callbacks, I can try to give some input on that as well. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:39 To: tuscany-dev@ws.apache.org Subject: RE: Support for callbacks I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: 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? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe
Re: Support for callbacks
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for callbacks
I have got an implementation based on Doug Lea's concurrent utilities (JDK 1.4), I think this can be ported to use Java 5 concurrent libraries. If you don't mind, I can start looking at this. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:12 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: 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? Have you looked at any commonj work manager (JSR-237) implementations? Yep that's what I was thinking of with the WorkArea stuff. Right now we reused Geronimo's WorkManager impl for the async dispatching but it drags in a lot of dependencies for what it does. I was thinking we could just write a thin implementation of WorkManager using the JDK 5 concurrency libraries and eliminate the dependencies. When we run in a managed environment, we could swap implementations since the WorkManager is set up as a system service. I haven't had time to look at doing this so if anyone is interested (as well as joining in on the callback work), it would be great. Jim M -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 16:01 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail
Re: Support for callbacks
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
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 CI 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
Re: Support for callbacks
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 CI 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
Re: Support for callbacks
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 CI 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
Re: Support for callbacks
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On 6/30/06, Ignacio Silva-Lepe [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
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 CI 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
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 CI 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]
Re: Support for callbacks
- 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 CI 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]
