Conversational - spec funnies and other improvements
----------------------------------------------------
Key: TUSCANY-1511
URL: https://issues.apache.org/jira/browse/TUSCANY-1511
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Core Runtime
Environment: All
Reporter: Simon Laws
We closed http://issues.apache.org/jira/browse/TUSCANY-1377 when we got to the
stage where conversation support was basically back up and running. There are
still some outstanding issues recorded against that report that come down to
lack of clarity in the spec and/or are awaiting other bits of the Tuscany
runtime to be completed. Here is the list so far.
Features Currently Supported
-------------------------------------------
@Conversational - service & callback interfaces
@Scope(CONVERSATION)
@Scope(STATELESS)
@Init
@Destroy
@ConversationAttributes(maxAge="2 days",
maxIdleTime="5 minutes" )
@ConversationId
@EndsConversation - service and callback interfaces
ServiceReference
getConversationID()
setConversationID(Object)
CallableReference (can be persisted,can be passed)
isConversational()
getConversation()
Conversation
getConversationID()
end()
ConversationEndedException
Restrictions And Required Clarifications
--------------------------------------------------------
The specification is not clear on a number of points related to Stateful
callbacks.
1/ In the current implementation the spec has been interpreted to mean that the
"client" component, i.e. the component implementing the callback interface,
must be marked as conversational in order that callback messages return to the
same instance of the client component that originated the conversational call.
In this case the target of a callback (the source of the original message) has
to be stored against a conversationId so that the callback can find it and
invoke the callback operation on it. Currently, at the source component, the
incoming conversationid is reused for outgoing messages to allow this to happen
(the component instance will automatically have been registered against this id
when it was created).
A better solution would be to allow the reference logic to always create a new
conversation id (or accept a user defined conversation id) but, for stateful
callbacks this implies that the source component instance has to be registered
against multiple conversation ids in the conversational scope container. As
pumbing this in is a little tricky we need discuss round alternative solutions.
2/ The spec isn't explicit about what happens at the server when
Conversation.end() is used on the target service. In the current implementation
it will not free any resources held at the target. A protocol is required
between source and target to carry this end() instruction. As it stands the
target conversation will eventually time out. Subsequent requests to the target
will create a new conversation.
3/ @EndsConversation on the target component where a stateful callback is
defined will end the callback conversation at the target only, I.e. the
component
instance representing the conversation at the source end will remain in place.
It remains until the callback calls an @EndConversation annotated message. This
is tricky
because the source component instance may have been created as part of another
conversation which hasn't ended yet. Not clear whether the intention of the
spec is to get both to happen at once.
The specification also talks about the ability to pass round references that
refer to ongoing conversations.
No passing of services references, referring to conversational services, is
currently supported. This is primarily because the service reference is not
currently serializeable but
the spec could also benefit from some clarrification in this area. For example,
If a callable reference is passed off to another service how does that callable
reference know what the state of the conversation is?
There are also a few other pieces that are awaiting the completion of other
bits of work.
@Scope(COMPOSITE) excluded due to ML conversation
(http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20573.html)
@ConversationAttributes(singlePrincipal=false). Awaiting plicy/security work
The WS binding is being targetted as the first remote binding with conversation
support but this is not complete yet. Awaiting work on callbacks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
