The TOSCA language provides two ways for a designer to express an abstraction in the model:

1. by an abstract template and 

2. by a dangling requirement. 

Each of these methods has its strengths and shortcomings, and it is very important for a service designer to understand them.

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.

Flexible: With a dangling requirement, the designer has the whole toolbox of TOSCA constraints at his disposal, not only equal.

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.

Recommended practices

Chose the dangling requirement method when:

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

• to take extra care not to make your abstract node types concrete by accident.