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: "abstract" node types


We had an interesting discussion today in the ad-hoc group about some of the finer aspects of object-oriented derivation. One thing that came up is that in many objected-oriented architectures it is useful to have abstract types, that cannot be "instantiated", but are used as contracts for a system interacting with instances of the derived types. Due to the limitation of OOP, in some cases it might even be necessary to get around the limitations of single-parent derivation. Indeed, in the Simple Profile 1.3 we currently have an Abstract.Compute type.

My thought is this: bake this into the grammar. Add an "abstract" keyword that, if true, would ensure that the type cannot be used for a node template. In other words, it exists only for it to be derived from. Example:

node_types:
 Machine:
ÂÂÂ abstract: true
ÂÂÂ properties: ...

 Server:
ÂÂÂ derived_from: Machine
ÂÂÂ properties: ...
ÂÂÂ # default is "abstract: false"

topology_template:
 node_templates:
ÂÂÂ server1:
ÂÂÂÂÂ type: Machine # this would result in an error!

ÂÂÂ server2:
ÂÂÂÂÂ type: Server # this is valid!

This keyword can also exist in group types and policy types, which like node types can potentially be "instantiated" in the topology template.

For capability and relationship types it is more complicated, because they are not quite "insantiable" in the same way.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]