Polar is a secure and scalable knowledge graph framework, designed to address the challenges posed by building big data systems in highly regulated environments, and improve observability for DevSecOps Organizations.
Other
10
stars
1
forks
source link
Implementing an Exemplar Observer with Actor Model Concurrency #3
As the architect for the project, I want to introduce an exemplar Observer that is implemented using Actor Model concurrency,
so that we can efficiently observe the local Observable service with a robust and scalable design.
Details:
The Observer should be implemented on a WASM runtime.
Use the Lunatic framework: Lunatic.
The Observer will make observations of the local Observable service created in a previous story.
Implement the Observer using a supervision tree:
Top-level Supervisor: Oversees the entire tree of actors implementing the Observer.
Second Level:
State Manager Actor: Manages a state struct.
Task Manager Actor: Manages tasking for observers in the tree below it.
Policy Manager Actor: Manages a tree of actors reconciling changes to policy.
Task Manager Actor:
Handles incoming configuration messages.
Updates tasking for child actors by sending them messages.
Policy Manager Actor:
Determines when there are new policy changes.
Tasks child actors with determining what those changes look like.
Creates policy change messages for a given type of actor.
Sends a message to the Task Manager Actor once a policy change has been parsed.
State Management:
Ensures a consistent state.
Receives messages from observers when an observation is made.
Message Send Actor (broker):
Sends observation messages to a message broker (presently, RabbitMQ)
Establishes SSL connection to the broker, maintaining connection state.
Other actors do not need to know how to connect to the broker.
Acceptance Criteria:
Setup and Configuration:
The WASM runtime and Lunatic framework are correctly set up and configured.
Documentation is provided for the setup process.
Implementation:
A supervision tree is implemented with a top-level supervisor and second-level actors.
The Task Manager Actor can handle and process incoming configuration messages.
The Policy Manager Actor can detect policy changes and task child actors accordingly.
The State Manager Actor maintains a consistent state and updates it upon receiving messages.
Functionality:
Observers can make observations of the local Observable service.
Observers send messages to the State Manager Actor upon making observations.
The Final Actor can send messages to RabbitMQ, maintaining a secure SSL connection.
Testing:
Unit tests are created to verify the functionality of each actor.
Integration tests ensure the entire supervision tree works as expected.
Tests cover various scenarios, including configuration changes and policy updates.
Performance:
The implementation does not degrade performance of the local Observable service.
The actors operate efficiently, even under high load.
Error Handling:
Proper error handling is implemented at each level of the supervision tree.
Logs are generated for debugging and monitoring purposes.
Security:
The SSL connection to RabbitMQ is secure.
Sensitive information is protected and not exposed.
Documentation:
Clear documentation is provided for the implementation, including setup, usage, and troubleshooting.
The design and architecture of the supervision tree and actors are well-documented.
As the architect for the project, I want to introduce an exemplar Observer that is implemented using Actor Model concurrency, so that we can efficiently observe the local Observable service with a robust and scalable design.
Details:
The Observer should be implemented on a WASM runtime. Use the Lunatic framework: Lunatic. The Observer will make observations of the local Observable service created in a previous story.
Implement the Observer using a supervision tree: Top-level Supervisor: Oversees the entire tree of actors implementing the Observer.
Second Level: State Manager Actor: Manages a state struct. Task Manager Actor: Manages tasking for observers in the tree below it. Policy Manager Actor: Manages a tree of actors reconciling changes to policy.
Task Manager Actor: Handles incoming configuration messages. Updates tasking for child actors by sending them messages.
Policy Manager Actor: Determines when there are new policy changes. Tasks child actors with determining what those changes look like. Creates policy change messages for a given type of actor. Sends a message to the Task Manager Actor once a policy change has been parsed.
State Management: Ensures a consistent state. Receives messages from observers when an observation is made.
Message Send Actor (broker): Sends observation messages to a message broker (presently, RabbitMQ) Establishes SSL connection to the broker, maintaining connection state. Other actors do not need to know how to connect to the broker.
Acceptance Criteria:
Setup and Configuration: The WASM runtime and Lunatic framework are correctly set up and configured. Documentation is provided for the setup process.
Implementation: A supervision tree is implemented with a top-level supervisor and second-level actors. The Task Manager Actor can handle and process incoming configuration messages. The Policy Manager Actor can detect policy changes and task child actors accordingly. The State Manager Actor maintains a consistent state and updates it upon receiving messages.
Functionality: Observers can make observations of the local Observable service. Observers send messages to the State Manager Actor upon making observations. The Final Actor can send messages to RabbitMQ, maintaining a secure SSL connection.
Testing: Unit tests are created to verify the functionality of each actor. Integration tests ensure the entire supervision tree works as expected. Tests cover various scenarios, including configuration changes and policy updates.
Performance: The implementation does not degrade performance of the local Observable service. The actors operate efficiently, even under high load.
Error Handling: Proper error handling is implemented at each level of the supervision tree. Logs are generated for debugging and monitoring purposes.
Security: The SSL connection to RabbitMQ is secure. Sensitive information is protected and not exposed.
Documentation: Clear documentation is provided for the implementation, including setup, usage, and troubleshooting. The design and architecture of the supervision tree and actors are well-documented.