From our discussion about substitution mapping earlier this week, it is clear that we don’t yet have a common understanding of requirements themselves, independent of substitution mappings. Here are some of my thoughts:
-
One of the core differentiators of TOSCA is that it models systems (or applications or services) as topology graphs that consist of nodes and relationships between these nodes.
-
However, relationships in TOSCA are not established directly between nodes. Instead, each relationship is established from a requirement of one node to a capability of another node. Requirements and capabilities allow a component designer (i.e., the designer
of TOSCA node types) to specify the required and/or allowed relationships to and from other components.
-
There are a number of reasons to use requirements and capabilities:
o
Validation: they allow a system designer that uses pre-packaged components (i.e., the person that creates topology templates that include node templates of the specified type) to validate whether those components are used as intended/allowed
within their system. Based on the requirements and capabilities defined in a TOSCA node type, a validator can flag invalid relationships between components or identify relationships that are missing.
o
Modularity: requirements and capabilities allow for establishing relationships between nodes in different topology templates. This enables modular system design, where subsystems can be designed independently and combined into
larger systems that are composed of those subsystems. Requirements and capabilities allow relationships to be established across topology template boundaries.
-
TOSCA nodes with requirements and capabilities are an implementation of the component/port pattern where ports define the interconnection points between components. TOSCA nodes represent components, and requirements and capabilities represent the ports of those
components. Relationships are established to link requirements to capabilities.
-
TOSCA introduces separate requirement “ports” and capability “ports” to indicate directionality. In TOSCA, relationships are always established from a requirement (the “source” of the relationship) to a capability (the “target”) of a relationship. This directionality
is important to allow a pure TOSCA orchestrator to automatically determine dependency ordering when instantiating components and the relationships between components.
-
Note that we have seen some uses of TOSCA where capabilities are not used as ports, but instead are used as an “annotation” that specifies that a node implements some feature or some piece of functionality that other nodes may not. The “Scalable” capability
type in the v1.3 Simple Profile is an example that comes to mind: this capability type is used exclusively to specify that a node is scalable. It is never intended to be the target of a requirement. In my opinion, this is a complete misuse of what capabilities
are intended for.
With this context as background, we should then make sure we clearly define our terminology as it relates to requirements. Here are some examples:
-
In a requirement definition, the “occurrences” keyword include a lower bound that specifies the minimum required number of instances of the requirement, and an upper bound that specifies the maximum allowed (i.e., the upper bound should not be interpreted as
a “stretch goal” for the orchestrator)
-
We use the term “fulfilling a requirement” to indicate the process of matching a requirement of one node with a suitable capability of another node.
-
If the lower bound in the occurrences keyword is greater than zero, then we call the requirement a “mandatory requirement”. A topology representation is invalid if it contains node representations with mandatory requirements that are not fulfilled.
-
If a node template has a mandatory requirement that is not fulfilled, we call that requirement a “dangling requirement”.
Next, we should move on to specific aspects of the TOSCA syntax for requirements and capabilities:
-
When defining a requirement in a TOSCA node type, the only mandatory field is the capability type (i.e., the type of the capability that is needed to fulfill this requirement). In a requirement assignment, none of the fields are mandatory. This means that it
is possible to define a requirement and specify a target node for that requirement without ever defining the type of the relationship that is established as a result of linking a capability to a requirement. I believe this goes against the general TOSCA philosophy
where entities are typed. In my opinion, relationships must always be typed, which means that somewhere in the grammar it must be mandatory to specify a relationship type. If the requirement definition (in a node type) does not specify a relationship type,
then the requirement assignment (in a node template) must do so.
-
This raises a separate issue related to requirement assignments. In my opinion, we should reserve the use of the term “requirement assignment” to the scenario where a template designer explicitly assigns a target node (and optionally a target capability) to
a requirement. There is of course the other scenario where a node template leaves a requirement dangling, but the node template specifies additional information for identifying suitable target nodes (e.g., a node filter). We should use a term different from
“requirement assignment” for this use case. This scenario also isn’t a requirement refinement, since relationships are not mandatory in requirement refinements, but I believe they should be mandatory when specifying dangling requirements in a node template.
-
I also question whether it should be legal to use the “occurrences” keyword inside requirement assignments. Clearly, for actual requirement assignments (i.e., the scenario where we assign a target node to a requirement), the occurrences keyword does not make
sense and should not be used. For the scenario where we specify a dangling requirement inside a node template, what happens if we specify the dangling requirement multiple times (i.e., define multiple requirements with the same name) inside the same node template,
and in addition, we specify multiple occurrences for each of these requirement instances? Is this allowed?
I’m sure this list of questions is not exhaustive, but I hope that it will help stimulate our discussions.
Thanks,
Chris
|