See also: Complex Service Example (TOSCA)
The ONAP internal DM (R4+) establishes the following convention for modeling services:
- The global TOSCA node type onap.nodes.Service as part of the DM core:
- one node type for all types of services
- an abstract type, never used directly to type a node, never explicitly mentioned in a substitution_mappings
- very few TOSCA properties and attributes, no requirements or capabilities (will be defined as part of derived node types)
- TOSCA interfaces related to ONAP service, with default implementations
- For each specific service in the catalog, ONAP maintains:
- An “ONAP interface type” - a concrete TOSCA node type which is derived from onap.nodes.Service
- adds requirements and capabilities specific for this service
- extends the set of properties and attributes
- overloads the default operations in the interfaces defined for onap.nodes.Services
- an implementing topology that includes
- inputs
- nodes – to represent NFs, resources, VLs; policies, groups, etc.
- a substitution_mappings construct
- refers to the concrete service node type
- maps the “public” capabilities and requirements of the concrete service node type to the “internal” caps&reqs inside the topology
- maps the “public” properties of the concrete service node type to the input parameters of the topology
- maps the “public” interface operations to their internal implementations
- An “ONAP interface type” - a concrete TOSCA node type which is derived from onap.nodes.Service
...
- Both Service A and Service B have their ONAP interface node types and implementation topologies
- Service A’s implementation topology includes a node(s) of the ServiceB’s interface type
- The Service A model is distributed as a CSAR that contains the interface-implementation pairs for both Service A and Service B, and all interface-implementation pairs for all VNFs used in these services
...