Dynamic Policy Enforcement Point Updates Without Service Interruption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional distributed computing systems require service interruptions to change service level agreements (SLAs) or policy enforcement points (PEPs), as these components are hard-coded and must be redeployed, leading to service disruptions.
Innovation Solution
A method and apparatus for dynamically updating policy enforcement points and service level agreements in a distributed computing system, where a repository manager identifies associated services and transmits updates without interrupting service operations, allowing PEPs and SLAs to be installed or modified without shutting down the service.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If SLA and PEPs are hard coded into the service at deployment time, then the service has stable and reliable policy enforcement, but any change to SLA or PEP causes service interruption requiring shutdown and redeployment
Solution Approach 1:
The patent segments the policy enforcement functionality by separating PEPs from the core service code. PEPs are stored as independent, externally accessible objects in a repository rather than being hard-coded into the service. This allows the service to load and enforce policies dynamically without requiring service shutdown, resolving the contradiction between stable enforcement and update capability.
Solution Approach 2:
The patent introduces a repository manager as an intermediary component that mediates between policy administrators and the service. The repository manager stores PEPs and SLAs externally and provides mechanisms for the service to retrieve and enforce policies dynamically. This intermediary enables policy changes without service interruption while maintaining reliable enforcement through the structured repository system.
2Reliability
If SLA and PEPs are rewritten and service is redeployed to implement changes, then policy enforcement remains consistent with service code, but service downtime increases and productivity decreases
Solution Approach 1:
The patent makes the policy enforcement system dynamic by enabling the service to load, update, and enforce PEPs at runtime without redeployment. The service can dynamically retrieve updated PEPs from the repository manager and apply them immediately, eliminating the need for service shutdown and maintaining both consistency and high availability.
Solution Approach 2:
The patent implements preliminary action by pre-storing PEPs and SLAs in the repository manager before they are needed by the service. Policy changes can be prepared and stored in advance in the repository, and the service can retrieve them when ready without interruption, ensuring consistency while maintaining productivity.
3Device complexity
If PEPs are installed at service deployment time, then the service structure remains simple and easy to understand, but flexibility to modify policies without redeployment is lost
Solution Approach 1:
The patent extracts PEPs from the service code and places them in an external repository manager. This separation maintains service structure simplicity while enabling dynamic policy updates. The service retains a simple structure focused on core functionality, while policy management is handled by the external repository system, providing both simplicity and adaptability.
Solution Approach 2:
The repository manager serves multiple functions: storing PEPs, managing SLAs, facilitating policy updates, and providing retrieval mechanisms for the service. This universal component handles all policy-related operations externally, allowing the service to remain simple while gaining dynamic update capabilities through the multi-functional repository system.
Data Source
AI summary
A policy is added to a repository. The repository is a component of a distributed computing system. An active service associated with a service level agreement that specifies the policy is identified. The policy is propagated to the active service and then installed on the active service without interrupting the active service. The repository receives the service level agreement that specifies the policy in an enforcement policy. The service level agreement is propagated to the active service and then installed on the active service without interrupting the active service. The policy is then propagated to a client that is associated with the service level agreement installed at the active service.