...

This section provides a detailed analysis of these two methods.

?? –  - strength, ?   - shortcoming, ?? –   – just a neutral fact

Abstraction through abstract node template

Capability inversion in abstract

...

nodes 

When a model includes an abstract node, the capabilities of this abstract node are, in fact, the requirements of the model. This inverted meaning of the abstract node “capabilities” can be very confusing for any interpreter of the model, including orchestrators. Things can get even worse when such a deceiving “capability” leaks through the substitution mapping. In this case the capabilities set of the substitutable node in a higher-level topology turns into a twisted mix of “real” and “inverted” capabilities. 

Unlike capabilities, the requirements of an abstract node are, indeed, the requirements of the model.

Obscure constraints in abstract

...

nodes 

In an abstract node, properties of the node itself and its capabilities are equality constraints rather than property values. All other TOSCA constraints cannot be used with the abstract node.

Fragility of abstraction with abstract

...

nodes 

It is quite easy to accidentally turn an abstract node into something very concrete. For example, a careless addition of an artifact definition to an abstract node type turns this type along with all its subtypes into concrete, causing their “inverted” capabilities to become “real” capabilities and the effect of such an accidental change can be far going.

People love abstract

...

nodes 

People seem to like the abstract nodes more than dangling requirements.

Abstraction through dangling requirement

Requirement-based abstraction is unambiguous, flexible,

...

strong 

Unambiguous: A dangling requirement is always a requirement, no inversion. Will never turn into anything concrete by accident.

...

Strong: a dangling requirement can be taken through any number of substitution mappings.

Unable to express a shared

...

abstraction 

Imagine a template where multiple concrete nodes require one abstract, common for all. This situation cannot be modeled by just adding to each concrete node its own dangling requirement. As for now, there is no way in TOSCA to instruct the orchestrator to satisfy a selected group of requirements by capabilities of a single, shared node.

...

• There is a need to expose the requirement for an abstraction to higher-level topologies through the substitution mapping
• The implementation selection criteria require using advanced value constraints

Use abstract nodes when:

• The
abstracted entity is supposed to satisfy multiple requirements
• abstract node is involved into multiple relationships within the template
• The abstract node is expected to be resolved using substitution.
  
  When using abstract nodes in a topology, please be advised:
• to use their capabilities only to establish relationships within the topology. Do not expose the capabilities of the abstract nodes through the substitution mapping of the topology.
• When using abstract nodes, to take extra care not to make your abstract node types concrete by accident.