Executive Summary - Provide the capability to define&instantiate service, in a model-driven approach, selecting service deployment flavor based on rules.
Business Impact - Capacity to build & deliver customer services
Business Markets - all
Funding/Financial Impacts -
Organization Mgmt, Sales Strategies - Service Architect, Service Designer, Business view to Technical implementation view
|Service Resolver presentation in Architecture Comitee (18th June 2019)|
The solution must be :
- generic : any kind of service (vFirewall, Internet Access, virtualBox, Network Slice service, monitoring service...)
- model-driven : no need for "per service“ code, only service definition (data in database via API)
- adaptive to the context : the service "solution" is evaluated/defined at the moment a service order is received, based on rules
- standard API based : TMF641 (serviceOrder), TMF633 (serviceCatalog), TMF638 (serviceInventory)
- usable in simulation mode (without ONAP) to allow Service Designer elaborate/test their service definition before deploying the service definition for real with ONAP
- very simple to use : only one Json additional file to define Customer Service
A possible solution has been validated by a Proof-of-Concept (full Python based) : Service Resolver
That solution is using CFS/RFS concepts (Customer Facing Service / Resource Facing Service).
The main assumption is : "service" notion from ONAP SDC is equivalent to RFS specification.
The proposal then implements an additional "customer service" modelling layer and some instantiation rules that are evaluated when receiving a service order.
You can install and play with it : https://gitlab.com/Orange-OpenSource/lfn/onap/service-resolver