On 9/9/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > I don't think this makes it completely clear whether there is one > conversation A->B->A or two conversations A->B and B->A. This > description makes it sound like there is one, as you say, but it > would be good to have this spelled out somewhere. I had been under > the impression that A->B and B->A were separate conversations and > one could end without ending the other. > > If there is supposed to be one conversation, what would happen if > client A had called setCallback(C) before initiating the conversation? > In this case, C would receive the callback call marked with > @EndsConversation, and the stateful instance would be removed from > C's scope container rather than A's. In this scenario, how could > the conversation ID within A be set to null? > > Simon > > Raymond Feng wrote: > > > Hi, > > > > Following is quoted from the SCA assembly spec 1.0: > > > > "851 One or more operations in a conversational interface may be > > annotated with an > > 852 endsConversation annotation (the mechanism for annotating the > > interface depends on the > > 853 interface type). Where an interface is bidirectional, operations may > > also be annotated in this > > 854 way on operations of a callback interface. When a conversation > > ending operation is called, it > > 855 indicates to both the client and the service provider that the > > conversation is complete. Any > > 856 subsequent attempts to call an operation or a callback operation > > associated with the same > > 857 conversation will generate a sca:ConversationViolation fault." > > > > My understanding is that in your scenatio, both A->B and B->A are in the > > > same conversation and step 3 will ends the conversation for both A and > B. > > > > Thanks, > > Raymond > > > > ----- Original Message ----- From: "Simon Nash" < [EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Sunday, September 09, 2007 1:05 PM > > Subject: Re: Resetting state of service references at conversation end > > > > > >> Please can you explain the scenario in a little more detail. If I am > >> understanding the scenario correctly, the client's conversation ID > >> should not be set back to null. Here's what I think the scenario is: > >> 1. client A calls Service B on a conversational interface > >> 2. service B calls back to client A on a conversational interface > >> using the same conversation ID (a stateful callback) > >> 3. service B calls back to client A using an @EndsConversation method > >> 4. The conversation from B to A is now ended. but the conversation > >> from A to B will continue until A ends it. > >> > >> I think I must have misunderstood the scenario. Please clarify. > >> > >> Simon > >> > >> Simon Laws wrote: > >> > >>> When @ConversationEnd is called on a satefull callback the > >>> conversation id > >>> of the client reference is not reset back to null. I have put a fix > >>> in in > >>> the case where the scope of the originating component is > >>> CONVERSATION. This > >>> relies on storing the Conversation object in the conversational scope > >>> container so that when the instance is marked for removal the > >>> conversation > >>> id can be set to null also. > >>> > >>> However to make this approach work for all scopes I have to go and > >>> add this > >>> feature to the other scope containers. Before I do this is there an > >>> easy way > >>> to get to all of a component instances CallableReferences from the > >>> JavaImplementationInvoker? If there were I could search for the > >>> conversation > >>> object with the matching conversationId rather than adding extra code > to > >>> store it away. > >>> > >>> Simon > >>> > >> > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > I also think that the spec describes both forward and callback calls being part of a single conversation.
As soon as there is a 3rd party involved, either through setting a callback object or through serializing a reference(s) and sending it elsewhere, then it becomes difficult to coordinate the state of the conversation in all of the places it may occur. If we are to interpret the spec literally I can't see an alternative to having some domain level service that is tasked with ending conversations and setting conversation state appropriately in these situations. Regards Simon
