More comments inline.
[snip]
Simon Laws wrote:
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it has ended.
I would go further than this to say, if we follow the words of the spec, we
should keep the state of a conversation in a central place in a domain. At
least in the very specific cases where there is a 3rd party involved in the
conversation. However a sentral place in a node is a good place to start.
+1, a central place in a node is a good place to start :)
I propose that we do the following:
1) Define a ConversationManager like:
public interface ConversationManager() {
String start(String conversationID); // If the conversationID is
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.
Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.
Also I think it's better to return the Conversation object (see below
for its contents).
Why don't we register a Conversation object with a ConversationManager and
do away with getConversationState
+1
I think it's what I'm proposing. However I think we should distinguish
org.osoa.sca.Conversation (the API, for Java clients and component
implementations) and org.apache.tuscany.whatever.Conversation (the SPI
Conversation object I'm talking about here).
void end(String conversationID); // Ends the conversation
void endConversation(Conversation conversation)
Don't you need another method to make a conversation expire?
ConversationState getConversationState(String conversationID); //
Get the state of the conversation
Conversation getConversation(Object conversationID)
+1
[snip]
4) The ConversationScopeContainer will be registered as listener to
the ConversationManager. When an active conversation is started,
expired or ended, the ConversationScopeContainer will be notified.
It might be easier to register the actual instance wrapper wrappering
the component instance associated with a particular conversation.
An instance wrapped could be registered as a listener with multiple
conversations.
Exactly, an instance wrapper will be registered with the conversation
associated with an incoming call, plus the conversations that were
started by any outgoing calls through conversational interfaces. So
you'll register a wrapper with all the conversations that it
participates in. So we have two choices:
- register with the conversation an object carrying (the instance
wrapper + the conversation itself) and then we don't need to pass the
conversation in the listener methods
- or just register the instance wrapper and then the listener methods
needs to pass the conversation object.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
