WO2012037818A1 - Method and device for deploying and loading plug-ins - Google Patents

Abstract

A method and a device for deploying and loading plug-ins are provided. The method includes: grouping the loading plug-ins, establishing the plug-ins deploying file of the plug groups, the plug-ins groups are used to deploy the loaded group to the process. The deploying analyzing module calculates the plug-ins group dependent tree based on the plug-ins deploying file and the dependent relationship of the plug-ins groups. The program entrance module obtains the process name of a process and starts the process. The plug-ins loading module loads the plug-ins based on the plug-ins group dependent tree and the process. In the solution, plug-ins are loaded by groups, the distributed management is supported, the working directory of the process is isolated from the directory of the program, and the program files can be shared by the processes of different functions.

Description

 Method and device for plug-in deployment and loading

 The invention relates to a loading technology of a software plug-in, in particular to a method and a device for deploying and loading a plug-in. Background technique

 In large-scale software development, in order to facilitate the function expansion of the software, high cohesion within the module, low coupling between modules; in order to achieve the customizable function of the release software, plug-in development is often used, and the functions are packaged one by one. Implemented in the plugin, there are many types of plugins, that is, the plugin interfaces are different, and for the convenience of processing, these different interfaces can be derived from the same base interface.

 In the integrated network management, various professional network products need to be managed, and each professional network product has many kinds of devices, and the characteristics of the professional network are also different. Due to the difference between different devices, one network management has to manage tens of thousands. The metering device requires multiple processes and distributed management. Since the functions required for different processes are also different, providing a software architecture to develop such a large network management and managing different professional networks becomes a problem that we need to solve. Summary of the invention

 The object of the present invention is to provide a plug-in deployment and loading method and device, which utilizes a large software plug-in group management, a process sharing program directory, a distributed in-process plug-in deployment and a plug-in loading method, and solves different professional networks of large network management. The problem.

 According to an aspect of the present invention, a plug-in deployment and loading method is provided, including the following steps:

 A. Group the plugins to be loaded;

B. Establish a plug-in deployment file for the deployment process to load the grouped plug-in group; c. The deployment file analysis module calculates the plug-in group dependency tree according to the plug-in deployment file and the dependency relationship of the plug-in group;

 D, the program entry module obtains the process name of the process, and starts the process;

 E. The plugin load module loads the plugin by process according to the plugin group dependency tree.

 According to another aspect of the present invention, a plug-in deployment and loading apparatus is provided, including: a plug-in grouping module, configured to divide a plug-in to be loaded into a plug-in group suitable for loading by a process;

 The plug-in deployment module is configured to establish a plug-in deployment file for the deployment process to load the plug-in group; and a deployment file analysis module, configured to calculate the plug-in group dependency tree according to the plug-in deployment file and the dependency relationship of the plug-in group;

 a program entry module, configured to acquire a process name of the process, and start a process;

 A plugin load module for loading plugins by process according to the plugin group dependency tree.

 Compared with the prior art, the present invention has the following advantages: The present invention supports distributed management by means of a plug-in in a grouping manner, and separates a process working directory from a program directory, and implements sharing of program files by different functional processes. DRAWINGS

 1 is a schematic flow chart of a plug-in deployment and loading method provided by the present invention;

 2 is a schematic structural diagram of a plug-in deployment and loading device provided by the present invention;

 3 is a schematic diagram of grouping of network management plug-ins provided by an embodiment of the present invention;

 4 is a schematic diagram of a process startup process and an analysis command line acquisition process name provided by an embodiment of the present invention;

 FIG. 5 is a structural diagram of a software publishing directory provided by an embodiment of the present invention. detailed description

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings, The preferred embodiments illustrated are for illustrative purposes only and are not intended to limit the invention. FIG. 1 is a schematic flowchart of a plug-in deployment and loading method provided by the present invention, as shown in FIG. 1:

 Step 101: Group the plugins to be loaded.

 Before this step, the method further includes: defining a plug-in interface: establishing a base extension point interface of the program and a plug-in base extension point interface instance function of the base extension point interface; establishing a derived interface derived from the base extension point and the derived interface Plugin derived interface instance function; Define the description file format of the plugin: Define the plugin ID, plugin interface type and plugin library name.

 According to the product function, the plug-in products can be divided into product plug-in units (PPU), PPU is the top-level group, and there are multiple plug-in management units (PMUs) under one PPU. There are multiple plug-in function groups (PMU Function) under the PMU. There are multiple plugins or data files under the group. These plugin function groups can have cross plugins and data files.

 Step 102: Create a plug-in deployment file, in which the deployed plug-in group to be loaded by the process is deployed, and a process may have multiple deployment files, and the process loads the plug-ins according to the union of the files.

 Step 103: The deployment file analysis module calculates the plug-in group dependency tree according to the plug-in deployment file and the dependencies of the plug-in group.

 Step 104: The program entry module starts the process by analyzing the command line function to obtain the process name of the process.

 In addition, the program entry module needs to create the plugin factory interface, create a context interface, and then parse the plugin deployment file, the property data file, and the plugin group dependency tree.

 Before this step, it also includes: Establishing an attribute data file, which is a set of name value pairs required to define the process during startup or operation. These attribute files are hierarchical, and multiple layers can be defined as needed.

