RE: [tosca] Proposal for requirement "occurrences"

[Chris Lauwers <lauwers@ubicity.com>]

  My perspective is very different. In my opinion, node types (and other TOSCA types, for that matter) are the fundamental constructs from which services are created.  Node types define re-usable components that can be combined with other components to construct service topologies. It is node typesânot node templatesâthat define (component) semantics.

I understand that you think that way (it also connects to why you're sure substitution should happen at the node type level), but I disagree.

 

Types are schemas. This should obviously be true for data types, capability types, relationship types, policy types, group types, and artifact types. So I treat node types similarly. It breaks this basic TOSCA separation to think that node types are somehow "components". The topology_template area is where we have the components.

 

And I don't think this is a problem in any way. A profile designer models a domain. A topology designer takes those models and assigns them to an actual topology. That's where the types are realized.

 

Perhaps weâre getting hung up on terminology. Letâs try an analogy. Letâs assume Iâm a âprofile designerâ who models a domain. But letâs say I use Java rather than TOSCA. I would then define Java classes to model the âentitiesâ in the domain. My Java program would use âinstancesâ of those classes to define specific functionality using âentitiesâ in my domain.

 

Using TOSCA, I would define Node Types to define âclassesâ of entities in the domain. These âclassesâ represent what I called the reusable components. Service topologies are the âprogramsâ where âinstancesâ of the Node Types are realized. Note that I donât like to use âinstancesâ here, because we are really only creating âtemplatized instancesâ that allow for deployment-time variability as previously explained by Peter. The real âinstancesâ are created by applying deployment-specific inputs to the âtemplatizedâ instances (resulting in what we have previously defined the âinstance modelâ but are now calling ârepresentationsâ).

 

Using this analogy, Node Types are like Classes in Java, and node templates are âtemplatized instancesâ of those classes. However, just like in Java, the component-specific behavior is defined in the Node Types (the âclassesâ), not the instances. Given that TOSCA is a graph grammar (using Peterâs comments earlier), this behavior must include definitions of how the relationships must/can be formed between entities. As I stated earlier, using this analogy, requirement definitions arenât just a grammatical construct used for validation, they are a fundamental _expression_ of other components on which this component depends in order to function correctly.

 

So, just like Java classes arenât just schemas, TOSCA Node Types also arenât just schemas. They define the primitive components (and their associated behavior), instances of which can be used to create service topology graphs.

 

Chris