2. Topics covered in this Chapter
●
●
●
●
Event aggregation
Complex events
Event abstraction hierarchies
Personalized and role-based views of hierarchical
systems
3. 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.
4. 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.
5. 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.
6. 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. 7.2 Creating Complex Events 2/4
Example: 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)
8. 7.2 Creating Complex Events 3/4
Example: 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 7.4.1 Viewing Network Activity
Step 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)
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)
Level 1
14. 7.4.1 Viewing Network Activity
Step 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.
15. 7.4.1 Viewing Network Activity
Step 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)
