Event-driven orchestrable application running framework system

Abstract

The invention provides an event-driven orchestrable application running framework system which can be applied to a mobile operating system. The framework system comprises an application management center module used for managing application programs registered to the framework system, each application program is provided with an independent interface and a respective interface contract, and the interface contract is used for uniquely identifying the corresponding application program; the event bus module is used for generating an application running flow graph according to the processing rule of the to-be-processed event, the application running flow graph is used for indicating the sequence when the corresponding application program processes the to-be-processed event, and the processing rule is generated in a mode that a user arranges the application program; and the driving engine module is used for acquiring the actual address of the indicated application program from the application management center module according to the interface contract of the application program indicated by the application running flow graph, so as to drive the indicated application program to execute the to-be-processed events in sequence.

Description

Technical Field

[0001] The present invention relates to the field of mobile operating systems and distributed computing technologies, and in particular to an event-driven and programmable application running framework system. Background Art

[0002] In mobile device usage scenarios, multiple applications (apps) are installed on the same device. To complete a task, users need to click different app icons to launch the app. In certain scenarios, when users are distracted from operating their devices, different apps may not be able to automatically and orderly execute their tasks according to specific rules. Event-driven architectures can effectively solve the problem of automatic response among different apps, but there is no mature technical solution for integrating event-driven architectures with app execution on mobile devices. Summary of the Invention

[0003] In view of this, the present invention provides an event-driven programmable application execution framework system that can be applied to a mobile operating system.

[0004] An embodiment of the present invention provides an event-driven, programmable application execution framework system, including: an application management center module, which is used to manage applications registered with the framework system, each application having an independent interface and its own interface contract, and the interface contract is used to uniquely identify the corresponding application; an event bus module, which is used to generate an application execution flow chart according to the processing rules of the events to be processed, and the application execution flow chart is used to indicate the order in which the corresponding applications process the events to be processed, and the processing rules are generated by the user arranging the applications; a driving engine module, which is used to obtain the actual address of the indicated application from the application management center module according to the interface contract of the application indicated by the application execution flow chart, thereby driving the indicated application to execute the events to be processed in sequence.

[0005] According to an embodiment of the present invention, the information of the event to be processed is described through an event model, which contains labels and fields corresponding to the processing rules. The event bus module obtains the processing rules by parsing the labels and fields of the event model, and matches the processing rules with the preset rules in the rule library. If the match is successful, the corresponding application operation flow chart is generated.

[0006] According to an embodiment of the present invention, the event model includes a basic information part and an extended information part. The basic information part is used to associate the core information of the event to be processed, and the extended information part is used to associate the context information of the event to be processed. The labels and fields corresponding to the processing rules are located in the basic information part.

[0007] According to an embodiment of the present invention, the application program registered in the application management center module includes at least one application or at least one application function module having an atomicity feature, where the atomicity feature includes functional integrity and operational independence of the application.

[0008] According to an embodiment of the present invention, an application with atomicity characteristics is deployed on a local node or a remote node, and an event to be processed is generated by the local node or the remote node.

[0009] According to an embodiment of the present invention, the processing rules are defined in a rule file, which includes multiple sub-rules. Each sub-rule corresponds to an application. The user adjusts the running rules of the event to be processed by changing the content and number of the sub-rules.

[0010] According to an embodiment of the present invention, the sub-rule includes an interface contract field, and the interface contract field is used to associate the interface contract of the application corresponding to the sub-rule.

[0011] According to an embodiment of the present invention, the interface contract is expressed in dotted decimal form, and the interface contract includes an owner field, a node field, an application name field, and a version number field. The owner field is used to associate the owner of the application, the node field is used to associate the device node information where the application is actually deployed and running, the application name field is used to associate the application name, and the version field is used to associate the version number of the current application.

[0012] According to an embodiment of the present invention, the framework system further includes a rule management module, which is used to allow users to add, delete or modify processing rules through rule files and send the processing rules to the event bus module.

[0013] According to an embodiment of the present invention, the framework system further includes a log management module, which is used to obtain the operation logs of various modules of the framework system.

