[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
