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.
