A distributed, double-interface isolated, permission-controllable plug-in management system

Abstract

The application discloses a distributed, double-interface isolated, permission controllable plug-in management system, and belongs to the technical field of computer software plug-ins. The system is divided into an interface isolation layer, a core management layer, a distributed communication layer, a security permission layer, a plug-in execution layer and a three-terminal business layer. The interface isolation layer is provided with two types of independent interfaces for separating management instructions and business calling instructions. The core management layer realizes plug-in on-demand loading, intelligent scheduling and unified attribute configuration. The distributed communication layer completes transparent data transmission across terminals and network segments through middleware. The security permission layer realizes plug-in full life cycle auditing and permission control through multiple units. The plug-in execution layer centrally displays various functional plug-ins, and the three-terminal business layer cooperatively completes plug-in development, auditing, distribution and running. The system can realize plug-in lightweight operation, distributed cooperation, flexible scheduling and full-process security protection, and optimizes resource occupation and use experience.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a plug-in management system with distributed communication, interface isolation and full lifecycle permission control. Background Technology

[0002] Plug-in architecture is currently the mainstream technical solution for improving the scalability of software systems, reducing module coupling, and enabling on-demand customization of functions. It is widely used in various clients, servers, and distributed terminal devices. However, existing plug-in management technologies have the following shortcomings when facing complex business scenarios, distributed deployment requirements, and security control requirements: First, traditional plugin management solutions typically load all plugins at the application startup stage, which not only makes the software installation package bloated, but also allows a large number of long-term idle plugins to continuously occupy memory resources, directly leading to excessive system memory usage, application response delays, and significant performance bottlenecks.

[0003] Secondly, existing plugins generally have independent configuration entry points and lack a unified and centralized management panel. Users need to repeatedly set parameters such as reminder methods and display status for each plugin, which is cumbersome and has low overall efficiency.

[0004] Third, most existing solutions use a single interface to handle both plugin management commands and business call commands simultaneously, resulting in deep coupling between management logic and business logic. In high-concurrency scenarios, this can easily lead to command blocking and task conflicts, severely limiting system stability and functional scalability.

[0005] Fourth, most existing technologies only support plugins to run within a single device and a single process, and cannot achieve transparent plugin calls across IP (Internet Protocol), terminals, and network segments, making it difficult to adapt to complex deployment scenarios such as large-scale distributed systems, industrial IoT monitoring, and cloud service collaboration.

[0006] Fifth, the existing solution lacks a security control mechanism covering the entire lifecycle of the plugin. There are no comprehensive review and authorization processes set up for each stage from plugin development, release, installation to operation, which can easily lead to security risks such as malicious plugin implantation, data leakage, and unauthorized calls.

[0007] Sixth, the existing plugin call scheduling method is rigid and singular, and cannot flexibly adjust the execution mode according to conditions such as interface type, system load, and plugin priority, making it difficult to adapt to diversified business scenarios such as algorithm plugin chains and complex business pipelines.

[0008] Therefore, the industry urgently needs a plug-in management system that can solve the above problems at the same time and has the characteristics of being lightweight, distributed, highly secure, and easy to manage. Summary of the Invention

[0009] This application provides a distributed, dual-interface isolated, and permission-controlled plugin management system to solve the problems of high plugin resource consumption, severe interface coupling, lack of support for distributed calls, lack of security control, cumbersome management operations, and single scheduling strategy in the prior art.