[0014] According to the event-driven programmable application operation framework system of an embodiment of the present invention, event processing rules are pre-defined. The event processing rules include multiple applications with independent interfaces and their own interface contracts. When an event is collected, an application operation flow chart is generated according to its corresponding processing rules, and multiple different applications are combined in the same process and executed in sequence, thereby achieving the same goal through automatic and orderly collaboration of different apps. In this framework system, users can program application-defined event processing rules as needed, and different applications are executed according to the rules, thus achieving programmable application operation. The interface contract uniquely identifies the application, decoupling the application and the framework, ensuring that the framework can still achieve its functions without redeployment when the application changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above contents and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0016] Figure 1 Schematically shows a block diagram of an event-driven programmable application execution framework system according to a first embodiment of the present invention;

[0017] Figure 2 The flowchart schematically shows a working method of the event-driven programmable application execution framework system according to an embodiment of the present invention;

[0018] Figure 3 Schematically shows a block diagram of an event-driven programmable application execution framework system according to a second embodiment of the present invention;

[0019] Figure 4 Schematically shows a block diagram of an event-driven programmable application execution framework system according to a third embodiment of the present invention;

[0020] Figure 5 Schematically shows an event model definition diagram according to an embodiment of the present invention;

[0021] Figure 6 Schematically shows an interface contract definition diagram according to an embodiment of the present invention;

[0022] Figure 7 Schematically shows an application running rule definition diagram according to an embodiment of the present invention;

[0023] Figure 8 A block diagram schematically shows an electronic device suitable for implementing a working method of a programmable application execution framework system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0024] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present invention. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of embodiments of the present invention. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concept of the present invention.

[0025] The terms used herein are only for describing specific embodiments and are not intended to limit the present invention. The terms "comprise," "include," etc. used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0027] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0028] Event-driven architecture is a software design pattern widely used in the microservices-centric cloud computing landscape. Events are the core concept of event-driven architecture. Events represent changes or updates to state. They can carry state or simply be identifiers. Events trigger related services (which may have different business processing logic) to work together to achieve a common goal. Services do not need to know anything about each other except the event format.

[0029] A typical event-driven architecture typically consists of three core components: event producers, event routers, and event consumers. In a system employing an event-driven architecture, events are generated by event producers, extracted and filtered by event routers, and then sent to event consumers for processing. For example, in an event-driven human resources service system, a new employee's onboarding event is generated when they enter information in the information entry system. The event router receives the new employee onboarding event and forwards it to the equipment system, workstation system, and access control system. The equipment system distributes equipment and registers them, the workstation system allocates workstations and registers them, and the access control system authorizes and sends the information.

[0030] For event-driven architecture, the three core components of event producers, event routers, and event consumers are decoupled and can be independently deployed, updated, and scaled in a distributed manner. The application of event-driven architecture has the following advantages:

[0031] 1. Reduced coupling. Event producers only need to focus on the occurrence of events, not on how they are processed or to which subscribers they are distributed. Failures in any link will not affect the normal operation of other services.

[0032] 2. Asynchronous execution. Event-driven frameworks collect events from various sources, perform necessary processing, and then route them to downstream systems without waiting for system responses.

[0033] 3. Agile scalability. The core of an event-driven framework is events. Event handlers only need to specify the event format and are not concerned with the specific technical architecture used. They can be swiftly integrated into the event-driven framework. Furthermore, event handlers can be independently maintained, allowing for timely expansion of processing capabilities based on demand.

[0034] Application software (app) runs in the operating system's user state as an independent process. It has its own address space within the operating system, can interact with the user, and typically features a visual interface. For example, running a traditional mobile app typically involves clicking an app shortcut icon to launch the app and display the interactive interface.

[0035] The above is some background introduction about event-driven architecture and application software to help readers better understand the present invention, and does not constitute a limitation on the scope of protection of the present invention.

[0036] During their research, the applicant discovered that an event-driven architecture can effectively solve the problem of automatic responses from different apps. However, there is no mature technical solution for combining an event-driven architecture with app operation on mobile devices. In view of this, the present invention proposes an event-driven, programmable application operation framework system that can be applied to mobile scenarios. This event-driven framework solves the technical problem of different apps being unable to automatically and orderly collaborate to achieve specific goals according to rules, eliminating the need for manual user intervention and improving event processing efficiency. This is further explained below with reference to the accompanying figures.

[0037] Figure 1 The following schematically shows a block diagram of an event-driven programmable application execution framework system according to a first embodiment of the present invention. Figure 2 The flowchart schematically shows a working method of the event-driven programmable application execution framework system according to the first embodiment of the present invention.

