1. Chapter 5
Events, Timing, and Causality
jwj0831@gmail.com

2. Topics covered in this Chapter
●
●
●
●
●
●
●
●
What events are
How events are created
The form, significance, and relativity of an event
Timing, causality, and aggregation
Genetic parameters of events
Partial orderings of events
Timing requirements expressed as patterns of events
Examples of causal tracking of interprocess acitivity

3. 5.1 What Events Are 1/3
● An event is an object that is a record of an activity in a
system.
● The event siginfies the activity
● An event may be reated to other events.
● An events has three aspects
○ Form: The form of an event is an object.
○ Significance: An event signifies an acitivity.
○ Relativity: An activity is related to other activities by
time, causality, and aggregation.

4. 5.1 What Events Are 2/3
● The form of an input event would be an object of a Java
class called InputEvent:
Class InputEvent {
Name
NewOrder;
Event_Id E_Id;
Customer Id;
OrderNo O_Id;
Order(CD X, Book …);
Time
T;
Causality (Id1, Id2, …)
}
● Every event has a unique identifer field, Event_Id
● The Time filed is the timestamp.
● The Causality attribute of the event provides a way of
tracing its causal history.

5. 5.1 What Events Are 3/3
● There are two confusions between everyday usage and
CEP that we ant to avoid.
○
○
The first is confusing the everday usage of “event” as “something that
happens” with the CEP concept of an event as an object signifying an
activity.In event processing, we are processing event object and
not activities.
Another confusion happens often in computer science: It is quite
common to confuse an event with its form, such as “An event is just a
message.” This confusion ignores the other aspects of events. The
forms of events may be message, but the events also have
significance and relativity. Event processing is different from
message processing because it must deal with the relationships
between events.

6. 5.2 How Events Are Created
● To apply CEP to a target enterprise system, we must be
able to create events that signify the activities that are
happening in the system.
○ Observation Step
○ Adaptation Step
● There are three principal sources of events in modern
enterprise systems.
○ IT Layer
○ Instruementation
○ CEP

7. 5.3 Time, Causality, and Aggregation
1/4
● Time: Time is a relationship that orders events-for
example, event A happened before event B.
● A time relationship between events depends upon a
clock.
● Typically, when the event’s activity happens, the event
is created and a reading from a clock is entered into the
event as its timestamp.
● The order of their timestamps defines the time
relationship between the events.

8. 5.3 Time, Causality, and Aggregation
2/4
● Cause: If the activity signified by event A had to happen
in order for the activity signified by event B to happen,
then A caused B.
● Causality is a dependence relationship between
activities in a system.

9. 5.3 Time, Causality, and Aggregation
3/4
● Aggregation: If event A signfies an activity that consists
of the activities of a set of events, B1, B2, B3, ..., then A
is an aggregation of all the events Bi. Conversely, the
events Bi are members of A.
● Aggregation is an abstraction relationship.
● A is higer-level event.
● We call A a complex event.

10. 5.3 Time, Causality, and Aggregation
4/4
● All these relationships between events have some
simple mathematical properties.
○
○
○
○
transitive:
[Ex: Time]If A is eariler than B, and B is eariler than C, then A is earlier
than C.
asymmetric(antisymmetric):
[Ex: Causality] if A caused B and A isn’t B, then B did not cause A.
● Each of these relationships is called a partial ordering.
● That is, events A and B can exist such that neither A R
B nor B R A is true, where R is any of our three
relationships.

11. 5.3.1 The Cause-Time Axiom
If event A caused event B in system S, then no clock in
S gives B an earlier timestamp than it gives A.
● Systems that satisfy the cause-time axiom have clocks
that all agree in the sense that they do not ‘see’ paris of
causally related events in different orders.

12. 5.4 Genetic Parameters in Events
● Special data parameters are added to an event to
encode its timing and its casual relationships to other
events.
● They are often referred to as genetic parameter.
○ Timestamps
○ Casual vector: A parameter of an event that
contains the identifiers of the set of events that
caused the event.

13. 5.4.1 Timestamps
● Timestamps are a common way to represent the timing
of an event.
● We say “timestamps”, plural, because there are many
situations relating an event to time.
○ The activity may happen over a time interval, in
which case the event contains timestamps for its
start time and end time according to the reading of a
clock in the system.
○ An event can have timestamps indicating readings
from different clocks.

14. 5.4.2 Causal Vectors
● A causal vector is a parameter of an event that contains
the identifiers of the set of events that caused the event.
● Placing causal vectors in the events gives us a practical
way to trace causal relationships in complex systems.
Event A
Event D
Event B
A
Event C
B
C

15. 5.5 Time
● A timing relationship between events created by a
system tells how the system is performing.
● Timing is also an important filter in debugging.

16. 5.5 Time Example 1 1/2
Publish(Subject, TransactionId, Message, Time, ...)
Publish(StockTrade, A05643094, IBM, 09.51EST, ...)
Publish(StockTrade, A05643302, CSCO, 09.52EST, ...)
Receive(StockTrade, A05643309, CSCO, 10.02EST, ...)
Publish(StockTrade, A05650309, JWEB, 09.53EST, ...)
Receive(StockTrade, A05643094, IBM, 09.55EST, ...)
● A typical example is a publish/subscribe middleware
system.
● Suppose the system has to be set up as the IT layer of
some enterprise to meet a timing requirement.

