A method for unified extension and management of heterogeneous systems

Abstract

The application discloses a method for unified extension and management of a heterogeneous system, which can directly solve the problem that traditional plug-in combination cannot have the same name, and directly generates a form through background data to achieve a multiplier effect. The technical scheme is as follows: the application adopts a microkernel and plug-in, sets the priority of the plug-in, solves the problem that multiple plug-ins cannot have the same name under the same type, and performs extension. A form generation mode of form-create directly generates a form through background data.

Description

Technical Field

[0001] This invention relates to a heterogeneous system technology, specifically to a method for unified expansion and management of heterogeneous systems. Background Technology

[0002] When the system encounters multiple plugins of the same type, the existing approach uses SPI (Service Provider interface, which provides an interface for a service to be implemented by a service developer or vendor) to import the plugins into memory sequentially, and then provides the plugin's execution result to the front end. This results in subsequent components failing to import into memory if their names are the same as those of previously imported components. Furthermore, the front end can only use hardware decoding to write various forms based on the required tasks.

[0003] In detail, the SPI implementation method has the following drawbacks:

[0004] 1. It cannot load on demand; it requires iterating through all implementations and instantiating them before finding the required implementation within a loop. If you don't want to use certain implementation classes, or if instantiating certain classes is time-consuming, they will still be loaded and instantiated, resulting in waste.

[0005] 2. The way to obtain a certain implementation class is not flexible enough. It can only be obtained through Iterator, and it cannot obtain the corresponding implementation class based on a certain parameter (Spring's BeanFactory and ApplicationContext are more advanced).

[0006] 3. It is unsafe for multiple concurrent and multi-threaded instances of the ServiceLoader class to be used. Summary of the Invention

[0007] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0008] The purpose of this invention is to solve the above-mentioned problems and provide a method for unified expansion and management of heterogeneous systems. This method can directly solve the problem of traditional plug-in combinations not having the same name and can directly generate forms through backend data, achieving twice the result with half the effort.

[0009] The technical solution of this invention is as follows: This invention discloses a method for unified extension and management of heterogeneous systems, including defining plug-in processes, creating workflow processes, and executing workflow processes, wherein:

[0010] The plugin definition process includes:

[0011] Step 1-1: Define an abstract plugin factory. The abstract plugin factory extracts various basic characteristics and attributes of plugins of the same type and defines the extracted basic characteristics and attributes in the type plugin interface or base class.

[0012] Steps 1-2: Define abstract channels based on the abstract plugin factory. The abstract channel defines the abstract methods that different plugins of the same type need to implement by the plugin itself, and defines the implementation process inside the type plugin interface.

[0013] Steps 1-3: The defined abstract plugin factory and abstract channel are released to the public. By implementing the abstract plugin factory and abstract channel, plugins of the same heterogeneous type can be extended for unified management.

[0014] Creating a workflow process includes:

[0015] Step 2-1: The plugin manager of the heterogeneous system backend manages the predefined abstract plugin factory and stores all plugin content in memory;

[0016] Step 2-2: When the heterogeneous system frontend opens the task of creating a workflow, the corresponding form is generated first;

[0017] Steps 2-3: The heterogeneous system front-end creates a workflow, selects the type according to user needs, submits the created workflow to the back-end, and the back-end generates a process definition based on the received workflow and saves it to the database;

[0018] The workflow process includes:

[0019] Step 3-1: After the master node of the heterogeneous system starts, it starts a timed thread to check if there are any tasks to be scheduled. If so, it obtains all information about the task to be executed, including the workflow.

[0020] Step 3-2: The master node breaks down the rules, tasks, and execution order according to the workflow definition based on the workflow information of the task being executed;

[0021] Step 3-3: The master node sends the task instance identifier that needs to be completed to the task processing node based on the task priority defined in the workflow and the different working states of the task processing cluster nodes.

[0022] Steps 3-4: When the entire processing task cluster node starts, the plugin manager of the heterogeneous system backend is started. The plugin manager stores all plugins defined under the abstract plugin factory in memory.

[0023] Steps 3-5: When the cluster node starts the plugin manager of the heterogeneous system backend, it starts the work management thread. The work management thread listens to the task queue information in real time. If it receives the execution task instance information from the task queue, it obtains the detailed information of the execution task and creates the task execution thread.

[0024] Steps 3-6: The task execution thread starts executing the task based on the task plugin information and the task information to be executed, and sends the task execution status to the master node. The entire plugin lifecycle ends here.

