INTRODUCCIÓN AL CONCEPTO DE REFLEXIVIDAD

Raise an alert whenever an event say type A is followed by at least s, s≥1, non- consecutive events of specific type B, within δ time of event A.

Every occurrence of type A should trigger search for s occurrences of type B within δ time. Figure 8.10 illustrates the query for a pattern where s=2 type B events are of interest. Whenever two consecutive type B events occur within the δ time of event A, then an alert should be raised. No alerts are raised if occurrences of type B does not occur within δ time. Two occurrences of event B are searched for after the first occurrence of type A . Type A followed by two non-consecutive type B is the main event of interest. Any type B occurrence which is beyond the δ time is of no interest and alerts are not raised. If event type A with timestamp ti occurs, a search for event

type B should be initiated by a broadcast notification with a label {A, ti}.

In the figure 8.11, the event type A would trigger a search for the occurrence of succeeding type B with a label {A, ti}. In this case, the windows Wα and Wα+1

are split in two different computing nodes. Both type A and type B occurs in two windows. Under the parallelization, the two windows are placed in two nodes and the occurrences of the event are unknown to each other. The occurrence of the first two type B events (BI and B2) needs to be correlated with the type A event ordered by the timestamp.

In parallelization of event processing, independent occurrences of type A or B need to be carefully aggregated. Suppose the event {A1, ti} is generated from Node Ni and

Figure 8.10: Search for the pattern ABB within δ time

Figure 8.12: Illustration of communication delay for the pattern ABB within δ time

there is a worst case communication delay for the search broadcast notification to reach Node Nj. The worst case communication delay is defined as d for all messages,

as illustrated in Figure 8.12. When a type A event occurs in node Ni, it needs to

send a broadcast notification to all other nodes registered in the system and receive a response from other nodes registered in the system. Under a worst case communication delay, d in the network communication between the nodes, it will take an additional maximum of 2d time to send the notification and to receive the broadcast message. If s consecutive events occur in the system within the δ time, then the total time taken is {2d + δ}.

The algorithm used for the time limited search of the non-consecutive events works in three concurrently executed parts. During the system initiation, every node Ni builds

the following three parameters:

1. Search list, SL is maintained by the node and an entry is made whenever a node intitiates or receives a search.

2. Buffer b, is maintained locally in each node to store all type B events. 3. A response list, RL is maintained for each type B event stored in the buffer. Part1 is executed whenever a node Niencounters a type A, type B or a search request

for type B.

Step1.1 Whenever type A is observed with ti

Step1.1.1 Enter {{Ai, ti}, Ni} in to the SL

Step1.2 Whenever type A is received from other nodes, the search {{Ai, ti}, Nj} is

entered in the SL where (j 6= i)

Step1.3 Whenever type B is observed with tj, enter {B, tj} in the buffer.

Part2 is executed on the buffer of every node Ni

For every {B, tj} in buffer

if there is a {{A, ti}, Nk} in the SL and ti < tj ≤ ti+ δ then

if {A, ti} is in RL for the {B, tj} then

do nothing else

Inform search initiator of {{A, ti}, Nk}.

For {B, tj} enter the corresponding {A, ti} in the RL

end if end if EndFor

Part3, is executed on the SL of every node Ni

For every {{A, ti}, Nk} in the search list SL

if Nk = Ni then

if s responses is received for {{A, ti}, Nk} then

Alert is raised and delete the search {{A, ti}, Nk} from SL

else if (2d+δ) time is elapsed after the entry was made into SL then Delete entry from SL

end if else

Remove {A, ti} after (d+δ) time following its entry in to the SL

end if EndFor

Part4, is executed on the buffer of every node Ni

For every entry in buffer d, check if {B,tj} > d then

Delete the entry from buffer and RL end if

8.5

Evaluation

Splitting an event stream and letting multiple hosts process portions of the stream in parallel is often seen as an effective way of improving timeliness in large-scale dis- tributed event based systems. The Inter-EPN parallelism described in §8.2 argues that, unless some underlying integrity and semantic issues are paid attention, the approach has potential for loss of accuracy while processing even simple, not so un- common, classes of query operators. This evaluation section examines event schemes that can be used for fixing such a loss of accuracy. The algorithm as described in §8.4

is used to evaluate the timeliness and efficiency of the distributed event processing. For brevity, assume that a single stream of events or tuples is continually arriving to be processed and, for simplicity, in the temporal order of event generation times.