[0038] like Figure 1 As shown, the programmable application execution framework system 100 of this embodiment may include: an application management center module 110 , an event bus module 120 and a driving engine module 130 .

[0039] The application management center module 110 can be used to manage applications registered with the framework system, store and manage application information, including but not limited to the actual address information of the application. Each application registered with the framework system has an independent interface and its own interface contract, and the interface contract can uniquely identify the corresponding application. When implementing the event-driven framework function, the App needs to be registered in the event-driven framework. Taking into account the independence of the event-driven framework and the App, that is, the event-driven framework will not be redeployed as the App version changes or upgrades, and the App will not redevelop the registration interface as the event-driven framework is upgraded, the present invention designs a unique interface specification for the interaction between the App and the event-driven framework, namely the interface contract.

[0040] like Figure 1 As shown, the registered applications may include, for example, applications App_1, App_2…App_n, where n is an integer. The number of n may be determined according to actual needs and is not specifically limited by the present invention. The event bus module 120 may be used to generate an application execution flow chart based on the processing rules of the events to be processed. The application execution flow chart may indicate the order in which the corresponding applications process the events to be processed. The processing rules are generated by the user arranging the applications. In other words, the application execution flow chart may be a directed acyclic graph of application execution, and the order of application execution and dependencies may be obtained from the graph. The driving engine module 130 may be used to obtain the actual address of the indicated application from the application management center module 110 based on the interface contract of the application indicated by the application execution flow chart, thereby driving the indicated application (e.g., applications App_1, App_2…App_n) to execute the events to be processed in sequence.

[0041] like Figure 1 and Figure 2 As shown, in some embodiments, the working method of the programmable application operation framework system 100 can be described as follows: an application or device triggers an event and passes the event to the event bus module 120. The event bus module 120 parses the event and searches the rule library for corresponding processing rules. If the rule library contains corresponding processing rules, the event bus module 120 will generate a corresponding application operation flow chart according to the rule file description. Then, the event bus module 120 sends the application flow chart to the driver engine module 130. The driver engine module 130 obtains the actual application interface from the application management center module 110 according to the interface contract of the application in the application operation flow chart. If there is a corresponding application actual interface, the driver engine module 130 runs each application one by one according to the order and dependency relationship described in the application operation flow chart, and finally completes the automatic and orderly collaborative processing of events by different apps. In this process, users can program applications to implement custom processing rules and realize on-demand event processing. In this article, orchestration can include combining in sequence, arranging applications according to rules, etc.

[0042] According to the event-driven programmable application operation framework system 100 of an embodiment of the present invention, event processing rules are predefined. The event processing rules include multiple applications with independent interfaces and their own interface contracts. When an event is collected, an application operation flow chart can be generated according to its corresponding processing rules, and multiple different applications can be combined in the same process and executed in sequence, thereby achieving the same goal through automatic and orderly collaboration of different apps. In this framework system, users can program application-defined event processing rules as needed, and different applications are executed according to the rules, thereby achieving programmable application operation. The interface contract uniquely identifies the application, decoupling the application and the framework, ensuring that the framework can still achieve its functions without redeployment when the application changes.

[0043] Figure 3 The block diagram of an event-driven programmable application execution framework system 300 according to the second embodiment of the present invention is schematically shown.

[0044] like Figure 3 As shown, the difference between the programmable application execution framework system 300 of this embodiment and the programmable application execution framework system 100 is that the programmable application execution framework system 300 can also include a rule management module 140. The rule management module 140 can be used to allow users to add, delete, or change processing rules through a rule file and send the processing rules to the event bus module 120. Users can define event processing rules for applications as needed, and different applications are executed according to the rules, thus realizing programmable application operation. Since the rules are defined in the rule file, users do not need to stop the framework to implement the rule definition. The content of the rule file will be further explained later.

[0045] like Figure 2 and Figure 3 As shown, in addition to using the rule management module 140 to generate user-defined processing rules, the main workflow of the programmable application execution framework system 300 can be Figure 2 The workflow shown is similar and will not be repeated here.

[0046] Figure 4 A block diagram of an event-driven programmable application execution framework system 400 according to a third embodiment of the present invention is schematically shown.