[0010] This application provides a distributed, dual-interface-isolated, and permission-controlled plugin management system, including an interface isolation layer, a core management layer, a distributed communication layer, a security permission layer, a plugin execution layer, and a three-terminal business layer. The interface isolation layer contains logically isolated function management interfaces and function implementation interfaces; the function management interface is used to receive management instructions for plugin configuration, permission settings, attribute modification, and state switching; the function implementation interface is used to receive business instructions for plugin operation, invocation, and data interaction. The core management layer includes a plugin management module, a policy management module, and a general control module. The plugin management module is used to maintain the memory-resident table, as well as perform plugin lookup, on-demand loading, unloading, status monitoring, and full lifecycle maintenance. It also configures idle timers to monitor plugin call status and manage plugin validity periods. The policy management module is used to store and execute plugin selection rules and plugin call rules. The general control module is used to uniformly manage the common attributes of all plugins. The distributed communication layer includes a plugin management middleware and a communication middleware; the plugin management middleware is used to manage plugins in layers according to business type and is equipped with a multi-language interface adaptation layer; the communication middleware is used to complete data forwarding across terminals and network segments based on address information. The security permission layer includes a development review unit, an installation review unit, an operation review unit, and an expiration management unit. The development review unit, installation review unit, and operation review unit are used to review the plugin development, installation, and operation processes, respectively, while the expiration management unit is used to control the usage period of the plugin. The plugin execution layer is used to display various functional plugins and provide a centralized operation entry point; The three-terminal business layer includes the plugin development end, the plugin server end, and the plugin application end. The three ends work together to complete the plugin development, review, storage, distribution, installation and operation.

[0011] The distributed, dual-interface isolated, and permission-controlled plugin management system described in this application has the following advantages: 1. It adopts an on-demand loading + automatic timeout uninstallation mechanism, keeping only currently used plugins in memory, which greatly reduces system memory usage and effectively solves the performance degradation problem caused by idle plugins.

[0012] 2. Adopting a dual-interface isolation architecture, management traffic is isolated from business traffic, avoiding command blocking and conflicts in high-concurrency scenarios, and improving system stability and functional scalability.

[0013] 3. A distributed transmission architecture is built based on the plugin management middleware and communication middleware to realize transparent plugin calls across IP, terminals and network segments, adapting to various distributed deployment scenarios.

[0014] 4. Establish a multi-level audit and access control system covering the entire lifecycle of development, release, installation, operation, and destruction to effectively intercept malicious plugins and unauthorized operations and prevent data security risks.

[0015] 5. Provides a unified management interface, supporting a management mode that combines batch configuration with independent configuration of individual plugins, simplifying user operation processes and improving user experience.

[0016] 6. Configure diversified scheduling strategies, which can automatically match serial, parallel and mixed execution modes based on plug-in priority and system load, and adapt to complex scenarios such as algorithm plug-in chains and business pipelines. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating the composition of the plug-in management system provided in an embodiment of this application.

[0019] Figure 2 A flowchart illustrating the plugin invocation process provided in this application embodiment.

[0020] Figure 3 This is a flowchart illustrating the distributed plugin invocation process provided in an embodiment of this application.

[0021] Figure 4 A flowchart illustrating the full lifecycle review process for plugins provided in this application embodiment.

[0022] Figure 5 A flowchart for plug-in installation management provided in this application embodiment.

[0023] Figure 6 A schematic diagram of the unified management interface provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Figure 1 This is a system architecture diagram provided for an embodiment of this application. This embodiment of the application provides a distributed, dual-interface-isolated, and permission-controlled plugin management system, including an interface isolation layer, a core management layer, a distributed communication layer, a security and permission layer, a plugin execution layer, and a three-terminal business layer; The interface isolation layer contains logically isolated function management interfaces and function implementation interfaces; the function management interface is used to receive management instructions for plugin configuration, permission settings, attribute modification, and state switching; the function implementation interface is used to receive business instructions for plugin operation, invocation, and data interaction. The core management layer includes a plugin management module, a policy management module, and a general control module. The plugin management module is used to maintain the memory-resident table, as well as perform plugin lookup, on-demand loading, unloading, status monitoring, and full lifecycle maintenance. It also configures idle timers to monitor plugin call status and manage plugin validity periods. The policy management module is used to store and execute plugin selection rules and plugin call rules. The general control module is used to uniformly manage the common attributes of all plugins. The distributed communication layer includes a plugin management middleware and a communication middleware; the plugin management middleware is used to manage plugins in layers according to business type and is equipped with a multi-language interface adaptation layer; the communication middleware is used to complete data forwarding across terminals and network segments based on address information. The security permission layer includes a development review unit, an installation review unit, an operation review unit, and an expiration management unit. The development review unit, installation review unit, and operation review unit are used to review the plugin development, installation, and operation processes, respectively, while the expiration management unit is used to control the usage period of the plugin. The plugin execution layer is used to display various functional plugins and provide a centralized operation entry point; The three-terminal business layer includes the plugin development end, the plugin server end, and the plugin application end. The three ends work together to complete the plugin development, review, storage, distribution, installation and operation.

