The TOSCA language provides two ways for a designer to express an abstraction in the model:
- by an abstract template and
- 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.
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 abstracted entity is supposed to satisfy multiple requirements within the template
- When using abstract nodes in a topology, 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, take extra care not to make your abstract node types concrete by accident.