You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

OpenECOMP consists of a number of software subsystems. These subsystems are part of two major architectural frameworks:

  • a design-time environment to design, define and program the platform
  • an execution-time environment to execute the logic programmed in the design phase.

The design-time framework  is an integrated development environment with tools, techniques, and repositories for defining and describing deployable assets. It supports the development of new capabilities, augmentation of existing capabilities and continuous operational improvement throughout the lifecycle of a service. The execution-time framework uses closed-loop, policy-driven automation to drive down operational costs. Built-in dynamic, policy-enforced functions are provided for component and workload shaping, placement, execution, and administration. Access to the design-time and execution-time frameworks are provided by the OpenECOMP Portal, a role-based user interface.

Figure 1 shows the architecture of OpenECOMP.

OpenEcomp architecture

Figure 1. OpenECOMP architecture

OpenECOMP Portal

The OpenECOMP Portal (henceforth, Portal) is the web-based end-user interface to OpenECOMP. It offers both design-time tools and run-time monitoring and control.

Any user seeking access to an OpenECOMP application will first land on the Portal, where authentication will be performed. Based on the user’s access level (determined by OpenECOMP administrators), the Portal will let the user access different application widgets, and may also redirect the user to a specific run-time environment.
The Portal provides the following design-time features:
  • Visual design tools for Services
  • Policy creation (editing and conflict identification tools)
  • Visual design tools for Analytic Applications
The Portal provides the following run-time features:
  • Dashboards: customizable collections of dynamic widgets that provide summary content provided by applications running in separate environments. The available widgets are tailored for each user based on access level.
  • Reports and Visualizations (static snapshots)
  • Collaboration Services (video, text chatting, and screen sharing)
  • Application administration (on-boarding and management)
  • System monitoring, alarms, and auditing
  • Personalization
  • Service registration and discovery (occurs below the user-interface level, but allows applications to make themselves visible in the Portal)

Design-time framework

The design-time framework consists of the following components, or subsystems:

The ASDC subsystem enables developers to define, simulate, and certify assets and their associated processes and policies.The Policy Creation subsystem enables the creation of rules that instantiate conditions, requirements, constraints, attributes, or needs regarding the assets that must be provided, maintained, or enforced.

The design-time framework provides a set of common services and utilities and is intended for a variety of users with a different roles. For example, the design studio enables product and service designers to onboard, extend and retire resources, services and products. Also using the design studio, operations engineers, security experts and customer experience experts can create workflows, policies and methods. 

Run-time Framework

The run-time execution framework executes the rules and policies designed within the design-time framework, and consists of the following subsystems:

The run-time framework distributes the assets and policies created in the design environment to the subsystems within the execution framework. These subsystems use a set of common services that support access control, data management, and logging.

  • No labels