Step 105: The plugin loading module loads the plugin by process according to the plugin group dependency tree. There are two ways to load a plugin: some plugins are loaded during the process startup, or plugins are loaded on demand during the run. 2 is a schematic structural diagram of a plug-in deployment and loading apparatus provided by the present invention. As shown in FIG. 2, the apparatus includes a plug-in definition module, a plug-in grouping module, a plug-in deployment module, a deployment file analysis module, a program entry module, an attribute data module, and The plugin loads the module. among them,

 The plugin definition module includes a plugin base extension point definition unit, a plugin derived interface definition unit, and a plugin description file definition unit; wherein

 The plug-in base extension point definition unit is used to establish a program base extension point interface and an instance function of the base extension point interface.

 A plug-in derived interface definition unit that is used to build a derived interface derived from the underlying extension point interface and an instance function of the derived interface.

 A plug-in description file definition unit that defines a description file format of the plug-in, including: a plug-in ID, a plug-in interface type, and a plug-in library name.

 A plug-in grouping module, configured to divide the plug-in to be loaded into a plug-in group suitable for loading by process. A plug-in deployment module that is used to establish a plug-in deployment file for the deployment process to load a plug-in group. The deployment file analysis module is configured to calculate a plug-in group dependency tree according to the plug-in deployment file and the dependencies of the plug-in group.

 a program entry module, configured to acquire a process name of the process, start a process, and establish a plug-in factory interface for managing a plug-in base extension point interface instance function and a plug-in derived interface instance function, and establishing a context interface describing the runtime environment, and parsing the plug-in deployment Files, attribute data files, and plug-in group dependency trees.

 An attribute data module that defines the attribute data file for the process to start and run the required name-value pairs. A plugin load module for loading plugins by process according to the plugin group dependency tree.

FIG. 3 shows a grouping diagram of the network management plug-in provided by the embodiment of the present invention. As shown in FIG. 3, the top layer has two PPUs, bn.ppu and uca.ppu, and bn.ppu has bn-core-c.pmu, bn- Necommon-c.pmu and bn-res.pmu multiple PMUs, multiple plug-in function groups PMUFunction under each PMU, such as bn-res.pmu there are two functional groups osf and emf, each containing some directories, and There is a common directory common, and there are some numbers in the same directory as common. According to files, plugins and description files, the same level of dll is a normal dynamic library.

 Here is only an example of a plug-in grouping in a specific embodiment, wherein the name is some code number, the ratio bn represents the company's network, the uca represents the unified public application, and the bn-necommon-c represents the bearer network element common module. Bn-res indicates the bearer network resource module, osf indicates the operating system function, and emf indicates the network element mediation function.

