Debs2009 Event Processing Languages Tutorial

eptsevent processing technical society

Event Processing Language Tutorial

François Bry, Michael Eckert, Opher Etzion, Adrian Paschke, Jon Riecke

on behalf of the epts languages analysis working group

epts event processing technical society

2

TUTORIAL OUTLINE

• Introduction

• stream processing languages

• rule oriented languages

Break

• Agent oriented languages

• Temporal semantics

• Integrated development environments

• Formal approaches

• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


3

TUTORIAL OUTLINE

Introduction

• stream processing languages


Break





• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


4

What is it all about?

Consume and react to either raw or complex events

Generate and emit events perform operations on

events

Event Processing

EventConsumer

EventProducer

In this tutorial we are exploring the language issue – how the various event processing functions are expressed?

Filter, transform, enrich, route, Detect patterns, derive events

PatternMatch

Event processing has gained a lot of interest in recent years; according to analysts it is the fastest growing segment of middleware software


5

An ObservationThe Babylon Tower symbolizes the tendencyOf humanity to talk in multiple languages.

The Event Processing area is no different: most languages in the industry really followthe hammer and nails syndrome – and extended existing approaches• imperative script language• SQL extensions• Extension of inference rule language

The epts language analysis workgroup is aimed to understand the various stylesAnd extract common functions that can be used to define what is an event processing language; this tutorial is an interim report

It does not seem that we’ll succeed to settleIn the near future around a single programming style


6

Existing Styles for EP languages (samples)

InferenceRules

Stateoriented

Agent Oriented

Imperative/Script Based

RuleCore

Oracle

Aleri Streambase

Esper

EventZero

TIBCO

WBE

Apama

Spade

AMiT

Netcool Impact

* - if we add simple and mediated event processing the picture is even more diversified

ECARules

SQL extension

Coral8

Agent LogicStarview

XChangeEQProva


7

Dimensions to describe languages

• Events Data and Meta-data

• State

• Computation/execution model

• Programming model


8

The event Data and meta-data dimension

• Event structures supported (structured, semi-structured, unstructured)

• Data types supported for event’s payload

• Event identifiers/identities

• Event time-stamps and ordering

• Event relations

• Other meta-data entities in the language


9

The state dimension

• State of events / data

– Events and other data in states

– Life-cycle, duration policies

– Explicit visibility and manipulation of states

• State of execution

– Context-related grouping (e.g. time windows)

– Explicit visibility into state of execution


10

The execution model dimension

• Execution timing – immediate or deferred ?

• Guarantees: real-time, determinism, latency ?

• Time point or time interval semantics

• Concurrency – implicit / explicit

• Event at a time / set at a time processing

• Explicit event flow


11

The programming model dimension

• Programming style

• Abstractions

• Pattern matching

• Enrichment capabilities

• Transformation capabilities

• Filter capabilities


12

TUTORIAL OUTLINE

Introduction

stream processing languages


Break





• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


13

Hallmarks of Stream Processing

• Events are processed in a directed graph

• Nodes = computational elements

• Edges = communication of events between nodes

• Languages inspired by SQL/relational algebra (though not all use an extended SQL as the language)

• Difference: write the query first

• Results of query are updated as data flows in

• Academic examples: STREAM, Aurora, Cayuga, …

• Commercial examples: Aleri, Coral8, Esper/Nesper, StreamBase, System S, …


14

Some pictures


15

Some pictures


16

Some pictures


17

Historical Roots

• Relational Databases

• Triggers: change table when another table changes

• Materialized view maintenance: calculate small set of changes to view given set of changes to base tables

• Signal processing

• Control and Audio: Ptolemy, LabVIEW, …

• Music and video: OpenMusic, jMax, Max, vvvv,


18

Historical Roots: Static Dataflow Architecture

• Developed by Jack Dennis in 1960s

• Each arc carries one token

• Node fires when all data available on all arcs


19

Historical Roots: Dynamic Dataflow Architecture

• Matching section in front of each node

• Tokens are tagged by invocation instance; when all tokens with same tag are ready, node fires

• Allows more parallelism than static model


20

Kahn Dataflow Networks

• Non-blocking write/blocking read queues

• Deterministic nodes implies deterministic network


21

Stream Processing versus Signal Processing and Dataflow Architecture

• Events carry more information than simple data: records instead of, e.g., decimal numbers

• Slightly slower data rates (up to millions of events per second)

• Publish/subscribe model of input/output


22

Dimension Commonalities in Stream Processing

• Events: Non-mutable records (fields with values) Values have scalar types (integer, float, string, blob, xml)