[0026] For example, in the interface isolation layer, the function management interface and the function implementation interface are independent of each other at both the physical link and logical link levels. The function management interface only handles various control commands, while the function implementation interface only handles plug-in operation and data interaction commands. The data flow of the two types of interfaces is independent of each other, and no command cross-processing occurs.

[0027] The interface isolation layer serves as the entry point for external system interactions, architecturally isolating plugin management logic from business operation logic. All operation commands related to plugin configuration, permission adjustment, attribute editing, and start / stop status switching are uniformly received and processed by the function management interface, which does not participate in any plugin business execution process. Conversely, all business commands triggering plugin startup, function calls, and data transmission / reception are handled solely by the function implementation interface. These two types of interfaces operate independently, with no data cross-referencing, avoiding task blocking and logic conflicts caused by a single interface handling both types of commands simultaneously, making it particularly suitable for high-concurrency scenarios.

[0028] Furthermore, the plugin management module records loaded plugin information through a memory-resident table. When a plugin invocation request is received, it determines whether to dynamically load the target plugin based on the recorded results. After the plugin is loaded, an idle timer is started. If the plugin is not invoked within the idle time, it is automatically unloaded from memory. At the same time, the plugin's validity period is monitored in real time and its status is updated accordingly.

[0029] In the embodiments of this application, the memory-resident table records information such as the plugin identifier, loading time, and running status of plugins currently loaded into memory in real time. Upon receiving an external plugin call request, the module first searches the memory-resident table. If no corresponding plugin is found, it automatically performs a dynamic on-demand loading operation. If the plugin is already loaded, it directly responds to the call request. Each time a plugin completes a call, the idle timer resets. When the plugin's continuous idle time reaches a system-preset threshold, the module automatically unloads the plugin from memory to release system resources. Simultaneously, the module continuously verifies the validity period of each plugin. Once a plugin reaches its expiration date, its status is immediately updated, restricting further calls to the plugin and achieving basic state management throughout its entire lifecycle. The execution flow is as follows: Figure 2 As shown.

[0030] Furthermore, the strategy management module has built-in plugin selection and plugin invocation strategies, which can select the plugin to be executed based on interface type, plugin priority, and system load, and supports serial, parallel, and mixed execution of plugins.

[0031] Specifically, the strategy management module has multiple pre-stored switchable execution strategies. Upon receiving a plugin call request, it first selects the target plugin that best suits the current business based on the current interface type, the preset priorities of each plugin, and the real-time load of the entire system. For algorithm plugin chains with sequential execution order and complex pipeline-style businesses, a serial execution method is adopted; for multiple independent plugin tasks without logical dependencies, a parallel execution method is adopted; for complex scenarios that have both sequential requirements and independent tasks, a hybrid execution method is enabled to flexibly match diverse business operation needs.

[0032] Furthermore, the general control module unifies the common attributes of all plugins, including message reminder methods, scenario modes, and global function switches. The general control module can perform unified batch configuration of the common attributes of all plugins.

[0033] Specifically, the general control module can aggregate the common configuration items of all plugins within the system, eliminating the need to configure each plugin individually. Administrators can use this module to uniformly set all plugin message reminder rules, operating scenario modes, and global function master switches at once, greatly simplifying batch management operations and solving the problems of scattered configuration entry points and cumbersome repetitive operations in traditional solutions.

