Event filtering system and method based on event attributes and resource node state constraints

Abstract

The application provides an event filtering system and method based on event attribute and resource node state constraint, which is characterized by comprising an event publisher, an event subscriber, an event processing module, a policy processing module and a node information point; the event publisher, the event subscriber and the event processing module are the three basic components in the publish / subscribe model; the event publisher generates events, the event subscriber consumes events, the event processing module performs event routing and forwarding, the policy processing module analyzes the filtering policy defined by the EFPL and generates a selector for each event subscriber, and the node information point stores resource node state information; the application can determine whether to send events to the event subscribers according to the state of the event subscribers, thereby greatly avoiding invalid distribution of events; the application can define the complex filtering conditions of the state of resources and the event attribute; and the application can be organically integrated with the current publish / subscribe system.

Description

Technical Field

[0001] This invention relates to the technical field of event processing, and more specifically, to an event filtering system and method based on event attributes and resource node state constraints. Background Technology

[0002] Event distribution is typically implemented using a publish / subscribe system. Publish / subscribe is a distributed interaction paradigm that decouples communicating parties in time and space. Due to its loosely coupled nature, publish / subscribe systems are widely used in large-scale distributed systems. Currently, achieving accurate event distribution remains a major challenge.

[0003] Event filtering is the process by which event consumers select the events they want to receive and process. It is a crucial step in achieving accurate event distribution, and its essence is selective event distribution. During event filtering, it's essential to ensure that event receivers don't receive useless events that increase their load, while also ensuring that they don't miss relevant events.

