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