• Metadata: describes streams and types of records

• State: Unprocessed and processed events, and internal state of operations (e.g., aggregations)

• Computational model: records traverse the dataflow graph

• Programming model: extensions of SQL/relational algebra


23

Dimension Differences

• Events: small differences in scalar types

• State

• User-defined data structures (arrays, maps, …)?

• Disk-based persistence? What is persisted?


• Visual programming or text-based?

• Embedded in larger language, e.g., Java?

• Smaller language embedded in it?


24

Dimension Differences

• Computational model

• Cycles in dataflow graph?

• Deterministic?

• Consistent? What form of consistency?

• Parallel or concurrent execution?

• Distributed computation? Distributed data?

• Synchronous or asynchronous communication?


25

Aleri Streaming Platform Dataflow Networks

• One queue per node (instead of per edge)

• Nodes store records in table

• Events (insert/update/delete) change the table

• Nodes run in separate threads

• Optional persistence with roll-forward recovery


26



• Events may arrive in different orders, and may cause different output events

• Correctness: standard operators (join, compute, …) satisfy “eventual consistency”: the sequence of insert/update/deletes will produce the same table, no matter how the events flow through the graph


27


• Node A sends insert:[Id=3, Symbol=IBM, Price=45.0] Node B sends update:[Symbol=IBM, AvgPrice=43.40]

• Different arrival orders can cause different events

• (A then B)

• insert: [Id=3, Symbol=IBM, Price=45.0, AvgPrice=42.00]

• update: [Id=3, Symbol=IBM, Price=45.0, AvgPrice=43.40]

• (B then A)

• insert: [Id=3, Symbol=IBM, Price=45.0, AvgPrice=43.40]

A

B

C


28

Coral8 Dataflow Networks

• No queues; synchronization buffer in front

• Two kinds of nodes:

• Stream nodes process records but don’t store them

• Window nodes process and store records

• Optional persistence for unprocessed events, records in windows, aggregate state


29


• Computational model (simplified)

• External data flows into synchronization buffer

• Events carry a timestamp (point in time, microsecond granularity): set on arrival, or by source

• Events with same timestamp are fed into the network in one step, and are processed until network quiesces


30



• Deterministic: CCL programs produce the same output events given the same input

• Priorities assigned to nodes in graph to maintain determinacy


31


• Computational model: concurrent/distributed

• Project = group of CCL streams, windows, queries (code for calculating new events from old)

• Projects can send/receive events to/from other projects

• Each project has a thread (there are other threads too)

• Projects can be distributed across machines


32

Examples in CCL: Simple Market Data

• Schema: type of records– CREATE SCHEMA Trades_t – (Symbol STRING, Qty INTEGER, Price FLOAT);– CREATE SCHEMA Book_t– (Symbol STRING, Qty INTEGER, BuyPrice FLOAT);

• Other scalar types: BOOLEAN, TIMESTAMP, INTERVAL, XML, BLOB

• CCL streams: INPUT, OUTPUT, local– CREATE INPUT STREAM Trades_s SCHEMA Trades_t;– CREATE INPUT STREAM Book_s SCHEMA Book_t;


33

CCL Windows

• Windows are like streams, but store records– CREATE WINDOW Book_w SCHEMA Book_t KEEP ALL;– INSERT INTO Book_w – SELECT * FROM Book_s;

• Sample of KEEP policies (there are others):– KEEP LAST PER Id– KEEP 3 MINUTES– KEEP EVERY 3 MINUTES– KEEP UNTIL (”MON 17:00:00”)– KEEP 10 ROWS– KEEP LAST ROW– KEEP 10 ROWS PER Symbol


34

CCL Queries: SQL-based syntax

• Aggregation– CREATE STREAM Vwap_s SCHEMA (Symbol STRING, Vwap FLOAT);– INSERT INTO Vwap_s– SELECT Symbol, sum(Qty * Price)/sum(Qty)– FROM Trades_s KEEP 30 MINUTES– GROUP BY Symbol;

• Join– CREATE SCHEMA Value_t – INHERITS FROM Book_t (CurVal FLOAT, AvgVal FLOAT);– CREATE WINDOW BookValue_w– SCHEMA Value_t KEEP LAST PER Symbol;– INSERT INTO BookValue_w– SELECT B.Symbol, B.SharesHeld, B.BuyPrice, – B.SharesHeld * L.Price, B.SharesHeld*V.Vwap– FROM Book_w B, LastTrade_w L, Vwap_s V– WHERE B.Symbol = L.Symbol and B.Symbol = V.Symbol;