[0034] Furthermore, the plugin management middleware manages plugins in layers according to business types such as device, UI (user interface), and data, and configures a multi-language interface adaptation layer. The communication middleware distinguishes between local and remote nodes based on the deployment address of the target plugin, and forwards data for requests across IPs, terminals, and network segments. During the forwarding process, only the raw data is transmitted, and no business data is parsed.

[0035] Specifically, the plugin management middleware categorizes plugins within the system into different levels based on their business purpose, such as device, UI interface, and data processing, facilitating rapid retrieval and scheduling. Its multi-language interface adaptation layer ensures compatibility with plugins developed in different programming languages, expanding the system's plugin integration capabilities. When a plugin interaction request is generated, the communication middleware extracts the target plugin's IP address from the request to distinguish between local and remote nodes: for local nodes, request routing and forwarding are directly completed; for remote nodes, data transmission across IP addresses, terminals, and network segments is completed. The entire forwarding process only transmits the original business data as is, without interpreting or modifying the data content, ensuring complete transparency of the distributed call process to the upper-layer business. The execution flow is as follows: Figure 3 As shown.

[0036] Furthermore, the development review unit reviews plugin development requests, resource usage permissions, and data access scope; the installation review unit verifies the plugin installation permissions corresponding to the current user; the operation review unit verifies the legality of plugin operation permissions and data operation behavior in real time; and the validity period management unit works with the plugin management module to control the usage period of plugins.

[0037] Specifically, the security permission layer covers the entire security verification process for plugins, from development to operation. During plugin development, the development review unit verifies the developer's development requests, the system resource permissions required by the plugin, and the data access scope, blocking non-compliant development applications. During plugin installation, the installation review unit verifies the authorization scope of the current user, distributing legitimate plugin installation packages only to users with the corresponding permissions. During plugin operation, the operation review unit monitors the plugin's invocation behavior and data read / write operations throughout the process, immediately intercepting any illegal invocations or unauthorized data access. The expiration management unit works in conjunction with the plugin management module to continuously monitor plugin usage timelines, coordinating to change the status and restrict the use of expired plugins, comprehensively preventing security risks from malicious plugins and unauthorized operations. The execution process is as follows: Figure 4 and 5 As shown.

[0038] Furthermore, the plugin execution layer displays the plugin name, plugin unique identifier, and plugin running status in a list format. The plugin running status is divided into four categories: enabled, disabled, not installed, and expired. The plugin execution layer integrates one-click on / off, uninstallation, and independent configuration functions for individual plugins.

[0039] Specifically, the plugin execution layer provides users with a visual operation interface, such as... Figure 6 As shown, the interface displays basic information for all registered plugins in a list format. Plugin status is clearly categorized into four types: enabled, disabled, not installed, and expired, making the status readily apparent. Users can perform quick operations such as batch enabling, batch disabling, and batch uninstalling of plugins on this list interface. They can also access a dedicated configuration page for a specific plugin to customize parameters, balancing management efficiency with personalized usage needs.

[0040] Furthermore, the functional plugins deployed in the plugin execution layer include at least one of the following: device plugins, UI plugins, communication plugins, algorithm plugins, tool plugins, and business plugins.

[0041] Specifically, the plugin execution layer is equipped with various types of functional plugins, which can be flexibly combined and used according to actual business scenarios. Among them, the device plugin is used to connect to various terminal devices to complete data collection, the UI plugin is responsible for interface display and human-computer interaction, the communication plugin is responsible for data transmission-related functions, the algorithm plugin implements various calculation logics, the tool plugin provides auxiliary functions, and the business plugin carries the core business processes. All kinds of plugins work together to support the operation of the system.

[0042] Furthermore, the plugin development side is used to complete plugin writing and debugging, and submit plugin development permission requests; the plugin server side, as the core control node, is responsible for plugin registration, storage, multi-level review, permission file management, and plugin package distribution; the plugin application side initiates plugin installation and invocation requests according to business scenarios, and runs plugins within the scope of permissions.