[0025] According to an embodiment of the method for unified expansion and management of heterogeneous systems of the present invention, in step 1-1, the abstract plug-in factory is defined based on PrioritySPI; in step 2-1, all plug-in contents are stored in memory using the PrioritySPI definition method; and in step 3-4, the plug-in manager stores all plug-ins defined under the abstract plug-in factory in memory using the PrioritySPI definition method.

[0026] According to one embodiment of the method for unified expansion and management of heterogeneous systems of the present invention, in steps 1-3, the expansion is defined by the PrioritySPI interface, and the execution order is determined by setting the priority of plugins with the same name.

[0027] According to an embodiment of the method for unified expansion and management of heterogeneous systems of the present invention, in step 2-1, the plug-in manager refers to a management class that manages plug-ins of the same type, including task plug-ins, data source plug-ins, and alarm plug-ins.

[0028] According to an embodiment of the method for unified extension and management of heterogeneous systems of the present invention, in step 2-1, the PrioritySPI definition method refers to defining a new interface based on the original SPI implementation method. The new interface inherits the comparison interface and defines a method for setting priority. This method determines the priority by comparing the priority. The class implementing the PrioritySPI interface sets its own priority according to the passed priority, thereby realizing the PrioritySPI definition method.

[0029] According to an embodiment of the method for unified expansion and management of heterogeneous systems based on the present invention, in step 2-2, the form is generated by obtaining a JSON plugin from the backend and generating the corresponding form through the JSON plugin.

[0030] According to one embodiment of the method for unified expansion and management of heterogeneous systems of the present invention, in step 2-2, the form is generated by the JSON plugin using the form-creat method.

[0031] According to an embodiment of the method for unified expansion and management of heterogeneous systems based on the present invention, in steps 2-3, the selected type includes task type, data source type, or alarm type.

[0032] Compared with existing technologies, this invention has the following advantages: The method of this invention employs a microkernel approach, namely project-based and plug-in-based technology, in defining plugins. On one hand, the plugin factory (ChannelFactory) inherits from PrioritySPI, enabling: 1) setting plugin priorities to resolve the requirement that multiple plugins of the same type cannot have the same name, leading to deficiencies in many scenarios; 2) extending the use of SPI to different business scenarios by adding one or more additional attributes derived from the priority attribute.

[0033] On the other hand, when the results of a plugin need to be displayed on the front end, the original hard-coding method is not a good choice in terms of either effect or efficiency, due to the many variations in the combination of plugins or other interfaces that require expansion. It results in a significant waste of time and resources. To address this, this invention uses the `form-create` method to generate forms on the front end, offering the following advantages: 1) Supports generating forms using JSON data; 2) Supports generating any component, improving form flexibility and enabling more complex forms; 3) Adapts to multiple UI frameworks, including iview, view-design, element-ui, and ant-design-vue; 4) Two-way data binding ensures the page updates in real time after changes in generation rules; 5) Built-in component caching improves rendering speed.

[0034] Through the above combination, the present invention can directly solve the problem of traditional plug-in combinations not being able to have the same name, and can directly generate form data through the backend data, achieving twice the result with half the effort. This method can be directly applied to the unified extension components of heterogeneous systems, serving as an example. Attached Figure Description

[0035] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0036] Figure 1A , 1BFigure 1C shows a flowchart of an embodiment of the method for unified expansion and management of heterogeneous systems according to the present invention. Detailed Implementation

[0037] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0038] Figure 1A , 1B Figure 1C illustrates a flow diagram of an embodiment of the method for unified expansion and management of heterogeneous systems according to the present invention. Please refer to Figure 1C. Figure 1A and 1B The method in this embodiment includes, as follows: Figure 1A The definition of the plugin is shown. Figure 1B The workflow creation shown (using a plugin) and Figure 1C The execution workflow (running plugins) shown consists of three parts, and the implementation steps of each part are detailed below.

[0039] like Figure 1A As shown, the implementation steps for defining the plugin in this embodiment are as follows:

[0040] Step 1-1: Define an abstract plugin factory based on PrioritySPI. The abstract plugin factory extracts various basic characteristics and attributes of plugins of the same type and defines the extracted basic characteristics and attributes in the type plugin interface or base class.

[0041] There can be one or more plugin components of the same type, and each plugin component contains complete functions. When using these plugin components, users can choose to use them directly or select them as needed. In the DataTurbo product, task type plugins are mandatory for users, while alarm and data source plugins are optional.

[0042] Steps 1-2: Define abstract channels based on the abstract plugin factory. The abstract channel defines the abstract methods that different plugins of the same type need to implement by the plugin itself, and defines the internal implementation process of the type plugin interface.

