Initial Comments
- The long term aim is to integrate CLAMP into the Policy Framework and to align the structure and technologies of CLAMP and the Policy Framework in general
- We should have a picture of what the long term vision for CLAMP in the Policy Framework is
- How the TOSCA based Control Loop features are implemented should be in line with this long term vision
Policy Framework and CLAMP
Architecture
Architecturally, the Policy Framework and CLAMP are complimentary as separate systems. The Policy Framework is part of control loops, and CLAMP is a control loop management system.
Technologies
| Technology | Policy Framework | CLAMP | Comment |
|---|---|---|---|
| Lifecycle Management | Policy Common | Spring Framework | |
| REST | Policy Common, using JAX-RS annotations | Camel | |
| Parameter Handling | Built in parameter validation in policy common | Spring properties | |
| TOSCA Handling | Policy Models | CLAMP TOSCA handling | |
| Persistence | Policy Models using JPA/JDBC/Eclipselink/MariaDB | Spring using JPA/JDBC/Hibernate/MariaDB | |
| UI | None (Angular in TOSCA PoC) | React |
Code Structure, Build, and Test
| Area | Policy Framework | CLAMP | Comment |
|---|---|---|---|
| Module Structure | Maven multi module project | Single module project | |
| Docker Build | Common approach for all components and repos | Part of Single module | |
| Integration Test | CSITs done per component | Integration test part of build | |
| Persistence | Policy Models using JPA/JDBC/Eclipselink/MariaDB | Spring using JPA/JDBC/Hibernate/MariaDB | |
| UI | None (Angular in TOSCA PoC) | React |
Use of Policy/Common or Spring Framework for component LCM
TOSCA Handling
Use of Angular or React for GUIs
Use of Camel or direct REST coding for operations
Introduction of executable components for Participants
Structuring of policy/clamp for multiple components
Approach for integration testing