[0004] Event filtering is typically achieved by providing matching topics or subscription conditions. These topics or subscription conditions often constrain event types and attributes, neglecting the state of the resource nodes (event receivers). However, in some scenarios, it's desirable to incorporate the resource node's own state (whether it's occupied, busy, in a specific state, or needs processing for higher-priority events) into the subscription conditions to filter events and reduce the distribution of invalid events.

[0005] Patent document CN104111872B discloses a method, apparatus, and terminal for filtering system events. The technical solution provided by this invention reduces the number of system events sent to various system application modules by searching for frequent events in a system event set and filtering out frequent events whose current time falls within the system time window period. This reduces redundant computation within the system, saves system resources, and lowers power consumption.

[0006] Regarding the aforementioned technologies, the inventors believe that these technologies cannot both formulate filtering strategies based on event attributes and incorporate constraints on resource node states into the filtering strategies, thereby leading to an increase in invalid events and affecting work efficiency. Therefore, a new technical solution is needed to improve the aforementioned technical problems. Summary of the Invention

[0007] In view of the deficiencies in the prior art, the purpose of this invention is to provide an event filtering system and method based on event attributes and resource node state constraints.

[0008] An event filtering system based on event attributes and resource node state constraints, provided by the present invention, includes: an event publisher, an event subscriber, an event processing module, a strategy processing module, and node information points;

[0009] The event publisher, event subscriber, and event processing module are the three basic components of the publish / subscribe model;

[0010] The event publisher generates events, the event subscriber consumes events, the event processing module routes and forwards events, the policy processing module parses the filtering policy defined by EFPL and generates a selector for each event subscriber, and the node information point stores resource node status information.

[0011] Preferably, the system further includes an event filtering policy language EFPL, which is a syntax policy language that expresses constraints based on event attributes and resource node states in event filtering. The event filtering policy language EFPL includes a filtering policy, a filtering policy set, and an event hierarchy.

[0012] The filtering policy describes the rules for filtering events on resource nodes, represented as a quadruple, p =<pname,target,condition,entitlement> ;

[0013] The filtering policy set (PolicySet) consists of multiple policies with the same policy objective expression, represented as a triple, s =<sname,target,policies> ;

[0014] The event hierarchy defines the inheritance relationship between event types, represented as a triple, h =<hname,event,sub_event> .

[0015] Preferably, the pname in the filtering policy is the policy name, which uniquely identifies the filtering policy;

[0016] `target` is the policy target expression. When the target expression is True, the filtering policy is adopted. The target expression contains attributes such as event type and resource node ID.

[0017] The condition is the main constraint of the strategy, specifically the event filtering conditions;

[0018] The entitlement = {permit, deny} represents the policy entitlement, indicating the decision returned by the policy after satisfying the policy subject constraints; permit indicates that the event is not filtered, deny indicates that the event is filtered, and the policy return value is deny.

[0019] Preferably, sname in the PolicySet is the policy set name, which uniquely identifies the filtering policy set;

[0020] `target` is the target expression for the policy set. When the target expression is True, the policy set is used.

[0021] policies={p1,p2,...,p |policies|} represents a finite set of filtering strategies contained in the filtering strategy set.

[0022] Preferably, the hname in the event hierarchy is the name of the event hierarchy, uniquely identifying the event hierarchy;

[0023] event is the upper-level event type;

[0024] sub_event is the set of lower-level event types.

[0025] This invention also provides an event filtering method based on event attributes and resource node state constraints. The method applies the event filtering system based on event attributes and resource node state constraints described above, and includes the following steps:

[0026] Step S1: The policy processing module reads all policies defined using EFPL from the policy repository;

[0027] Step S2: The policy processing module parses the policy and converts it into an internal object;

[0028] Step S3: The event subscriber provides node information and subscription information to generate a node-corresponding selector;

[0029] Step S4: The strategy processing module generates a selector based on the algorithm and returns it to the resource node;

[0030] Step S5: The resource node passes in the subscribed topic and selector to establish a connection with the event handling module;

[0031] Step S6: The event producer establishes a connection with the event handling module;

[0032] Step S7: Obtain data;

[0033] Step S8: The event producer obtains relevant node information based on the published topic;

[0034] Step S9: The event producer generates the corresponding event and supplements the information;

[0035] Step S10: The event producer publishes the event to the corresponding topic;

[0036] Step S11: The event handling module filters and forwards events based on subscription information and selectors;

[0037] Step S12: When the status of a resource node changes, update the corresponding information in the node information point.

[0038] Preferably, in step S4, when the strategy processing module generates the selector, the resource node needs to match the corresponding strategy, calculate the value of the target expression in the strategy or strategy set, and find the relevant event type set of each resource node according to the event hierarchy by using the relevant event type set construction algorithm during the process of matching the filtering strategy of the resource node.

[0039] Preferably, the algorithm for constructing the relevant event type set includes the following steps:

[0040] Step 1: Construct a parent event table based on the event hierarchy definition, and find the parent event for each event type;

[0041] Step 2: For each resource node, construct an empty set of related event types and an auxiliary queue, and insert the event types subscribed to by the node from the tail of the auxiliary queue;

[0042] Step 3: Pop the first element of the auxiliary queue. If the relevant event type set does not contain the event type, add the event type to the relevant event type set and insert the parent event type of the event type into the auxiliary queue from the tail. Repeat Step 3 until the auxiliary queue is empty.

[0043] Step 4: When the auxiliary queue is empty, obtain the set of relevant event types for that node.

[0044] Preferably, after the resource node constructs the relevant event type set according to the relevant event type set construction algorithm, it constructs its corresponding selector through the selector construction algorithm. The selector construction algorithm includes three steps: matching, classification and transformation.

[0045] Preferably, the selector construction algorithm includes three steps:

[0046] Matching: Resource nodes calculate the value of the target expression of the filtering policy and the filtering policy set based on their relevant event type set and their ID, and search for their corresponding policy and policy set;

[0047] Classification: Resource nodes categorize the matched policies and policy sets into allowed policy sets and denied policy sets based on policy rights;

[0048] Transformation: For policies in the allow policy set, connect the policy body constraints with "OR" and enclose the concatenated string in parentheses; for policies in the deny policy set, connect the policy body constraints with "OR", enclose the concatenated string in parentheses, add "NOT" before the concatenated string, and finally connect the two strings with "OR". The resulting string is the selector for the resource node.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] 1. This invention can determine whether to send an event to the subscribers based on their status, thereby greatly avoiding invalid event distribution;

