DCAE Controller documentation DCAEGEN2-213
[dcaegen2.git] / docs / sections / components / intro.rst
diff --git a/docs/sections/components/intro.rst b/docs/sections/components/intro.rst
new file mode 100755 (executable)
index 0000000..8a31e84
--- /dev/null
@@ -0,0 +1,97 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.\r
+.. http://creativecommons.org/licenses/by/4.0\r
+\r
+.. _intro:\r
+\r
+\r
+Component Developer Overview\r
+============================\r
+\r
+DCAE components are services that provide a specific functionality and\r
+are written to be composable with other DCAE service components. The\r
+DCAE platform is responsible for running and managing DCAE service\r
+components reliably.\r
+\r
+Currently, the DCAE platform supports two types of components, CDAP\r
+applications and Docker containers. For each, there are requirements\r
+that must be met for the component to integrate into the DCAE platform\r
+(see :doc:`CDAP <component-type-cdap>` and :doc:`Docker <component-type-docker>`.\r
+\r
+Components requires one or more data formats.\r
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+Components are software applications that do some function. Components\r
+don’t run independently, they depend upon other components. A\r
+component’s function could require connecting to other components to\r
+fulfill that function. A component could also be providing its function\r
+as a service through an interface for other components to use.\r
+\r
+Components cannot connect to or be connected with any other component.\r
+The upstream and downstream components must *speak* the same vocabulary\r
+or *data format*. The output of an one component must match another\r
+component’s input. This is necessary for components to function\r
+correctly and without errors.\r
+\r
+The platform requires data formats to ensure that a component will be\r
+run with other *compatible* components.\r
+\r
+Data formats can and should be shared by multiple components.\r
+\r
+Each Component requires a component specification.\r
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
+\r
+The component specification is a JSON artifact that fully specifies the\r
+component, it’s interfaces, and configuration. It’s standardized for\r
+CDAP and Docker applications and is validated using a :any:`JSON\r
+schema <dcae-component-schema>`.\r
+\r
+The component specification fully specifies all the configuration\r
+parameters of the component. This is used by the designer and by policy\r
+(future) to configure the runtime behavior of the component.\r
+\r
+The component specification is used to *generate* application\r
+configuration in a standardized JSON that the platform will make\r
+available to the component. This application configuration JSON will\r
+include:\r
+\r
+-  Parameters that have been assigned values from the component\r
+   specification, policy, and/or the designer\r
+-  Connection details of downstream components\r
+\r
+The component specification is transformed by DCAE tooling (explained\r
+later) into TOSCA models (one for the component, and in the future, one\r
+for Policy). The TOSCA models then get transformed into Cloudify\r
+blueprints.\r
+\r
+The component specification is used by:\r
+\r
+-  dcae_cli tool - to validate it\r
+-  Design Tools - TOSCA models are generated from the component\r
+   specification so that the component can be used by designers to\r
+   compose new DCAE services in SDC.\r
+-  Policy (future) - TOSCA models are generated from the component\r
+   specification so that operations can create policy models used to\r
+   dynamically configure the component.\r
+-  the runtime platform - The component’s application configuration\r
+   (JSON) is generated from the component specification and will be\r
+   provided to the component at runtime.\r
+\r
+Onboarding\r
+----------\r
+\r
+Onboarding is a process that ensures that the component is compliant\r
+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
+\r
+1. Defining the :doc:`data formats <data-formats>` if they don’t already\r
+   exist.\r
+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
+3. Use the dcae_cli tool to :any:`add the data formats <adding-data-formats>`\r
+   and :any:`add the component <adding-component>` to\r
+   the onboarding catalog. This process will validate them as well.\r
+4. Use the dcae_cli tool to :any:`deploy <development-and-testing>`\r
+   the component. (The component is deployed to the environment\r
+   indicated in :any:`profile <setting-profile>`).\r
+5. Test the component. Also do pairwise-test the component with any\r
+   other components it connects with.\r
+6. Publish the component and data formats into the Service Design and\r
+   Creation (SDC) ‘catalog’. (Currently, this is a manual step).\r