35

CCL Pattern Matching

• MATCHING clause– INSERT INTO OrdersMatch_s– SELECT B.ID, S.ID, B.Price– FROM BuyOrders_s B, Trades_s T, SellOrders_s S,– MATCHING [30 SECONDS: B, !T, S]– ON B.Price = S.Price = T.Price;

• Operators in patterns (cf. finite-state automata):

• Three boolean operators: ! (not), & (and), | (or)

• One temporal operator: , (followed by)

• Temporal scope can be nested– MATCHING [30 SECONDS: [10 SECONDS: B, !T], S]


36

Modularity

• Note: concrete syntax in future version of CCL

• Group of streams can be abstracted into a module– CREATE MODULE OptionPrice– CREATE INPUT STREAM Option_s;– CREATE OUTPUT STREAM OptionPrice_s;– CREATE PARAMETER FLOAT InterestRate = 0.05;– // internal stream definitions– END MODULE;

• Modules can be instantiatedLOAD MODULE OptionPrice as LondonOptionPrices STREAMS Input = LondonOptions_s, Output = LondonOptionPrices_s PARAMETERS InterestRate = 0.03;


37

Other Features from Other Languages

• Esper (Java)/Nesper (C#)

• Extensions of SQL

• Embedded within host language

• AleriML

• SPLASH: a C-like embedded language for writing nodes

• Data structures: vectors, dictionaries, event caches

• Mechanisms for discarding stored records (time, # records)

• StreamBase

• Primitive types include nested records and vectors (lists)

• LOCK/UNLOCK for holding and releasing records


38

TUTORIAL OUTLINE

Introduction


Rule oriented languages

• Break





• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


39

Production Rules


40

Production Rules and CEP

• Production rules react to states changes (not events)

• PR systems with object model and external fact updates might be extended to CEP

– Event types and classes are defined in the rule declarations

– New event data instances are added to the fact base / working memory

• might be an external fact base, e.g. a event queue

– The instances of declarations are filtered and joined in the conditions via typed pattern matching and if they pass the condition list the action part of the rule is triggered

• Might be further extended with mechanisms like query languages, state models and temporal constraints

• Examples: TIBCO Business Events, Drools


41

Production Rules

• A production rules is a statement of the form:

“if Condition then Action”

• Members, e.g. OPS5, Clips, Jess, Drools, Fair Isaac Blaze Advisor, ILog jRules, CA Aion, Haley, ESI Logist, …

• Operational semantics: forward-chaining

– primitive update actions (assert, retract, …);


42

Operational Semantics

• Operational processing

1. forward-chaining order-independent execution (e.g. based on variations of the RETE algorithm)

2. Procedural order-dependent sequential execution in a (compiled) execution environment (rule engine).

• Conflict resolution

– Refraction

– Priority

– Recency

– Specificity

– …


43

The Rete Pattern-Matching Algorithm

• Rete Pattern-Matching Algorithm (and variations of it)

– matches facts against the patterns in rules to determine which rule conditions are satisfied

– incremental evaluation of production rules' conditions

• Developed by Charles L. Forgy in the late 70s for OPS5 (Official Production System) shell

– stores information about the antecedents in a network

– in every cycle, it only checks for changes in the networks

this greatly improves efficiency


44

OMG Production Rules Representation (OMG PRR)

• Formal model for vendor-neutral rule-model representation in UML for production rules

• Consortium of developers and supporters– Rule vendors (including Fair Isaac, IBM/ILOG, LibRT, Pega,

Corticon, TIBCO)

– Academic community (RuleML Group)

– Related vendor community (Fujitsu)

• PRR is currently “adopted" as a standard and in “finalization", meaning that it is in Beta, with a final version 1.0 in 2009.


45

OMG Production Rules Representation

• OMG MDA PIM model

• PRR beta spec applies to a PRR Core using OMG MOF defined in UML

– Extends UML so production rules are 1st class citizens alongside objects

– Spec. excludes an explicit expression language

• Can use other standards as expression language

– e.g. W3C Rule Interchange Format (W3C RIF) and the production rule language of RuleML


46

OMG PRR ProductionRule Classes

if [condition] then [action]


47

W3C Rule Interchange Format

• W3C Rule Interchange Format (W3C RIF)

http://www.w3.org/2005/rules/wiki/RIF_Working_Group

• Goal Standardization of a web-based Rule Interchange Format (RIF)

• RIF 1.0 three dialects:

– RIF Production Rules Dialect (RIF-PRD)

• specifies the RIF production rules dialect to enable the interchange of production rules

– RIF Basic Logic Dialect (RIF-BLD)• specifies a basic interchange format that allows logic rules (definite

Horn rules with equality) to be exchanged

– RIF Core • RIF-Core, a common subset of RIF-BLD and RIF-PRD


48

W3C RIF Production Rules Dialect

• Production Rules (Condition-Action)

– Based on RIF condition language (from RIF Core)

– Actions: Retract, Assert, Modify, Execute

– Negation (inflationary negation)

• Syntax

– Normative XML syntax• Might be concrete representation language for OMG PRR

– Non-normative EBNF-based presentation syntax

• for presentation purposes


49

RIF Production Rule

<Implies>

<if> FORMULA </if>

<then rif:ordered="yes">

<Do>

ACTION*

</Do>

</then>

</Implies>Syntax close to PR

RuleML syntax


50

Event Condition Action Rules


51

Event Condition Action Rules

• ECA Rule “on Event if Condition do Action”;

– Explicit complex event part; separated from conditions and actions

• e.g. expresses customer order (event); check if credit card is valid (condition)

• Evolved from active databases

– extend databases with reactions, e.g. HiPac, ACCOOD, Chimera, ADL, COMPOSE, NAOS

– Composite event algebra, e.g. SAMOS, COMPOSE, Snoop

• Sequence | Disjunction | Xor | Conjunction | Concurrent | Not | Any | Aperiodic | Periodic


52

Time-point vs. Interval-based Semantics

–Time-point semantics• Event definition: B; (A;C) (Sequence)

event instance sequence EIS = b, a, c => detect event event instance sequence EIS = a, b, c => detect event

– Interval-based semantics• Event definition B;(A;C) (Sequence)

event instance sequence EIS = b, a, c => detect event event instance sequence EIS = a, b, c => do not detect event

T1 T2 T3 T4

B A C


53


1. Specification Phase– Definition of event/action pattern e.g. by event algebra– Based on declarative formalization or procedural implementation – Defined over an atomic instant or an interval of time,

events/actions, situation, transition etc.

2. Selection– Defines selection function to select one event from several

occurred events of a particular type in an event instance sequence, e.g. “first”, “last”

– Crucial for the outcome of a reaction rule, since the events may contain different (context) information, e.g. different message payloads or sensing information


54


3. Consumption– Optionally defines which events are consumed after the detection of a

composite event– An event may contribute to the detection of several composite events, if

it is not consumed– Distinction in event messaging between “multiple receive” and “single

receive”– Events which can no longer contribute, e.g. are outdated, should be

removed

4. Execution– Actions might have an internal effect i.e. change the knowledge state

leading to state transition from (pre)-condition state to post-condition state.

– Actions might have an external side effect


55

Example: REWERSE MARS

• MARS (Modular Active Rules for the Semantic Web)

– rule uses specialized heterogeneous event language (E), one or more query languages (Q), a test language (T), and an action language (A)

– each of these languages and their constructs are described by metadata and an ontology of its semantics

– well-defined interface for communication between the E, Q&T, and A components by variables

– SNOOP (E), OWLQ (Q&T) and CCS - Calculus of Communicating Systems (A)


56

Example: XChangeEQ

• ECA rules ON Event query IF Web query DO Action

– the condition part is a declarative query to XML data

– the event part is as well a declarative query to XML event data• distributed and web-based: events issued by web nodes (with both

emission and reception times)

– - action: simple or complex updates send to web nodes

• Complex events are expressed as (compound) queries to the event stream

– temporal restrictions and event compositions • conjunction, disjunction, exclusion, quantifications, repetitions, and

ranks• absolute temporal restrictions, also relative temporal restrictions

(within)


57

XChangeEQ

• The four dimensions of event querying are kept separated:– data extraction (eg oder number, book title)– event composition (eg oder of a dictionary and a grammar both from the same

publisher)– temporal (and other) relationships (eg two orders within a week)– event accumulation (eg no default of paiement between the order of the two

abovementioned buys)

• Equivalent Semantics:– Declarative semantics: Model and fixpoint theories– Operational semantics: CERA (Complex Event Relational Algebra)

• XChange^EQ operational semantics:– by language design, the system never wait forever for a complex event to possibly

resume.– Incremental evaluation (refining RETE).– Built-in garbage collection of irrelevant complex events (eg events that cannot

resume).


58

Example: XChange Composite Event

andthen [

xchange:event {{

xchange:sender {"http://airline.com"},

cancellation-notification {{

flight {{ number { var Number } }} }}

}},

xchange:event {{

xchange:sender {"http://airline.com"},

important {"Accomodation is not granted!"}

}}

] within 2 h


60

IBM AMIT Situation Manager Rule Language • Definition of situations and their detection conditions

– syntactically equivalent to (complex) event patterns – lifespans which hold references to events with relevant context for a

particular pattern calculation

• Conceptual event model defines an event type generalization hierarchy – Root event type defines a set of standard attributes e.g.,

• the event source, creation type, temporal dimensions like occurrence time, detection time and /or transaction time of an event, and quantifications such as status, priority, severity, count

– Application specific event types inherit from root event type and define further user-defined attributes

– Two types of event relationships • Based-on - a pure syntactical relationship to ease the development process. If

an event A is 'basedon' event B, event A inherits the entire structure of event B and can extend it.

• Reference - a relationship that allows deriving events without pattern detection. Useful for transformation and enrichment purposes.


61

Example AMIT SMRL

<eventTypes>

<eventType name="doctorEnterRoom"> <attributeType name="doctor" xsi:type="string"/> <attributeType name="room" xsi:type="integer"/> </eventType>

<eventType name="patientEnterRoom"> <attributeType name="patient" xsi:type="string"/> <attributeType name="r_o_o_m" xsi:type="integer"/> </eventType>

<eventType name="lockRoom"> <attributeType name="room" xsi:type="integer"/> </eventType>

<eventType name="unlockRoom"> <attributeType name="room" xsi:type="integer"/>

</eventType>

</eventTypes>

<lifespan name="roomOpen"> <initiator> <eventInitiator name="unlockRoom"/> </initiator> <terminator> <eventTerminator name="lockRoom"/> </terminator> <keyBy name="sameRoom"/>

</lifespan>

AMIT SMRL markup language provides an event algebra with semantic notations such as context (lifespan intervals), and semantic association (event group) to define situations


62

(Reaction) RuleML

• General (reaction) rule form that can be specialized as needed

• Platform-independent XML-based rule interchange format

– translation into platform-specific executable rule languages, e.g. Prova

• Three general execution styles:

– Active: 'actively' polls/detects occurred events in global ECA style, e.g. by a ping on a service/system or a query on an internal or external event database

– Messaging: Waits for incoming complex event message

– Reasoning: KR event/action logic reasoning and transitions (as e.g. in Event Calculus, Situation Calculus, TAL formalizations)

• Appearance

– Global: ‘globally’ defined reaction rule

– Local: ‘locally’ defined reaction rule in a specific context

63

General Syntax for Reaction Rules<Rule style="active" eval="strong"> <on>

 </on>

<if> 

</if>

<do> 

</do>

<ifPost> 

</ifPost>

<doAlternative> 

</doAlternative></Rule>


64

Selected Reaction RuleML Extended Features

• Action Algebra: Succession (Ordered Succession of Actions), Choice (Non-Determenistic Choice), Flow (Parallel Flow), Loop (Loops)

• Event Algebra: Sequence (Ordered), Disjunction (Or) , Xor (Mutal Exclusive), Conjunction (And), Concurrent , Not, Any, Aperiodic, Periodic

• Support for event / action messaging

• Support for different detection, selection and consumption policies

• Support for intervals (Time, Event)

• Support for situations (States, Fluents)

• Support for external event query languages

• ...


65

TUTORIAL OUTLINE

Introduction


rule oriented languages

Break





• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics

10 minutes break


66

TUTORIAL OUTLINE

Introduction



Break

agent oriented languages




• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


67

EPA and EPN

• In David Luckham’s “the power of events” the term EPN (Event Processing Network) was used as a collection of EPAs (Event Processing Agents).

• The EPN describes the “programming in the large”, while each individual agent describes the “programming in the small”.

IBM Haifa Research Lab – Event Processing © 2008 IBM Corporation

EPN Example

Fever F

Fever C

c2

c3

c8

Enrich: Is diabetic?

Translate: C2F fever

Pattern detection:Alert physician

Pattern Detection: Alert Nurse

c6

Fever F

Blood pressure reading

p2

p4

p3

p6

p5

p10

p9

p8

p1

p11

p12

p12

admittance

Aggregator: Max.

p7

Pattern Detection: Continuous Fever

c7

c9

Filter: Diabetes c1 c5

p13p14

p15

p16

p17

p18

p19

p20


68

Some EPN, event flow and data flow oriented languages

Agent Logic Oracle/BEA

IBM InfoSphere Streams

© 2008, 2009 IBM Corporation194 Tutorial on the SPADE language

A SPADE program builds a data-flow network out of operators

sinkoperator

sourceoperator

processingoperator

sourceoperator

processingoperator

processingoperator

stream

stream

stream

stream

stre

am

stream

sinkoperator

Spade (IBM

System S)

Event Zero

Streambase


69

What is the idea ?

• The EPN (event processing network) represents the event processing application as a directed graph:

– The nodes represent event processing agents (and states in some models)

– The edges represent either individual events or event streams (depends on the processing type). A generalized EPN may support both.

• The coverage of EPN varies

– It may cover some language operator (e.g. SQL like language)

– It may take a broader approach and cover also routing decisions, pub/sub etc…

– EPN can have a specific programming model, or an hybrid programming model, where one or more languages represent the agents.


70

Anatomy of Agents

Selector Processor Deriver

Selects the events that are relevant for the processing

Performs the processing

(e.g. detect patterns) Derives output events


71

Event Processing Agent

Filter Transform Detect Pattern

Translate

Route

Aggregate Split Compose ProjectEnrich

Event Processing Specialized Agent types


72

Itinerary-based routing

Subscription-based routing

Intelligent routing

Routing – channel EPA


73

Making the agents context sensitive

When?

Where?

Which state?

Who?

Time interval that starts by: {event, clock, offset from event} and terminates by: {event, clock, offset from event, count of certain events} – each can have multiple instances (e.g. several events, periodic clock, multiple offsets}

Spatial dimensions/ abstraction

An entity or a collection of entities that determine the partition of the context

The event happens when some state is in effect

Examples: [9:00AM, angry-customer-alert], [angry-customer-alert, +1 hour], [request – 2 hours, request]

Inside building A, In Italy, within 1KM from here (given GPS coordinate)

Class of customer, customer + order, large order…

Traffic Jam, Red Alert, Bullish Market


74

Many of the raw events are not relevant for processing, in some applications only a sample is selected for processing.

Filtering


75

Translation / projection: Translation and simple derivations

Aggregation/ composition: statistical aggregator or concatenating events, can be stand alone agent or a scalar derivation. May be in network edge.

Splitting: Splits events to multiple events

Transformation


76

Enrichment

Enriches the content of events from reference data in databases, spreadsheets, Email messages, text files etc..


77

Pattern Matching

In many cases, the agent does not consume raw events, but event that are derived from pattern matching.

Pattern definition example

DEBS 2008 tutorial on event processing patterns provided a deep dive


78

Dimensions - I

• Meta-data

– EPN and agent definitions may be defined as meta-data

– Event schema is implementation dependent

• State

– State can be represented as another node in the EPN

– Some EPAs may be state oriented, e.g. the input event is change in state

– State is one of the context dimensions


79

Dimensions - II

• Execution model:

– EPN representation is natural one for concurrency/parallelism since the dependencies are explicit

– Since it models explicitly the end-to-end event flow, it serve as a convenient model for QoS related optimizations (latency, throughput, real-time constraints)

• Programming model:

– Can support multiple programming styles

– Can support all types of event processing functionality


80

Fever F

Fever C

c2

c3

c8

Enrich: Is diabetic?

Translate: C2F fever

Pattern detection:Alert physician

Pattern Detection: Alert Nurse

c6

Fever F

Blood pressure reading

p2

p4

p3

p6

p5

p10

p9

p8

p1

p11

p12

p12

admittance

Aggregator: Max.

p7

Pattern Detection: Continuous Fever

c7

c9

Filter: Diabetes c1 c5

p13p14

p15

p16

p17

p18

p19

p20

EPN example


81

Event Zero example


82

System S Example

IHE Adapter

Congestive Heart FailureCongestive Heart Failure

QRSQRS

BP S/DBP S/D

RRRR P and TP and T

FreqAnalyzer

FreqAnalyzer ArrhythmiaArrhythmia

Weight trenddetector

Weight trenddetector

CHFCHF

alert

alert

GlucoseGlucoseSource PESource PE

*Daby Sow


83

Agent Logic example


84

TUTORIAL OUTLINE

Introduction



Break


Temporal semantics



• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


85

Varieties of Temporal Semantics

• Do events carry timestamps? Where does the timestamp come from (CEP system or external world)?

• Granularity? Second, millisecond, microsecond, …?

• Point in time or interval of time?

• Can events arrive out-of-order from a single data source?

• Can events be reordered if they arrive out-of-order?

• How long does the system wait?

• What happens if system moves ahead, and old event arrives?

• In distributed case, is there a difference between emission and reception time?


86

Simple Temporal Semantics

• Events arrive in order from a single data source

• Events have timestamps, but not reordered

• Advantage

• Process as soon as possible

• Disadvantages

• Non-deterministic

• Hard to manage if time really matters

• Emission times de-synchronized in distributed case


87

Global Clock

• Events have timestamps consistent across data sources

• Wait for events for specified time; discard if wait too long

• Advantages

• Deterministic

• Time might be relevant

• Disadvantages

• Speed of processing

• Buffering required for reordering events


88

TUTORIAL OUTLINE

Introduction



Break


Temporal semantics

Integrated development environments


• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


89

Integrated Development Environments (IDEs)

• Two main forms

• Text based

• Visual or graphical based

• Not an either-or; most systems have some combination of text and visual display of dataflow


90

Visual IDEs

• Streams = nodes, flows = edges

• Drag-and-drop streams from palette onto canvas and wire together

• Configure streams with property sheets or text

• Advantages: simple metaphor; easy to see flow

• Disadvantages: managing screen real-estate


91

Visual IDE Example


92

Text-based IDEs

• Streams represented in text

• Advantages

• Appeals to programmers

• Can be quicker to write code

• Disadvantages

• Hard to see the data flow

• Hard to find bottlenecks in program


93

Text-based IDE


94

Another Text-based IDE


95

Advanced Features in IDEs

• Ability to start/stop programs

• Debugging, including viewing intermediate events and setting breakpoints

• Tests, including ability to control data feeds

• Dashboards for displaying results


96

Breakpoints and Debugging


97

Performance Monitoring


98

Dashboard Construction


99

Dashboard Construction


100

Assessment: IDEs still have a ways to go

• Need more features that programmers have come to expect

• Single-stepping with line numbers

• Examination of events and data

• Forward and backward replay of time

• Need to be integrated into more dashboards and other visualization tools


101

TUTORIAL OUTLINE

Introduction



Break


Temporal semantics


Formal approaches

• Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


102

Formal ApproachesTemporal Event/Action Logics for

Reasoning on Changes


103

(Temporal) Event Logics

• (Temporal) event/action logics– Events with effects on changeable properties / states / fluents

– Focus: reasoning on effects of events/actions on knowledge states and properties

– Not Complex Event Processing Languages, but can be used in reasoning on/with complex events

• Members e.g. – event calculus and variants,

– situation calculus,

– features and fluents calculus,

– various (temporal) action languages (TAL),

– fluent calculi and versatile event logics.


104

The Situation Calculus

• A situation is a snapshot of the world at some point in time

• Every true or false statement is made with respect to a particular situation

When an agent performs an action A is situation S1, the result is a new situation S2 McCarthy 1963, McCarthy & Hayes 1969, Green 1969


105

Event Calculus

• Kowalski and Sergot’s EC

– a formalism for temporal reasoning about events and their effects • computation of earlier events (long-term "historical" perspective)

– model of change • events happen at time-points and initiate and/or terminate properties (time-

varying fluents) of the world– Law of inertia:

Things normally tend to stay the same

• Main differences in EC to SC

– branching time in SC vs. linear time in EC

– explicit notion of previous state of the world / situation in SC

– state transitions are functions in SC


106

Classical Event Calculus Example

• EC Basic Axioms:– happens(E,T) event E happens at time point T– initiates(E,F,T) event E initiates fluent F for all time>T– terminates(E,F,T) event E terminates fluent F for all time>T– holdsAt(F,T) fluent F holds at time point T

• Many EC Extensions, e.g.:– valueAt(P,T,X) parameter P has changeable value X at time point T– planned(E,T) event E is believed to happen at time point T

Example:

initiates(stopService,serviceUnavailable,T)terminates(startService,serviceUnavailable,T)happens(stopService,t1); happens(startService,t5)

holdsAt(serviceUnavailable,t3)? trueholdsAt(serviceUnavailable,t7)? false

stopService

t1 t5

startService

t3 ? t7 ?


107

Example: Interval-based Event Calculus Event Algebra

– Event initiate and terminate Situations (Fluents) which hold at an time interval

– Interval-based Event Calculus semantics (model-theory + proof theory) based on time intervals modeled as fluents

I: Ti x Fl {true, false}

– Example: B;(A;C) (Sequence)

(A;B;C) [T1,T3]) <=

holdsInterval([a,b] [T1,T2]) Λ holdsInterval([b,c] [T2,T3]) Λ [T1,T2]<=[T2,T3]

– Rule-based implementation of EC event algebra, e.g. as meta logic program

– Rule-based arithmetic involving times and durations, e.g. Allen’s interval logic

T1 T2 T3 T4

A B C


108

Combinations of Rule Types

1. Rules that influence the operational / decision processes:• Derivation rules (deduction rules): establish / derive new

information that is used e.g. in a decision process.• Reaction rules that establish when certain activities should place

(e.g. ECA rules)

2. Constraints on system/organisation's structure, behavior or information:• Structural constraints (e.g. deontic assignments), State constraints,

Process / flow constraints


109

Example: Prova Messaging Reaction Rules

%Event MessagercvMsg(EventID, jms, Requester, acl_query-ref, Task) :-%Condition(s) – “find available service” available(Service),

%Action Message – “load task on service” sendMsg(Sub-ID,jms,Service,acl_query-ref, load(Task)).

% Derivation rulesavailable(S) :- service(S), not(maintenance(S)), not(loaded(S),T).

maintenance(S):- …

loaded(S) :- … automatic rule chaining

variable data binding


110

Messaging Reaction Rules in Prova

• Send a messagesendMsg(XID,Protocol,Agent,Performative,[Predicate|Args]|Context)

• Receive a messagercvMsg(XID,Protocol,Agent,Performative,[Predicate|Args]|Context)

• Receive multiple messages

rcvMult(XID,Protocol,Agent,Performative,[Predicate|Args]|Context)

Syntax:

– XID is the conversation / event instance sequence identifier

– Protocol: ESB transport protocols (>30 e.g. self, jade, jms, soap,…)

– Agent: denotes the target or sender of the message

– Performative: pragmatic context, e.g. FIPA ACL primitives

– [Predicate|Args] or Predicate(Arg1,..,Argn): Message payload


111

TUTORIAL OUTLINE

Introduction



Break


Temporal semantics


Formal approaches

Conclusion

Opher Etzion

Jon Riecke

Adrian Paschke

Opher Etzion

Jon Riecke

Jon Riecke

Adrian Paschke

Opher Etzion

Languages

Styles

Advanced

Topics


112

Event Processing Languages – insights from this tutorial


An ObservationThe Babylon Tower symbolizes the tendencyOf humanity to talk in multiple languages.

The Event Processing area is no different: most languages in the industry really followthe hammer and nails syndrome – and extended existing approaches• imperative script language• SQL extensions• Extension of inference rule language

The epts language analysis workgroup is aimed to understand the various stylesAnd extract common functions that can be used to define what is an event processing language; this tutorial is an interim report

I t does not seem that we’ll succeed to settleIn the near future around a single programming style


Dimensions to describe languages

• Events Data and Meta-data

• State

• Computation/execution model



113

Towards event processing languages standard ?

• Eventually – a single language ?

Mid 1970-ies

1st generation

of relational DBMS products

1990

SQL standard approved

Mid 200-ies

1st generation

of EP products

?

EP standard approved

• OR – variety of language style standards ?

• Meta-language as an intermediate standard ?


114

The epts “Event Processing Language Analysis” workgroup

WG Leaders: Opher Etzion (IBM) and Jon Riecke (Aleri)

Members:

• Alex Kozlenkov (Betfair)

• Adrian Paschke (FU Berlin)

• Arno Jacobsen (U of Toronto)

• Bala Maniymaran (U of Toronto)

• Bob Hagmann (Aleri)

• David Tucker (EventZero)

• Dermot McPeake (FirstDerivatives)

• Francois Bry (LMU)

• Guy Sharon (IBM)

• Louis Lovas (Progress/Apama)

• Michael Eckert (TIBCO)

• Pedro Bizarro (University of Coimbra)

• Richard Tibbetts (Streambase)

• Robert McKeown (IBM)

• Susan Urban (Texas Tech. University)

• Simon Courtenage (Westminister U.)

• Serge Mankovskii (CA)

Mission:

The purpose of this working group is to conduct a study of the features that exist in the contemporary and planned languages

in the area of event processing (including event stream processing).

The goal is to understand the functional properties that exist in event processing languages and abstract out semantic functions,

regardless of syntax and implementation considerations.

This is a first step in a way to determine future possible standardization in the event processing area

eptsevent processing technical society

If you want to participate in these discussions, contribute to this topic and/or others topics, and be part of the community effort to advance the state of the art and state of the practice:

JOIN EPTS

For details: http://www.ep-ts.com/

Debs2009 Event Processing Languages Tutorial

Technology

Transcript of Debs2009 Event Processing Languages Tutorial