| ===================== |
| DCAE MOD Architecture |
| ===================== |
| |
| |
| DCAE MOD is composed of a mix of components developed in ONAP and other |
| components taken from the Apache Nifi project and modified for |
| appropriate use. The MOD architecture and design was intended to simplify the onboarding |
| and design experience in ONAP addressing below goals. |
| |
| .. toctree:: |
| :maxdepth: 1 |
| |
| ./DCAE-MOD-goals.rst |
| |
| |
| MOD aims to streamline the construction, management, |
| and evolution of DCAE flows from role to role, from environment to |
| environment, and from release to release. MOD is composed of three functional areas: onboarding, design, and |
| distribution and caters to different `user group <./Roles>`__ |
| |
| |
| The below illustrations describe the architecture of DCAE-MOD and show the |
| usage flow in DCAE MOD |
| |
| |image0| |
| |
| |image1| |
| |
| Onboarding API |
| -------------- |
| |
| It is a component developed to onboard |
| models/components/microservices (spec files) into DCAE MOD. |
| |
| Genprocessor |
| ------------ |
| |
| It has been developed in Java. This project is a tool to |
| experiment with generating a Nifi Processor POJO from a DCAE component |
| spec. |
| |
| Nifi Web UI |
| ----------- |
| |
| It is a component taken from the Apache Nifi Project but modified for |
| use in the MOD project. |
| |
| Apache NiFi is a dataflow system based on the concepts of flow-based |
| programming. It supports powerful and scalable directed graphs of data |
| routing, transformation, and system mediation logic. NiFi has a |
| web-based user interface for design, control, feedback, and monitoring |
| of dataflows. It is highly configurable along several dimensions of |
| quality of service, such as loss-tolerant versus guaranteed delivery, |
| low latency versus high throughput, and priority-based queuing. NiFi |
| provides fine-grained data provenance for all data received, forked, |
| joined cloned, modified, sent, and ultimately dropped upon reaching its |
| configured end-state. |
| |
| The NiFi UI provides mechanisms for creating automated dataflows, as |
| well as visualizing, editing, monitoring, and administering those |
| dataflows. The UI can be broken down into several segments, each |
| responsible for different functionality of the application. This section |
| provides screenshots of the application and highlights the different |
| segments of the UI. Each segment is discussed in further detail later in |
| the document. |
| |
| The users of Apache Nifi will find that it is used very differently than |
| intended to serve our purpose in the DCAE-MOD project. |
| |
| |
| Registry API |
| ------------ |
| |
| This component taken from the Apache Nifi project, is a REST API that |
| provides an interface to a registry with operations for saving, |
| versioning, reading NiFi flows and components. |
| |
| Distributor API |
| --------------- |
| |
| It is a component developed using the Flask framework in Python. |
| It is a HTTP API to manage distribution targets for DCAE design. |
| Distribution targets are DCAE runtime environments that have been |
| registered and are enabled to accept flow design changes that are to be |
| orchestrated in that environment. |
| |
| Flow Based Programming (FBP) |
| ---------------------------- |
| |
| NiFi’s fundamental design concepts closely relate to the main ideas of |
| Flow Based |
| Programming `[fbp] <https://nifi.apache.org/docs/nifi-docs/html/overview.html#fbp>`__. |
| |
| For more information on how some of the main NiFi concepts map to FBP, |
| check out https://nifi.apache.org/docs/nifi-docs/html/overview.html |
| |
| Runtime API |
| ----------- |
| |
| It is developed in Java’s Spring Boot framework. It |
| is a HTTP API to support runtime environment for DCAE-MOD. It has two |
| major functionalities: |
| |
| 1. It accepts changes on the flow-graph via fbp protocol |
| |
| 2. It generates and distributes blueprints based on the change made on |
| the flow-graph |
| |
| Blueprint Generator |
| ------------------- |
| |
| This tool allows the user to create a blueprint from a component spec json file. |
| This tool is used by the runtime api. |
| |
| Inventory API |
| ------------- |
| |
| DCAE Inventory is a web |
| service that provides the following: |
| |
| 1. Real-time data on all DCAE services and their components |
| |
| 2. Comprehensive details on available DCAE service types |
| |
| DCAE Inventory is a composite API that relies on other APIs to obtain |
| resources on underlying components and uses these resources to compose a |
| DCAE service resource. In addition, DCAE Inventory will store data that |
| is unique to the DCAE service level including: |
| |
| 1. DCAE service metadata |
| |
| 2. DCAE service type description and composition details |
| |
| 3. Relationships between DCAE service and DCAE service types and their |
| respective VNF and VNF types |
| |
| DCAE Inventory has a REST interface to service client requests. It has a |
| well-defined query interface that would filter result sets based upon |
| resource attributes. |
| |
| Here, think of it as a back end API for the DCAE dashboard. The runtime |
| posts Cloudify Blueprints to this API so they show up in the DCAE |
| dashboard. |
| |
| DCAE Dashboard |
| -------------- |
| |
| The DCAE dashboard provides visibility into running DCAE services for |
| operational purposes. It queries the DCAE Inventory for aggregate |
| details on all the running DCAE services and for getting up-to-date |
| status information on DCAE services and their components. |
| |
| End-to-End Flow |
| --------------- |
| |
| A model/component/microservice can be onboarded by a ms Developer by |
| posting a spec file on the onboarding API. Alternatively, an Acumos |
| model can be onboarded using the Acumos Adapter. Once successfully |
| onboarded, the genprocessor converts converts them to jars and onboards |
| them into Nifi i.e DCAE MOD. These artifacts are now available to use |
| from the Modified Nifi Web UI i.e DCAE Designer. |
| |
| The registry api offers version control and retrieval for flows. The |
| distributor api can be used to set distribution targets. Once a flow is |
| designed and distributed, it goes to the distributor api which is |
| supposed to post graph changes (in accordance with fbp) to the runtime |
| api. The runtime api generates and distributes blueprints based on the |
| change made on the flow-graph. These blueprints received by the DCAE |
| inventory can then be viewed and deployed from the DCAE dashboard. |
| |
| |
| |
| .. |image0| image:: ../images/DCAE-Mod-Architecture.png |
| |
| .. |image1| image:: ../images/Onboarding-with-DCAE-MOD.png |
| |
| .. |image2| image:: ../images/nifi-toolbar-components.png |