[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-115) Requirements Capabilities to provide interfaces
[ http://tools.oasis-open.org/issues/browse/TOSCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36124#action_36124 ]
Derek Palma commented on TOSCA-115:
-----------------------------------
Allowing Capability Types to have operations creates a new problem concerning how to order operations across all the capabilities of a node. What is the order of lifecycle operations when there are duplicates in multiple capabilities? The interdependencies of Node Types are concisely expressed with Relationship Types allowing ordering of operations can be computed between nodes. Inter-capability dependencies would have to be addressed in as general a manner as Node Type interdependencies.
There is a case for allowing Capability Types to provide operations if they do not collide with operations in other Capability Types. This would address (part of) the reusability issue, however, only in the less general cases. One important aspect that operations in the same interface implementation have in common is that they know how to coexist with each other. This is mainly because they are written by one person. It is highly unlikely that two different people can create implementations of operations which rely on the behaviors of others without more concise semantics, such as the interdependencies mentioned above and this reality diminishes the effective reuse. As a result, only Capability Types with completely independent operations could be expected to coexist in the same Node Type.
> Requirements Capabilities to provide interfaces
> -----------------------------------------------
>
> Key: TOSCA-115
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-115
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: New Feature
> Affects Versions: V1.1_CSD01
> Reporter: Kevin Wilson
>
> Requirements and capabilities should provide specific interface definitions. So that the designer of a app can depend on a contract set of public properties that are to be provided and a contracted set method/interfaces that are provided by the requirement.
> For example:
> If I have a dependency on a DB Server, and need to run SQL on that server, at design time, I would like to know the methods supported by the DBServer requirement so that I can leverage that in my component scripting.
> On the implementation side providing the component, the script/method to execute the script may be different for each DBServer type. IE commands to run SQL on MySQL are not the same commands that would be used for Oracle. However, the SQL may the same in some cases.
> Similar methods/use cases exist for J2EE server deploy methods etc.
> By providing a interface on the Requirement/Capability we can leverage the workflows specific to the capability in a generic way. And the designer would be able to identify the contracted calls that are made available.
> https://www.oasis-open.org/apps/org/workgroup/tosca/document.php?document_id=49635
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]