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: <tuscany-dev@ws.apache.org>
> 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
