[OASIS Issue Tracker] Commented: (TOSCA-116) Normative Base Types Proposal (Node/Relationship) - derived from experience with SugarCRM private interop.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/TOSCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33711#action_33711 ] 

Frank Leymann  commented on TOSCA-116:
--------------------------------------

I think I don't understand this discussion - maybe I am missing something:  

Capabilities and Requirements (more precisely: Requirement Definitions and Capability Definitions) are use for matchmaking, that's what the current spec describes. First, the matchmaking is done "explicitly" by having each Requirement Type specifying the Capability Type "it needs"; any subtype of the latter Capability Type will satisfy the requirement. The corresponding definitions result in some sort of a "map" that steers the matchmaking algorithm. 

Second, matchmaking is done during modeling:  each relationship type specifies the Node Types it can connect, or the Requirement Type and Capability Type is can connect (again: subtypes considered).  When connecting two Node Templates by a Relationship Template the matching of the types of the connected Node Templates is verified. 

Third, matchmaking is done during deployment time (note that this is not explicitly described in the current spec, as far as I recall): a Topology Template may include Node Templates that have unmatched Requirements. When deploying such a template, the underlying TOSCA container may satisfy such Requirements. From a conceptual (!) point of view, this means the the container will determine Node Types in its environment that have matching capabilities, create corresponding Node Templates, and wire the Node Template via an appropriate Relationship Template. I.e. from a conceptual point of view, the container completes the model - of course, implementations may not create such a completed model; some modeling tools may auto-complete a topology template with dangling requirements.

Note, that the latter introduces the question of which dangling requirements need to be "completed": only those of leaf Node Templates? etc

If the fact that a node type implements a certain interface is important, a corresponding Capability Type can be defined. But not all capabilities can be expressed based on interaces - at least not in a seamless manner. I..e I don't think that the generic notion of capabilities and requirements goes away. And Interfaces defined with the Node Type MUST be implemented (in contrast to the interface claimed by means of such capability type). 

Finally, if we as a TC don't like type hierarchies, we (i) either don't have to use them, or (ii) we eliminate them from the spec.  As a reminder: the TC discussed this for quite some time and we explicitly added the ability to define such hierarchies to the spec. 

> Normative Base Types Proposal (Node/Relationship) - derived from experience with SugarCRM private interop.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: TOSCA-116
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-116
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Task
>          Components: Interop
>            Reporter: Matthew Rutkowski 
>
> This issue (task) will be used to propose and develop a set of normative, base node and relationship types that will evolve to support Interop. SC use cases.

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