docs/sections/components/intro.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 Component Developer Overview\r
   8 ============================\r
   9 \r
  10 DCAE components are services that provide a specific functionality and\r
  11 are written to be composable with other DCAE service components. The\r
  12 DCAE platform is responsible for running and managing DCAE service\r
  13 components reliably.\r
  14 \r
  15 Currently, the DCAE platform supports two types of components, CDAP\r
  16 applications and Docker containers. For each, there are requirements\r
  17 that must be met for the component to integrate into the DCAE platform\r
  18 (see :doc:`CDAP <component-type-cdap>` and :doc:`Docker <component-type-docker>`.\r
  19 \r
  20 Components requires one or more data formats.\r
  21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
  22 \r
  23 Components are software applications that do some function. Components\r
  24 don’t run independently, they depend upon other components. A\r
  25 component’s function could require connecting to other components to\r
  26 fulfill that function. A component could also be providing its function\r
  27 as a service through an interface for other components to use.\r
  28 \r
  29 Components cannot connect to or be connected with any other component.\r
  30 The upstream and downstream components must *speak* the same vocabulary\r
  31 or *data format*. The output of an one component must match another\r
  32 component’s input. This is necessary for components to function\r
  33 correctly and without errors.\r
  34 \r
  35 The platform requires data formats to ensure that a component will be\r
  36 run with other *compatible* components.\r
  37 \r
  38 Data formats can and should be shared by multiple components.\r
  39 \r
  40 Each Component requires a component specification.\r
  41 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
  42 \r
  43 The component specification is a JSON artifact that fully specifies the\r
  44 component, it’s interfaces, and configuration. It’s standardized for\r
  45 CDAP and Docker applications and is validated using a :any:`JSON\r
  46 schema <dcae-component-schema>`.\r
  47 \r
  48 The component specification fully specifies all the configuration\r
  49 parameters of the component. This is used by the designer and by policy\r
  50 (future) to configure the runtime behavior of the component.\r
  51 \r
  52 The component specification is used to *generate* application\r
  53 configuration in a standardized JSON that the platform will make\r
  54 available to the component. This application configuration JSON will\r
  55 include:\r
  56 \r
  57 -  Parameters that have been assigned values from the component\r
  58    specification, policy, and/or the designer\r
  59 -  Connection details of downstream components\r
  60 \r
  61 The component specification is transformed by DCAE tooling (explained\r
  62 later) into TOSCA models (one for the component, and in the future, one\r
  63 for Policy). The TOSCA models then get transformed into Cloudify\r
  64 blueprints.\r
  65 \r
  66 The component specification is used by:\r
  67 \r
  68 -  dcae_cli tool - to validate it\r
  69 -  Design Tools - TOSCA models are generated from the component\r
  70    specification so that the component can be used by designers to\r
  71    compose new DCAE services in SDC.\r
  72 -  Policy (future) - TOSCA models are generated from the component\r
  73    specification so that operations can create policy models used to\r
  74    dynamically configure the component.\r
  75 -  the runtime platform - The component’s application configuration\r
  76    (JSON) is generated from the component specification and will be\r
  77    provided to the component at runtime.\r
  78 \r
  79 Onboarding\r
  80 ----------\r
  81 \r
  82 Onboarding is a process that ensures that the component is compliant\r
  83 with the DCAE platform rules. A command-line tool called :doc:`dcae-cli <dcae-cli/quickstart>` is provided to help with onboarding. The high level summary of the onboarding process is:\r
  84 \r
  85 1. Defining the :doc:`data formats <data-formats>` if they don’t already\r
  86    exist.\r
  87 2. Define the :doc:`component specification <component-specification/common-specification>`. See :doc:`Docker <component-specification/docker-specification>` and :doc:`CDAP <component-specification/cdap-specification>`.\r
  88 3. Use the dcae_cli tool to :any:`add the data formats <adding-data-formats>`\r
  89    and :any:`add the component <adding-component>` to\r
  90    the onboarding catalog. This process will validate them as well.\r
  91 4. Use the dcae_cli tool to :any:`deploy <development-and-testing>`\r
  92    the component. (The component is deployed to the environment\r
  93    indicated in :any:`profile <setting-profile>`).\r
  94 5. Test the component. Also do pairwise-test the component with any\r
  95    other components it connects with.\r
  96 6. Publish the component and data formats into the Service Design and\r
  97    Creation (SDC) ‘catalog’. (Currently, this is a manual step).\r