[jira] Assigned: (TUSCANY-1511) Conversational - spec funnies and other improvements

["Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino reassigned TUSCANY-1511:
-----------------------------------------------

    Assignee: Simon Laws

Could you please close this JIRA and open new JIRAs for the few specific remaining issues? Thanks. 

> 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
>            Assignee: Simon Laws
>            Priority: Minor
>             Fix For: Java-SCA-Next
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org