The spec is not clear. One section talks about @CA on an impls,
while another talks about it on interfaces. This should be raised to the
spec group. Can you post to the feedback list?
FWIW, I don't think @CA should be allowed on impl classes. I don't
think it's good to overload the meaning. If we want something to control
instance lifecycle, we should have a separate annotation.
Dave
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 13, 2007 5:35 PM
Subject: Re: Resetting state of service references at conversation end
Hi, Dave.
Please confirm if the following understanding is correct. It's not very
clear in the java spec.
The @ConversationAttributes can apply to java component implementation
class or conversational interfaces. For implementation class, it describes
the life time of the implementation instance for a given conversation. For
conversational interfaces, it describes the life time of the conversations
that will be started for the conversational interfaces. When a reference
is wired to a service, the conversational-related settings have to be
compatible.
Thanks,
Raymond
----- Original Message -----
From: "scabooz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, September 13, 2007 2:12 PM
Subject: Re: Resetting state of service references at conversation end
Please Java spec errata #11 at this link:
http://www.osoa.org/display/Main/Errata+for+Java+Annotations+and+APIs+V1.00
I didn't see it referenced in the discussion, and it clears up the
A->B->A question.
Dave
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, September 09, 2007 6:44 PM
Subject: Re: Resetting state of service references at conversation end
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
