OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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=33821#action_33821 ] 

Thomas Spatzier  commented on TOSCA-115:
----------------------------------------

I have thought about this issue some more and want to share a couple of thoughts.

So first of all: there is no question that requirements and capabilities should define a clear contract. That's what they have been designed for. So when a client has a requirement on a specific capability it must be ensured that certain properties are provided and certain behavior is ensured at runtime.

Regarding properties, the definition is already contained in the spec, i.e. you can define properties for both requirements and capabilities.

Regarding interfaces, my first reaction is that I would not include them in capability definitions. One reason is that this would be a major change to the spec. Secondly, I don't see a need yet based on the use case stated at the top of this issue.
Taking this example, if a client expects a certain SQL DBMS so you can rely on certain commands in scripts to work, you would require a specific capability that constrains the DBMS you will get. Any Node Type (or the backing implementation) will then just provide the expected behavior. This is pure runtime behavior, I mean you expect something in your client scripts that will be executed at runtime, and the serving component provides a specific implementation that works at runtime. I don't see a requirement for having special interface definitions in the model.

So bottom line: I would suggest to see how far we get with what we have at the moment. If we see that a key use case cannot be covered at all, then we can think about necessary changes.

> 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]