...

These definitions are included into both the providing and the consuming services.

Core DM Types

Node type onap.nodes.Service

Node type onap.nodes.Resource

Node type onap.nodes.NetworkFunction

Capability type onap.capabilities,AllottedResorceProvider

Relationship type onap.relationships.AllottedBy

Imaginary Types made up for this example

...

node_types:
  onap.examples.nodes.Firewall:
    derived_from: toscaonap.nodes.RootNetworkFunction
    description: an abstract firewall
    capabilities:
      i_can_be_a_firewall:
        type: onap.examples.capabilities.Firewall 

...

The "Interface node type" for this service 

According to the Service Model Principles, any service definition will include a node type derived from onap.nodes.Service. This is a general ONAP service modeling convention rather than something specific for AR providing services. Just to remind - this type may be later use to create nodes of embedded services in a higher-order topology.

...

node_types:
  vendorXXX.nodes.MyVerySpecialFirewall:
    derived_from: onap.examples.nodes.Firewall
    capabilities:
      i_can_be_a_firewall:
        type: vendorXXX.capabilities.Firewall
    requirements:      
i_can_provide_firewalls:      - provider_service          
        node: vendorXXX.nodes.FirewallsProvidingService          
     type   capability: vendorXXX.capabilities.FirewallsProvider          
        relationship:  onap.relationships.AllottedBy
    properties:
      # extra props
    interfaces:
      Standard:
        create: my_creation_script.sh # AR creation logic
        delete: my_delete_script.sh

The example above shows one of the possible ways to implement a node type, through implementation script artifacts. These scripts may include a special logic that communicates to a "factory" node inside the service. In this example, the capability of being a firewall and the capability of providing firewall are combined in one node. More elaborate designs may separate these functionalities and have a dedicated node for each of them. 

All other TOSCA ways to implement an abstract node are also valid. Foe For example, a vendor may choose to have an implementing (substituting) topology for this node type.

Providing service topology

Service Model Principles stipulate that any ONAP service definition includes, besides the "interface" node type, the implementing topology. The AR services are no exception of this principle.

topology_template:       
  node_templates:
    # the provider service topology captures the guts of what's required to be instantiated in order
    # to be prepared to allot, e.g., the allotted firewall network functions
    some_vnf:
    my_firewall  type: some.concrete.type.which.forms.the.internals.of.the.provider.service


    possibly_some_other_vnf:
      type: vendorXXX.nodes.MyVerySpecialFirewallalso.some.concrete.type.which.forms.the.internals.of.the.provider.service
           
  substitution_mappings:
    type: vendorXXX.nodes.FirewallsProvidingService
    capabilities:
      i_can_provide_firewalls: [my_firewall, i_can_provide_firewalls]
       

TODO: separate nodes for the share and the "manager"

Consuming Service

The "Interface node type" of the Consuming Service 

The Consuming service definition, like any other ONAP service definition, will include an "interface node type". Its details are irrelevant for this example.

...

node_types:
  onap.examples.nodes.FirewallShare:
    derived_from: onap.examples.nodes.Firewall
    description: an abstract firewall as AR
    requirements:
      - i_need_a_providing_service:
          capability: onap.capabilities.AllottedResourceProvider 


topology_template:
  node_templates:
 
    # A more releasedunconstrained abstraction of a firewall, can be implemented by any way including an allotted resource
    firewall_1:
      type: onap.examples.nodes.Firewall
 
    # A more restricted abstraction - must be resolved by an allotted resource
    firewall_2:
      type: onap.examples.nodes.FirewallShare
    
    # service designer specifies the exact allotted firewall
    firewall_3:
      type: vendorXXX.nodes.MyVerySpecialFirewall
 

TODO: add a section on the orchestration logic