246 write an architecture document for didcomm mediator server e13 #269
+741
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…-server-e13' of github.com:adorsys/didcomm-mediator-rs into 246-write-an-architecture-document-for-didcomm-mediator-server-e13
…-server-e13' of github.com:adorsys/didcomm-mediator-rs into 246-write-an-architecture-document-for-didcomm-mediator-server-e13
Signed-off-by: Francis Pouatcha <[email protected]>
merging from main
Tekum-Emmanuella
requested review from
francis-pouatcha,
IngridPuppet,
Hermann-Core,
Christiantyemele,
Blindspot22 and
ndefokou
7 tasks
Christiantyemele
requested changes
Nov 25, 2024
|
|
||
| --- | ||
|
|
||
| # DIDComm Mediator RS - ARC42 Architecture Documentation |
There was a problem hiding this comment.
this RS here is confusing
|
|
||
| ### 2.1 Technical Constraints | ||
| - **Rust Programming Language**: Ensures high performance and memory safety. | ||
| - **Transport Agnosticism**: Supports various protocols (HTTP, Bluetooth, etc.). |
There was a problem hiding this comment.
Bluetooth is not yet supported
| - **No External State**: Minimal reliance on external systems for scalability. | ||
|
|
||
| ### 2.2 Regulatory Constraints | ||
| - **Privacy Compliance**: Aligns with GDPR and similar regulations. |
There was a problem hiding this comment.
What does this GDPR means
Comment on lines
+62
to
+68
| graph LR | ||
| Agent1[Agent 1] --> Transport1 | ||
| Transport1 --> Mediator1 | ||
| Mediator1 --> Mediator2 | ||
| Mediator2 --> Transport2 | ||
| Transport2 --> Agent2[Agent 2] | ||
| ``` |
There was a problem hiding this comment.
Suggested change
| graph LR | |
| Agent1[Agent 1] --> Transport1 | |
| Transport1 --> Mediator1 | |
| Mediator1 --> Mediator2 | |
| Mediator2 --> Transport2 | |
| Transport2 --> Agent2[Agent 2] | |
| ``` | |
| graph LR | |
| Agent1[Agent 1] --> Transport1 | |
| Transport1 --> Mediator1 | |
| Mediator1 --> Mediator2 | |
| Mediator2 --> Transport2 | |
| Transport2 --> Mediator3 | |
| Mediator3 --> Agent2[Agent 2] |
| | **DID Rotation** | Accepted | ✅ Implemented | | ||
| | **Cross-Domain Messaging/Routing Protocol** | Adopted | ✅ Implemented | | ||
| | **Trust Ping Protocol** | Adopted | ✅ Implemented | | ||
| | **Discover Features Protocol** | Adopted | ⚪ In Progress | |
There was a problem hiding this comment.
Suggested change
| | **Discover Features Protocol** | Adopted | ⚪ In Progress | | |
| | **Discover Features Protocol** | Adopted | ⚪ Implemented | |
Comment on lines
+96
to
+99
| 2. **In Progress Features**: | ||
| - **Discover Features Protocol** and **Out-of-Band Messaging** are under development to expand functionality. | ||
| - **Basic Message Protocol** will enable straightforward message exchanges between agents. | ||
|
|
There was a problem hiding this comment.
i feel like its preferable to remove this highlight here because this will require frequent modifications, beside the discover features protocol is implemented already
|
|
||
| 1. **Web Plugin Layer**: | ||
| - Enables plug-and-play of web endpoints. | ||
| - Currently used to implement features such as DID endpoints, out-of-band messages, and DIDComm messaging. |
There was a problem hiding this comment.
Suggested change
| - Currently used to implement features such as DID endpoints, out-of-band messages, and DIDComm messaging. | |
| - Currently used to implement features such as **DID Endpoints**, **out-of-band messaging**, and **DIDComm messaging**. |
| At the core is the **Generic Server**, responsible for hosting the overall application and enabling the plugin system. The main components are: | ||
|
|
||
| 1. **Dispatcher**: Routes incoming requests to the appropriate web plugin. | ||
| 2. **Web Plugin Layer**: Hosts modular implementations for endpoint-specific logic (e.g., DID endpoint generation, out-of-band messages). |
There was a problem hiding this comment.
Suggested change
| 2. **Web Plugin Layer**: Hosts modular implementations for endpoint-specific logic (e.g., DID endpoint generation, out-of-band messages). | |
| 2. **Web Plugin Layer**: Hosts modular implementations for endpoint-specific logic (e.g., DID endpoint generation, out-of-band messaging). |
Comment on lines
+145
to
+157
| graph TD | ||
| GenericServer[Generic Server] --> Dispatcher[Dispatcher] | ||
| Dispatcher --> WebPluginLayer[Web Plugin Layer] | ||
| WebPluginLayer --> DIDEndpoint[DID Endpoint] | ||
| WebPluginLayer --> OOBMessaging[Out-of-Band Messages] | ||
| WebPluginLayer --> DIDCommMessaging[DIDComm Messaging Endpoint] | ||
| DIDCommMessaging --> CommonProcessing[Common DIDComm Processing] | ||
| DIDCommMessaging --> MessagingPlugins[Messaging Plugin Layer] | ||
| MessagingPlugins --> Forward[Forward Protocol] | ||
| MessagingPlugins --> Pickup[Pickup Protocol] | ||
| MessagingPlugins --> Coordination[Mediator Coordination Protocol] | ||
| MessagingPlugins --> Trustping[Trust Ping Protocol] | ||
| ``` |
There was a problem hiding this comment.
Please change the Out-of-Band messages to Out-of-Band Messaging
Comment on lines
+231
to
+342
|
|
||
| **Disadvantages**: | ||
| - No fault tolerance: if the mediator fails, the service becomes unavailable. | ||
| - Limited scalability. | ||
|
|
||
| --- | ||
|
|
||
| #### 2. **Distributed Deployment with Load Balancer (Recommended)** | ||
|
|
||
| **Use Case**: Ideal for production environments requiring high availability and scalability. | ||
|
|
||
| - Multiple mediator instances are deployed behind a load balancer. | ||
| - The load balancer distributes requests evenly across mediators, ensuring efficient utilization of resources. | ||
| - Supports horizontal scaling by adding more mediator instances as needed. | ||
|
|
||
| **Advantages**: | ||
| - High availability: If one mediator instance fails, others continue handling requests. | ||
| - Scalable: New instances can be added to handle increased load. | ||
| - Efficient routing: Load balancer optimizes resource utilization. | ||
|
|
||
| **Disadvantages**: | ||
| - Slightly higher complexity due to additional components (load balancer). | ||
|
|
||
| --- | ||
|
|
||
| ### 7.3 Deployment Diagram | ||
|
|
||
| Below is a component diagram showcasing the deployment with multiple mediators and a load balancer: | ||
|
|
||
| ```mermaid | ||
| graph TD | ||
| subgraph Internet | ||
| User1[Recipient Agent] | ||
| User2[Sender Agent] | ||
| end | ||
|
|
||
| User1 --> LB[Load Balancer] | ||
| User2 --> LB | ||
|
|
||
| subgraph Mediator Cluster | ||
| Mediator1[Mediator Instance 1] | ||
| Mediator2[Mediator Instance 2] | ||
| end | ||
|
|
||
| LB --> Mediator1 | ||
| LB --> Mediator2 | ||
|
|
||
| Mediator1 --> DB1[Message Storage DB] | ||
| Mediator2 --> DB1 | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ### 7.4 Deployment Considerations | ||
|
|
||
| #### **Cloud Deployment** | ||
|
|
||
| **Infrastructure**: | ||
| - Use cloud platforms like AWS, Azure, or GCP. | ||
| - Services like Elastic Load Balancer (AWS), Application Gateway (Azure), or Cloud Load Balancer (GCP) can be employed for load balancing. | ||
|
|
||
| **Scaling**: | ||
| - Leverage auto-scaling groups to dynamically scale mediator instances based on traffic. | ||
|
|
||
| **Monitoring**: | ||
| - Use monitoring tools (e.g., Prometheus, CloudWatch, or Azure Monitor) to track mediator performance, error rates, and resource usage. | ||
|
|
||
| --- | ||
|
|
||
| #### **On-Premises Deployment** | ||
|
|
||
| **Infrastructure**: | ||
| - Deploy mediators on virtual machines or containers (e.g., Docker). | ||
| - Use a software-based load balancer (e.g., HAProxy, NGINX) for request distribution. | ||
|
|
||
| **Scaling**: | ||
| - Add more mediator instances manually to handle increased traffic. | ||
|
|
||
| **Monitoring**: | ||
| - Use tools like Grafana and Prometheus to monitor system health. | ||
|
|
||
| --- | ||
|
|
||
| ### 7.5 Benefits of Load Balancer in Deployment | ||
|
|
||
| 1. **Fault Tolerance**: | ||
| - Ensures service continuity even if one mediator instance fails. | ||
|
|
||
| 2. **Scalability**: | ||
| - Handles growing traffic by distributing load across multiple instances. | ||
|
|
||
| 3. **Optimized Resource Utilization**: | ||
| - Prevents overloading a single mediator, ensuring consistent performance. | ||
|
|
||
| 4. **Simplified Maintenance**: | ||
| - Instances can be updated or replaced without downtime by redirecting traffic. | ||
|
|
||
| This detailed deployment view provides clarity on how the system can be deployed effectively, balancing performance, fault tolerance, and scalability. | ||
|
|
||
| --- |
There was a problem hiding this comment.
in the whole of this deployment view we only saying what can be use, i think the document is to empose what to do base our capabilities
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
please @ all, read this arc doc so we can review together and merge.