On 7/20/07, Simon Laws <[EMAIL PROTECTED] > wrote:
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] > > So I've looked a little more at how to associate the ServiceReference and
InvocationHandler more closely. The question that comes to mind is who owns the conversational state.Currently, it's managed by the AbstractInvocationHandler and passed from ServiceReference to the AbstractInvocationHandler via the thread context. Although there is no route back interestingly. I've created a ConversationImpl to hold the conversationId. For the time being an instance gets created in the WireObjectFactory and is made available from there to the ServiceReference and the AbstractInvocationHandler. The WireObjectFactory will only create a Conversation object if the target interface is conversational. This leads to some interesting scenarios. 1) Client Reference1 ----> NonConversational Iface / Component1 / Reference2 ----> Conversational Iface Component2 Here Reference1 has no conversation object assigned as it is referring to a non-conversational interface of Component1. Reference2 though will have a Conversation object as it is targetting a conversational interface. The conversation id in this Conversation will either be automatically generated or be application specificed. If Reference2 were a SystemReference retrieved through the Tuscany APIs to allow an application conversation id to be specified then the Conversation object provides the bridge between the ServiceReference and the infrastructure code that tracks the state of the conversation. 2) Client Reference1----> Conversational Iface / Component1 / Reference2 ----> Conversational Iface Component2 Conversational Iface <---- Reference3 Component2 (this is the callback case) In this case Reference1 does have a Conversation object which stores the conversation id of the conversation between it and Component1. Reference2 also has a Conversation object as in case 1). Reference3 represents a callback and has the same conversation id used by reference2. The way the code is at the moment this also has to be the same conversation id as used by Reference1 also otherwise Reference3 would not be able to find the instance of Component1 that initiated the call. This is because a call through Reference1 created the instance in the first place. Simon
