+++ /dev/null
-.. 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
-Overview\r
-========\r
-\r
-DCAE components are services that provide a specific functionality and\r
-are generally written to be composable with other DCAE components,\r
-although a component can run independently as well. The DCAE platform is\r
-responsible for running and managing DCAE service components reliably.\r
-\r
-The DCAE Design platform aims to provide a common catalog of available DCAE \r
-Service components, enabling designers to select required \r
-components to construct and deploy composite flows into DCAE Runtime platform.\r
-\r
-Service component/MS to be onboarded and deployed into DCAE platform would \r
-typically go through the following phases\r
-\r
- - Onboarding \r
- - Design \r
- - Runtime\r
-\r
-DCAE Design Platform supports onboarding and service design through MOD. \r
-\r
-\r
-Onboarding is a process that ensures that the component is compliant\r
-with the DCAE platform rules. The high level summary of the onboarding process\r
-is:\r
-\r
-1. Defining the :doc:`data formats <data-formats>` if they don’t already\r
- exist. \r
-2. Defining the :doc:`component specification <./component-specification/component-specification>`\r
-3. Validate the component spec schema against\r
- `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
-4. Use :doc:`blueprint-generator tool <./blueprint_generator>` to generate Cloudify blueprint\r
-5. Test the blueprint generated in DCAE Runtime Environment (using either Dashboard UI or Cloudify cli from bootstrap)\r
-6. Using :doc:`DCAE-MOD <../DCAE-MOD/DCAE-MOD-User-Guide>` , publish the component and data formats into DCAE-MOD catalog. \r
- (This step is required if Microservice needs to be deployed part of flow/usecase)\r
-\r
-\r
-A Component requires one or more data formats.\r
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
-\r
-A component is a software application that performs a function. It\r
-doesn’t run independently; it depends 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
-A component 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 (deprecated) and Docker applications and is validated using a \r
-:doc:`JSON schema <./component-specification/component-json-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
-\r
-- Blueprint Generator - Tool to generate standalone cloudify blueprint\r
- using component spec. The blueprints can be uploaded into inventory \r
- using Dashboard and triggered for deployment.\r
-- MOD Platform - To onboard the microservice and maintain in catalog\r
- enabling designer to compose new DCAE service flows and distribute\r
- to DCAE Runtime platform.\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
-- 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 (through ConfigBindingService\r
- or Consul).\r
-\r
-
\ No newline at end of file
Code Review / dcaegen2.git / blobdiff