[0051] 2. This invention can define complex filtering conditions for resource status and event attributes;

[0052] 3. This invention can be organically integrated with existing publish-subscribe systems. Attached Figure Description

[0053] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0054] Figure 1 This is a diagram of the EFPL element relationship model of the present invention;

[0055] Figure 2 This is the EFPL syntax diagram of the present invention;

[0056] Figure 3 This is a structural diagram of the event filtering system of the present invention. Detailed Implementation

[0057] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0058] Example 1:

[0059] An event filtering system based on event attributes and resource node state constraints provided by the present invention includes: an event publisher, an event subscriber, an event processing module, a policy processing module, and node information points; the event publisher, event subscriber, and event processing module are the three basic components in the publish / subscribe model; the event publisher generates events, the event subscriber consumes events, the event processing module routes and forwards events, the policy processing module parses the filtering policy defined by EFPL and generates a selector for each event subscriber, and the node information points store resource node state information.

[0060] The system also includes the Event Filtering Policy Language (EFPL), a syntax-based policy language that expresses constraints in event filtering based on event attributes and resource node states. EFPL includes filtering policies, policy sets, and event hierarchies. A filtering policy describes the rules for filtering events on resource nodes and is represented as a four-tuple, p = ...<pname,target,condition,entitlemebt> A policy set (PolicySet) consists of multiple policies with the same objective expression, represented as a triple, s =<sname,target,policies> The event hierarchy defines the inheritance relationship between event types, represented as a triple, h =<hname,event,sub_event> .

[0061] In the filtering policy, pname is the policy name, uniquely identifying the filtering policy; target is the policy target expression. When the target expression is True, the filtering policy is adopted. The target expression includes attributes such as event type and resource node ID; condition is the policy body constraint, the specific event filtering conditions; entitlement = {permit, deny} is the policy entitlement, representing the decision returned by the policy after satisfying the policy body constraint; permit indicates that the event is not filtered, deny indicates that the event is filtered, and the policy return value is deny.

[0062] In the PolicySet, sname is the policy set name, uniquely identifying the filter policy set; target is the target expression for the policy set; when the target expression is True, the filter policy set is adopted; policies = {p1, p2, ..., p |policies|} represents a finite set of filtering strategies contained in the filtering strategy set.

[0063] In the event hierarchy, hname is the name of the event hierarchy, uniquely identifying the event hierarchy; event is the upper-level event type; and sub_event is the set of lower-level event types.

[0064] This invention also provides an event filtering method based on event attributes and resource node state constraints. The method applies the event filtering system based on event attributes and resource node state constraints described above, and includes the following steps:

[0065] Step S1: The policy processing module reads all policies defined using EFPL from the policy repository;

[0066] Step S2: The policy processing module parses the policy and converts it into an internal object;

[0067] Step S3: The event subscriber provides node information and subscription information to generate a node-corresponding selector;

[0068] Step S4: The strategy processing module generates a selector based on the algorithm and returns it to the resource node;

[0069] Step S5: The resource node passes in the subscribed topic and selector to establish a connection with the event handling module;

[0070] Step S6: The event producer establishes a connection with the event handling module;

[0071] Step S7: Obtain data;

[0072] Step S8: The event producer obtains relevant node information based on the published topic;

[0073] Step S9: The event producer generates the corresponding event and supplements the information;

[0074] Step S10: The event producer publishes the event to the corresponding topic;

[0075] Step S11: The event handling module filters and forwards events based on subscription information and selectors;

[0076] Step S12: When the status of a resource node changes, update the corresponding information in the node information point.

