diff options
Diffstat (limited to 'docs/sections/design-components/overview.rst')
-rwxr-xr-x | docs/sections/design-components/overview.rst | 107 |
1 files changed, 107 insertions, 0 deletions
diff --git a/docs/sections/design-components/overview.rst b/docs/sections/design-components/overview.rst new file mode 100755 index 00000000..654a0c11 --- /dev/null +++ b/docs/sections/design-components/overview.rst @@ -0,0 +1,107 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+.. _intro:
+
+
+Overview
+========
+
+DCAE components are services that provide a specific functionality and
+are generally written to be composable with other DCAE components,
+although a component can run independently as well. The DCAE platform is
+responsible for running and managing DCAE service components reliably.
+
+The DCAE Design platform aims to provide a common catalog of available DCAE
+Service components, enabling designers to select required
+components to construct and deploy composite flows into DCAE Runtime platform.
+
+Service component/MS to be onboarded and deployed into DCAE platform would
+typically go through the following phases
+
+ - Onboarding
+ - Design
+ - Runtime
+
+DCAE Design Platform supports onboarding and service design through MOD.
+
+
+Onboarding is a process that ensures that the component is compliant
+with the DCAE platform rules. The high level summary of the onboarding process
+is:
+
+1. Defining the :doc:`data formats <data-formats>` if they don’t already
+ exist.
+2. Defining the :doc:`component specification <./component-specification/component-specification>`
+3. Validate the component spec schema against
+ `Component Spec json schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/component-specification/dcae-cli-v2/component-spec-schema.json>`__
+4. Use :doc:`blueprint-generator tool <./blueprint_generator>` to generate Cloudify blueprint
+5. Test the blueprint generated in DCAE Runtime Environment (using either Dashboard UI or Cloudify cli from bootstrap)
+6. Using :doc:`DCAE-MOD <../DCAE-MOD/DCAE-MOD-User-Guide>` , publish the component and data formats into DCAE-MOD catalog.
+ (This step is required if Microservice needs to be deployed part of flow/usecase)
+
+
+A Component requires one or more data formats.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A component is a software application that performs a function. It
+doesn’t run independently; it depends 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.
+
+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 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.
+
+Data formats can and should be shared by multiple components.
+
+Each Component requires a component specification.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The component specification is a JSON artifact that fully specifies the
+component, it’s interfaces, and configuration. It’s standardized for
+CDAP (deprecated) and Docker applications and is validated using a
+:doc:`JSON schema <./component-specification/component-json-schema>`.
+
+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.
+
+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:
+
+- Parameters that have been assigned values from the component
+ specification, policy, and/or the designer
+- Connection details of downstream components
+
+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.
+
+The component specification is used by:
+
+
+- Blueprint Generator - Tool to generate standalone cloudify blueprint
+ using component spec. The blueprints can be uploaded into inventory
+ using Dashboard and triggered for deployment.
+- MOD Platform - To onboard the microservice and maintain in catalog
+ enabling designer to compose new DCAE service flows and distribute
+ to DCAE Runtime platform.
+- Policy (future) - TOSCA models are generated from the component
+ specification so that operations can create policy models used to
+ dynamically configure the component.
+- Runtime platform - The component’s application configuration
+ (JSON) is generated from the component specification and will be
+ provided to the component at runtime (through ConfigBindingService
+ or Consul).
+
+
\ No newline at end of file |