[0047] like Figure 4As shown, the programmable application execution framework system 400 of this embodiment differs from programmable application execution framework systems 100 and 300 in that the programmable application execution framework system 400 further includes a log management module 150. The log management module 150 can be used to obtain operation log information from various modules, such as the application management module 110, the event bus module 120, the driver engine module 130, and the rule management module 140. For example, it can support hierarchical logging of different severity levels (such as DEBUG, INFO, WARN, ERROR, FATAL, etc.) and can also support the acquisition of runtime context information (such as timestamps, thread IDs, class / method names, and other data).

[0048] like Figure 4 and Figure 3 As shown, in addition to using the log management management 150 to obtain the operation logs of each module, the main workflow of the application operation framework system 400 can be arranged with Figure 2 The workflow shown is similar and will not be repeated here.

[0049] In any of the framework systems 100, 300, and 400 of the aforementioned embodiments, information about an event to be processed can be described using an event model. The event model includes tags and fields corresponding to processing rules. The event bus module can quickly and accurately obtain processing rules by parsing the tags and fields of the event model, thereby improving parsing efficiency.

[0050] Furthermore, the event model can include a basic information section and an extended information section. The basic information section can be used to associate the core information of the event to be processed, and the extended information section can be used to associate the contextual information of the event to be processed. The labels and fields corresponding to the processing rules are located in the basic information section. As an example, the basic information section may include core information such as the event number, source, type, corresponding processing rules, and generation time. The extended information may include the IP address of the event producer, the geographic location, the address of the data source to be processed, and other contextual information.

[0051] In some embodiments, during the implementation of the event-driven framework, the event model may be defined using an Extensible Markup Language (XML) format. Figure 5 The event model definition diagram according to an embodiment of the present invention is schematically shown.

[0052] like Figure 5As shown, the event model of this embodiment may include the content contained in the <basic information> tag and the content contained in the <extended information> tag. As an example, the <basic information> tag may include the content of the <number> tag, the <source> tag, the <type> tag, the <rule> tag and the <time> tag. The <number> tag may correspond to the number of the event, and the <source> tag may correspond to the source of the event, which may contain two attributes "node" and "format". The "node" attribute indicates that the event is generated at a local or remote node, and the "format" attribute indicates that the event is automatically generated by the application or generated by human-computer interaction. In other words, the events processed by the present invention may originate from local or remote nodes. The <type> tag may correspond to the type of event, and the event type may include, for example, a notification (note), a request (request) or an instruction (order); the <rule> tag may correspond to the processing rule of the event, and the event bus module 120 parses the event after collecting the event and starts the process to process the event according to the processing rule; the <time> tag may refer to the time when the event is generated. The content of the <extended information> tag can be defined as needed. It should be emphasized that Figure 5 The various tags in the event model shown are only examples. In some embodiments, tags can be added or deleted as needed.

[0053] In some embodiments, applications registered with the application management center module 110 (e.g., applications App_1, App_2, ..., App_n) may be atomic. This atomicity compares applications to independently running atoms and can include characteristics such as functional integrity and operational independence. Functional integrity means that an application can independently implement a specific business function, while operational independence means that the application can execute without relying on other application services. In this context, atomic applications, or simply atomic applications, can be modular, lightweight applications with specific characteristics such as fast response time and minimal image storage space. Atomic applications also have independent functions, independent of other services and applications, and independent entry points through which their functions can be started or invoked. For example, atomic applications can independently perform functions such as code scanning, navigation, and weather querying. Atomic applications can be deployed on local or remote nodes. Processed events can also be generated by local or remote nodes. In other words, the event-driven, choreographed application execution framework system provided by the present invention can support distributed operation.

[0054] In some other embodiments, the applications registered in the application management center module 110 (e.g., applications App_1, App_2, ..., App_n) can also be non-atomic applications. For example, they can be specific functional modules within an application. The interface contract provided by the present invention can also be applied to this by mapping the application interface contract to the functional module interface.

[0055] In some embodiments, the interface contract may refer to the dotted decimal representation of the IP address in the TCP / IP network protocol stack, and may include an owner field, a node field, an application name field, and a version number field. For example, the interface contract may be designed in the form of "owner.function.application name.version". Figure 6 The diagram schematically shows an interface contract definition diagram according to an embodiment of the present invention.

[0056] like Figure 6 As shown in the figure, the owner field in the interface contract indicates the owner of the application, the node field indicates the device node where the application is actually deployed and running, the application name field specifies the application name, and the version field specifies the current application version number. Thus, the interface contract uniquely identifies an application within the event-driven framework system, and the dotted decimal notation is concise and clear, making it easy to extract and identify.

