The Power Of Event Chapter 5


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Power Of Event Chapter 5

  1. 1. Chapter 5 Events, Timing, and Causality
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.