Function item definition and application method and system based on declaration and registration mechanism
Through the method of defining and application of function items based on declaration and registration mechanism, the maintainability and flexibility problems in function menu maintenance and extension are solved, the decoupling and efficient management of function items are realized, and the flexibility of the system is improved. and maintainability.
Patent Information
- Application Number
- CN202411405856.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-10
- Publication Date
- 2025-02-11
AI Technical Summary
The prior art has problems with poor maintainability, poor flexibility and waste of resources in the maintenance and expansion of functional menus. Especially when functional menus become complicated, it is difficult to achieve efficient management and maintenance.
Using the method of function item definition and application based on the declaration and registration mechanism, the attributes and dependencies of the function item are declared through the Packfile file, and combined with the sidecar component to handle the function item registration and status synchronization, forming a real-time function list of the function center.
Decoupling of functional items is achieved, simplifies the function iteration and deployment process, improves the flexibility and maintainability of the system, reduces resource waste, and supports high availability and flexible management of service instances.
Smart Images

Figure CN119415138A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a method and system for defining and applying function items based on a declaration and registration mechanism. Background Art
[0002] No matter what system or application you make, the ultimate goal is to achieve functions. The manifestation of functions is often achieved through function menus and function points on the interface. It is a bridge for users to interact with program functions. Whether creating documents, adjusting settings, managing data or performing other tasks, users usually need to start the corresponding operations through function menus. Function menus are important components in the background management system. The common ways to maintain their function data are hard coding and configuration files.
[0003] Hard coding is a traditional implementation method, in which the logic and data of the function menu are written directly in the background code. The advantages are simplicity, speed, and suitability for small projects or rapid prototyping. But the disadvantages are also obvious. Poor maintainability: The hard coding method makes the code difficult to maintain and expand, especially when the function menu becomes complex. Poor flexibility: Once the function menu changes, the code needs to be modified, which may lead to a lot of refactoring work. Waste of resources: Due to the need for frequent updates, this method is inefficient and may affect system performance.
[0004] Based on the configuration file approach, in this approach, the data of the function menu is managed through configuration files (such as XML, JSON, etc.). The advantages are strong readability, easy maintenance and expansion. However, there are also some disadvantages, such as security issues: configuration files may contain sensitive information, and complex configuration file management issues. As the scale of the project expands, the configuration files may become large and complex, requiring special tools or platforms to manage. In this context, a technology that simplifies the functions of complex systems is needed to solve this problem. Summary of the invention
[0005] The purpose of the present invention is to provide a method and system for defining and applying function items based on a declaration and registration mechanism to solve the problems raised in the above background technology.
[0006] To achieve the above object, the present invention provides the following technical solution: a method for defining and applying function items based on a declaration and registration mechanism, the method comprising the following steps:
[0007] Function item definition based on declaration mechanism;
[0008] Registration of functional item applications and registration of functional item services;
[0009] Handle functional item dependencies;
[0010] Function item status synchronization.
[0011] Preferably, the function item definition based on the declaration mechanism includes the following steps:
[0012] Create a function item declaration carrier Packagefile, which contains a list of system or platform function items;
[0013] Declare the basic properties of the component and the functions of the component in the Packfile. The functions are listed in the Functions array.
[0014] Define the types of function items, including static function items and dynamic function items. Static function items are accessed through the relative address within the system, while dynamic function items require cross-domain access.
[0015] Set the function route URL, function icon Icon and the service group Services attributes that the function depends on for the function item;
[0016] Organize related functional items into functional groups to display and manage a group of functional items or functional groups.
[0017] Preferably, the registration of the function item application includes the following steps: when the function item application is started, the sidecar component is used to detect whether it is the first run; when it is the first run, the Packfile file is parsed and the function item information is registered to the function center; when it is not the first run, the current version is detected to be consistent with the version registered in the function center. If not, the function item is re-registered according to the current Packfile; the message middleware is used to notify the authority management system or other subscribers of changes in the function item;
[0018] The registration of function item services includes the following steps: when the function item service is started, the sidecar component is used to detect whether it is the first instance of the service; the first instance parses the Packfile and registers the service information and status to the function center. If it is not the first instance, only the instance information is registered; the registration information includes the service name, type, version and which function items it depends on; the service status of the relevant function items in the function center is updated to ensure that the dependencies are correctly reflected.
[0019] Preferably, processing the functional item dependency relationship comprises the following steps:
[0020] In the Packfile, declare the service group that each function item depends on;
[0021] When registering a function item, check whether all dependent services have been registered and are available;
[0022] If all dependent services are available, the function item is marked as available and the permission management system is allowed to authorize it;
[0023] If there is an unregistered dependent service, the function item will be marked as unavailable and the permission management system will be prohibited from authorizing it.
[0024] Preferably, the function item state synchronization includes the following steps:
[0025] When a functional application or service is registered, updated, or deregistered, a state change event is generated through the sidecar component;
[0026] Send state change events to the message middleware so that subscribers can receive them;
[0027] The permission management system or other subscribers monitor the message middleware and receive status change events;
[0028] Based on the received state change events, the function item state information in the local cache or database is updated to ensure the consistency of the state.
[0029] A function item definition and application system based on a declaration and registration mechanism, the system comprising:
[0030] A function center is used to maintain a list of all function items of the system or platform, which serves as the original function data for permission management;
[0031] One or more services or components. Each service or component contains a Packfile file, which declares the properties of the service or component itself and its functional items. The functional items are declared in the Functions array in the Includes part of the Packfile. Each Function represents a functional item.
[0032] Function items include static function items and dynamic function items. Static function items are accessed through relative addresses within the system, while dynamic function items need to be accessed across domains and integrate the functions of other systems or subsystems.
[0033] The function item also has the function route URL, function icon Icon and the service group Services attribute on which the function depends. The function icons are divided into built-in icons and dynamic icons, which can be configured through the interface.
[0034] A functional group, as a combination of functional items or functional groups, does not have any function itself but is used to organize and manage related functional items.
[0035] Preferably, the format of the Packfile file is not limited, and includes but is not limited to the following structure:
[0036] Basic information of the component;
[0037] Functions array, used to declare the functions of the component. Each Function contains the name, type, route URL, icon, and dependent service group Services information of the function item;
[0038] As a special element of the Functions array, a function group contains sub-function items or sub-function groups.
[0039] Preferably, it also includes:
[0040] Functional application, including the user interface, its Packfile must declare Functions;
[0041] Functional services only provide services without interacting with users, and there is no need to declare Functions in their Packfile;
[0042] The sidecar component is configured in each function item application and function item service to process the business logic related to function item registration and decouple it from the function logic of the function item itself;
[0043] The function center maintains the function item table of the entire business system, receives and manages the registration information of function item applications and function item services.
[0044] Preferably, the registration process of the function item application includes:
[0045] The sidecar component detects whether it is the first run. If so, it parses the Packfile and registers the function item to the function center;
[0046] If it is not the first time to run, the sidecar component detects whether the current application version is consistent with the version registered in the function center. If they are inconsistent, the function item is re-registered according to the Packfile;
[0047] When a function item changes, the sidecar component notifies the subscriber through the message middleware to synchronize the function item status changes.
[0048] Preferably, the registration process of the function item service includes:
[0049] The sidecar component detects whether it is the first instance of the function item service. If so, it parses the Packfile and registers the service information with the function center, changing the service status to start;
[0050] If it is not the first instance, only the instance information is registered;
[0051] When a function item service is registered, it needs to be registered with multiple function items that it depends on, reflecting the dependency relationship between the function item and the service, and supporting high availability and flexible management of service instances.
[0052] Compared with the prior art, the present invention has the following beneficial effects:
[0053] The method and system for defining and applying function items based on declaration and registration mechanism proposed in the present invention, by defining function items, declare the related attributes of function items and dependent services, and form a real-time list of functions of the function center by combining function item application with function item service registration, and provide function permission data for the permission management system of the application system. Through this technical method, the decoupling of function items is realized, which greatly facilitates the function iteration, deployment and function upgrade of various large, medium and small application systems and platforms. BRIEF DESCRIPTION OF THE DRAWINGS
[0054] Figure 1 is a flow chart of the method of the present invention;
[0055] Figure 2 This is a system block diagram of the present invention. DETAILED DESCRIPTION
[0056] In order to make the purpose and technical solution of the present invention clearly and completely described, and the advantages more clearly understood, the embodiments of the present invention are further described in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, rather than all of the embodiments, and are only used to explain the embodiments of the present invention, and are not used to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0057] For example, see Figure 1 The present invention provides a technical solution: a method for defining and applying function items based on a declaration and registration mechanism, the method comprising the following steps:
[0058] 1. Functional item definition based on declaration mechanism
[0059] (1) Package file, the declaration carrier of function items
[0060] The function center maintains a list of all the function items of the system or platform, which serves as the original function data for permission management. Each service or component that needs to be registered with the function center must have a packfile file. Each packfile contains the following attributes:
[0061]
[0062] In addition to declaring the properties of the component itself, this file also declares its functional items. The parts related to the functional items are declared in the Functions array in Includes. A Function is a functional item, and the Functions array indicates that a component can have multiple functional items.
[0063] (2) Function
[0064] Each function item contains the following attributes:
[0065]
[0066]
[0067] Function group: is a group of function items or a combination of function groups, which is to combine related functions together, and does not have any function itself. Each function group can be regarded as a function tree, and the function items are regarded as the leaves of the function tree.
[0068] Static function item: the function of the system itself, which can be accessed through relative address. Taking the BS structure system as an example, there is no cross-domain function access. For example, if the current browser access address is http: / / abc.com / index.html, to access function A, you only need to access http: / / abc.com / index.html#a.
[0069] Dynamic function items: This system does not contain them itself and needs to integrate the functions of other systems or subsystems. The functions require cross-domain access. For example, if the current browser access address is http: / / abc.com / index.html, to access function B, you need to access http: / / bbc.com / index.html#b. Special instructions are required. To access function B under permission control, the abc.com system and the bbc.com system need to implement single sign-on. There are many mature technical implementation solutions for single sign-on. This technology is used in this solution, but it is not within the scope of this solution.
[0070] Function routing Url: When it is a function group, this attribute is empty. Static functions and dynamic functions are different. When it is a static function, you can use the relative address declared in the packfile. When it is a dynamic function, you need to combine the service registration address and the packfile declaration address.
[0071] Function Icon: No matter in what system, function icons are indispensable. Clearly designed icons allow users to find the corresponding functions at a glance. In the present invention, there are two types of icons, one is a built-in icon and the other is a dynamic icon. The built-in icon is the Icon attribute, which is carried by the component that declares this function. The dynamic icon refers to the icon of the function item that supports setting through the interface. In actual applications, if the built-in icon cannot meet the scene requirements, the icon can be configured by calling the setting interface of the function item. The name of each icon is named after the function code of the function.
[0072] The service group that the function depends on: When it is a function group, this attribute must be empty. Whether the function group is displayed or not does not depend on the service it depends on, but on all the function groups and function items under this function group. As long as one of the subordinates can be used, the function group can be used. When it is a function, you can also not set Services, which means that this function item does not depend on any service, that is, this is a function that can definitely be used, but if Services is set, the function item will only be available when all Services are installed. If any service that a function item depends on is not installed, this function cannot be provided for permission management configuration.
[0073] (3) Example of declaration file packfile
[0074] The present invention does not limit the format of packfile, which can be xml, json, yaml, etc. The following example takes json format as an example.
[0075] Example scenario Take the packfile of the PC-side web management interface component of an OA system as an example. In the following file structure, permission management is a functional group, which contains two functional items: user management and role management. The user management function depends on two services: xy1-manager and xy2-manager, and the role management function depends on three services: xx1-manager, xx2-manager, and xx2-search. Sort the function items by the value of Index. When displayed, user management is before role management.
[0076]
[0077]
[0078] 2. Functional items, applications and services based on the registration mechanism
[0079] We call services or components with functional items functional items applications. Functional item applications contain operating interfaces for interaction with users, and their packfiles must declare Functions. We call components that only provide services and do not interact with users functional items services, and Functions do not need to be declared in their packfiles.
[0080] Using the sidecar pattern in software design patterns, we equip each functional application and functional service with a sidecar component to specifically handle the decoupling of the business logic related to functional registration and the functional logic of the functional item itself.
[0081] (1) Function item application is registered to the function center
[0082] When the function item application is started, the sidecar component will detect whether it is the first time to run. If it is the first time to run, the sidecar component will parse the packfile and register the Function contained in the application to the function center. The function center maintains a function item table for the entire business system. This list is all the capabilities of the business system. These capabilities can be provided to the permission management system as options to authorize user roles. If it is not the first time to run, the sidecar component will detect whether the current application version is consistent with the version registered in the function center. If they are consistent, the parsing work is completed. If the versions are inconsistent, the function is re-registered according to the current component packfile. There are two cases of version inconsistency: the new version adds functions and the new version removes functions. As long as the function item changes, the sidecar component will send a message notification to the message middleware to notify the subscriber of the message that the function item of the function item application has changed.
[0083] There are many middlewares for message notifications. This solution does not limit the specific middleware used, such as RabbitMQ, ActiveMQ, RocketMQ, or KafKa.
[0084] The real-time table of function items can be stored in a variety of ways. It can use a registration center such as consul, an in-memory database such as redis, or a relational database such as mysql. There is no restriction on the way of use. This solution uses a two-dimensional table structure to illustrate the status of the function item application after registration.
[0085]
[0086] (2) Function item service is registered to the function center
[0087] A function item will depend on multiple function item services, and each function item service will start one or more running instances. The purpose of multiple instances is to achieve high availability, because as long as there is one instance available, their corresponding function items can be used. When the function item service is started, the sidecar component will detect whether it is the first instance of this function item service. If it is the first instance, the sidecar component will parse its own related information in the packfile, such as Name, PackageType, Version, etc., and register with the function center to change the service status corresponding to the function to start; if it is not the first instance, you only need to register the instance information, because the status of the service has been changed when the first instance is registered.
[0088] The registration of a function item service is different from the registration of a function item application. When a function item application is registered, the function item is implemented from scratch, while the function item service changes the state of the function item. In other words, the function item application registers the function item, while the function item service registers the dependency of the function item.
[0089] A function item can depend on multiple services, and a service can be depended on by multiple function items. There is a many-to-many relationship between them. When a function service is registered, it needs to be registered to the multiple function items it depends on.
[0090] The two-dimensional table structure is still used to describe the status of the function item service after registration.
[0091]
[0092] In the above table, because the xx2-search instance that role management depends on has no started instance, this function item cannot be provided to the permission center.
[0093] The decoupling of functions is achieved, and each function is a small unit in itself. No matter how complex the function menu of a system or platform is, they do not affect each other. When a function is needed, its corresponding components and services are deployed on demand to save resources. System upgrades and iterations are inevitable. When the system adds new functions, the function menu and permission management parts do not need to modify any code, nor do they need to add any configuration files. Just deploy the application of the new function item and the dependent services, and there will be no impact on the original functions. Especially for platforms or systems with a large number of users, new and old functions can be online at the same time and gradually replaced. Any real-time upgrade of any function will not affect system performance.
[0094] Embodiment 2, based on embodiment 1, proposes a function item definition and application system based on declaration and registration mechanism, the system comprising:
[0095] A function center is used to maintain a list of all function items of the system or platform, which serves as the original function data for permission management;
[0096] One or more services or components. Each service or component contains a Packfile file, which declares the properties of the service or component itself and its functional items. The functional items are declared in the Functions array in the Includes part of the Packfile. Each Function represents a functional item.
[0097] Function items include static function items and dynamic function items. Static function items are accessed through relative addresses within the system, while dynamic function items need to be accessed across domains and integrate the functions of other systems or subsystems.
[0098] The function item also has the function route URL, function icon Icon and the service group Services attribute on which the function depends. The function icons are divided into built-in icons and dynamic icons, which can be configured through the interface.
[0099] A functional group, as a combination of functional items or functional groups, does not have any function itself but is used to organize and manage related functional items.
[0100] The format of the Packfile is not restricted and includes but is not limited to the following structures:
[0101] Basic information of the component;
[0102] Functions array, used to declare the functions of the component. Each Function contains the name, type, route URL, icon, and dependent service group Services information of the function item;
[0103] As a special element of the Functions array, a function group contains sub-function items or sub-function groups.
[0104] Also includes:
[0105] Functional application, including the user interface, its Packfile must declare Functions;
[0106] Functional services only provide services without interacting with users, and there is no need to declare Functions in their Packfile;
[0107] The sidecar component is configured in each function item application and function item service to process the business logic related to function item registration and decouple it from the function logic of the function item itself;
[0108] The function center maintains the function item table of the entire business system, receives and manages the registration information of function item applications and function item services.
[0109] The registration process of a function item application includes:
[0110] The sidecar component detects whether it is the first run. If so, it parses the Packfile and registers the function item to the function center;
[0111] If it is not the first time to run, the sidecar component detects whether the current application version is consistent with the version registered in the function center. If they are inconsistent, the function item is re-registered according to the Packfile;
[0112] When a function item changes, the sidecar component notifies the subscriber through the message middleware to synchronize the function item status changes.
[0113] The registration process of the functional service includes:
[0114] The sidecar component detects whether it is the first instance of the function item service. If so, it parses the Packfile and registers the service information with the function center, changing the service status to start;
[0115] If it is not the first instance, only the instance information is registered;
[0116] When a function item service is registered, it needs to be registered with multiple function items that it depends on, reflecting the dependency relationship between the function item and the service, and supporting high availability and flexible management of service instances.
[0117] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A method for defining and applying function items based on a declaration and registration mechanism, characterized in that: The method comprises the following steps: Function item definition based on declaration mechanism; Registration of functional item applications and registration of functional item services; Handle functional item dependencies; Function item status synchronization.
2. The method for defining and applying function items based on a declaration and registration mechanism according to claim 1, characterized in that: The definition of function items based on the declaration mechanism includes the following steps: Create a function item declaration carrier Packagefile, which contains a list of function items of the system or platform; Declare the basic properties of the component and the functions of the component in the Packfile. The functions are listed in the Functions array. Define the types of function items, including static function items and dynamic function items. Static function items are accessed through the relative address within the system, while dynamic function items require cross-domain access. Set the function route URL, function icon Icon and the service group Services attributes that the function depends on for the function item; Organize related functional items into functional groups to display and manage a group of functional items or functional groups.
3. The method for defining and applying function items based on declaration and registration mechanism according to claim 1, characterized in that: The registration of function item applications includes the following steps: when the function item application is started, the sidecar component is used to detect whether it is the first run; when it is the first run, the Packfile file is parsed and the function item information is registered to the function center; when it is not the first run, the current version is detected to see if it is consistent with the version registered in the function center. If not, the function item is re-registered according to the current Packfile; the message middleware is used to notify the permission management system or other subscribers of changes in the function item; The registration of function item services includes the following steps: when the function item service is started, the sidecar component is used to detect whether it is the first instance of the service; the first instance parses the Packfile and registers the service information and status to the function center. If it is not the first instance, only the instance information is registered; the registration information includes the service name, type, version and which function items it depends on; the service status of the relevant function items in the function center is updated to ensure that the dependencies are correctly reflected.
4. The method for defining and applying function items based on a declaration and registration mechanism according to claim 1, characterized in that: Processing feature item dependencies involves the following steps: In the Packfile, declare the service group that each function item depends on; When registering a function item, check whether all dependent services have been registered and are available; If all dependent services are available, the function item is marked as available and the permission management system is allowed to authorize it; If there is an unregistered dependent service, the function item will be marked as unavailable and the permission management system will be prohibited from authorizing it.
5. The method for defining and applying function items based on declaration and registration mechanism according to claim 1, characterized in that: Function item status synchronization includes the following steps: When a functional application or service is registered, updated, or deregistered, a state change event is generated through the sidecar component; Send state change events to the message middleware so that subscribers can receive them; The permission management system or other subscribers monitor the message middleware and receive status change events; Based on the received state change events, the function item state information in the local cache or database is updated to ensure the consistency of the state.
6. A function item definition and application system based on a declaration and registration mechanism according to the method for defining and applying a function item based on a declaration and registration mechanism according to any one of claims 1 to 5, characterized in that: The system comprises: A function center is used to maintain a list of all function items of the system or platform, which serves as the original function data for permission management; One or more services or components. Each service or component contains a Packfile file, which declares the properties of the service or component itself and its functional items. The functional items are declared in the Functions array in the Includes part of the Packfile. Each Function represents a functional item. Function items include static function items and dynamic function items. Static function items are accessed through relative addresses within the system, while dynamic function items need to be accessed across domains and integrate the functions of other systems or subsystems. The function item also has the function route URL, function icon Icon and the service group Services attribute on which the function depends. The function icons are divided into built-in icons and dynamic icons, which can be configured through the interface. A functional group, as a combination of functional items or functional groups, does not have any function itself but is used to organize and manage related functional items.
7. A function item definition and application system based on declaration and registration mechanism according to claim 6, characterized in that: The format of the Packfile is not restricted and includes but is not limited to the following structures: Basic information of the component; Functions array, used to declare the functions of the component. Each Function contains the name, type, route URL, icon, and dependent service group Services information of the function item; As a special element of the Functions array, a function group contains sub-function items or sub-function groups.
8. A function item definition and application system based on declaration and registration mechanism according to claim 6, characterized in that: Also includes: Functional application, including the user interface, its Packfile must declare Functions; Functional services only provide services without interacting with users, and there is no need to declare Functions in their Packfile; The sidecar component is configured in each function item application and function item service to process the business logic related to function item registration and decouple it from the function logic of the function item itself; The function center maintains the function item table of the entire business system, receives and manages the registration information of function item applications and function item services.
9. A function item definition and application system based on declaration and registration mechanism according to claim 8, characterized in that: The registration process of a function item application includes: The sidecar component detects whether it is the first run. If so, it parses the Packfile and registers the function item to the function center; If it is not the first time to run, the sidecar component detects whether the current application version is consistent with the version registered in the function center. If they are inconsistent, the function item is re-registered according to the Packfile; When a function item changes, the sidecar component notifies the subscriber through the message middleware to synchronize the function item status changes.
10. A function item definition and application system based on declaration and registration mechanism according to claim 8, characterized in that: The registration process of the functional service includes: The sidecar component detects whether it is the first instance of the function item service. If so, it parses the Packfile and registers the service information with the function center, changing the service status to start; If it is not the first instance, only the instance information is registered; When a function item service is registered, it needs to be registered with multiple function items that it depends on, reflecting the dependency relationship between the function item and the service, and supporting high availability and flexible management of service instances.