[0043] Specifically, the plugin development side is the platform for plugin creation. Developers complete plugin code writing and functional debugging here. After plugin development is complete, they simultaneously submit development permission applications and the finished plugin to the plugin server. The plugin server is the core of the entire system's management and control. It registers received plugin information and conducts multi-level compliance reviews. After approval, the plugin is stored in the plugin repository for unified storage. It also maintains various permission files and distributes plugin packages according to user permissions. The plugin application side is geared towards the end-user scenario. Staff browse the list of available plugins based on actual business needs and initiate installation or invocation requests. All plugin-related operations are strictly performed within the scope of their authorized permissions.

[0044] The system operation flow of this application is as follows: 1. Plugin call process.

[0045] The plugin application initiates a plugin call request through the function implementation interface, carrying the plugin's unique identifier, call parameters, and business data. Upon receiving the request, the plugin management module first parses the relevant information and, in conjunction with the security and permission layer, performs preliminary verification of the plugin's legality, execution permissions, and validity period. Then, it searches the memory-resident table to determine if the target plugin is already loaded; if not, it performs a dynamic loading operation. Next, the policy management module matches the corresponding plugin selection policy and execution mode, controls the plugin to complete its function execution, and sends the results back to the plugin application. After the plugin completes execution, an idle timer starts; once the preset idle time is reached, the plugin management module automatically uninstalls the plugin.

[0046] 2. Distributed plugin invocation process.

[0047] The source plugin encapsulates its source plugin identifier, target plugin identifier, target plugin deployment IP, and the data to be transmitted before initiating a request. The plugin management middleware determines whether the target is a local node based on the IP address. If it is a local node, the request is directly forwarded to the corresponding plugin; if it is a remote node, the communication middleware handles the cross-node data forwarding. After receiving the data, the target node's communication middleware forwards it to the local plugin management middleware, which then routes it to the target plugin to execute the task. The final execution result is returned along the original transmission path.

[0048] 3. Plugin lifecycle management process.

[0049] During the development phase, the plugin developer submits a request for development permissions and the finished plugin. The plugin server completes the review through the development review unit. After the review is passed, the plugin identifier and permission file are assigned.

[0050] During the release phase, the plugin developer uploads the final version of the plugin, and the plugin server performs a second review before storing the plugin in the plugin library.

[0051] During the installation phase, the plugin application requests a list of plugins, and the plugin server pushes the corresponding list based on the user's permissions. After the user selects the plugin to install, the installation review unit completes permission verification and distributes the plugin package, and the plugin application completes the installation and registration.

[0052] During the runtime phase, the plugin works normally according to the aforementioned call process, while being subject to permission and timeliness control throughout the process.

[0053] During the destruction phase, users can manually uninstall plugins, or the system can automatically disable expired plugins and clean up resources.

[0054] 4. Unified management process.

[0055] Users can access the unified management interface of the plugin execution layer and perform batch start / stop and batch uninstallation of plugins through a list. Based on the general control module, users can perform batch configuration of common attributes for all plugins, or access the configuration page of a specific plugin to complete personalized parameter settings for that plugin.

[0056] Example The plugin server deploys a plugin management application, a permission management module, and a plugin library, handling review, storage, and distribution. Terminal A, as the plugin application, runs a device plugin to collect industrial equipment data; Terminal B, as another plugin application, runs a UI plugin to visualize the data. After Terminal A initiates a data collection request, the device plugin is loaded on demand and collects device data, then sends a cross-terminal data request carrying Terminal B's IP address. The distributed communication layer handles cross-network segment data forwarding, and Terminal B's UI plugin loads and displays the data on demand. When the monitoring interface is closed, the UI plugin enters an idle state and is automatically unloaded from memory after a timeout. The entire process of plugin development, installation, and operation undergoes multi-level security and permission layer review to ensure data and system security.

