...
The orchestration engine is a reusable service. Any component of the architecture can execute process recipes. Orchestration Services will be capable of consuming can consume a process recipe and executing against execute it to completion. The Service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structure and version of the workflow execution environment.
Orchestration Services will expose a common set of APIs to drive consistency across the interaction of ECOMP components. To maintain consistency across the platform, orchestration processes will interact with other platform components or external systems via standard and well-defined APIs. (See SDK?)
The Master Service Orchestrator’s (MSO’s) primary function is the automation of end-to-end service instance provisioning activities. The MSO is responsible for the instantiation /and release, and subsequent migration /and relocation of VNFs in support of overall ECOMP end-to-end service instantiation, operations and management. The MSO executes well-defined processes to complete its objectives and is typically triggered by the receipt of ‘service requests’ service requests generated by other ECOMP OpenECOMP components or by Order Lifecycle Management in the BSS layer. The orchestration “recipe” "recipe” is obtained from the Service Design and Creation (ASDC) component of the ECOMP Platform OpenECOMP, where all Service Designs service designs are created and exposed/distributed for consumption.
Controllers (Infrastructure, Network and Application) participate in service instantiation and are the primary players in ongoing service management, e.g.; for example, control loop actions, service migration /and scaling, service configuration, and service management activities. Each Controller controller instance supports some form of orchestration to manage operations within its scope.
...