[
https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514622
]
Simon Laws commented on TUSCANY-1377:
-------------------------------------
Some work has been going on in the area over the last few days.
Many of the conversational features that the spec defines have been brought
back to life
Features
--------
@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
----------------
A number of restrictions are recoded against these features...
Stateful callbacks. 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.
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?
@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
Conversation.end() 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.
@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 WS binding is being targetted as the first remote binding with conversation
support but this is not complete yet. Awaiting work on callbacks.
> Conversational PM- HTTP Session persistence
> -------------------------------------------
>
> Key: TUSCANY-1377
> URL: https://issues.apache.org/jira/browse/TUSCANY-1377
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Core Runtime
> Affects Versions: Java-SCA-Next
> Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> Implement conversational PM- HTTP Session persistence
--
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]