[0057] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0058] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A distributed, dual-interface isolated, and permission-controlled plugin management system, characterized in that, It includes an interface isolation layer, a core management layer, a distributed communication layer, a security and permission layer, a plugin execution layer, and a three-terminal business layer; The interface isolation layer includes logically isolated function management interfaces and function implementation interfaces; The function management interface is used to receive management instructions for plugin configuration, permission settings, attribute modification, and state switching; the function implementation interface is used to receive business instructions for plugin execution, invocation, and data interaction. The core management layer includes a plugin management module, a strategy management module, and a general control module. The plugin management module is used to maintain the memory-resident table, as well as perform plugin lookup, on-demand loading, unloading, status monitoring, and full lifecycle maintenance. It also configures an idle timer to monitor the plugin call status and manage the plugin's validity period. The strategy management module is used to store and execute plugin selection rules and plugin invocation rules; the general control module is used to uniformly manage the common attributes of all plugins. The distributed communication layer includes a plugin management middleware and a communication middleware; the plugin management middleware is used to manage plugins hierarchically according to business type and is equipped with a multi-language interface adaptation layer; the communication middleware is used to complete data forwarding across terminals and network segments based on address information; The security permission layer includes a development review unit, an installation review unit, an operation review unit, and an expiration management unit; the development review unit, the installation review unit, and the operation review unit are respectively used to review the plugin development, installation, and operation stages, and the expiration management unit is used to control the usage period of the plugin; The plugin execution layer is used to display various functional plugins and provide a centralized operation entry point; The three-terminal business layer includes a plugin development terminal, a plugin server terminal, and a plugin application terminal. The three terminals work together to complete plugin development, review, storage, distribution, installation, and operation.

2. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The function management interface and the function implementation interface are independent of each other at both the physical link and logical link levels.

3. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The plugin management module records loaded plugin information through the memory resident table. When a plugin call request is received, the plugin management module determines whether to dynamically load the target plugin based on the recorded results. After the plugin is loaded, an idle timer is started. If the plugin is not called after the idle time exceeds the time limit, the plugin is automatically unloaded from memory. At the same time, the plugin validity period is monitored in real time and the plugin status is updated.

4. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The plugin management middleware manages plugins in layers according to the business types of devices, UIs, and data, and configures a multi-language interface adaptation layer. The communication middleware distinguishes between local nodes and remote nodes based on the deployment address of the target plugin, and forwards data for requests across IPs, terminals, and network segments, transmitting only the original data during the forwarding process.

5. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The development review unit reviews plugin development requests, resource usage permissions, and data access scope. The installation verification unit verifies the plugin installation permissions corresponding to the current user. The operation audit unit verifies the legality of the plugin's running permissions and data operation behavior in real time; The validity period management unit works in conjunction with the plugin management module to control the usage period of plugins.

6. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The strategy management module has built-in plugin selection and plugin invocation strategies, which can select the plugin to be executed based on interface type, plugin priority and system load, and supports serial, parallel and mixed execution of plugins.

7. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The general control module uniformly collects the common attributes of all plugins. These common attributes include message reminder methods, scenario modes, and global function switches. The general control module can uniformly batch configure these common attributes of all plugins.

8. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The plugin execution layer displays the plugin name, plugin unique identifier, and plugin running status in a list format. The plugin running status is divided into four categories: enabled, disabled, not installed, and expired. The plugin execution layer integrates one-click on / off, uninstallation, and independent configuration functions for single plugins.

9. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The plugin development client is used to complete plugin writing and debugging, and submit plugin development permission requests; The plugin server is responsible for plugin registration, storage, multi-level review, permission file management, and plugin package distribution; the plugin application initiates plugin installation and invocation requests according to business scenarios and runs plugins within the scope of permissions.

10. The distributed, dual-interface isolated, and permission-controlled plugin management system according to claim 1, characterized in that, The functional plugins deployed in the plugin execution layer include at least one of the following: device plugins, UI plugins, communication plugins, algorithm plugins, tool plugins, and business plugins.

Images