Commit 046eafcc authored by Jorge Moratinos's avatar Jorge Moratinos
Browse files

Architecture section improved and new image uploaded

parent e5e3a43b
Loading
Loading
Loading
Loading
+38 −11
Changes for doc/architecture.md: 38 added lines, 11 removed lines.
Original line number Diff line number Diff line
@@ -4,7 +4,7 @@

The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:

![New Architecture](./images/architecture/New_Architecture.png)
![New Architecture](./images/architecture/Architecture.png)

Each component is separated into different namespaces and all communications between them use Rest APIs.

@@ -13,27 +13,54 @@ Apart from the communication between components, there are 2 other entities that
- **Admin/superadmin**: Responsible for managing users with the Register or carrying out special operations in the CCF.
- **Users**: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the CCF.

## **Register NS**
## **Vault NS**

This namespace belongs to Vault. 

This namespace belongs to the Register service, and we find 2 components:
This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.

## **OpenCAPIF NS**

This namespace belongs to the Register service, and all OpenCAPIF micro-services. We can find 2 main components:

- **Register Service**: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.
- **Register MONGO DATABASE**: It is the Register database, in it we store all the information about registered users.
- **OpenCAPIF Services**: This is the core function of OpenCAPIF.

## **Vault NS**

This namespace belongs to Vault. 
### Register Component

This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.
The Register component consists in 2 main services:

- **Register Service**: This contains all logic to manage and give access to users:
  - **Admin Role**: Admin can create, delete or list users.
  - **User Role**: User created by admin, can request access to OpenCAPIF, this will give JWT Token and all endpoints accessible by that user to interact with OpenCAPIF Core.
- **Register DB**: This DB stores all user information.

This component will expose a URL at K8s ingress to access it.

### OpenCAPIF Services**

Te OpenCAPIF Component consists in X services, each one related with one API:

## **Mon NS**
- **CAPIF Discover Service**
- **CAPIF Publish Service**
- **CAPIF Events Service**
- **CAPIF Invoker Management Service**
- **CAPIF Security Service**
- **CAPIF Logging Service**
- **CAPIF Auditing Service**
- **CAPIF Access Control Policy Service**
- **CAPIF Provider Management Service**
- **CAPIF Routing Info Service**
- **CAPIF Open Discover Service**
- **Helper Service**: Service that simplifies integration with third parties such as external management portals.

This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:
Also this component deploys some side services:

- **NGINX**: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.
- **REDIS**: Used for internal communication of services.
- **CAPIF MONGO DATABASE**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.
- **HELPER**: Service that simplifies integration with third parties such as external management portals.
- **Celery**: This component is responsible of send event messages when eventReq feature is active.
- **CAPIF DB**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.

## **New Architecture**

+129 KiB
Loading image diff...
+1 −1
Changes for doc/releasenotes.md: 1 added line, 1 removed line.
Original line number Diff line number Diff line
## **Release X.X.X**
## **Release 5.0.0**

### **New Features**

+4 −4
Changes for mkdocs.yml: 4 added lines, 4 removed lines.
Original line number Diff line number Diff line
@@ -93,14 +93,14 @@ nav:
      - How to Run Locally: ./gettingstarted/howtorun.md
      - How to Deploy Using Helm: ./gettingstarted/howtodeploy.md
  - Features:
      - Vendor Extensibility: ./vendor-ext/vendor-ext.md
      - Api Status: ./api-status/api-status.md
      - Event Filter: ./event-filter/event-filter.md
      - Dynamic Configuration: ./configuration/configuration.md
      - Event Filter: ./event-filter/event-filter.md
      - Event Reporting Information: ./event-req/event-req.md
      - Vault Certificate Management: ./vault/vault.md
      - OpenCAPIF Interconnection: ./interconnection/interconnection.md
      - Open Discover: ./open-discover/open-discover.md
      - OpenCAPIF Interconnection: ./interconnection/interconnection.md
      - Vault Certificate Management: ./vault/vault.md
      - Vendor Extensibility: ./vendor-ext/vendor-ext.md
      - Visibility Control: ./features/visibility-control/visibility-control.md
  - SDK:
      - Introduction: ./sdk/sdk_introduction.md