Not applicable.
Not applicable.
Not applicable.
Distributed event-based systems find wide applications in many communication systems and networks such as clouds, internet of things (IoT), and Software-defined Networks (SDN). In the distributed event-based systems, notifications are generated by event sources according to subscriptions from event sinks and are routed from the event sources to the event sinks through interconnected event brokers. For real-time communications, the event sinks may receive the notifications from a large number of event sources such as virtual machines, traffic lights, switches, and phones.
The subscriptions may describe general properties of the notifications that the event sinks want to receive from the event sources. For example, the event sinks may transmit subscriptions for new books to the event sources. In response to the subscription, the event sources may send a notification to the event sinks whenever a new book is released. However, the event sinks may only want to receive certain categories of new books. For example, the event sinks may only want to receive new parenting books, not new romance books. Therefore, the event sinks may receive many unnecessary notifications from the event sources based on the subscriptions.
One method to reduce the unnecessary notifications from the event sources is content-based filtering. During content-based filtering, the event sinks transmit filters in addition to the subscriptions to the event sources using interconnected event brokers within a network in order to restrict the notifications that the event sinks receive. For example, the event sinks may transmit a filter for new parenting books to the event sources through the event brokers of the network. By doing so, the event sinks only receive new books corresponding to parenting.
In an embodiment, the disclosure includes a filter manager of an event broker, comprising a receiver configured to receive a package uniform resource identifier (URI) from an event sink, wherein the package URI links to a filter package stored in a package server, and wherein the filter package includes URIs of a plurality of filters, a processor operably coupled to a memory and the receiver, wherein the processor is configured to transmit a request for the filter package to the package server according to the package URI, receive the filter package from the package server in response to the request for the filter package, and unpack the filter package to obtain the plurality of filters according to the URIs of the plurality of filters following receipt of the filter package.
In another embodiment, the disclosure includes a method for filter covering-based notification routing implemented in an event broker, comprising receiving, by a filter manager, a first subscription and a second subscription from a child node, transmitting, by the filter manager, a request for a first filter and a second filter to a package server, wherein the first filter corresponds to the first subscription and the second filter corresponds to the second subscription, receiving, by the filter manager, a filter package from the package server, creating, by the filter manager, the first filter and the second filter in the event broker based on the filter package, wherein the first filter and the second filter implement a filter service provider interface (SPI), forwarding, by the filter manager, the first subscription and the second subscription to an event source after the first filter and the second filter have been created, receiving, by the filter manager, notifications corresponding to the first subscription and the second subscription from one of the event source and an event source simulator in response to the first subscription and the second subscription having been forwarded, determining, by the filter manager, a first number of the notifications in a first set of the notifications and a second number of the notifications in a second set of the notifications, wherein the first set of the notifications satisfies both the first filter and the second filter, and wherein the second set of the notifications satisfies the second filter, and comparing, by the first manager, the first number and the second number, wherein the first filter covers the second filter when the first number is equal to the second number.
In yet another embodiment, the disclosure includes an event broker, comprising a receiver configured to receive a first subscription and a second subscription from a child node, a processor operably coupled to a memory and the receiver, wherein the processor is configured to transmit a request for a first filter and a second filter to a package server, wherein the first filter corresponds to the first subscription and the second filter corresponds to the second subscription, receive a filter package from the package server, create the first filter and the second filter in the event broker based on the filter package, wherein the first filter and the second filter implement a filter SPI, forward the first subscription and the second subscription to an event source after the first filter and the second filter have been created, receive notifications corresponding to the first subscription and the second subscription from one of the event source and an event source simulator in response to the first subscription and the second subscription having been forwarded, determine a first number of the notifications in a first set of the notifications and a second number of the notifications in a second set of the notifications, wherein the first set of the notifications satisfies both the first filter and the second filter, and wherein the second set of the notifications satisfies the second filter, and compare the first number and the second number, wherein the first filter covers the second filter when the first number is equal to the second number.
These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
One problem of content-based filtering is that the event sources may transmit redundant notifications to the event sinks according to the filters when a filter-covering relationship is satisfied. The filter-covering relationship indicates that a first filter covers a second filter when a set of the notifications that satisfy the first filter is a superset of a set of the notifications that satisfy the second filter. For example, when the first filter requests for the new books with prices below $20 and the second filter requests for the new books with prices below $15, the filter-covering relationship that the first filter covers the second filter is satisfied. As a result, the notifications that satisfy the second filter are included in the notifications that satisfy the first filter. In other word, the notifications that satisfy the second filter are redundant notifications because they are transmitted twice when the event sources transmit the notifications according to both the first filter and the second filter.
A large amount of the redundant notifications may congest the network between the event sinks and the event sources. In order to reduce the redundant notifications, the event sources may unsubscribe the second filter and transmit the notifications according to the first filter when the first filter covers the second filter. This technique is called “covering-based routing.” In the existing solutions, the filter-covering relationship is determined by comparing the filters based on the filtering languages that express the filters.
Table 1 shows some common content languages that may express the notifications and the corresponding filtering languages that may express the filters (e.g., f1 110, f2 120, f3 130, f4 140, f5 150, and f6 160). In a heterogeneous service-oriented architecture (SOA), the notifications may be expressed in various content languages as listed in Table 1. The event sources determine the content languages and the corresponding filtering languages. The event brokers of the network between the event sources and the event sinks forward the subscriptions and the notifications and do not determine the content language or the filtering languages. Such SOA impose some technical issues on determining filter-covering relationships based on the filtering languages. First, it is difficult to ensure that the event brokers understand all the content languages and the filtering languages to determine the filter-covering relationships, particularly when the numbers of the content languages and the filtering languages increase with time. Second, some content languages (e.g., Hyper Text Markup Language (HTML), Yet Another Markup Language (YAML), Atom, and Rich Site Summary (RSS)) may not have corresponding filtering languages. Therefore, the event brokers cannot determine the filter-covering relationships based on the filtering languages. Third, it is difficult to determine the filter-covering relationships between the filters expressed in some specific filtering languages due to lack of efficient comparing algorithm. For example, such specific filtering languages may include extensible markup language query (XQuery) and simple protocol and resource description framework (RDF) query language (SPARQL). Fourth, it is difficult to determine the filter-covering relationships between the filters expressed in different filtering languages (e.g., XQuery and SPARQL). Fifth, the exposure of the filtering languages to the event brokers may increase security threats to the event sources and/or the event sinks. Therefore, a need exists for an alternative filter covering-based notification routing scheme without determining the filter-covering relationships based on the filtering languages.
Disclosed herein are various embodiments for filter covering-based notification routing without comparing filters based on filtering languages. Event sinks communicate the subscriptions to the event sources. Each subscription includes a uniform resource identifier (URI) of one of the filters, which consist of executable code packaged by a package server. In an embodiment, the package server is one of the event sinks. In an embodiment, the package server is a server in communication with the event sinks. The event sinks further transmit the subscriptions to the event sources through a plurality of event brokers within a network. All event brokers in a path connecting the event sinks and the event sources may receive the subscriptions. In addition, all the event brokers in the path connecting the event sinks and the event sources receive the filter packages from the package server, unpack the filter packages to obtain URIs of the filters, load the filters into the memory according to the URIs of the filters, and register the filters in filter registrations of the event brokers. Each of the filter registrations designates a filter service provider interface (SPI). The event brokers may invoke the filters through the filter SPI without knowing the filtering languages of the filters. One of the event brokers in the path connecting the event sinks and the event sources may be selected to determine a filter-covering relationship between any two of the filters based on the outcome of invoking the filters. For example, the selected event broker receives notifications from the event sources or event source simulators corresponding to a first filter and a second filter. Following receipt of the notifications, the selected event broker determines a first set of the notifications that satisfy both the first filter and the second filter. The selected event broker further determines a second set of the notifications that satisfy the second filter. A first number represents the cardinality of the first set of the notifications, which indicates a total number of the notifications in the first set. A second number represents the cardinality of the second set of the notifications, which indicates a total number of the notifications in the second set. The selected event broker determines a probability by dividing the first number by the second number. When the probability is equal to 1 (i.e., the first number is equal to the second number), it is determined that the first filter covers the second filter indicating the second set of the notifications that satisfies the second filter are redundant notifications. When the probability is not equal to 1, it is determined the first filter does not cover the second filter. When the first filter covers the second filter, the selected event broker informs its parent event broker to unsubscribe the second filter. The parent event broker is a neighboring event broker of the selected event broker in the path closer to the event sources. The parent event broker unsubscribes the second filter and informs its parent event broker to unsubscribe the second filters, and so on, until the event sources are informed to unsubscribe the second filters. Finally, the event sources unsubscribe the second filter so that they only transmit notifications that satisfy the first filter to the event sinks over the network. As a result, the redundant notifications (e.g., the second set of the notifications) from the event sources due to the second filter are reduced.
Since the filter-covering relationships are determined based on the outcome of invoking the filters rather than examining the filtering languages, the method for filter covering-based notification routing may be implemented in a distributed event-based system in an attempt to resolve the issues noted above. In addition, the method is efficient in performing the filter covering-based notification routing and is compatible with the existing distributed event-based systems. Moreover, the distributed event-based systems that employ the method may be scalable and more secure for the event sources and event sinks by hiding the filtering languages.
The network 230 comprises a plurality of event brokers such as event brokers 220A, 220B, 220C, 220D, and 220E interconnected with links 240. Each of the event brokers 220A, 220B, 220C, 220D, and 220E may be configured to communicate messages (e.g., the notifications, the subscriptions, and/or other messages) with the clients 210A, 210B, 210C, 210D, 210E, and 210F and forward the messages inside the network 230. In an embodiment, the links 240 may be physical links such as electrical cables and/or optical fibers. In an embodiment, the links 240 may be virtual links or wireless links. The clients 210A, 210B, 210C, 210D, 210E, and 210F communicate with the event brokers 220A, 220B, 220C, 220D, and 220E of the network 230 by using client-server protocols such as Hypertext Transfer Protocol (HTTP) and/or Extensible Messaging and Presence Protocol (XMPP).
In an embodiment as shown in
Each of the event brokers in the path (e.g., the event brokers 220A, 220B, 220C, and 220D) is coupled to a child event broker, a parent event broker, or both. The child event broker refers to a neighboring event broker in the path that is closer to the event sinks. The parent event broker refers to a neighboring event broker in the path that is closer to the event sources. For example, the event broker 220A is a child event broker of the event broker 220B and does not have a parent event broker. The event broker 220B is a parent event broker of the event broker 220A and a child event broker of the event broker 220C. The event broker 220D is a parent event broker of the event broker 220C and does not have a parent event broker.
The event broker 320 is coupled to a child node 370, which may be a child event broker or the event sinks (e.g., the client 210A and the client 210B). The event broker 320 is further coupled to a parent node 380, which may be a parent event broker or event sources 310 (e.g., the client 210E and the client 210F). For example, when the event broker 320 is the event broker 220A in
The event broker 320 creates the plurality of filters 360 upon receipt of subscriptions from the child node 370 and the plurality of filters 360 from a package server (not shown), which is described in further details in
In an embodiment, the plurality of filters 450 and 460 may be deployed in the event broker 430 after subscriptions 412. The event sink 410 transmits the subscriptions 412 (“[POST/subscriptions Package_URI, Filter_URI]”) to the filter manager 440. The subscriptions 412 indicate a package uniform resource identifier (URI) (Package_URI) and a filter URI (Filter_URI). The plurality of filters 450 and 460 are packed in a filter package in the package server 420. The Package_URI identifies a name of the filter package stored in the package server 420. The Filter_URI includes a URI for each of the filters 450 and 460.
In response to the subscriptions 412, the filter manager 440 transmits a request 422 for the filter package with a message “GET Package_URI” according to the Package_URI to the package server 420. The package server 420 transmits the filter package 424 to the filter manager 440 in response to the request 422 for the filter package 424. Following receipt of the filter package 424, the filter manager 440 unpacks the filter package 424 and obtains the plurality of the filters 450 and 460 according to the Filter_URI with a procedure “[unpack (Filter Class, Filter_URI)]” 426. Each of the plurality of filters 450 and 460 may be defined as a filter class.
Next, the filter manager 440 creates (e.g., instantiates objects from a class) the plurality of filters 450 and 460 and registers the plurality of filters 450 and 460 in the filter registration 470 one by one. For example, the filter manager 440 creates f1 450 by creating a first new filter object 442 named f1 and storing f1 450 in the event broker 430. The filter manager 440 further registers f1 450 in the filter registration 470 with a procedure “register(URI_1, f1)” 444, where URI_1 is the URI of f1 450. Similarly, the filter manager 440 creates fk 460 by creating a second new filter object 446 named fk and storing fk 460 in the event broker 430. The filter manager 440 further registers fk 460 in the filter registration 470 with a procedure “register(URI_k, fk)” 448, where URI_k is the URI of fk 460.
After all the filters 450 and 460 have been registered in the filter registration 470, the filter registration 470 designates a filter SPI (e.g., the filter SPI 350) to manage the plurality of filters 450 and 460 so that the event broker 430 may invoke the filters 450 and 460 through the filter SPI without knowing the filtering languages of the filters 450 and 460. The filter manager 440 then transmits a message “[201 Created]” 452 to the event sink 410 indicating the plurality of filters 450 and 460 are deployed in the event broker 430. The protocol is concluded after transmission of the message 452.
In an embodiment, the plurality of filters 450 and 460 may be deployed in the event broker 430 before subscriptions 455. The method for this embodiment is similar to the method described above except for two differences. First, the event sink 410 initially transmits a filter registration message 411 ([POST/filter_registration Package_URI]) to the filter manager 440 rather than the subscriptions 412 (“[POST/subscriptions Package_URI, Filter_URI]”). The filter registration message 411 indicates the package_URI. Second, in response to the message ([201 Created]) 452, the event sink 410 further transmits the subscriptions 455 ([POST/subscriptions Filter_URI]) to the filter manager 440, where Filter_URI indicates the URIs of the plurality of filters 450 and 460 deployed in the event broker 430. The protocol is concluded after transmission of the subscriptions 455.
The filter manager 540 receives a filter package 524 (e.g., the filter package 424) from a package server (e.g., the package server 420). In an embodiment, the filter package 524 may be expressed by docker images in the open-source docker container technology. In an embodiment, the filter package 524 may be a web application archive (WAR) file as shown in
Following receipt of the filter package 524, the filter manager 540 creates the plurality of filters 550 and 560, and registers the plurality of filters 550 and 560 in the filter registration 570. In an embodiment, the filter manager 540 may instruct the filter registration 570 to add the filters 550 and 560 using a procedure “add_filter(Filter_object, Filter_URI),” where Filter_object may refer to the names of the filters 550 and 560. In an embodiment, the filter manager 540 may instruct the filter registration 570 to remove the plurality of the filters 550 and 560 using a procedure “remove_filter(Filter_URI).”
The filter registration 570 further designates the filter SPI 575 to manage the plurality of the filters 550 and 560 so that the event broker 530 may invoke the filters 550 and 560 through the filter SPI 575 without knowing the filtering languages of the filters 550 and 560. The filters 550 and 560 may be used through the filter SPI 575 with a procedure “filter(context, notification).” The notification 580 may be obtained by using a procedure “get_content( )” The context 520 may be any additional information not indicated in the notification 580. For example, the context 520 may indicate a specific time that the filters 550 and 560 may be used in a different way from other time through the filter SPI 575. Such context 520 may be obtained by using a procedure “get_timestamp( )” For another example, the context 520 may indicate an event source of the notification 580 (e.g., the client 210E and/or the client 210F). Such context 520 may be obtained by using a procedure “get_source( ).”
In an embodiment, the procedure “filter(context, notification)” may return a binary number or a Boolean value (true or false) indicating a filtering result of the notification 580 in the context 520. For example, the binary number may be 1 when the notification 580 satisfies the filter (e.g., the filter 550 or 560) in the context 520. For another example, the binary number may be 0 when the notification 580 does not satisfy the filter (e.g., the filter 550 or 560) in the context 520.
The filter manager 540 further receives subscriptions 512 (e.g., the subscriptions 412 or the subscriptions 455). The subscriptions 512 may indicate Filter_URI, the expiry of the subscriptions 512, and a URI of an event sink (e.g., the event sink 410) which transmits the subscriptions 512. Following receipt of the subscription 512, the filter manager 540 forwards the subscriptions 512 to the subscription manager 590, which may add the subscription 512 according to the Filter_URI, the expiry of the subscription 512, and the URI of the event sink (e.g., the event sink 410) with a procedure “add subscription(Filter_URI, Expiry, Event sink_URI)” or remove the subscriptions 512 according to an URI of the subscription (subscription_URI) with a procedure “remove_subscription(subscription_URI).”
In an embodiment, the subscription 512 is similar to the subscription 412. The filter manager 540 may receive the filter package 524 after the subscriptions 512. In an embodiment, the subscription 512 is similar to the subscription 455. The filter manager 540 may receive the filter package 524 before the subscription 512.
After the plurality of filters (e.g., the filters 550 and 560) are deployed in the event broker (e.g., the event brokers 430 and 530), the filter manager (e.g., the filter managers 330, 440, and 540) employs a statistical model to determine the filter covering relationship between any two of the plurality of filters (e.g., the filters 360, 450, 460, 550, and 560). In the statistical model, PN (filter-covering relationship) is defined as a probability when the filter-covering relationship is satisfied for a nonempty set of notifications (e.g., the notifications 580) represented by N.
P
N(fx≧fy)=PN(fx|fy)=PN(fxfy)/PN(fy)=(N(fxfy)/|N|)/(N(fy)/|N|)=N(fxfy)/N(fy) (1)
where PN(fx|fy) represents a conditional probability that the notifications in set N satisfy fx if the notifications in N satisfy fy, PN(fx fy) represents a joint probability that the notifications in N satisfy both fx and fy, PN(fy) represents a probability that the notifications in N satisfy fy, N(fxfy) represents a number of the notifications in N that satisfy both fx and fy, |N| represents the cardinality of set N indicating the total number of the notifications in N, and N(fy) represents a number of the notifications in N that satisfy fy. According to equation (1), the filter manager (e.g., the filter managers 330, 440, and 540) may determine the filter-covering relationship between fx and fy by dividing N(fxfy) by N(fy) without knowing the filtering languages which express fx and fy.
In addition, two properties of a filter-covering relationship may be derived according to equation (1). First, when a first filter covers a second filter, and a second filter covers a third filter, it is determined that the first filter covers the third filter without comparing the first filter and the third filter. Second, when a first filter covers a second filter, and the second filter covers the first filter, it is determined that the first filter is equivalent to the second filter no matter whether their filter languages are the same.
Various methods may be employed by the filter manager (e.g., the filter manager 330, 440, and 540) to implement the statistical model above to determine the filter-covering relationships of a plurality of filters (e.g., the filters 360, 450, 460, 550, and 560). One method to implement the statistical model is described below. In this method, event sources (e.g., the event sources 310) or event source simulators (e.g., the event source simulator 315) transmit m notifications represented by N[1], N[2], . . . , N[m] to an event broker (e.g., the event brokers 320, 430, and 530) which maintains k filters represented by f1, f2, f3, . . . , and fk in order to determine the filter-covering relationship of the k filters. Both m and k are positive integers.
A first matrix S[m+1, k] is created as shown in Table 2, which includes (m+1) rows and k columns. The columns show the k filters and the rows show the m notifications. Each of the first m rows indicates filtering results of the k filters for each of the m notifications as shown in the intersections between the columns and the rows. The filtering results are binary and may be obtained with the procedure “filter(context, notification)” as described in
In addition to the first matrix S[m+1, k], a second matrix C[k,k] is created as shown in Table 3 based on the first matrix S[m+1,k]. In the second matrix C[k,k], both the columns and the rows represent the k filters. A relationship value at each intersection of the columns and rows indicates a filter covering relationship between a first filter represented by the row and a second filter represented by the column corresponding to the intersection. The relationship values in Table 3 may be calculated based on the first matrix S[m+1, k] according to equation (1) by executing the code in Table 4. In an embodiment, the relationship values are 1 when it is determined the first filters cover the second filters based on the first matrix S[m+1,k] (e.g., as illustrated in
The relationship values of the second matrix C[k,k] may be updated whenever the first matrix S[m+1,k] is updated by executing the code in Table 5. The procedure “compute cover(S, C, i, j)” in line 3 of table 5 is defined in lines 10-13 of Table 4.
Each arrow 940 indicates one state (e.g., one of the first state 910, the second state 920, and the third state 930) may transition to the other state (e.g., one of the first state 910, the second state 920, and the third state 930) according to an update of the first matrix S[m+1, k] by the procedures in Tables 4 and 5. For example, the arrow 940 shows the first state 910 may transition to the second state 920, indicating the relationship value may change from 1 to −1 after the first matrix S[m+1,k] is updated by the procedures based on a new set of notifications. As shown in
When it is determined that the first filter covers the second filter (e.g., the relationship value equals 1 in table 3), the second filter is regarded as a redundant filter. As a result, the column representing the second filter in Table 2 and both the row and the column representing the second filter in table 3 are removed by executing the code in Table 6. In addition to remove one or more filters, the filter manager (e.g., the filter managers 330, 440, and 540) may add one or more new filters for new subscriptions by executing the code in Table 7, for example, when the one or more new filters are deployed in the event broker.
Finally, subscriptions (e.g., the subscriptions 512) may be updated by executing the code in Table 8 due to the state transitions as shown in
When the third state 930 transitions to the first state 910, it is indicated that the first filter covers the second filter, while the previous updates did not determine the filter-covering relationship between the first filter and the second filter. Therefore, the subscription manager (e.g., the subscription managers 340 and 590) of the event broker (e.g., the event brokers 320, 430, and 530) instructs the parent event broker of the event broker to remove the subscription corresponding to the second filter. The parent event broker continues to instruct its parent event broker until the event source is instructed to remove the subscription corresponding to the second filter. Finally, the subscription corresponding to the second filter is unsubscribed in all the event brokers of set B (the second filter) and the event source. As a result, the redundant notifications corresponding to the second filter may be reduced from the event sources.
Event sinks 1010 forward subscriptions 1012 to the first event broker H11020. Specifically, the subscriptions 1012 include a first subscription and a second subscription. The first event sink k1 and the second event sink k2 send the first subscription and the second subscription to the first event broker H11020, respectively. Before or after receipt of the subscriptions 1012, the first event broker H11020 receives a first filter fx corresponding to the first subscription and a second filter fy corresponding to the second subscription from a package server (e.g., the package server 420). In response to the subscriptions 1012, the first event broker H11020 creates the first filter fx with a record “(fx, k1)” indicating that the first subscription corresponding to the first filter fx is forwarded from the first event sink k1 to the first event broker 1020. The first event broker H11020 further creates the second filter fy with a record “(fy, k2)” indicating that the second subscription corresponding to the second filter fy is forwarded from the second event sink k2 to the first event broker 1020. After both the first filter fy and the second filter fy are created in the first event broker H11020, the first event broker H11020 forwards the subscriptions 1012 to the second event broker 1030.
Before or after receipt of the subscriptions 1012, the second event broker H21030 receives the first filter fx and the second filter fy from the package server (e.g., the package server 420). In response to the subscriptions 1012, the second event broker H21030 creates the first filter fx with a record “(fx, h1)” indicating that the first subscription corresponding to the first filter fx is forwarded from the first event broker H11020 to the second event broker H21030. The second event broker H21030 further creates the second filter fy with a record “(fy, h1)” indicating the second subscription corresponding to the second filter fy is forwarded from the first event broker H11020 to the second event broker H21030. After both the first filter fx and the second filter fy are created in the second event broker H21030, the second event broker H21030 forwards the subscriptions 1012 to the event source 1040.
Before or after receipt of the subscriptions 1012, the event source 1040 receives the first filter fx and the second filter fy from the package server (e.g., the package server 420). In response to the subscriptions 1012, the event source 1040 creates the first filter fx with a record “(fx, h2)” indicating the first subscription corresponding to the first filter fx is forwarded from the second event broker H21030 to the event source 1040. The event source 1040 further creates the second filter fy with a record “(fy, h2)” indicating the second subscription corresponding to the second filter fy is forwarded from the second event broker H21030 to the event source 1040.
In order to determine the filter-covering relationship between the first filter fx and the second filter fy, the event source 1040 or an event source simulator (e.g., the event source simulator 315) transmits notifications 1024 corresponding to the subscriptions 1012 to the second event broker H21030 after both the first filter fx and the second filter fy are subscribed in the event source 1040. The notifications 1024 include first notifications corresponding to the first filter fx and second notifications corresponding to the second filter fy. A number of the first notifications may be denoted by N(fx). A number of the second notifications may be denoted by N(fy). Upon receipt of the notifications 1024, the second event broker H21030 forwards the notifications 1024 to the first event broker H11020.
Upon receipt of the notifications 2014, the first event broker H11020 forwards the first notifications to the first event sink k1 according to the record “(fx, k1)” and the second notifications to the second event sink k2 according to the record “(fy, k2).” In the meanwhile, a filter manager (e.g., the filter managers 330 and 440) of the first event broker H11020 determines a filter-covering relationship between the first filter fx and the second filter fy based on the notifications 1024. In an embodiment, the filter manager of the first event broker H11020 determines a first number of the notifications 1024 that satisfy both the first filter fx and the second filter fy. The filter manager of the first event broker H11020 further determines a second number of the notifications 1024 that satisfy the second filter fy. When the first number of the test notifications 1024 is equal to the second number of the test notifications 1024, the filter manager of the first event broker H11020 determines the first filter fx covers the second filter fy (e.g., as illustrated in
In an embodiment, the filter manager of the first event broker H11020 determines a number of the first notifications that satisfy the first filter fx and the second filter fy denoted by N(fxfy). When N(fxfy) is equal to N(fy), the filter manager of the first event broker 1020 determines the first filter fx covers the second filter fy (e.g., as illustrated in
When it is determined that the first filter fx covers the second filter fy, a subscription manager (e.g., the subscription managers 340 and 590) of the first event broker H11020 transmits a request message 1034 to remove the second subscription corresponding to the second filter fy to the second event broker H21030. In response to the message 1034, a subscription manager (e.g., the subscription manager 340, 590) of the second event broker H21030 removes the second subscription, for example, by executing the code in Table 8 and unsubscribe the second filter, for example, by executing the code in Table 6. The subscription manager of the second event broker H21030 further forwards the command 1034 to the event source 1040.
In response to the message 1034, the event source 1040 removes the second subscription. As a result, the event source 1040 transmits third notifications 1044 corresponding to the first filter fx to the second event broker H21030. As shown in
The second event broker H21030 forwards the third notifications to the first event broker H11020 following receipt of the third notifications 1044. In an embodiment, the first event broker H11020 forwards a portion of the third notifications which satisfies the second filter fy to the second event sink k2 according to the record “(fy, k2).” The number of notifications in the portion of the third notification that satisfies the second filter fy may be denoted by N′(fy). The first event broker H11020 further forwards the third notifications 1044 to the first event sink k1 according to the record “(fx, k1)” as shown in
At step 1110, a first subscription and a second subscription are received by a filter manager (e.g., the filter managers 330, 440, and 540) from a child node (e.g., the child node 370). The first subscription and the second subscription may be similar to the subscriptions 412. At step 1120, a request (e.g., the request 422) for a first filter and a second filter is transmitted by the filter manager (e.g., the filter managers 330, 440, and 540) to a package server (e.g., the package server 420). The first filter corresponds to the first subscription, and the second filter corresponds to the second subscription. In an embodiment, the first filter and the second filter are requested as a filter package (e.g., the filter packages 424 and 524).
At step 1130, the filter package (e.g., the filter packages 424 and 524) is received by the filter manager (e.g., the filter managers 330 and 440) from the package server (e.g., the package server 420). In an embodiment, the filter package is a WAR file. Step 1110 may take place before the step 1120. Alternatively, step 1110 may take place after the step 1130.
At step 1140, the first filter and the second filter are created in the event broker based on the filter package by the filter manager (e.g., the filter manager 330 and 440). The first filter and the second filter may implement a filter SPI (e.g., the filter SPIs 350 and 575) so that the event broker may invoke the first filter and/or the second filter through the filter SPI without knowing the filtering languages of the first filter and/or the second filter.
At step 1150, the first subscription and the second subscription are forwarded to an event source (e.g., the client 210E, the client 210F, the event sources 310, and the event source 1040) by the filter manager (e.g., the filter managers 330 and 440) after both the first filter and the second filter have been created. At step 1160, notifications corresponding to the first subscription and the second subscription are received by the filter manager (e.g., the filter managers 330, 440, and 540) in response to the first subscription and the second subscription having been forwarded. In an embodiment, the notifications are received from the event sources (e.g., the client 210E, the client 210F, the event sources 310, and the event source 1040). In an embodiment, the notifications are received from the event source simulator (e.g., the event source simulator 315).
At step 1170, a first number of the notifications in a first set of the notifications and a second number of the notifications in a second set of the notifications are determined by the filter manager (e.g., the filter managers 330 and 440). The first set of the notifications satisfies both the first filter and the second filter. The second set of the notifications satisfies the second filter. At step 1180, the first number and the second number are compared by the filter manager (e.g., the filter managers 330, 440, and 540). Based on the comparison, the filter-covering relationship between the first filter and the second filter is determined by the filter manager. For example, it is determined that the first filter covers the second filter when the first number is equal to the second number (e.g., as indicated in
The processor 1220 may be implemented by hardware and software. The processor 1220 may be implemented as one or more CPU chips, cores (for example, as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 1220 is in communication with the Rx 1212, the Tx 1232, and the memory 1222.
The memory 1222 includes one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 1222 may be volatile and non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM). In an embodiment, a filter manager module 1240 (e.g., the filter managers 330 and 440) and a subscription manager module 1250 (e.g., the subscription managers 340 and 590) are implemented as instructions stored in the memory 1222 such that when executed by the processor 1220, or implemented in part in the processor 1220 and in part in the memory 1222 causes the processor 1220 to perform the method 1100.
While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.