[0077] In step S4, when the policy processing module generates the selector, the resource node needs to match the corresponding policy, calculate the value of the policy or the target expression in the policy set, and find the relevant event type set of each resource node according to the event hierarchy by using the relevant event type set construction algorithm during the process of matching the filtering policy of the resource node.

[0078] The algorithm for constructing a set of related event types includes the following steps:

[0079] Step 1: Construct a parent event table based on the event hierarchy definition, and find the parent event for each event type;

[0080] Step 2: For each resource node, construct an empty set of related event types and an auxiliary queue, and insert the event types subscribed to by the node from the tail of the auxiliary queue;

[0081] Step 3: Pop the first element of the auxiliary queue. If the relevant event type set does not contain the event type, add the event type to the relevant event type set and insert the parent event type of the event type into the auxiliary queue from the tail. Repeat Step 3 until the auxiliary queue is empty.

[0082] Step 4: When the auxiliary queue is empty, obtain the set of relevant event types for that node.

[0083] After the resource node constructs the relevant event type set according to the relevant event type set construction algorithm, it constructs its corresponding selector through the selector construction algorithm. The selector construction algorithm includes three steps: matching, classification and transformation.

[0084] The selector construction algorithm consists of three steps:

[0085] Matching: Resource nodes calculate the value of the target expression of the filtering policy and the filtering policy set based on their relevant event type set and their ID, and search for their corresponding policy and policy set;

[0086] Classification: Resource nodes categorize the matched policies and policy sets into allowed policy sets and denied policy sets based on policy rights;

[0087] Transformation: For policies in the allow policy set, connect the policy body constraints with "OR" and enclose the concatenated string in parentheses; for policies in the deny policy set, connect the policy body constraints with "OR", enclose the concatenated string in parentheses, add "NOT" before the concatenated string, and finally connect the two strings with "OR". The resulting string is the selector for the resource node.

[0088] Example 2:

[0089] Example 2 is a preferred embodiment of Example 1, and is used to illustrate the present invention in more detail.

[0090] This invention provides an event filtering system based on event attributes and resource node state constraints, with the core being the Event Filtering Policy Language (EFPL) and its processing module.

[0091] The Event Filtering Policy Language (EFPL) is a concise policy language that expresses complex constraints based on event attributes and resource node states in event filtering. EFPL consists of three elements: a filtering policy, a policy set, and an event hierarchy.

[0092] A filtering policy describes the rules for filtering events on resource nodes and can be represented as a quadruple, i.e., p =<pname,target,condition,entitlement> .in:

[0093] pname is the policy name, which uniquely identifies the filtering policy.

[0094] `target` is the policy target expression. When the target expression is True, the filtering policy is adopted. The target expression includes attributes such as event type and resource node ID.

[0095] The condition is the constraint of the strategy body, that is, the specific event filtering conditions.

[0096] `entitlement = {permit, deny}` represents the policy rights, indicating the decision returned by the policy after satisfying the constraints of the policy subject. `permit` indicates that the event is not filtered, while `deny` indicates that the event is filtered. The return value of the policy is generally `deny`.

[0097] A policy set consists of multiple policies with the same objective expression, and can be represented as a triple, i.e., s =<sname,target,policies> .in:

[0098] sname is the policy set name, which uniquely identifies the filtering policy set.

[0099] `target` is the target expression for the policy set. When the target expression is True, the filtering policy set is adopted.

[0100] policies={p1,p2,...,p |policies|} represents a finite set of filtering strategies contained in the filtering strategy set.

[0101] The event hierarchy defines the inheritance relationship between event types, which can be represented as a triple, i.e., h =<hname,event,sub_event> .in:

[0102] hname is the name of the event hierarchy, which uniquely identifies the event hierarchy.

[0103] `event` refers to the event type at the higher level.

[0104] sub_event is the set of lower-level event types.

