[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=36125#action_36125 ]
Kishore Jagannath commented on TOSCA-115:
-----------------------------------------
Thanks for your feedback Derek.
I would like state the following points to clarify this further
What is proposed is a Design Change and not specific to Implementation. During Implementation I can add the specific Deployment Artifacts which would need to be transferred to any target machine on which the Implementation scripts would act. I do not need to specify a Deployment Artifact at the time of designing my NodeType. Also ordering depends on my NodeTypeImplementation and not necessarily tied to my NodeType. Moreover In case of Declarative Processing an execution plan can be specified to enforce an order if necessary. During Implementation time a single person can provide the implementation of all Operations regardless of whether they are defined in the NodeType or CapabilityType and have an understanding of operations which relies on other operations
RelationshipTypes bind two different NodeTypes and can optionally specific operations to be executed on these NodeTypes
I do not think this will cause the need to have Interdependant Capability Types and we could still have Relations at a Node level alone.
> 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]