Parallel Class Loader for Hot-Pluggable Access Management Plugins
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing access management systems require server downtime for updates and customization, as they lack the ability to dynamically load and manage plug-ins without restarting, which is undesirable for maintaining high availability.
Innovation Solution
Implementing a parallel class loader within the JVM to load custom plug-in jar files without modifying the server's class path, using the OSGI framework for dynamic and secure loading and unloading of plug-ins, and managing plug-in lifecycles to ensure security and manageability in a clustered environment.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the access management system server is shut down for updates or customization, then the system can be updated or extended with new features, but the system availability is reduced and service disruption occurs
Solution Approach 1:
The system implements dynamic plugin loading and unloading capabilities, allowing the access management system to be extended or modified without requiring a server shutdown. Plugins can be added, removed, or updated while the system remains operational, resolving the contradiction between system extensibility and continuous availability.
Solution Approach 2:
The system performs preliminary validation and preparation of plugin packages before activation. Plugin metadata is registered and validated in advance, ensuring that updates can be applied smoothly without service interruption, thus maintaining system availability while enabling extensibility.
2Adaptability or versatility
If custom authentication modules or authorization modules are added to the access management system, then the system functionality is enhanced, but the system complexity increases and requires server restart
Solution Approach 1:
The system segments customization functionality into independent, modular plugins that can be developed, deployed, and managed separately. Each plugin encapsulates specific authentication or authorization logic, reducing overall system complexity while enhancing customization capability. Plugins can be independently activated without affecting the entire system.
Solution Approach 2:
The plugin architecture provides a universal interface for adding custom authentication and authorization modules. The same plugin mechanism handles diverse customization needs, from simple authentication extensions to complex authorization workflows, reducing the complexity of managing different types of customizations through a unified approach.
3Ease of operation
If the server class path is modified to include custom plug-ins, then the plug-ins can be loaded and executed, but the server must be restarted for changes to take effect
Solution Approach 1:
The system dynamically updates the class path at runtime by registering plugin JAR files in a designated directory and automatically loading them without requiring server restart. The class loader is configured to monitor and load new plugins dynamically, enabling easy deployment while avoiding server downtime.
Solution Approach 2:
The system introduces a plugin management intermediary layer that handles the loading and registration of custom plugins. This intermediary manages the class path modifications and plugin lifecycle independently of the core server process, allowing plugins to be deployed and activated without interrupting server operations.
Data Source
AI summary
Embodiments described herein relate to extending the functionality of one or more access management servers, using plug-in files which may be uploaded while the servers are running. The plug-in files may be discovered in both the plug-in file's own class path and the server's class path, and then may be used in the server's authentication and other operations. In certain embodiments, the server's class path need not be modified during this process, and the server need not be shut down or restarted. Certain embodiments may implement a parallel class loader. Custom plug-in file code may be loaded by the parallel class loader, and the parallel class loader is started a container class loader may be made the parent of the parallel class loader.