[0105] EFPL has a clear syntax, sufficient expressiveness to cover most event filtering scenarios based on event attributes and resource node attributes, and good readability. In EFPL, each filtering policy begins with the keyword `policy` and the policy name. This is followed by the right `permit` or `deny`, indicating the decision indicated by the filtering policy. This is followed by a Boolean objective expression. The purpose of the objective expression is to allow indexing of the filtering policy and avoid access to irrelevant policies. The rest of the policy is evaluated only if the objective expression evaluates to `True` for a given subscription; such policies are considered to match the subscription. If omitted, the objective expression is considered to evaluate to `True` for all subscriptions. The objective expression is followed by an optional `where` block, the body constraint of the policy, consisting of semicolon-separated Boolean expressions. If both the policy's objective expression and `where` block evaluate to `True`, the filtering policy returns the decision indicated by the right defined above, i.e., `permit` or `deny`. Event attributes and resource node attributes are accessed via `event.` and `node.`, respectively, in the objective expression and body constraint. The policy name and policy right in a filtering policy cannot be empty. When the rest of the filtering policy is empty, the policy will match all subscriptions and always produce a given right, resulting in a "filter all" or "do not filter all" policy.

[0106] A filter policy set is a collection of filter policies. A filter policy set begins with the keyword `set` and the policy set name. Optionally, a filter policy set can declare a policy set target expression after the keyword, which is used in the same way as the target statement of the filter policies, followed by multiple policies in sequence. The filter policy set is evaluated if the policy set target statement evaluates to true for a given subscription. For the policies in the filter policy set, their target expressions are empty. Therefore, a filter policy set is essentially composed of policies with the same target expression. In addition, the filter policies in the filter policy set may have different weights. When the principal constraints of these policies are all satisfied, how to decide whether to filter the corresponding event? In EFPL, a permit-overrides combination algorithm is used: when the principal constraints of filter policies with different weights are simultaneously satisfied, the policy set returns a permit, meaning the corresponding event is not filtered.

[0107] Event hierarchies begin with the keyword "hierarchy" and the event hierarchy name. This is followed by the upper-level event type and multiple lower-level event types. Event hierarchies define the inheritance relationship between events, and this inheritance is transitive. The definition of event hierarchies effectively describes the general-to-specific relationships between strategies, thus providing a more flexible and convenient way to define event filtering strategies.

[0108] The event filtering system is implemented by extending Apache ActiveMQ, an open-source project under Apache that conforms to the JMS (Java Message Service) specification and is a message-driven middleware (MOM). ActiveMQ provides a custom message filtering function, selector, using SQL92 expression syntax. A selector is a way to attach filtering conditions to subscriptions to perform content-based routing; that is, selectors can be used to implement subscriptions based on topics and content. In this system, resource nodes match relevant event filtering strategies and generate selectors based on the main constraints of the strategies to achieve event filtering based on event attributes and resource node state constraints.

[0109] The system consists of five parts: event publishers, event subscribers, event processing modules, policy processing modules, and node information points. Event publishers, event subscribers, and event processing modules are the three basic components of the publish / subscribe model. Event publishers are primarily responsible for generating events, event subscribers are primarily responsible for consuming events, the event processing module routes and forwards events, the policy processing module is responsible for parsing the filtering policies defined using EFPL and generating a selector for each event subscriber (resource node), and node information points are responsible for storing resource node status information. The specific steps are as follows:

[0110] S1. The policy processing module reads all policies defined using EFPL from the policy repository.

[0111] S2, the strategy processing module parses the strategy and converts it into an internal object.

[0112] S3. Event subscribers (i.e. resource nodes) provide node information and subscription information to generate the selector corresponding to the node.

[0113] S4. The strategy processing module generates a selector based on the algorithm and returns it to the resource node.

[0114] S5. Resource nodes pass in the subscribed topic and selector to establish a connection with the event handling module.

[0115] S6. The event producer establishes a connection with the event handling module.

[0116] S7. Obtain data.

[0117] S8. Event producers obtain relevant node information based on the published topic.

[0118] S9. The event producer generates the corresponding event and supplements the information.