[0057] In order to allow different applications to automatically execute according to rules and adapt to various scenarios, the event-driven framework system of the present invention also designs an application operation rule file. Users can customize the application operation rules when processing events in the rule file as needed, that is, to achieve programmable application operation rules. Figure 7 The diagram schematically shows an application running rule definition diagram according to an embodiment of the present invention.

[0058] like Figure 7 As shown, a rule file can consist of multiple sub-rules (e.g., sub-rule 1, sub-rule 2). Each sub-rule corresponds to an application. Users can adjust the rules for the events being processed by changing the content and number of sub-rules. Corresponding to the atomic applications mentioned above, sub-rules can also be called atomic rules, the smallest unit of processing rules.

[0059] like Figure 7As shown, as an example, sub-rule 1 can be composed of fields such as "address", "process", "dependency", "request", "response" and "status". The "address" field indicates on which device the atomic application is applied, and the default value is local (local), that is, this device. The value of the "process" field is the interface contract of the specific atomic application; the "dependency" field indicates that the rule depends on the results of other rules. If it does not depend on other rules, the field can be empty; the "request" field is the input processed by the atomic application, and can be filled in according to the input specification of the atomic application; the "response" field is the output of the atomic application, and can be filled in according to the output specification of the atomic application; the "status" field indicates the execution status of the rule, such as pending (pending), completed (ok), etc. The fields of sub-rule 2 can be the same as the fields of sub-rule 1, and will not be repeated here. The number of sub-rules contained in the rule file can be determined according to the complexity of the event, and the present invention does not make specific limitations.

[0060] According to the above-mentioned multiple embodiments, the present invention realizes an event-driven and programmable application running framework through event models, atomic applications, interface contracts and completed system designs, which can realize that events trigger different apps to automatically and orderly collaborate to achieve the same goal after deployment on the mobile terminal. The interface contract decouples the application and the framework, ensuring that the framework can still realize its function without redeployment when the application changes. At the same time, users can define and organize application custom event processing rules according to the rule definition specifications, and the application runs according to the rules to realize programmable applications. In some embodiments, atomic applications can be deployed on local nodes or on remote nodes, and events can be generated by this node or by a remote node. The event-driven and programmable application running framework supports distributed operation. In some embodiments, for non-atomic applications, the event-driven and programmable application running framework of the present invention is still applicable, and the application interface contract corresponds to a specific functional module interface of the application.

[0061] It should be noted that if Figure 1 、 Figure 3 and Figure 4As shown, according to an embodiment of the present invention, any multiple modules among the application management center module 110, event bus module 120, driver engine module 130, rule management module 140, and log management module 150 can be combined into a single module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in a single module. According to an embodiment of the present invention, at least one of the application management center module 110, event bus module 120, driver engine module 130, rule management module 140, and log management module 150 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented in hardware or firmware through any other reasonable method of circuit integration or packaging, or can be implemented in any one of the three implementation methods of software, hardware, and firmware, or any appropriate combination of any of these. Alternatively, at least one of the application management center module 110, the event bus module 120, the driving engine module 130, the rule management module 140 and the log management module 150 can be at least partially implemented as a computer program module, which can perform corresponding functions when executed.

[0062] Figure 8 A block diagram schematically shows an electronic device suitable for implementing a working method of a programmable application execution framework system according to an embodiment of the present invention.

[0063] like Figure 8 As shown, an electronic device 800 according to an embodiment of the present invention includes a processor 801, which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 802 or programs loaded from a storage unit 808 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or related chipsets and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0064] The RAM 803 stores various programs and data required for the operation of the electronic device 800. The processor 801, ROM 802, and RAM 803 are connected to each other via a bus 804. The processor 801 executes the programs in the ROM 802 and / or RAM 803 to perform the various operations of the method flow according to the embodiment of the present invention. It should be noted that the programs may also be stored in one or more memories other than the ROM 802 and RAM 803. The processor 801 may also execute the programs stored in one or more memories to perform the various operations of the method flow according to the embodiment of the present invention.

[0065] According to an embodiment of the present invention, electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to bus 804. Electronic device 800 may also include one or more of the following components connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 808 including a hard disk; and a communication section 809 including a network interface card such as a LAN card or modem. Communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. Removable media 811, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 810 as needed, so that computer programs read from the removable media can be installed into storage section 808 as needed.

