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.0 specification.

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]

Reply via email to