More comments in line
On 7/20/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Thursday, July 19, 2007 3:31 PM
Subject: Relating ServiceReference/CallableReference to the reference
proxy?
> CallableReference presents an interface for setting and getting
> conversation
> information.
I think CallableReference is not only for conversation. It's more like an
endpoint reference which contains the address (uri and properties) and
state
(parameter).
Agreed. I'm interested in the conversation aspects of it so should have said
"CallableReference presents an interface for, amongst other things, setting
and getting...". Your point is a good one as where ever the callable
reference goes it should take its understanding of the conversation state
with it. That does raise the question of how that conversation state is
coordinated but that is another question.
When it comes time to dispatch a message the information is
> required in the invoker handler. There is not direct relationship
between
> these two structures. The current mechanism of using the
> ThreadMessageContext to transfer bits of this information is suspect in
my
> opinion because the conversation information in question is related to
the
> message to be sent and not to the context of the message that was
> received.
I think we should move into more message-oriented than
invocation-oriented.
The Message should carry more metadata (message headers). When the message
reaches an implemention/binding provider, the provider will create context
out of the message and present them to the impl/binding (on the thread, or
in binding-specific way).
I agree. However in this case my concern is about how service references
operate within a client rather than between the client and the
conversational service. I.e. Consider a message arriving at an operation (in
my client component) that is going to get a service reference and call a
stateless conversational service
void MyOperation (? someparam) {
ServiceReference<ConversationalService> serviceReference =
componentContext.getServiceReference(ConversationalService.class,
"conversationalService");
serviceReference.setConversationID("MyConversation");
ConversationalService callableReference =
serviceReference.getService();
callableReference.initializeCount(1);
}
So here I'm setting the conversationId in the serviceReferences and calling
the conversationalService via the callable reference. So the conversation
state (the conversationIs in this case) has to get from the callablReference
into the gust of the dispatching code. My question was in this area rather
than how the conversational id is then transferred across the wire to the
conversational service.
There is an issue because the object you set the state on (serviceReference)
is not the same object (callableReference) that you call operations on.
> I could bend the (non spi) interfaces to pass the originating service
> reference into the WireObjectFactor, ProxyService and hence on into the
> proxy/invoker handler. Looks a bit tricky due to the way it's structured
> atm.
> Without changing interfaces I could invent a hidden method on the proxy
to
> accept a reference to the ServiceReference which can be used to get
> conversation information as required.
>
A third option comes to mind typing this.
Have thread local storage that is indexed on proxy that is in use.
Is there an obvious (easy) way that these are/can be associated?
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