[0043] In steps 1-1 and 1-2 above, templates are directly defined for subsequent type plugin extensions and management.

[0044] Steps 1-3: Publish the abstract plugin factory and abstract channel to the outside world. If you need to extend the same heterogeneous type of plugin, you only need to implement the abstract plugin factory and abstract channel, thus achieving unified management.

[0045] Steps 1-3 address the shortcomings of the common implementation techniques used in steps 1-1 and 1-2, extending their high availability and improving efficiency. This invention inherits the PrioritySPI interface, directly overcoming the limitation of name conflicts in plugin implementations. It determines the execution order by setting the priority of plugins with the same name. This invention extends the priority definition of the PrioritySPI interface. If the plugin selection is not solely determined by priority, other determining attributes can be defined within PrioritySPI, achieving unified extension and configuration.

[0046] like Figure 1B As shown, the implementation steps for creating a workflow in this embodiment are as follows:

[0047] Step 2-1: The plugin manager of the heterogeneous system backend manages the abstract plugin factory that has been defined in the system and stores all plugin content in memory using the PrioritySPI definition method.

[0048] In step 2-1, pre-defined plugins of the same type will not be rejected from being stored in memory due to identical names, thus preventing the front-end view from using newly defined plugins. It only needs to check whether two plugins with the same name have the same priority to solve the drawback of the original service providing interface to handle the same name.

[0049] A plugin manager refers to a class that manages plugins of the same type, such as task plugins, data source plugins, and alert plugins. Figure 1A The abstract plugin factory has already been implemented using PrioritySPI, and more abstract plugin factories can be added later according to business needs.

[0050] PrioritySPI defines a new interface based on the existing PrioritySPI implementation. This new interface inherits from the Comparable interface and defines a method for setting the priority. Because it inherits from Comparable, it also overrides the compareTo method, which determines the priority by comparing the priorities. Classes implementing the PrioritySPI interface can set their own priorities based on the passed-in priorities, thus implementing PrioritySPI.

[0051] Step 2-1 lays the foundation for creating plugin runtime instances and running instances on the front end, which determines that because in the first stage... Figure 1A The process of defining plugins as shown adopts a unified configuration and management approach, directly encapsulating internal changes for users.

[0052] Step 2-2: When the front end of the heterogeneous system opens the task of creating a workflow, the front end first obtains the JSON plugin from the back end through the API interface, and generates the corresponding form through the JSON plugin.

[0053] Generating forms using a JSON plugin is the existing approach, namely using form-creat, a form generation component based on Vue 3.0.

[0054] Step 2-2 encapsulates configuration and management changes in the plugins created in Step 2-1. By using the JSON of all plugins of the same type and the form-creating technology, forms are dynamically created directly. This is a "modify and forget" approach, with the system handling all subsequent tasks, greatly improving the system's development efficiency.

[0055] The form-creat technology also has the following characteristics:

[0056] 1) Supports the generation of any component, improving the flexibility of forms and enabling more complex forms;

[0057] 2) Compatible with multiple UI frameworks, including iview, view-design, element-ui, and ant-design-vue.

[0058] 3) Two-way data binding: the page will update in real time after the generation rules change;

[0059] 4) Built-in component caching function improves rendering speed.

[0060] Steps 2-3: The heterogeneous system front-end creates a workflow, selects the task type, data source type or alarm type according to user needs, and submits the created workflow to the back-end. The back-end generates a process definition based on the received workflow and saves it to the database.

[0061] like Figure 1C As shown, the implementation steps of the workflow are as follows:

[0062] Step 3-1: After the heterogeneous system's master node starts, it starts a timed thread to check if there are any tasks to be scheduled. If so, it obtains all information about the task to be executed, including the workflow.

[0063] Step 3-2: The master node breaks down the rules, tasks, and execution order according to the workflow definition based on the workflow information of the task being executed.

[0064] Step 3-2 and Figure 1BThe steps 2-1 shown are the same as those for creating a workflow, which is used to solve the drawback of traditional technologies where plugins with the same name cannot be saved to memory at the same time.

[0065] Step 3-3: The master node, based on the task priority defined in the workflow and the different working states of the task cluster nodes, sends the task instance identifier (id) that needs to be completed to the appropriate task processing node through a queue.

[0066] Steps 3-4: When the entire processing task cluster node starts, the plugin manager of the heterogeneous system backend is started. The plugin manager stores all the actual plugins defined under the abstract plugin factory in memory according to the rules defined by PrioritySPI.