[0119] S10. The event producer publishes the event to the corresponding topic.

[0120] S11. The event handling module filters and forwards events based on subscription information and selector.

[0121] S12. When the status of a resource node changes, update the corresponding information in the node information point.

[0122] Preferably, when the policy processing module generates the selector in S4, the resource node needs to match the corresponding policy and calculate the value of the objective expression in the policy or policy set. For example, if resource node n1 subscribes to event type t2, and the objective expression of policy p1 is event.type = t1, then resource node n1 and policy p1 do not match. In EFPL, the inheritance relationship of event types can be described by defining the event hierarchy. If event type t2 is defined as a lower-level event of event type t1, that is... Therefore, resource node n1 matches strategy p1. Thus, during the resource node matching and filtering strategy process, a relevant event type set construction algorithm is used to find the relevant event type set (i.e., the event types subscribed to by the resource node and their parent event types) based on the event hierarchy. The specific steps of the relevant event type set construction algorithm are as follows:

[0123] Step 1: Construct a higher-level event table based on the event hierarchy definition to find the higher-level event for each event type.

[0124] Step 2: For each resource node, construct an empty set of related event types and an auxiliary queue, and insert the event types subscribed to by the node from the tail of the auxiliary queue.

[0125] Step 3: Pop the first element from the auxiliary queue. If the relevant event type set does not contain the event type, add the event type to the relevant event type set, and insert the parent event type of the event type into the auxiliary queue from the tail. Repeat Step 3 until the auxiliary queue is empty.

[0126] Step 4: When the auxiliary queue is empty, obtain the set of relevant event types for that node.

[0127] After a resource node constructs a set of relevant event types using the relevant event type set construction algorithm, it can then use a selector construction algorithm to construct its corresponding selector. The selector construction algorithm includes the following three steps: matching, classification, and transformation. Where:

[0128] Matching: Resource nodes calculate the value of the target expression of the filtering policy and the filtering policy set based on their related event type set and their ID, and search for their corresponding policy and policy set.

[0129] Classification: The resource nodes will classify the matched policies and policy sets into allowed policy sets and denied policy sets according to policy rights.

[0130] Transformation: For policies within the allow policy set, connect the policy body constraints using "OR" and enclose the concatenated string in parentheses. For policies within the deny policy set, connect the policy body constraints using "OR", enclose the concatenated string in parentheses, and then add "NOT" before the concatenated string. Finally, connect the two strings using "OR" to obtain the selector for that resource node.

[0131] Those skilled in the art can understand this embodiment as a more specific description of Embodiment 1.

[0132] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0133] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. An event filtering method based on event attributes and resource node state constraints, characterized in that, The method includes the following steps: Step S1: The policy processing module reads all policies defined using EFPL from the policy repository; Step S2: The policy processing module parses the policy and converts it into an internal object; Step S3: The event subscriber provides node information and subscription information to generate a node-corresponding selector; Step S4: The strategy processing module generates a selector based on the algorithm and returns it to the resource node; Step S5: The resource node passes in the subscribed topic and selector to establish a connection with the event handling module; Step S6: The event producer establishes a connection with the event handling module; Step S7: Obtain data; Step S8: The event producer obtains relevant node information based on the published topic; Step S9: The event producer generates the corresponding event and supplements the information; Step S10: The event producer publishes the event to the corresponding topic; Step S11: The event handling module filters and forwards events based on subscription information and selectors; Step S12: When the status of a resource node changes, update the corresponding information in the node information point; The method is applied to an event filtering system constrained by event attributes and resource node status, including: event publishers, event subscribers, event processing modules, strategy processing modules, and node information points; The event publisher, event subscriber, and event processing module are the three basic components of the publish / subscribe model; The event publisher generates events, the event subscriber consumes events, the event processing module routes and forwards events, the policy processing module parses the filtering policy defined by EFPL and generates a selector for each event subscriber, and the node information point stores resource node status information.

