docs/sections/design-components/overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.\r
   2 .. http://creativecommons.org/licenses/by/4.0\r
   3 \r
   4 .. _intro:\r
   5 \r
   6 \r
   7 Overview\r
   8 ========\r
   9 \r
  10 DCAE components are services that provide a specific functionality and\r
  11 are generally written to be composable with other DCAE components,\r
  12 although a component can run independently as well. The DCAE platform is\r
  13 responsible for running and managing DCAE service components reliably.\r
  14 \r
  15 The DCAE Design platform aims to provide a common catalog of available DCAE \r
  16 Service components, enabling designers to select required \r
  17 components to construct and deploy composite flows into DCAE Runtime platform.\r
  18 \r
  19 Service component/MS to be onboarded and deployed into DCAE platform would \r
  20 typically go through the following phases\r
  21 \r
  22  - Onboarding \r
  23  - Design \r
  24  - Runtime\r
  25 \r
  26 DCAE Design Platform supports onboarding and service design through MOD. \r
  27 \r
  28 \r
  29 Onboarding is a process that ensures that the component is compliant\r
  30 with the DCAE platform rules. The high level summary of the onboarding process\r
  31 is:\r
  32 \r
  33 1. Defining the :doc:`data formats <data-formats>` if they don’t already\r
  34    exist. \r
  35 2. Defining the :doc:`component specification <./component-specification/component-specification>`\r
  36 3. Validate the component spec schema against\r
  37    `Component Spec json schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/component-specification/dcae-cli-v2/component-spec-schema.json>`__\r
  38 4. Use  :doc:`blueprint-generator tool <./blueprint_generator>` to generate Cloudify blueprint\r
  39 5. Test the blueprint generated in DCAE Runtime Environment (using either Dashboard UI or Cloudify cli from bootstrap)\r
  40 6. Using :doc:`DCAE-MOD <../DCAE-MOD/DCAE-MOD-User-Guide>` , publish the component and data formats into DCAE-MOD catalog. \r
  41    (This step is required if Microservice needs to be deployed part of flow/usecase)\r
  42 \r
  43 \r
  44 A Component requires one or more data formats.\r
  45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
  46 \r
  47 A component is a software application that performs a function. It\r
  48 doesn’t run independently; it depends upon other components. A\r
  49 component’s function could require connecting to other components to\r
  50 fulfill that function. A component could also be providing its function\r
  51 as a service through an interface for other components to use.\r
  52 \r
  53 A component cannot connect to or be connected with any other component.\r
  54 The upstream and downstream components must *speak* the same vocabulary\r
  55 or *data format*. The output of an one component must match another\r
  56 component’s input. This is necessary for components to function\r
  57 correctly and without errors.\r
  58 \r
  59 The platform requires data formats to ensure that a component will be\r
  60 run with other *compatible* components.\r
  61 \r
  62 Data formats can and should be shared by multiple components.\r
  63 \r
  64 Each Component requires a component specification.\r
  65 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
  66 \r
  67 The component specification is a JSON artifact that fully specifies the\r
  68 component, it’s interfaces, and configuration. It’s standardized for\r
  69 CDAP (deprecated) and Docker applications and is validated using a \r
  70 :doc:`JSON schema <./component-specification/component-json-schema>`.\r
  71 \r
  72 The component specification fully specifies all the configuration\r
  73 parameters of the component. This is used by the designer and by policy\r
  74 (future) to configure the runtime behavior of the component.\r
  75 \r
  76 The component specification is used to *generate* application\r
  77 configuration in a standardized JSON that the platform will make\r
  78 available to the component. This application configuration JSON will\r
  79 include:\r
  80 \r
  81 -  Parameters that have been assigned values from the component\r
  82    specification, policy, and/or the designer\r
  83 -  Connection details of downstream components\r
  84 \r
  85 The component specification is transformed by DCAE tooling (explained\r
  86 later) into TOSCA models (one for the component, and in the future, one\r
  87 for Policy). The TOSCA models then get transformed into Cloudify\r
  88 blueprints.\r
  89 \r
  90 The component specification is used by:\r
  91 \r
  92 \r
  93 -  Blueprint Generator - Tool to generate standalone cloudify blueprint\r
  94    using component spec. The blueprints can be uploaded into inventory \r
  95    using Dashboard and triggered for deployment.\r
  96 -  MOD Platform - To onboard the microservice and maintain in catalog\r
  97    enabling designer to compose new DCAE service flows and distribute\r
  98    to DCAE Runtime platform.\r
  99 -  Policy (future) - TOSCA models are generated from the component\r
 100    specification so that operations can create policy models used to\r
 101    dynamically configure the component.\r
 102 -  Runtime platform - The component’s application configuration\r
 103    (JSON) is generated from the component specification and will be\r
 104    provided to the component at runtime (through ConfigBindingService\r
 105    or Consul).\r
 106 \r
 107