[0067] Steps 3-4 are the same. Figure 1B Step 2-1 shown Figure 1C Step 3-2 shown is used to solve the drawback of traditional technology that plugins with the same name cannot be saved to memory at the same time.

[0068] Steps 3-5: When the cluster nodes of the processing task start the plugin manager of the heterogeneous system backend, they also start the work management thread. The work management thread listens to the task queue information at any time. If it receives the execution task instance information from the task queue, it obtains the detailed information of the execution task and creates the task execution thread.

[0069] Steps 3-6: The task execution thread starts executing the task based on the task plugin information and the task information to be executed, and sends the task execution status to the master node. The entire plugin lifecycle ends here.

[0070] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0071] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0072] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0073] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0074] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0075] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for unified expansion and management of heterogeneous systems, characterized in that, This includes defining the plugin process, creating the workflow process, and executing the workflow process, where: The plugin definition process includes: Step 1-1: Define an abstract plugin factory. The abstract plugin factory extracts various basic characteristics and attributes of plugins of the same type and defines the extracted basic characteristics and attributes in the type plugin interface or base class. Steps 1-2: Define abstract channels based on the abstract plugin factory. The abstract channel defines the abstract methods that different plugins of the same type need to implement by the plugin itself, and defines the implementation process inside the type plugin interface. Steps 1-3: The defined abstract plugin factory and abstract channel are released to the public. By implementing the abstract plugin factory and abstract channel, plugins of the same heterogeneous type can be extended for unified management. Creating a workflow process includes: Step 2-1: The plugin manager of the heterogeneous system backend manages the predefined abstract plugin factory and stores all plugin content in memory; Step 2-2: When the heterogeneous system frontend opens the task of creating a workflow, the corresponding form is generated first; Steps 2-3: The heterogeneous system front-end creates a workflow, selects the type according to user needs, submits the created workflow to the back-end, and the back-end generates a process definition based on the received workflow and saves it to the database; The workflow process includes: Step 3-1: After the master node of the heterogeneous system starts, it starts a timed thread to check if there are any tasks to be scheduled. If so, it obtains all information about the task to be executed, including the workflow. Step 3-2: The master node breaks down the rules, tasks, and execution order according to the workflow definition based on the workflow information of the task being executed; Step 3-3: The master node sends the task instance identifier that needs to be completed to the task processing node based on the task priority defined in the workflow and the different working states of the task processing cluster nodes. Steps 3-4: When the entire processing task cluster node starts, the plugin manager of the heterogeneous system backend is started. The plugin manager stores all plugins defined under the abstract plugin factory in memory. Steps 3-5: When the cluster node starts the plugin manager of the heterogeneous system backend, it starts the work management thread. The work management thread listens to the task queue information in real time. If it receives the execution task instance information from the task queue, it obtains the detailed information of the execution task and creates the task execution thread. Steps 3-6: The task execution thread starts executing the task based on the task plugin information and the task information to be executed, and sends the task execution status to the master node. The entire plugin lifecycle ends here. In step 1-1, the abstract plugin factory is defined based on PrioritySPI. In step 2-1, all plugin content is stored in memory using the PrioritySPI definition method. In steps 3-4, the plugin manager stores all plugins defined under the abstract plugin factory in memory using the PrioritySPI definition method. In steps 1-3, the priority is defined by the PrioritySPI interface and extended to determine the execution order of plugins with the same name by setting their priority.

2. The method for unified expansion and management of heterogeneous systems according to claim 1, characterized in that, In step 2-1, the plugin manager refers to the management class that manages plugins of the same type. Plugins include task plugins, data source plugins, and alarm plugins.

3. The method for unified expansion and management of heterogeneous systems according to claim 1, characterized in that, In step 2-1, the PrioritySPI definition method refers to defining a new interface based on the original SPI implementation method. This new interface inherits the comparison interface and defines a method for setting priority. This method for setting priority determines the priority by comparing the priority values. Classes implementing the PrioritySPI interface set their own priority according to the passed-in priority, thereby implementing the PrioritySPI definition method.

4. The method for unified expansion and management of heterogeneous systems according to claim 1, characterized in that, In step 2-2, the form is generated by retrieving a JSON plugin from the backend and using the JSON plugin to generate the corresponding form.

5. The method for unified expansion and management of heterogeneous systems according to claim 4, characterized in that, In step 2-2, the form is generated using the form-creat method via the JSON plugin.

6. The method for unified expansion and management of heterogeneous systems according to claim 1, characterized in that, In steps 2-3, the selected type includes task type, data source type, or alarm type.

Images