Proposal Support Standard Workflow Modeling Languages for Imperative

Proposal: Support Standard Workflow Modeling Languages for Imperative Workflow March 14, 2017 This proposal is co-authored by the following individuals on behalf of their organizations/communities: Claude Noshpitz, AT&T, Open. ECOMP Lingli Deng, CMCC, OPEN-O Oliver Kopp, University of Stuttgart, Open. TOSCA Zhaoxing Meng, Huabing Zhao, ZTE, OPEN-O Co-Presented by Huabing & Claude

Table of Contents • • Background Motivation Proposal Annex – Case study: ETSI NFV Architecture – Case study: OPEN-O – Case study: ECOMP

Background Workflows for TOSCA based NFV Orchestration Resource Topology Design Explicit Workflow Design Time ❶ Declarative Workflows (Inferred from the TOSCA topology definition) ❷ Imperative Workflows (Explicitly provided alongside the TOSCA topology definition) Pack/Unpack TOSCA Parser Execution Engine Run Time Orchestrator

Background Imperative Workflow definition in v 1. 0 XML • TOSCA V 1. 0 XML does not specify a metamodel for defining operational workflows. Instead, it assumes the use of a process modelling language like BPEL [BPEL 2. 0] or BPMN [BPMN 2. 0]. Although the specification favors the use of BPMN, is it not prescriptive in this regard. Resource Topology Design Explicit Workflow Design Time ❶ Declarative Workflows (Inferred from the TOSCA topology definition) ❷ Imperative Workflows (BPEL/BPMN Process, . . . ) TOSCA Parser Execution Engine Run Time Orchestrator

Background Imperative Workflow definition in V 1. 1 YAML • Defines a new DSL, specific to TOSCA V 1. 1, for describing operational workflows. • Does not mention use of alternative process modelling or workflow languages, for example BPMN, BPEL, or direct use of Mistral. Resource Topology Design ❶ Declarative Workflows ❷ Imperative Workflows TOSCA Parser (DSL for workflow modelling) Explicit Workflow Design Time Execution Engine Run Time Orchestrator

Table of Contents • • Background Motivation Proposal Annex – Case study: ETSI NFV Architecture – Case study: OPEN-O – Case study: ECOMP

Motivation This proposal intends to address these issues: • The workflow definition in v 1. 1 YAML is exclusive – No standardized way for compliant orchestrators to expose alternative workflow processors, or to represent such workflows within a type definition. – Workflow DSL cannot be portably extended to add domain-specific functionality and human tasks. • The workflow definition in v 1. 1 YAML is not backward compatible with v 1. 0 XML – Semantics of 1. 0 -based workflows are not preserved, so those currently defined using an alternative processor cannot be incorporated. – Implies rework for existing implementations that have already adopted TOSCA but leverage BPMN/BPEL or other processors. • The approach is not aligned with Model-Driven Design for NFV – The binding of parse and execution of workflows directly to TOSCA makes it difficult to co-evolve with community-driven MANO-based and ONAP (Open-O + ECOMP) efforts. – Not clear how to integrate with other lifecycle data models, e. g. YANG.

Table of Contents • • Background Motivation Proposal Annex – Case study: ETSI NFV Architecture – Case study: OPEN-O – Case study: ECOMP

Proposal Support both v 1. 1 imperative Workflow DSL and alternative workflow modelling languages such as BPMN or BPEL. Benefits: • Reliance on diverse workflow models facilitates portability and interoperability – BPMN/BPEL standards are supported by a variety of orchestration providers. – Orchestration implementations have alternative choices for workflow engines to reduce risk • An open, extensible workflow standard can help grow TOSCA adoption – Allows orchestrator implementations to choose the technologies best suited to their own environment. – Implementations can incrementally evolve operational tooling in accordance with business needs. • Building ecosystems – Encourage adaptation and extension of TOSCA across a broad range of business domains. – Support for multiple workflow models makes it easier to integrate and benefit from TOSCA. – Integration with domain-specific orchestration environments helps drive uptake, reuse, and sharing. • Ensure that the TOSCA standard evolves in a compatible manner – Reduce rework for workflow modelling and execution logic in TOSCA V 1. 0 -based implementations. – Avoid “forking” of the standard due to runtime implementations working around V 1. 1 Workflow DSL.

Proposal Imperative Workflows Can Be Delegated to An Artifact Standard workflow example topology_template: workflows: deploy: description: Workflow to deploy the application steps: A: on_success: -B -C. . Delegate workflow example topology_template: workflows: deploy: description: A BPMN workflow to deploy the application delegate: plan/deploy. bpmn • An inclusive approach for workflow definition: While the user can define each step of the imperative workflow, the workflow can also be delegated to an arbitrary artifact, which could be BPMN, BPEL or any other implementations which make sense. • Add a “delegate” keyname at the workflow level to signal that the workflow is delegated to an artifact implementation. The value of “delegate” keyname is the relative path of the artifact file in the CSAR package which the tosca template is in. During the runtime, the orchestrator is responsible for instantiating the corresponding artifact processor and hand over the workflow to it.

Table of Contents • • Background Motivation Proposal Annex – Case study: ETSI NFV Architecture – Case study: OPEN-O – Case study: ECOMP

Case Study -1 ETSI NFV MANO Architecture and NS LCM Workflows • The NS LCM workflow includes interactions between a bunch of components which are not nodes inside TOSCA service template, such as Catalog, Inventory, VFNM, VIM, SDNC, EM etc. , which can be better described by the BPMN/BPEL workflow modelling.

Case Study-2 OPEN-O NFV-O Implementation GS-O/OSS Portal Microservice API Gagteway REST Model Design. Common REST Security Log NS LCM REST Workflow Engine(BPEL) REST NFV Res. Mgr. REST HA Inventory Catalog Drivers Parser VNFM Drivers NFV SDNC VIM Drivers VNFM SDNC VIM REST pub/sub FM PM

Case Study -3 ECOMP-MSO Workflow Engine Resourceoriented management End-to-end service management End-to-end delivery involves long-lived interactions with complex backend services, implying imperative workflow and potentially transactional rollback semantics. Resource lifecycle management is delegated. . . BPMN TOSCA Lifecycle operations on discrete servicesupporting resources map well to a declarative, dependency-driven execution model. Crossresource and higher-level management are delegated. . . The below description is extracted from Open. ECOMP WIKI • These process flows start with a template that may include common functions such as homing determination, selection of Infrastructure, network and application controllers, consultation of policies and interrogation of Active and Available Inventory (AAI) to obtain information needed to guide the process flows. MSO does not provide any process-based functionality without a workflow for the requested activity (in the current release the process flows are designed directly in MSO using BPMN flows).