Conversational state in 2.x

[Florian MOGA <mo...@gmail.com>]

Hi,

I'm currently working on multiple response support for the comet binding. I
have an initial implementation but I'm using the thread context to store
some internal state between forward and callback calls and this leads to
some limitations. So I was thinking that something similar to
@Conversational from Tuscany 1.x would improve scalabilty as storing state
does not depend on the thread context anymore.

To be more precise, for each client an object is created server-side and it
has to be accessible from the Invoker when performing a callback call. At
the moment, I'm passing this object through the bindingContext property of
the Message. When performing the callback call, the callback message is
built by copying most of the properties of the ThreadContext Message so I
added a slight modification to the core which copies the bindingContext as
well. If it's possible, I'd like to be more thread context independent and
conversational scope seems to provide this thread-neutral client-specific
storage space. It would also enable me to make async invocation of the
service implementation.

Could you point me out a way to achieve something similar to @Conversational
in Tuscany 2.x? From Tuscany In Action I found out that "conversations
aren’t included in the SCA 1.1 specifications being defined by OASIS and
will be reconsidered for a future version of SCA. They’re supported in the
Tuscany SCA 1.x codebase but not in Tuscany 2.x".

Thanks,

Florian

Re: Conversational state in 2.x

[Florian Moga <mo...@gmail.com>]

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 <mo...@gmail.com> wrote:

> Hi Mike,
>
> A few comments inline:
>
> On Tue, Feb 1, 2011 at 4:03 PM, Mike Edwards <
> mike.edwards.inglenook@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
>

Re: Conversational state in 2.x

[Florian MOGA <mo...@gmail.com>]

Hi Mike,

A few comments inline:

On Tue, Feb 1, 2011 at 4:03 PM, Mike Edwards <
mike.edwards.inglenook@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

Re: Conversational state in 2.x

[Mike Edwards <mi...@gmail.com>]

On 01/02/2011 13:12, Florian MOGA wrote:
> Hi,
>
> I'm currently working on multiple response support for the comet binding. I have an initial
> implementation but I'm using the thread context to store some internal state between forward and
> callback calls and this leads to some limitations. So I was thinking that something similar to
> @Conversational from Tuscany 1.x would improve scalabilty as storing state does not depend on the
> thread context anymore.
>
> To be more precise, for each client an object is created server-side and it has to be accessible
> from the Invoker when performing a callback call. At the moment, I'm passing this object through the
> bindingContext property of the Message. When performing the callback call, the callback message is
> built by copying most of the properties of the ThreadContext Message so I added a slight
> modification to the core which copies the bindingContext as well. If it's possible, I'd like to be
> more thread context independent and conversational scope seems to provide this thread-neutral
> client-specific storage space. It would also enable me to make async invocation of the service
> implementation.
>
> Could you point me out a way to achieve something similar to @Conversational in Tuscany 2.x? From
> Tuscany In Action I found out that "conversations aren’t included in the SCA 1.1 specifications
> being defined by OASIS and will be reconsidered for a future version of SCA. They’re supported in
> the Tuscany SCA 1.x codebase but not in Tuscany 2.x".
>
> Thanks,
>
> Florian
>
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.

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.

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.


Does this thinking hit the mark?


Yours,  Mike.