4 is a schematic diagram of a process startup process and an analysis command line acquisition process name provided by an embodiment of the present invention. As shown in FIG. 4, a program entry module first creates a plugin factory interface, and then creates a context interface, in a context initialization plugin function. Create a local system interface ILocalSystem, the local system interface is responsible for analyzing the deployment and loading the launch plugin. The plugin factory interface IExtensionService, the context interface IContext, and the local system interface ILocalSystem must have one instance for each process. Under procs is the program and data files. Under the works, there are some corresponding directories of the process. There are some subdirectories under the corresponding directory of the process, such as l ₀ g directory to store the logs generated during the running process, and deploy to store the plug-ins. Deployment files and attribute data files.

 The requirements of the unified network management are described below with reference to FIG. 1 to FIG. 3.

 (1) Source of demand.

 In a unified network management system, devices of various product lines need to be managed in one network management system. Each product line has multiple types of devices, and the difference between the devices is large. Managing devices in multiple product lines in a single network management system saves resources and facilitates unified management. In the case of a large number of devices, distributed management is required.

 (2) Development platform.

 Self-adapted communication environment ACE (ADAPTIVE Communication Environment), compiler vc7 or gcc, supports multiple operating systems such as Win32, Solaris and Linux.

 (3) Implementation of plug-in development.

