diff options
Diffstat (limited to 'platformdoc/docs/components/intro.md')
| -rw-r--r-- | platformdoc/docs/components/intro.md | 60 |
1 files changed, 26 insertions, 34 deletions
diff --git a/platformdoc/docs/components/intro.md b/platformdoc/docs/components/intro.md index 2e0087c1..6bd3b2d1 100644 --- a/platformdoc/docs/components/intro.md +++ b/platformdoc/docs/components/intro.md @@ -2,55 +2,47 @@ DCAE components are services that provide a specific functionality and are written to be composable with other DCAE service components. The DCAE platform is responsible for running and managing DCAE service components reliably. -Currently, the DCAE platform supports two types of components, CDAP applications and Docker containers. For each, there are requirements that must be met for the component to integrate into the DCAE platform (see [CDAP](component-type-docker.md) and [Docker](component-type-docker.md)). +Currently, the DCAE platform supports two types of components, CDAP applications and Docker containers. For each, there are requirements that must be met for the component to integrate into the DCAE platform (see [CDAP](component-type-cdap.md) and [Docker](component-type-docker.md)). -## Onboarding - -There is an onboarding process that all component developers will have to take their components through to ensure that their DCAE service components are compliant with the DCAE platform and are authorized to push their component into the ASDC catalog. A command-line tool called [`dcae-cli`](ONAP URL TBD) is provided to help you through this process. The high level summary of the onboarding process is: - -1. Defining your [Data formats](data-formats.md) -2. Defining your component specification], which is a JSON that is used to describe and configure the component is to be provided by component developers upon the completion of micro-service implementation and certification testing steps. See [docker](component-specification/docker-specification.md) and [CDAP](component-specification/cdap-specification.md). -3. Testing your component locally -4. Pairwise-testing your component with any other components you connect to -5. Pushing your component and data formats into the ASDC catalog - -## The whys - -### Components require data formats... +### Components requires one or more data formats. Components are software applications that do some function. Components don't run independently, they depend upon other components. A component's function could require connecting to other components to fulfill that function. A component could also be providing its function as a service through an interface for other components to use. -The challenge is that a component cannot connect to or be connected with any other component. The upstream and downstream components must *speak* the same vocabulary or *data format*. The output of an upstream component must match your component's input or your component's output must match the downstream component's input. This is necessary for components to function without errors and correctly. +Components cannot connect to or be connected with any other component. The upstream and downstream components must *speak* the same vocabulary or *data format*. The output of an one component must match another component's input. This is necessary for components to function correctly and without errors. + +The platform requires data formats to ensure that a component will be run with other *compatible* components. -All components must have data formats. The platform requires this to validate and to ensure that your component will be run with *compatible* components. +Data formats can and should be shared by multiple components. -Components *should* have one to many data formats. Data formats should be shared. -### Components require a component specification... +### Each Component requires a component specification. -One design goal of the DCAE was to have a single place for component developers to describe their component. They should *not* have to worry about Tosca, blueprints, yaml files, etc. The component specification (and it's linked data formats) is the only piece of information about a component that each component developer has to provide. Here are some benefits: +The component specification is a JSON artifact that fully specifies the component, it's interfaces, and configuration. It's standardized for CDAP and Docker applications and is validated using a [JSON schema](ONAP URL TBD). -1. The component specification fully specifies your inputs and outputs, so DCAE knows how it can compose your component. The component specification is where you define what types of other components your component connects with and what types of other components can connect to you. You are defining your inputs and outputs. +The component specification fully specifies all the configuration parameters of the component. This is used by the designer and by policy (future) to configure the runtime behavior of the component. -2. The component specification fully specifies all the configuration parameters of your component. This is used by the designer and by policy to configure the runtime behavior of your component. +The component specification is used to *generate* application configuration in a standardized JSON that the platform will make available to the component. This application configuration JSON will include: -3. The component specification is used to *generate* your application configuration in a standardized JSON that the platform will make available. This application configuration JSON will include: +* Parameters that have been assigned values from the component specification, policy, and/or the designer +* Connection details of downstream components -* Parameters that have been assigned values from you, policy, and/or design -* Connection details of downstream components you are dependent upon +The component specification is transformed by DCAE tooling (explained later) into TOSCA models (one for the component, and in the future, one for Policy). The TOSCA models then get transformed into Cloudify blueprints. -4. The component specification is transformed by DCAE tooling into Policy models and Cloudify blueprints, so you need not worry about these. +The component specification is used by: -Every component should have one component specification. +* dcae_cli tool - to validate it +* Design Tools - TOSCA models are generated from the component specification so that the component can be used by designers to compose new DCAE services in SDC. +* Policy (future) - TOSCA models are generated from the component specification so that operations can create policy models used to dynamically configure the component. +* the runtime platform - The component's application configuration (JSON) is generated from the component specification and will be provided to the component at runtime. -### Component developers should use the dcae-cli... +## Onboarding -The dcae-cli was developed to empower component developers with developing their components for the DCAE platform. It is intended to help with: +Onboarding is a process that ensures that the component is compliant with the DCAE platform rules. A command-line tool called [`dcae-cli`](/components/dcae-cli/quickstart.md) is provided to help with onboarding. The high level summary of the onboarding process is: -* Crafting your component specification and your data formats -* Finding and sharing existing data formats -* Finding and running existing components -* Testing and launching your component as it would be run on the platform -* Push your component into the catalog to be shared and to be used by designers +1. Defining the [data formats](data-formats.md) if they don't already exist. +2. Defining the [component specification](/components/component-specification/common-specification.md). See [docker](component-specification/docker-specification.md) and [CDAP](component-specification/cdap-specification.md). +3. Use the dcae_cli tool to [add the data formats](/components/dcae-cli/walkthrough/#adding-data-formats) and [add the component](/components/dcae-cli/walkthrough/#adding-component) to the onboarding catalog. This process will validate them as well. +4. Use the dcae_cli tool to [deploy](/components/dcae-cli/walkthrough/#development-and-testing) the component. (The component is deployed to the environment indicated in the [profile](/components/dcae-cli/walkthrough/#setting-profile) section. +5. Test the component. Also do pairwise-test the component with any other components it connects with. +7. Publish the component and data formats into the Service Design and Creation (SDC) 'catalog'. (Currently, this is a manual step). -All this from a single command-line tool. |