[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=33717#action_33717 ]
Travis Tripp commented on TOSCA-115:
------------------------------------
I think the relationship takes care of some of the issue originally reported.
One thing I'm looking for is a way to stop having to basically duplicate node types and requirements / capabilities. In the example models, you essentially get a 1:1 that every node type also has a corresponding capability type, which somewhat defeats the purpose. You end up building duplicate hierarchies. I'd be very interested in having less Node Type. For example, what if I had a NodeType of Software that I can assign capabilities to it like MySQL and now that NodeType gets the MySQL properties and the MySQL interfaces. If I am interpreting this wrong, please correct!
Additionally, if interfaces are on capability types, you get a container to define reusable interface definitions. For example, rather than having a root node type that has a default lifecycle, you could instead have some normative capabilities of something like:
Runnable and define start, stop on it. Then you could assign the Runnable capability to a NodeType and it would get the interfaces. You could have a Snapshot Capability with interfaces like snapshot, revert, etc and assign it to Nodes that support snapshotting.
All of that said, Thomas' point is well taken about having too many ways to do things, but as of right now, things like interface seem to have to also be redefined on every node type rather than just assigning a capability. You guys designed most of the spec, so again very open to hear your thoughts.
> 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.
--
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]