I have just committed an initial implementation of multiple response support as discussed above. Feel free to review the comet binding runtime [1] and to give a try to the new version of the comet binding sample [2]. To do that, please make sure you are using the latest core [3], otherwise NPEs are likely to appear.
Looking forward to upgrade the module to the new async service support by following your guidelines. [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-comet-runtime/ [2] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/learning-more/binding-comet/weather-webapp/ <http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/learning-more/binding-comet/weather-webapp/> [3] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core/ On Tue, Feb 1, 2011 at 5:20 PM, Florian MOGA <moga....@gmail.com> wrote: > 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 >
