You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Simon Laws (JIRA)" <tu...@ws.apache.org> on 2007/08/07 09:10:00 UTC
[jira] Created: (TUSCANY-1511) Conversational - spec funnies and
other improvements
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Assigned: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "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
[jira] Updated: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "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 updated TUSCANY-1511:
--------------------------------------------
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
> 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
> Fix For: Java-SCA-1.0
>
>
> 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
[jira] Commented: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "Simon Laws (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524456 ]
Simon Laws commented on TUSCANY-1511:
-------------------------------------
A mail list thread clarifying point 1is here (http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21863.html) and the implementation follows this model
A mail list thread cdiscussing point 2 is here (http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21984.html). This is not yet implemented awaiting serialization support for CallableReferences
Point 3 is done with both ends conversational state being removed as appropriate.
> 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
> Fix For: Java-SCA-1.0
>
>
> 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
[jira] Closed: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "Simon Laws (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws closed TUSCANY-1511.
-------------------------------
Resolution: Fixed
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.2
Closing this general tracking JIRA and opening two specific JIRA for those issues that remain outstanding.
http://issues.apache.org/jira/browse/TUSCANY-2070
http://issues.apache.org/jira/browse/TUSCANY-2071
> 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-1.2
>
>
> 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
[jira] Commented: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "Simon Laws (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525994 ]
Simon Laws commented on TUSCANY-1511:
-------------------------------------
Another associated issue has come to light. I.e. the resetting on the conversaionId to null in the originatine service reference when the conversation is ended by a callback. This is tricky because on the callback is hard to tell what the originating reference is. I've put in a fix for the case that the originating component has conversation scope. This works by storing a reference to the conversation in the scope container and is convenient as the conversatio has to be stored there anyhow so that we can reference count the component instance.
The other scopes need a addressing and an better general solution may drop as this is done.
> 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
> Fix For: Java-SCA-1.0
>
>
> 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
[jira] Updated: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "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 updated TUSCANY-1511:
--------------------------------------------
Fix Version/s: (was: Java-SCA-1.0)
Java-SCA-Next
> 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
[jira] Updated: (TUSCANY-1511) Conversational - spec funnies and
other improvements
Posted by "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 updated TUSCANY-1511:
--------------------------------------------
Priority: Minor (was: Major)
Changing the priority of these issues which do not seem to be major issues.
> 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
> Priority: Minor
> Fix For: Java-SCA-1.0
>
>
> 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