The Power Of Event Chapter 6
Upcoming SlideShare
Loading in...5
×
 

The Power Of Event Chapter 6

on

  • 1,503 views

 

Statistics

Views

Total Views
1,503
Views on SlideShare
520
Embed Views
983

Actions

Likes
0
Downloads
2
Comments
0

2 Embeds 983

http://www.notforme.kr 982
http://jwj0831.cafe24.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Power Of Event Chapter 6 The Power Of Event Chapter 6 Presentation Transcript

  • Chapter 6 Event Patterns, Rules, and Constraints jwj0831@gmail.com
  • Topics covered in this Chapter ● ● ● ● ● ● Familiar kinds of pattern searching Event patterns A strawman event pattern language Event pattern rules Event pattern constraints Capturing business rules as event patterns
  • 6.1 Common Kinds of Pattern Searching 1/4 ● We need to be able to describe a pattern of events that we are interested in and quickly find the sets of events that match the pattern. ● To do this, we first need a precise method to describe event patterns. ● One way is to write the pattern in a computer language called an event pattern language(EPL).
  • 6.1 Common Kinds of Pattern Searching 2/4 ● Another way, which many of us are familiar with, is to use a graphical user interface(GUI) such as those provided in popular Web search engines. ○ Unfortunately, search GUIs usually allow only very simple patterns to be described
  • 6.1 Common Kinds of Pattern Searching 3/4 ● Pattern matching applied to other kinds of object than events, such as strings and files, has been around a lot longer than the Internet.
  • 6.1 Common Kinds of Pattern Searching 4/4 ● In CEP we need to specify sets of events that have certain common data in some of the events and also have specific timing, causal, and aggregation relationships between events. ● The need to specify sets of events that have parts in common and specific relativities is a step beyond string searching. ● A pattern language in which we can express such pattherns will necessarily be more complex than string searching language.
  • 6.2 Event Patterns ● An event pattern is a template that matches certain sets of events - the sets you want to find. ● It describes precisely not only the events but also their causal dependencies, timing, data parameters, and context. ● So an event pattern is a template for posets.
  • 6.2 Event Patterns Example Content-Sensitive Pattern All orders from customer C in the last month ● To see if an order matches this pattern, we must look at the data in the order to see if the customer is C and the time bound is met.
  • 6.2 Event Patterns Example Context-Sensitive Pattern All orders from frequent customers in the last month ● The second pattern is similar to the first one, except that instead of searching the data in an order to see if the customer is C, we must evaluate the context of the customer. ● for example, by searching a database to see if the customer is part of the state in which the matching take place.
  • 6.2 Event Patterns Example Filter Pattern 1/2 All orders from customers in response to a discount announcement ● We interpret “in response to” as a causal relationship. ● The pattern picks out from the set of all order events those orders that are caused by the announcement. ● It acts as a filter using the causal relationship between an order event and the announcement event to reduce the space of events to a small part of the incoming events.
  • 6.2 Event Patterns Example Filter Pattern 2/2 Order Confirm Order ... Confirm Order Order ... Order Discount ... ... ...
  • 6.2 Event Patterns Example Complex Pattern 1/2 All orders from customers at the regular price that have led to the customer requesting a reduced price in response to the discount announcement ● The fourth pattern is more complicated. ● Matching this pattern uses relationships between three events: the order, the announcement, and the request in the poset of incoming events. ● This kind of pattern is beyond the power of expression of most event pattern languages.
  • 6.2 Event Patterns Example Complex Pattern 2/2 Discount Order Order Order Confirm Reduction Request Reduction Request ...
  • 6.3 A Strawman Pattern Language ● A Strawman Pattern Language: STRAW-EPL ● This is not a powreful event pattern language. ● STRAW-EPL can be used to specify patterns with three relational operators: and, or, ->(causes) ● Some examples ○ A and B and C: Matches a set of three events, A, B, C ○ A or B or C: Matches any one of A, B, or C ○ A -> B: Matches pairs of events A, B where A causes B
  • 6.3 A Strawman Pattern Language Four Elements of STRAW-EPL 1/2 ● Variables are declared with their types: ○ A variable M of type Message: Message M; ○ A variable T of type Time: Time T; ● Event types have a name and a parameter list of variables and their types: ○ A Send event: Send(Message M, Bit B, Timt T); ○ A ReSend event: ReSend(Message M, Bit B, Time T);
  • 6.3 A Strawman Pattern Language Four Elements of STRAW-EPL 2/2 ● A pattern is a set of event templates together with relationships between the event templates: ○ A Send and Resend with the same message and bit,, and possibly different timestamps: Send(M, B, T1) and ReSend(M, B,T2) ● A context condition is a test that must be true when the pattern is matched: ○ The time between the Send and ReSend event must be less than a bound: 0 < T2 - T1 < 10;
  • 6.3.1 Pattern Matching ● Each match of a pattern is a poset that is an instance of the pattern constructed by replacing variables in the pattern with the values. ● A variable must be replaced by the same value wherever it occurs in the pattern. ● The process of replacing variables in a pattrn with values is called matching.
  • 6.3.2 Writing Patterns in STRAW-EPL ● Patterns in STRAW-EPL are written in a tabular format. ● The table gives the name of the pattern and each of its element ● The tabular format declares ○ the variables(also called placeholders) in the pattern together with their types, ○ the types of events in the pattern, ○ the relational operators used in the pattern, ○ the pattern, ○ and the context test.
  • 6.3.2 Writing Patterns in STRAW-EPL Example Pattern: Data Transfer Pattern: Data Transfer Element Declarations Variable Data D, Bit B, Time T, Time T1, Time T2 Event types Send(Data D, Bit B, Time T) Receive(Data D, Bit B, Time T) Ack(Bit B, Timt T) RecAck(Bit B, Time T) Relational operators ->(causes) Pattern Send(D, B, T1) -> Receive(D, B, T) -> Ack(B, T) -> RecAck (B, T2) Context test T2 - T1 < 10 secs
  • 6.3.2 Writing Patterns in STRAW-EPL Example Pattern: StockTrade Messsage Test Pattern: StockTrade Message Test Element Declarations Variable Subject S, Message M, String Id, Time T, Time T1, Time T2 Event types Publish(Subject S, String Id, Message M, Time T) Receive(Subject S, String Id, Message M, Time T) Relational operators and Pattern Publish(S, Id, M, T) and Receive(S, Id, M, T) Context test T2 - T1 < 35 mins and S = “StockTrade”
  • 6.4 Event Pattern Rules 1/3 ● An event pattren rule is reactive rule that specifies an action to be taken whenever an event pattern is matched. ● An event pattern rule implies a causal relationship between the events that trigger it by matching its pattern and the events that are created when the rule executes its action. ● A reactive rule has two parts: ○ A trigger, which is an event pattern ○ An action, which is an event that is created whenever the trigger matches
  • 6.4 Event Pattern Rules 2/3 ● The causal implication is, whenever an event pattern rule is triggered by a poset of events, the event it creates is caused by the triggering events. ● The triggering events are causal ancestors of the new event.
  • 6.4 Event Pattern Rules 3/3 ● Reactive rules can be either sequential or parallel. ○ A sequential rule implies that all its triggerings take place in a sequence, one after the other. ○ A parallel rule implies that its triggerings take place independently, as if executed by new threads of control. MT502 MT513 MT502 MT502 MT513 Sequential MT513 MT502 MT513 MT502 MT513 Parallel MT502 MT513
  • 6.4 Event Pattern Rules 1/2 Example Rule: Warning of late network data transfer 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) Warning(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 < 1 hour Action create Warning(N1, N2, T1, T4)
  • 6.4 Event Pattern Rules 2/2 Example Rule: Warning of late network data transfer Warning Send Receive Ack TimeOut Resend RecAck TimeOut
  • 6.5 Constraints 1/3 ● A constraints expresses a condition that must be satisfied by the events observed in a system. ● Constraints can be used to specify not only how a target system should behave, but also how its user should use it. ● Our strawman constraints express a very simple of condition called never constraints. ● A never constraint consists of the following: ○ The temporal operator never ○ A STRAW-EPL pattern
  • 6.5 Constraints 2/3 Never Confirm and Then Cancel an Order Element Declarations Variable Customer Id, Item I, OrderNo N, Dollars Price, Time T1, Time T2 Event types Confirm(Customer Id, OrderNo N, Item I, Dollars Price, Time T1) Deny(Customer Id, OrderNo N, Item I, Dollars Price, Time T1) Relational operators and Temporal operator never Pattern Confirm(Id, N, I, Price, T1) and Deny(Id, N, I, Price, T2) Context test T1 <= T2
  • 6.5 Constraints 3/3 ● The purpose of a rule is to create new events in response to situations. ● The purpose of a constraints is different, simply to monitor for a situation. ● Typically, a constraint is used to express a requirement on system behavior that is not guaranteed by the system.