Chapter 7Complex Events and Event Hierarchies

jwj0831@gmail.com

Topics covered in this Chapter

● Event aggregation● Complex events● Event abstraction hierarchies● Personalized and role-based views of hierarchical

systems

7.1 Aggregation and Complex Events

● A complex event is an aggregation of other events, called its members as defined in Section 5.3.

● The relationship between a complex event and its members is called aggregation.

● A complex event can signify an acitivity that consists of several activities in different parts of a distributed system.

● Conceptually, we think of a complex event as an event at a higher level thatn the levels of its members.

7.1 Aggregation and Complex Events Example 1: A CPU instruction, Add(X, Y)

● An Add instruction of a processor is a complex event made up of a set of events generated by the registers, asynchronous logic units, control units, and the clock of a processor.

● The Add event is thought of as being an event at the instruction level, and its member events are thought of as being at a lower level, the resigter transfer level of the processor.

7.1 Aggregation and Complex Events Example 2: Message M has been routed to client C based upon C’s

● Clients running applications on messaging middleware can request the contents of messages to be tested before receiving them.

● This event signifies a successful content-based routing activity carried out on a publish/subscribe middleware.

● It aggregates several middleware events and rules engine events.

7.2 Creating Complex Events 1/4

● Event pattern rules are used in CEP to create complex events siginifying the acitivities of sets of events.

● We refer to rules used to create complex events as aggregation rules.

● This use of event pattern rules gives us a powerful method of recognizing significant high-level events from among a cloud of low-level events.

7.2 Creating Complex Events 2/4Example: Using event pattern rules

to create complex events

Element Declarations

Variable Node N1, N2, Data D, Bit B, Time T1, T2, T3, T4

Event types Send(Node N1,Node N2, Data D, Bit B, Time T1)Receive(Node N1,Node N2, Data D, Bit B, Time T1)Ack(Node N1,Node N2, Bit B, Timt T1)RecAck(Node N1, Node N2, Bit B, Time T)CompletdTrans(Node N1, Node N2, Time T1, Time T2)

Relational operators ->(causes)

Pattern Send(N1, N2, D, B, T1) -> Receive(N2, N1, D, B, T2) -> Ack(N2, N1, B, T3) -> RecAck (N1, N2, B, T4)

Context test T4 - T1 < TimeBound

Action create CompletdTran(N1, N2, T1, T4)

7.2 Creating Complex Events 3/4Example: Using event pattern rules

to create complex events

● The CompletedTran event is a higher-event. ● Lower-level details, such as the value of the bit used in

the transfer, are abstracted away.● CEP treats CompletedTran just as any other event.● And if needed, the lower-events can be traced back

from the complex event.● Backtracking from a complex event to its member in

CEP is called drill down.

7.2 Creating Complex Events 4/4

● Aggregation is a tool for making the activities in a complex system understandable to humans.

● One of the reasons we need event patterns to create complex events is that a complex event can happen in more than one way-more than one set of lower-level events, related in the right way, can signify the activity of the complex event.

7.3 Event Abstraction Hierarchies● In CEP an event abstraction hierarchy consists of the following

elements.○ A sequence of levels of activities: Each level consists of a

set of descriptioins of system acitivities and, for each activities, a specification of the types of events that signify instances of that acitivity. Level 1 is the lowest level

○ A set of event aggregation rules for each level: For each level(except level 1), there must be a rule for creating each type of event at that level as an aggregation of events at levels below.

● The crucial aspect of this definition is the set of rules specifying how each event at a higher level is an aggregation of events at levels below it.

7.4 Building Personalized Concept Abstraction Hierarchies 1/2● We use event abstraction hierarchies to specify and implement

personalized views of a target system for each stakeholder in the system.

● This is a two step process following the definition in Section 7.3.● Aggregation rules are the key to the second step.

○ The types of events that we choose to view at each hierarchical level must be specified as types of CEP events. This is the step where "personalization" of views takes places.

○ An aggregation rule must be defined for each type of event at each level above level 1.

7.4 Building Personalized Concept Abstraction Hierarchies 2/2● Monitoring refers to observing and analyzing level 1 events.● Viewing refers to computing higher-level complex events using

aggregation rules, and analyzing them by graphical and drill-down techniques.

● CEP allows us to change our hierarchy definition and introduce new aggregation rules on the fly, while the target system is running.

● Viewing shuld be always be flexible, allowing changes to meet shifts of interests in what the target system is doing.

● CEP lets us choose our types of complex events to suit our roles and needs. In other words, we can personalize our views.

7.4.1 Viewing Network ActivityStep 1: Define an Event Abstraction Hierarchy 1/2

Level Activities Event Types

Level 2 Completed transmission CompletedTrans(Node N1, Node N2, Time T1, Time T2)

Degraded performance DegPerf(Node N1, Node N2, Time T, Time T1)

Level 1 Send data with bit Send(Node N1,Node N2, Data D, Bit B, Time T)

Wait for acknowledge Wait(Node N, Data D, Bit B, Time T)

Time out TimeOut(Node N, Time Delta, Time T)

Resend data ReSend(Node N1, Node N2, Data D, Bit B, Time T)

Acknowledge data with bit Ack(Node N1,Node N2, Data D, Bit B, Timt T)

Receive data Receive(Node N1,Node N2, Bit B, Time T)

Receive an acknowledge ReceiveAck(Node N1, Node N2, Bit B, Time T)

7.4.1 Viewing Network ActivityStep 1: Define an Event Abstraction Hierarchy 2/2

● Our goal is to show how an abstraction hierarchy is used to define monitoring and viewing.

● Level 1 activities are those of the alternating bit protocol itself.● Leve 2 defines the activities that are significant to us in our view of

the network protocol activity.● In this example, we choose two views:

○ completed transmission as a measure of good performance○ degraded performance as a measure of bad performance

● Each level 2 event is an aggregation of level 1 events.

7.4.1 Viewing Network ActivityStep 2: Define Aggregation Rules 1/2

Element Declarations

Variable Node N1, N2, Data D, Bit B, Time T1, T2, T3, T4

Event types Send(Node N1,Node N2, Data D, Bit B, Time T1)Receive(Node N1,Node N2, Data D, Bit B, Time T1)Ack(Node N1,Node N2, Bit B, Timt T1)RecAck(Node N1, Node N2, Bit B, Time T)CompletdTrans(Node N1, Node N2, Time T1, Time T2)

Relational operators ->(causes)

Pattern Send(N1, N2, D, B, T1) -> Receive(N2, N1, D, B, T2) -> Ack(N2, N1, B, T3) -> RecAck (N1, N2, B, T4)

Context test T4 - T1 < TimeBound

Action create CompletdTran(N1, N2, T1, T4)

7.4.1 Viewing Network ActivityStep 2: Define Aggregation Rules 2/2

● Drill Down

7521 3 4 6 time

SendM,0

WaitM,0

ReceiveM1,0

RecAckM,0

ReSendM,0

ReceiveM,0

SendM1,0

TimeOutM,0

SendM2,1

AckM1,0

WaitM2,1

ReceiveM,0

RecAckM1,0

AckM,0

AckM,0

Level 1

Level 2 Completed TransmissionM1(2,5)

Completed TransmissionM(1,7)