[0066] The present invention also provides a computer-readable storage medium, which may be included in the device / system described in the above embodiments, or may exist independently and not incorporated into the device / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of the present invention.

[0067] According to an embodiment of the present invention, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. For example, according to an embodiment of the present invention, a computer-readable storage medium may include the ROM 802 and / or RAM 803 described above, and / or one or more memories other than ROM 802 and RAM 803.

[0068] Embodiments of the present invention also include a computer program product comprising a computer program containing program code for executing the method shown in the flowchart. When the computer program product is executed in a computer system, the program code is used to cause the computer system to implement the operating method of the programmable application execution framework system provided by the embodiments of the present invention.

[0069] The computer program executes the above functions defined in the system of the embodiment of the present invention when the processor 801 executes the computer program. According to the embodiment of the present invention, the system, modules, units, etc. described above can be implemented by computer program modules.

[0070] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 809, and / or installed from a removable medium 811. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0071] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809 and / or installed from a removable medium 811. When the computer program is executed by the processor 801, the above-described functions defined in the system of the embodiment of the present invention are performed. According to the embodiment of the present invention, the systems, devices, modules, units, etc. described above can be implemented by computer program modules.

[0072] According to an embodiment of the present invention, the program code for executing the computer program provided by the embodiment of the present invention can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0073] The flowcharts and block diagrams in the accompanying drawings illustrate the system architecture, functions and operations that may be implemented according to the systems of various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0074] It will be understood by those skilled in the art that the features described in the various embodiments of the present invention may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in the present invention. In particular, the features described in the various embodiments of the present invention may be combined and / or coupled in various ways without departing from the spirit and teachings of the present invention. All such combinations and / or couplings fall within the scope of the present invention.

[0075] The above describes embodiments of the present invention. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present invention, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present invention.

Claims

1. An event-driven, programmable application execution framework system, characterized in that: include: An application management center module is used to manage applications registered with the framework system. Each application has an independent interface and its own interface contract. The interface contract is used to uniquely identify the corresponding application. An event bus module is used to generate an application operation flow chart based on the processing rules of the pending events, wherein the application operation flow chart is used to indicate the order in which the corresponding application processes the pending events. The processing rules are generated by the user arranging the application; The driving engine module is used to obtain the actual address of the indicated application from the application management center module according to the interface contract of the application indicated by the application running flow chart, thereby driving the indicated application to execute the pending events in the order.

2. The frame system according to claim 1, characterized in that The information of the event to be processed is described through an event model, which contains labels and fields corresponding to the processing rules. The event bus module obtains the processing rules by parsing the labels and fields of the event model, and matches the processing rules with the preset rules in the rule library. If the match is successful, the corresponding application operation flow chart is generated.

3. The frame system according to claim 2, characterized in that The event model includes a basic information part and an extended information part. The basic information part is used to associate the core information of the event to be processed, and the extended information part is used to associate the context information of the event to be processed. The labels and fields corresponding to the processing rules are located in the basic information part.

4. The frame system according to claim 1, characterized in that The application program registered in the application management center module includes at least one application with atomicity characteristics or at least one application function module, and the atomicity characteristics include functional integrity and operation independence of the application.

5. The frame system according to claim 4, characterized in that The application with atomicity characteristics is deployed on a local node or a remote node, and the event to be processed is generated by the local node or the remote node.

6. The frame system according to claim 1, characterized in that The processing rules are defined in a rule file, which includes a plurality of sub-rules. Each sub-rule corresponds to one application. The user adjusts the running rules of the event to be processed by changing the content and number of the sub-rules.

7. The frame system according to claim 6, characterized in that The sub-rule includes an interface contract field, and the interface contract field is used to associate the interface contract of the application corresponding to the sub-rule.

8. The frame system according to claim 1 or 7, characterized in that: The interface contract is expressed in dotted decimal form and includes an owner field, a node field, an application name field, and a version number field. The owner field is used to associate the owner of the application, the node field is used to associate the device node information where the application is actually deployed and running, the application name field is used to associate the application name, and the version field is used to associate the version number of the current application.

9. The frame system according to claim 6, characterized in that The framework system further includes a rule management module, which is used to allow the user to add, delete or modify the processing rules through the rule file and send the processing rules to the event bus module.

10. The frame system according to claim 1, wherein: The framework system further includes a log management module, which is used to obtain the operation logs of each module of the framework system.

Images