[WIT-2826] Java Tech Adapter Framework HLD

# New features and improvements * Added framework HLD # Related issue Closes WIT-2826 # Definition of Done So you are going to put your MR in review, but are you sure you have done all things listed here? ## All Developments - [ ] **Feature was implemented as per the requirements** - [ ] **If some code parts are complex they must be commented with code documentation** - [ ] **Unit, integration and E2E tests have been performed and code coverage is not reduced**, so that new code is covered - [ ] **CI/CD is successful** - [ ] **Exceptions and errors are handled, returning meaningful errors to the user**, without letting the underlying framework to respond with a generic Internal Server Error. Technical details are stored in the errors/problems and not in the user message - [X] **Documentation (user documentation, HLD and others) has been updated** - Documentation has been updated with explanation of the new feature if it's user-facing (e.g. component now has additional setting) or it impacts them in some other way (e.g. optional field that becomes mandatory) - If it is a breaking change, we have documented it as such in the MR description in a "Breaking Changes" section - [ ] **Helm chart and other DevOps artifacts** have been updated and are valid deployment tools for the new version - [ ] **Problematic information (sensitive information, credentials, customer information or other intellectual property) is not included in the changes** as they could end up being public (most SPs are already published and automatically mirrored on every merge) - [ ] **Feature doesn't negatively affect any existing environments**, especially the clients Playgrounds. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed** - [ ] **If dependencies were changed, be sure that they will not impact the project**, that their license is compatible, and that they introduce no vulnerabilities - [ ] **Security, Authentication and Authorization have been considered**. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved ## API related Development - [ ] **API Parameters and return body are compliant** with the API specification - [ ] **Errors are correctly handled**, respecting the type of errors return bodies and responses for each endpoint - [ ] **API is logging in compliance with audit standards**, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed ## DB related Development - [ ] **The database schema is designed to accurately** represent the data model and meet the requirements - [ ] **Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately**, following best practices and a common naming convention - [ ] **Sensitive data is stored securely**, encrypted if required, and access is restricted to authorized users - [ ] **Migration scripts to upgrade and downgrade the database have been implemented and tested**

Author: Sergio Andres Mejia Tovar

.gitignore

@@ -0,0 +1,46 @@
+target/
+!.mvn/wrapper/maven-wrapper.jar
+!**/src/main/**/target/
+!**/src/test/**/target/
+
+### IntelliJ IDEA ###
+.idea/modules.xml
+.idea/jarRepositories.xml
+.idea/compiler.xml
+.idea/libraries/
+*.iws
+*.iml
+*.ipr
+
+### Eclipse ###
+.apt_generated
+.classpath
+.factorypath
+.project
+.settings
+.springBeans
+.sts4-cache
+
+### NetBeans ###
+/nbproject/private/
+/nbbuild/
+/dist/
+/nbdist/
+/.nb-gradle/
+build/
+!**/src/main/**/build/
+!**/src/test/**/build/
+
+### VS Code ###
+.vscode/
+
+### Mac OS ###
+.DS_Store
+/.idea/
+
+### LOGS ###
+*.log
+
+### HELM ###
+
+helm/charts

README.md

@@ -0,0 +1 @@
+# Java Tech Adapter Framework

docs/HLD.md

@@ -0,0 +1,57 @@
+# High Level Design
+
+This High Level Design defines the Java Tech Adapter Framework design, a Spring Boot based framework to streamline the experience of creating Witboost tech adapters by standardizing common features, namely the API layer, descriptor parsing, base configuration, etc. This also allows to introduce new features and fix issues faster and without the need to propagate the feature or fix to all developed Java tech adapters.
+
+The base for this Framework will follow the existing [Java scaffold](https://github.com/agile-lab-dev/witboost-java-scaffold), and will take most of the implementation as-is, improving the existing base features to allow complete use of the potential of Witboost tech adapters.
+
+At a high level, the features this framework should provide are:
+
+- Support for the whole Tech Adapter OpenAPI specification v2.2.0 at API level with plans to update to newer versions of the API (current version as of 01/08/2024 is 2.6.0).
+- Implement the API layer of a typical Java Tech Adapter, including appropriate error handling with support for the full error schema
+- Provide extension points to define provisioning and validation business logic with a well-defined interface.
+- Support to both component level and data product level provisioning. 
+- Descriptor parsing and the possibility to configure the expected component `specific` schema for component level operations.
+ - Possibility to configure the request `params` schema for ReverseProvisioning requests
+
+Parsing the input to the framework model, and validating said input will be decoupled operations, allowing the framework to handle all possible parsing errors, and providing an interface to validate the parsed input against the specific environment or technology for which the Tech Adapter is developed.
+
+Thus, the interface must provide all the necessary information that the business logic may need to perform all its operations. This includes the following items, but more may be necessary:
+
+- Complete parsed descriptor/request, including data product information
+ - Requests must contain all possible fields as per the specification. Optional fields should be marked accordingly
+- For component level provisioning: Component to provision parsed with the appropriate schema
+ - Other components not to be provisioned are also correctly parsed as JSON but not decoded as a class
+- For validation operation: As this task is executed during different operations, the type of Operation being performed
+
+![HLD](img/HLD.png)
+
+## Spring Boot
+We will continue to use Spring Boot as the underlying API framework and leveraging the Spring facilities to achieve the wiring between the framework API layer and the business logic by using Spring's Dependency Injection.
+
+We may provide default behaviour on the interfaces which return Not Implemented errors for each method.
+
+## Sync/async operations
+The framework must support both synchronous and asynchronous operations. This should be handled via configuration, and its implementation should be transparent to the tech adapter implementation, which will only implement the (sync) business logic interface. The asynchronous pool handling shall be done by the framework. The configuration shall provide:
+
+- Enable/disable async provisioning
+- The implementation type of the repository, following WIT-229 design. As a first implementation, only the Cache (in-memory) strategy will be implemented
+
+## OpenTelemetry
+Currently, we provide integration with OpenTelemetry as part of the Java Scaffold project. This integration should remain at the Java scaffold level, as not to impose this tool onto the framework users. Thus, an OpenTelemetry dependency should not be present on the framework.
+
+## Java Scaffold
+The Java Scaffold should be rewritten to remove the API layer and instead including the framework as a dependency, injecting the business logic by implementing the necessary interfaces.
+
+The scaffold will still contain artifacts like the Dockerfile, Helm chart, documentation, and of course, the business logic.
+
+### Helm
+Explore the possibility to have a base chart that could be used as-is or extended for each provisioner, so that we also deduplicate the several charts we have.
+
+## Migration
+The idea of creating the framework is not only to facilitate the creation of future tech adapters, but also to migrate the existing Java and Scala tech adapters to use it and standardize all of our repositories. The migration should be performed only when the framework can support all the tech adapter features that a certain adapter implementation uses.
+
+For example, the Databricks Tech Adapter uses asynchronous operations, so unless the frameworks supports them, it cannot be migrated as we must avoid missing existing features when migrating.
+
+There are other instances, like the ADLS Gen2 Output Port Tech Adapter which slightly modifies the ValidationService interfaces provided by the scaffold to account for the use case it solves. Because of this is necessary to analyze the existing implementations to support them on the framework, else it would be of no use for said tech adapter.
+
+For this purpose, we must provide a sensible guide on how to migrate existing Java and Scala tech adapters to use this framework.