Design-Time Data Model: Modelling Principles & Patterns
- Anatoly Katzman
Taking advantage of TOSCA expressiveness
The ETSI information model is all defined in terms of information elements and their attributes. TOSCA proposes a much richer and more flexible meta-model; besides nodes and their properties, it offers to a designer such constructs as capabilities, requirements, relationships, policies, artifacts, interfaces, relationships, etc.
ETSI & ONAP Information Elements | TOSCA Constructs |
|---|---|
Descriptors: NSD, VNFD, PNFD | Topology Template to describe the internal composition and other implementation details; Node Type to express the “interface”; Node Template to represent an occurrence of the service/function within a higher-level composition (see Modelling Complex Resources) |
VLD, CpD | Normative Node Types and Node Templates based on these types (see Modelling Simple Resources) |
Information Elements | Data Types |
Naming, Scaling, Affinity | Policies |
Lifecycle, Operations | Interfaces |
Operation scripts, software images, etc. | Artifacts |
Properties vs. Metadata Fields
Property | Metadata Field |
|---|---|
Has to do with the core business purpose of the model object, what the model does. | Tells how the model object is maintained, stored, displayed, handled by business logic, etc. |
Examples: IP address, required amount of memory, virtualization container type | Examples: Author name, release number, change timestamp, ID in the data store |
Populated by vendor, designer | Populated by the infrastructure logic |
Inherited by derived types | - |
Used by functions (i.e. get_property()) | - |
Has a data type, including constraints to observe | No structure, just a loose string |
Design-time resource instances
Today ECOMP uses the term “instance” to designate a usage of a resource within a higher-level composition in design time. Should we introduce another term for such a design-time usage in order to prevent confusion with the run-time instances?
A resource occurrence maybe?
Modelling Simple Resources
A simple resource is a resource that cannot be decomposed into a topology of lower-layer component resources. Possible ways for a resource to be simple:
The resource definition includes a complete set of artifacts which is sufficient for the orchestrator to create instances of this resource
The resource is so basic and well-known that any orchestrator just knows what to do with it without any artifacts provided.
The following TOSCA constructs are used through this data model to represent simple resources:
A TOSCA node type is used to model the simple resource definition.
TOSCA node templates of this node type are used to represent occurrences (design-time instances) of this resource within a higher-level composition topology.
Modelling Complex Resources
A complex resource is a resource that is backed by a topology of lower-level component resources. The following TOSCA constructs are used through this data model to represent complex resources:
A TOSCA topology template to describe the internal composition and other implementation details
A TOSCA node type to express the “interface” capabilities, requirements, and properties of this resource
A TOSCA substitution_mappings clause wires the capabilities, requirements and properties of this interface node type to the capabilities, requirements and properties of the component nodes inside the implementing topology template
TOSCA node templates of the “interface” node type are used to represent occurrences of this complex resources within a higher-level composition