First, define the base extension point. Class IExtension {

 Public:

 IExtension(const char* version = "VI.0");

 Virtual ~IExtension(){ }

 Virtual int Init(int argc, char *argv[]);

 Virtual int Finish ();

 Virtual void SetVersion(const char* version);

 Virtual const char* GetVersion();

 Virtual void ProcessDebugCommand(std::string& cmd, :: StringList& paras, std::ostream&os);

 Private:

 _STD_ string m_strVersion;

Init initializes the plugin based on the process startup parameters. Finish is used to clean up the extension point before it is destroyed, such as closing the handle and freeing the memory. GetVersion and SetVersion are used to set the plugin version. ProcessDebugCommand is a method that supports command line adaptation, similar to the basic functions to add functions as needed.

 Plugin base extension point instance creation function IExtension *Create_Extension (const char* path, CProperties* properties) is the only export function of the plugin dynamic library pair, create an instance of the plugin base extension point, path is the directory path where the plugin is located, properties is The name-value pair of the plug-in property, the function returns the extension point pointer.

The name of the plugin uses '., split string, such as ican.context.localservice.log to indicate a plugin id, ican. context. localservice indicates that it is an ILocalService corresponding plugin, and its sub-plugin is represented by the extension of the plugin id. For example, ican.context.localservice.log.xxplg means ican. context. localservice sub-plugin, this id is a bit long, you can use the alias method to simplify the plugin id, such as log can be used as ican.context.localservice.log 々 another ll name . The plugin description file is defined by an xml file. The file defines the plugin ID, the version, the name of the corresponding dll, etc. It is also possible to stipulate that a certain type of sub-plugin is loaded by its parent plugin.

 Next, define the local service provider interface ILocalService, the service interface IServant and the IServant local or remote proxy IService interface, these interfaces are derived from lExtension, these plug-ins implement the specific functions of the network management, so there are many of these plug-ins, if necessary Some other plugin interfaces can be defined. The main methods of these three interfaces are given below:

 (1) ILocalService provides services to this process module:

 Virtual void PreInit(IContext* ctx)

 Virtual IDefaultContext* GetCtx(void)

 Among them, Prelnit is used to set the context, and GetCtx is used to get the context.

 (2) IServant provides services to the process or remote process. The service provision is mainly implemented by Get and Set:

 Virtual void PreInit(IContext* ctx)

 Virtual CMsg* Get (CMsg & msgbuf, CMsgHead & headinfo)

 Virtual void Set (CMsg & msgbuf, CMsgHead& headinfo)

 Prelnit is used to set the context, Get is the response message processing function, CMsg is the message, headinfo is the command code and the user header information, and Set is the non-response message processing function.

 (3) The client can call IServant's Get and Set through IService, and IContext::HasServant can determine whether the servant is local.

 Virtual void PreInit(IContext* ctx, const char* servantName)

 Virtual void SetServant(IIcanServant* servant)

 Virtual CMsg* Get(CMsg & msgbuf,CMsgHead& headinfo)

 Virtual void Set(CMsg & msgbuf,CMsgHead& headinfo)

 Prelnit is used to set the context and the name of the corresponding IServant servantName , SetServant is used to set the name of the corresponding IServant, Get is the response message processing function, and Set is the non-response message processing function.

Then, define the plugin grouping, divide into multiple PPUs according to product functions, and PPU is the top group, one There are multiple PMUs under one PPU, and there are multiple PMUFunctions under one PMU. The PPU corresponds to a directory, and the PMU corresponds to a subdirectory under the PPU. A plugin function group can contain multiple directories of the PMU. Each directory has multiple plugins or data files. These plugin function groups may have cross directories. Dependencies on other functional groups are also defined in PMUFunction.

 Redefine the process deployment, deploy the definition in the file of the process working directory, there can be more than one file, and the deployment definition file is used to define which PMUFunctions are deployed by the process.

 Then define the IContext and IExtensionService interfaces, which can be derived from IExtension. Includes:

 (1) Define the method of IExtensionService:

 Virtual IExtension* CreateExtension(const char* extName, bool isSingleton);

 Virtual void DestroyExtension(IExtension *pcExtension) = 0;

 Virtual StringList GetExtensions(const char* pcSubject) = 0;

 CreateExtension creates a base extension point instance named extName as a singleton. DestroyExtension destroys the extension point. GetExtensions gets all the child plugins of the principal pcSubject, that is, the partial prefix of the plugin ID split by V.

 (2) IContext creates and runs the context of the plugin in a process: virtual void PreInit(IExtensionService*)

 Virtual ILocalService* GetLocalService(const char* extName, const char* strpmufunc);

 Virtual IServant* GetServant(const char* extName, const char* strpmufunc);

 Virtual IService* GetService (const char* extName, const char* strpmufunc);

 Virtual IExtensionService* GetExtService();

Virtual bool HasServant(const char* extName, const char* strpmufunc); Prelnit is used to set the plugin factory. GetLocalService gets the plugin function group strpmufunc The ILocalService named extName, strpmufunc is NULL, where the lookup scope is all PMUs of the process. GetServant gets the IServant named extName under the plugin function group strpmufunc. GetService gets the IService named extName under the plugin function group strpmufunc. HasServant determines whether the process plugin function group strpmufunc has an IServant named extName. GetExtService gets the plugin factory.

 Subsequently, ILocalSystem is derived from ILocalService, which is the process deployment analysis and plug-in group analysis module. It reads the name value pairs in the process attribute data file, and analyzes which plug-in groups and plug-in group dependency trees are deployed in this process. In this embodiment, Analyze which functional groups PmuFunction and their dependency trees are deployed. The leaf nodes in the dependency tree have dependencies on the parent nodes. Then, the plugins are loaded from the tree ^=艮 node layer to the leaf nodes. The plugins under the same PMUFunction can be named by directory or plugin. Define the order of loading. Some principles are agreed to load certain types of plugins when the program starts, and some types of plugins are loaded as needed. For example, in this embodiment, plugins with IServant extension points are loaded at startup.

 After implementing the above interface functions or plug-ins, release the software. Plug-ins and dlls are placed in the Procs directory according to the PPU and PMU sub-directories. PMUFunction contains those directories and plug-ins. Each function group corresponds to an xml description file. The Works directory is defined at the same level as Procs. The works directory is some process directories. Some data files related to the process, such as process deployment files and attribute data files.

 Finally, the program entry module specifies the process name through the program's command line, and the process's working directory is known by the process name, so that the process entry module can load different processes. Create IContext and IExtensionService, pass the process working directory to ILocalSystem, ILocalSystem is responsible for loading the plug-ins needed for startup according to the deployment, and directly calling IContext to load the plug-ins on demand.

In addition, various possible changes or substitutions may be made according to the description and specific embodiments of the technical solutions of the present invention, such as IContext and IExtensionService merge, the description file does not use the xml format, the basic extension point interface adds or reduces some methods, or Process-oriented language The structure and function pointers implement the interface.

 In summary, the present invention has the following technical effects: 1. A group management plug-in, which facilitates management of plug-ins by large software. 2. The plug-in id and type can be defined by files. 3, has a unified plug-in interface, easy to create extension points. 4. Support distributed deployment. 5. The process working directory and the program directory are separated, so that multiple processes can share program files. 6, support process-related attribute name value pairs, to facilitate the definition of process variables. 7, because of the use of object-oriented interface mechanism, has a high degree of abstract processing power. In addition, the methods themselves are generic, independent of the specific operating system and specific object-oriented languages, and even implemented in structured languages.

 Although the invention has been described in detail above, the invention is not limited thereto, and various modifications may be made by those skilled in the art in accordance with the principles of the invention. Therefore, modifications in accordance with the principles of the invention should be understood as falling within the scope of the invention.

Claims

Claim  A plug-in deployment and loading method, comprising the steps of:  A. Group the plugins to be loaded;  B. Establish a plug-in deployment file for the deployment process to load the grouped plug-in group; C. Calculating a plug-in group dependency tree according to the plug-in deployment file and the dependency relationship of the plug-in group;  D, obtain the process name of the process, start the process; and,  E. Load the plugin according to the process according to the plugin group dependency tree.  The plug-in deployment and loading method according to claim 1, wherein before the step A, the method further comprises:  Establishing a base extension point interface for adding a plugin implementation basic function and a plugin base extension point interface instance function of the base extension point interface;  Establishing a corresponding derived interface for managing different types of plugins and a plugin derived interface instance function derived from the derived interface derived from the base extension point;  Define the type of the plugin interface.  3. The plug-in deployment and loading method according to claim 1, wherein before the step D, the method further comprises: establishing an attribute data file for defining a name-value pair required for starting and running the process. .  The plug-in deployment and loading method according to claim 3, further comprising: between the step D and the step E,  Establishing a plugin factory interface for managing the plugin base extension point interface instance function and the plugin derived interface instance function;  Establish a context interface to describe the runtime environment; and,  Parsing the plugin deployment file, the attribute data file, and the plugin group dependency tree. 5. A plug-in deployment and loading device, comprising: a plug-in grouping module, configured to divide the plug-in to be loaded into a plug-in group suitable for loading by process;  a plug-in deployment module, configured to establish a plug-in deployment file of the plug-in group to be used by the deployment process, and a deployment file analysis module, configured to calculate a plug-in group dependency tree according to the plug-in deployment file and the dependency relationship of the plug-in group;  a program entry module, configured to acquire a process name of the process, and start a process; and, a plug-in loading module, configured to load the plug-in according to the process according to the plug-in group dependency tree. The plug-in deployment and loading apparatus according to claim 5, further comprising: a plug-in definition module, configured to define a plug-in base extension point interface, a derived interface; an instance function of the plug-in base extension point interface An instance function of the derived interface and a type of the plugin interface.  The plug-in deployment and loading device according to claim 6, wherein the plug-in definition unit comprises:  a plug-in base extension point definition unit, configured to establish a base extension point interface for adding a plug-in implementation basic function and a plug-in base extension point interface instance function of the base extension point interface;  a plug-in derived interface definition unit for establishing a plug-in derived interface instance function for managing a corresponding derived interface of the different types of plug-ins and the derived interface derived from the base extension point;  A plugin description file definition unit for defining a type of the plugin interface.  8. The plug-in deployment and loading device of claim 5, wherein the device further comprises:  An attribute data module that defines the attribute data file for the process to start and run the required name-value pairs. The plug-in deployment and loading apparatus according to claim 8, wherein the program entry module is further configured to establish a plug-in factory that manages the plug-in base extension point interface instance function and the plug-in derived interface instance function. An interface; establishing a context interface describing the runtime environment, and parsing the plugin deployment file, the attribute data file, and the plugin group dependency tree.