Hi Mike, A few comments inline:
On Tue, Feb 1, 2011 at 4:03 PM, Mike Edwards < mike.edwards.inglen...@gmail.com> wrote: > > Florian, > > First, let's be clear that Conversational interactions were deliberately > removed from SCA V1.1 by the OASIS spec group because of their complexity - > and they were also removed from Tuscany 2.0 to match. > > However, I am not sure that Conversational is what you're really looking > for. Let me play back what I think you're wanting. > > From what you say, the function that you're looking for is for the binding > code (in the Comet binding in your case) to be able to store some > binding-specific data on a forward request call that is then later accessed > by the binding code when a callback is made to that original request. > That is exactly right. > Logically, what you're really looking for is the capability for the binding > to place some binding-specific data into the Callback object and for the > binding code to be able to access this data at the point where the Callback > object is invoked. And one thing to note about this is that the Callback > object *might* be serialized between the initial request and the callback - > PLUS it is very likely that a different thread will be used to do the > callback - so that thread local stuff simply is not going to work. > The case of the comet binding is that it only has a service side becase the 'reference' side is a collection of javascript proxies that are injected into the browser page. This means that the whole callback mechanism doesn't involve passing data through the wire, it's an operation that happens server-side exclusively and then the callback response is sent through the native async capabilities of comet back to the browser. Does that still imply the possibility of serialization and decoupling from the original thread? At the moment the server-side callback mechanism is actually sequential (the service method implementation is an infinite loop that sends a response via the callback object every X seconds synchronously) and I'm not that happy with it. In order to make things work I had to make the forward service invocation with a manually constructed Message on which I've set a mock RuntimeEndpointReferenceImpl on the 'from' property so that Tuscany internals won't throw NPEs. This means that when the callback is invoked I'm not having an actual implementation of the callback interface that I'm calling, I'm just handling the operations in the Invoker. I've been doing this kind of thing for the async service support that has > been added recently - and I noticed that the callback mechanism is nowhere > near as powerful as the new async code. > > The async stuff has an internal object called the AsyncResponseInvoker that > is used to carry data between the forward invocation and the response - and > this includes binding-specific information. This object is also serializable > and forms part of the serialization processes used by the service > implementation. > > Currently, the callback processing does not use this approach - but I think > that it should. I think that a similar "CallbackInvoker" should be created > in the processing of the forward request - and that it should form part of > the callback object state that is serializable. It should have the > capability for the binding to insert and retrieve whatever information is > required. > That sounds great. When do you think something like the CallbackInvoker will be available in Tuscany? > Does this thinking hit the mark? > Totally, thank you for the detailed response. I'll try and finish up the remaining refactorings and commit an initial version early next week. We can have a more proper discussion alongside with the code. It would be great if you could review it and give me some suggestions on how to use the new async service support. > > Yours, Mike. > > Florian
