On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Simon, > > OK, Part 2 of my reply.... > > Simon Laws wrote: > > > > 2/ The specifications describe the freeing of state associated with a > > conversation when Conversation.end() is called on a conversation object > . > > See section 1.6.5 of the SCA Java Annotations and APIs V1.0specification. > > > > Assuming that the Conversation object is available from a service > reference > > within the client of the conversation then, in the current > implementation, > > the state associated with the conversation held by the service will not > be > > freed directly if end() is called. > > > > A separate message exchange would be required between client and service > to > > carry this end() instruction directly. As it stands the target > conversation > > will eventually time out. > > > > What is the specification's intention in this case? > > > > Regards > > > > Simon > > I think I'm going to need your help to work out exactly what the problem > is here. > > The specification identifies a number of ways in which a conversation > may end, in 1.6.5, as you say. > > Some of the methods of ending a conversation make it clear that > communication occurs between client and provider (eg an > @EndsConversation method is called). These cases ensure that both sides > of the conversation can deallocate resources at the "same time". > > In the other cases, the spec does not make it a requirement that > communication occurs between client and provider. However, neither does > it forbid it. What does need to be clear is that the conversation is > ended and that it cannot be reused - depending on the implementation of > the comms mechanism between client and provider that MAY require some > additional communication to travel from the client side to the provider > side. > > A design that uses timeouts on the provider side is OK, as long as the > requirement that the conversation cannot be (re)used once the end() > method has been called is satisfied by the runtime/binding implementation. > > Have I hit the mark with my response? > > > Yours, Mike. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Yes, I think so. From a specification point of view I was worrying about the expected timescale of resource removal. Your assertion that it means that the conversation cannot be reused clarifies this point.
I'm not sure I agree with the MAY in the sentence "depending on the implementation of the comms mechanism between client and provider that MAY require some additional communication to travel from the client side to the provider side.". I can't square this away easily with the requirement of section 1.6.3 of the Java Annotations and API spec to allow for the passing of conversational services as parameters where, if I understand it correctly, a third party could be holding a reference to a conversation for which the original client now calls Conversation.end(). Here a timeout is not good enough and the service should be aware that the conversation has ended. Regards Simon