2. The event filtering method based on event attributes and resource node state constraints according to claim 1, characterized in that, The system also includes the Event Filtering Policy Language (EFPL), which is a syntax policy language that expresses constraints based on event attributes and resource node states in event filtering. The Event Filtering Policy Language (EFPL) includes filtering policies, filtering policy sets, and event hierarchies. The filtering policy describes the rules for filtering events on resource nodes, represented as a quadruple, p =<paname,target,condition,entitlement> ; The filtering policy set (PolicySet) consists of multiple policies with the same policy objective expression, represented as a triple, s =<sname,target,policies> ; The event hierarchy defines the inheritance relationship between event types, represented as a triple, h =<hname,event,sub_event> .

3. The event filtering method based on event attributes and resource node state constraints according to claim 2, characterized in that, The pname in the filtering policy is the policy name, which uniquely identifies the filtering policy. `target` is the policy target expression. When the target expression is True, the filtering policy is adopted. The target expression contains attributes such as event type and resource node ID. The condition is the main constraint of the strategy, specifically the event filtering conditions; The entitlement = {permit, deny} represents the policy entitlement, indicating the decision returned by the policy after satisfying the policy subject constraints; permit indicates that the event is not filtered, deny indicates that the event is filtered, and the policy return value is deny.

4. The event filtering method based on event attributes and resource node state constraints according to claim 2, characterized in that, The sname in the PolicySet is the policy set name, which uniquely identifies the filtering policy set. `target` is the target expression for the policy set. When the target expression is True, the policy set is used. policies={p1,p2,...,p |policies| } represents a finite set of filtering strategies contained in the filtering strategy set.

5. The event filtering method based on event attributes and resource node state constraints according to claim 2, characterized in that, The hname in the event hierarchy is the name of the event hierarchy, which uniquely identifies the event hierarchy; event is the upper-level event type; sub_event is the set of lower-level event types.

6. The event filtering method based on event attributes and resource node state constraints according to claim 1, characterized in that, In step S4, when the policy processing module generates the selector, the resource node needs to match the corresponding policy, calculate the value of the target expression in the policy or policy set, and find the relevant event type set of each resource node according to the event hierarchy by using the relevant event type set construction algorithm during the process of matching the filtering policy of the resource node.

7. The event filtering method based on event attributes and resource node state constraints according to claim 6, characterized in that, The algorithm for constructing the relevant event type set includes the following steps: Step 1: Construct a parent event table based on the event hierarchy definition, and find the parent event for each event type; Step 2: For each resource node, construct an empty set of related event types and an auxiliary queue, and insert the event types subscribed to by the node from the tail of the auxiliary queue; Step 3: Pop the first element of the auxiliary queue. If the relevant event type set does not contain the event type, add the event type to the relevant event type set and insert the parent event type of the event type into the auxiliary queue from the tail. Repeat Step 3 until the auxiliary queue is empty. Step 4: When the auxiliary queue is empty, obtain the set of relevant event types for that node.

8. The event filtering method based on event attributes and resource node state constraints according to claim 7, characterized in that, After the resource node constructs the relevant event type set according to the relevant event type set construction algorithm, it constructs its corresponding selector through the selector construction algorithm. The selector construction algorithm includes three steps: matching, classification and transformation.

9. The event filtering method based on event attributes and resource node state constraints according to claim 8, characterized in that, The selector construction algorithm includes three steps: Matching: Resource nodes calculate the value of the target expression of the filtering policy and the filtering policy set based on their relevant event type set and their ID, and search for their corresponding policy and policy set; Classification: Resource nodes categorize the matched policies and policy sets into allowed policy sets and denied policy sets based on policy rights; Transformation: For policies in the allow policy set, connect the policy body constraints with "OR" and enclose the connected string in parentheses; for policies in the deny policy set, connect the policy body constraints with "OR", enclose the connected string in parentheses, add "NOT" before the connected string, and finally connect the two strings with "OR". The resulting string is the selector for the resource node.

Images