17. 5.5 Time Example 1 2/2
● If middleware message contain timestamps, an in this
example, we can use CEP to monitor that all Publish
messages are routed to subscribers and received within
a specified time deadline.
● By using CEP, we can easily deal with the issue that
their order of observation might be different from their
order of execution.
● The concept that makes this possible is event pattern
matching.
● Event patterns are a powerful way to state our
deadline requirement simply and concisely.

18. 5.5 Time Example 2 1/2
● This example uses a simple pattern language that is
described in the netxt chapter.
Rule: Check Timely Delibery
Element
Declarations
Variable
Subject S, Message M, String Id, Time T, T1, T2
Event types
Publish(Subject S, String Id, Message M, Time T),
Receive(Subject S, String Id, Message M, Time T),
Warning(String Id, Time T)
Relational operators
and
Pattern
Publish(StockTrade, Id, M, T1) and Receive(StockTrade, Id, M, T2)
Context test
T2 - T1 >= 10 mins
Action
create Warning(Id, T2 - T1)

19. 5.5 Time Example 2 2/2
● The variable row defines the variables in the pattern.
● The event types row defines the types of events in the
pattern.
● The relational operators row defines the relational
operator between events that is used in the pattern.
Publish(StockTrade, A05643302, CSCO, 09.52EST, ...)
Receive(StockTrade, A05643302, CSCO, 10.22EST, ...)
Warning(A05643302, 30min)
● CEP rules like this example are called constraints
because their purpose is to check a system's
performance for violation of requirements

20. 5.6 Causality and Posets 1/2
● A set of events together with their causal relationship is
called poset, partially ordered set of events.
● Posets are often represented graphically by DAGs,
directed acyclic graphs.
● The essential role of causality is to focus the search
space for the causes of some activity.
● Each event in a poset has a causal history consisting of
the events that caused it, their causes, and so on.

21. 5.6 Causality and Posets 2/3
Deposit (5, A1)
Deposit (10, A2)
Transfer (5, A1, A2)
Deposit (10, A1)
Deposit (5, A2)
Withdraw (15, A1)
Deposit (10, A2)
Overdraft (A1)

22. 5.6 Causality and Posets 3/3
● If we search for what caused the Overdraft event on
account A1, we will look at its causal predecessors in
the graph-that is, its causal history, which is shaded in
the figure.
● This shows that the Overdraft on account A1
depends upon a Transfer from A1 to A2.
● This event will be chosen as the probable real cause.
● The figure shows that a causal history can contain
irrelevent events, such as the first deposit on account
A2.

23. 5.7 Causal Event Executions- Realtime Posets
● A causal event execution is a poset consisting of events
generated by a system and their relationships.
● We use "causal event execution" to emphasize that we
are dealing with events and their relativities online real
time.

24. 5.7 Causal Event Executions- Realtime Posets Ex1 1/2
● Events are transmitted between pairs of nodes in a
network according to a protocol.
Send
M2,1
Wait
M2,1
RecAck
M1,0
Send
M1,0
TimeOut
M,0
Ack
M1,0
Receive
M,0
Ack
M,0
Send
M,0
Wait
M,0
Receive
M1,0
ReSend
M,0
Receive
M,0
Ack
M,0
RecAck
M,0
1
2
3
4
5
6
7
time

25. 5.7 Causal Event Executions- Realtime Posets Ex1 2/2
Send
M2,1
Wait
M2,1
RecAck
M1,0
Send
M1,0
TimeOut
M,0
Ack
M1,0
Receive
M,0
Ack
M,0
Send
M,0
Wait
M,0
Receive
M1,0
ReSend
M,0
Receive
M,0
Ack
M,0
RecAck
M,0
1
2
3
4
5
6
7
time

26. 5.8 Orderly Obsercation
● If their time of arrival is consistent with their causal
relationship in the target system, we say that the
observation is orderly.
Orderly observation: for any pair of events A and B,
if A --> B then ArrivalTime(A) <= ArrivalTime(B)
● Orderly observation is not necessary for CEP to apply to
a system. But it is convenient and makes some
applications of CEP simpler and easier to implement.

27. 5.9 Obsercation and Uncertainty 1/2
● The events created by CEP can be thought of as
event inferences drawn from observed events.
● CEP may also process these event inferences and use
them to create more inferences.
● Event inferences can signify activities within the system
that were not signified by events observed in the system
itself.

28. 5.9 Obsercation and Uncertainty 2/2
● The totality of what we can observe, together with what
we can infer, is called observable system
● Observable System: The set of all events that can be
observed from a target ssytem, or inferred from
observations, is called the observable system.
● Uncetainty Principle
○ An activity within a target system may not have any signifying
event in the observable system.
○ We must always bear in mind that there may be activities going
on in the system that we cannot know about.