Operations Manager Decouples Policy From Source Code
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional operational policy management approaches require changes to source code and recompilation, making them inefficient and error-prone, especially in complex software applications, and they lack the ability to support dynamic updates or decouple policies from source code authorship and compilation processes.
Innovation Solution
A dynamically updatable operational policy management system that decouples operational policies from source code, using a subscription configuration file to trigger behaviors associated with operational events, allowing for independent management and updates without altering the client source code, and providing tools for developers to weave operational activities into the code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If operational policies are hard coded with event-generating operational code, then the policies are tightly integrated with the source code, but any policy changes require source code editing and recompilation, which is time-consuming and error-prone
Solution Approach 1:
The patent segments the operational policy from the event-generating code by introducing a separate policy specification file (e.g., XML or JSON format). This file contains policy definitions that are independent of the source code, allowing policies to be modified without touching the actual codebase. The event-generating code simply references these external policy files, creating a clear separation between code and policy configuration.
Solution Approach 2:
The patent introduces an intermediary component (policy management system or configuration parser) that acts as a mediator between the event-generating code and the policy definitions. This intermediary reads the external policy specification files and translates them into executable policy rules that the operational code can follow, eliminating the need for direct code modification when policies change.
2Adaptability or versatility
If source code is edited to change operational policies, then the policies can be updated, but the process requires recompilation and is suitable only for build-time changes, not runtime updates
Solution Approach 1:
The patent makes the operational policy dynamic by allowing it to be specified in external configuration files that can be modified at runtime without recompiling the application. The system loads and reloads these policy specifications dynamically, enabling policy changes to take effect immediately when the configuration files are updated, thus providing both build-time and runtime adaptability.
Solution Approach 2:
The patent enables parameter changes in operational policies by storing policy definitions as configurable parameters in external files. These parameters can be adjusted without changing the source code structure, allowing flexible modification of policy behavior through simple configuration file edits rather than code changes.
3Manufacturing precision
If multiple operational policies are managed across different source code files, then comprehensive coverage is achieved, but finding and changing all policies consistently becomes difficult and time-consuming
Solution Approach 1:
The patent creates a universal policy specification format (such as XML or JSON) that can define all operational policies across the entire application in a single standardized structure. This universal format replaces the need for scattered policy definitions throughout multiple source code files, providing a centralized location for policy management that ensures consistency across the application.
Solution Approach 2:
The patent extracts all operational policy definitions from the source code files and places them into separate external configuration files. This extraction eliminates the complexity of searching through multiple source files to find and modify policies, as all policy changes can now be made in a single external location without affecting the source code structure.
4Productivity
If operational code is removed or deactivated, then performance is improved, but the ability to debug and test is reduced
Solution Approach 1:
The patent makes the inclusion or exclusion of operational code dynamic through configuration file settings. The external policy specification files contain parameters that control whether operational events are generated, logged, or executed. By changing these configuration parameters, the system can switch between performance-optimized mode (with operational code deactivated) and debugging mode (with operational code fully active), without requiring code changes or recompilation.
Data Source
AI summary
An Operations Manager subsystem decouples the generation of operational events from an associated behavior triggered by those events. The Operations Manager subsystem allows changing the associated behavior without requiring rebuilds or recompilations of the source code. In addition, changes to policies are possible even at runtime in order to enable more agile debugging and better application supportability. The Operations Manger subsystem includes separate reporting and subscription services. The reporting services provide an API defining operational code for the generation of operational events. The subscription services include a file system and an API that support multiple user subscriptions to the various code operational events defining the behavior associated with those events.