Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ER 2013 tutorial: modeling the event driven world

3,176 views

Published on

This tutorial is a first public exposure of the event model

Published in: Technology
  • Be the first to comment

ER 2013 tutorial: modeling the event driven world

  1. 1. ER 2013 – TUTORIAL Modeling the event driven world Opher Etzion and Barbara von Halle © 2012 Knowledge Partners International LLC www.kpiusa.com www.thedecisionmodel.com
  2. 2. Prologue: The Internet of everything for situation awareness Such applications become possible since everything is connected A person enters a car and the car starts moving; the person does not look like one of the authorized drivers None of the authorized drivers location is near the car’s location theft is concluded Whom to notify; whether to activate stopper Use a built-in car stopper to slow the intruder and dispatch the security company
  3. 3. Prologue: Does the “Internet of everything” really exhibit the benefits of the Internet? The success of the Internet is attributed to its relative simplicity  to connect  to create content  to search Imagine that any search in the Internet would have been done using SQL queries… How pervasive do you think the Internet would have been?
  4. 4. Prologue: For situational awareness…. we are not even in the SQL era Event Patterns Listing 1.1 Example of the MonitorScript event programming language from Apama if isAuto then { DeliveryBid db; on DeliveryBid(store=dr.store):db within(ASSIGNMENT_TIME){ assignmentTimer.quit(); route Assignment(dr.requestId, dr.store, db.driver, dr.addresseeLocationPointX, dr.addresseeLocationPointY, db.committedPickUpTime, dr.requiredDeliveryTime); watchForPickUp(dr, db.driver, db.committedPickUpTime); watchForDelivery(dr, db.driver); } } #1 #2 Most of the event-based programming today is still adhoc and hand-coded; existing languages are rather low level
  5. 5. Agenda I Topic I: Introduction – Brief history of event processing II Topic II: The major differentiation factors of event-based thinking vs. traditional computing III Topic III: The computational independent model 5 IV Topic IV: Drill down to the model components V Topic V: Epilogue
  6. 6. How did we get here? IBM Joins Apama acquisition By Progress 2012 Hitting the analysts hype… TIBCO and Oracle announce 2013 products M&A: 2008 First start-ups Descendents of academic projects 2007 EPTS Established 2005 Streambase Coral8 Around 2000 6/30/2013 6 TIBCO/Streambase Software AG/Apama New players: SAS. Yahoo, Twitter EP at the height of BIG DATA hype Cycle
  7. 7. Where are events used? Virtually everywhere Events, as “data in motion” is one of the fundamental ingredients in big data: event -driven analytics Event -driven services / making events part of SOA Event-based decision making and event driven Optimization Event -driven processing as a backbone of next generation systems: event-based robotic, autonomic vehicles, human enhancement technology… 6/30/2013 7
  8. 8. Gartner’s Big Data hype cycle 2012 8 Event processing Again in the hype Source: Gartner Cycle – in different publication context G00235042, July 31, 2012
  9. 9. The event processing market today Source: Event processing Manifesto
  10. 10. The reality A year ago, Roy Schulte from Gartner published a personal blog entitled “does anybody care about event processing” His observation is that 95% of the event processing market is not visible since it is homebuilt and not labeled as EP He admitted that his predictions about the actual size of the event processing market is smaller than predicted In this tutorial we will discuss what is event driven thinking and how smart modeling is able to help the world to exploit the power of events
  11. 11. Barriers to wider adoption Lack of standards: SOA took off only when WS standards were accepted Lack of sufficient awareness and good ROI understanding: Need entry points and methodology about benefits to individuals, enterprises, packaged applications providers. Lack of understanding of what is event-based thinking and how to translate it to implementation Lack of skills – current tools require highly skilled developers to do tricky programming 6/30/2013 11
  12. 12. Major gap -- skills required A comprehensive user survey shows that 84% of the users wish that event rules could be defined by business users There is a gap Current models: Implementation oriented 6/30/2013 12 Business analysts oriented Modeling
  13. 13. Summary of topic I In the business level – it is not well understood how to think in events and how to utilize events In the application level – the life-cycle of event-based systems require skilled IT developers Next - we explain what is different about event-driven thinking 6/30/2013 13
  14. 14. Agenda I Topic I: Introduction – Brief history of event processing II Topic II: The major differentiation factors of event-based thinking vs. traditional computing III Topic III: The computational independent model 14 IV Topic IV: Drill down to the model components V Topic V: Epilogue
  15. 15. Event driven applications follow the 4D paradigm I want to know about it immediately and react in the best possible way Awareness Detect 6/30/2013 Situation Derive 15 Reaction Decide Do
  16. 16. Let’s take a very simple example of money laundering I want to know about it immediately and react in the best possible way A suspicious account is detected whenever there are at least three large cash deposits within 10 days Detect Cash deposit Transfer abroad Derive Decide Do A suspicious account Assign risk score and determine course of action Open investigation
  17. 17. Some features of this scenario I want to know about it immediately and react in the best possible way A suspicious account is detected whenever there are at least three large cash deposits within 10 days Events trigger action Events influence logic for the results 6/30/2013 There may be multiple events whose combined content influences the results 17 Temporal contexts (10 days) influence the results
  18. 18. The way that most people would approach it Insert the event into a database; use periodic or ondemand queries to process the events The processing may not be efficient – many of the requests will not yield results 6/30/2013 The processing may not be effective – the time to react may be missed 18
  19. 19. A suspicious account design using traditional BPMN…
  20. 20. A suspicious account using BPMN…
  21. 21. A suspicious account using BPMN…
  22. 22. Difficulties in the way that most people would approach it The event-driven vs. request-driven nature The temporal oriented behavior Effectiveness and Efficiency issues The hidden state handling 6/30/2013 22
  23. 23. Efficiency and effectiveness issues The processing may not be efficient – many of the requests will not yield results 6/30/2013 The processing may not be effective – the time to react may be missed 23
  24. 24. While people typically are event-driven we tend to think about computerized systems in request driven way Searching the web, database queries, use of web services, use of mobile applications 6/30/2013 24
  25. 25. What are the differences in thinking? Question Response Driven Why is an action being taken? As a response to a specific Triggered by the fact of a request specific situation When is an action being taken? When the request is being Determined based on the processed context of the situation What happens when the request / event occurs? A response is always produced 6/30/2013 25 Event Drive The event can be ignored, increment the state, trigger an internal derive event, or trigger a situation
  26. 26. Temporal consideration changes everything In traditional models temporal functions are handcoded, adding complexity The logic is sensitive to timing of events The logic is sensitive to the order of events A delivery should be confirmed by the deadline The winner in the bid is the first one who made the highest bid Why? What? 6/30/2013 26 The logic is determined by timing considerations When?
  27. 27. The logic is sensitive to the timing of events’ occurrences Events during rush hour are of interest, events outside rush hour are not Events that occur or don’t occur relative to a deadline Is the reported problem already solved, or is it still open? 6/30/2013 27
  28. 28. The logic is sensitive to the order of events’ occurences Who arrived first? Has the bid arrived while the auction was still open? 6/30/2013 28
  29. 29. The logic of situation is determined by timing considerations Determine the status of a patient based on blood pressure measurements: Every 8 measurements 6/30/2013 29 Every 5 hours
  30. 30. Handling the state Event Patterns Pattern “event1 occurs after event2” requires keeping state of all unmatched instances of event1 6/30/2013 30
  31. 31. Event processing applications are a step further … but is this enough? (1/3) I want to know about it immediately and react in the best possible way A suspicious account is detected whenever there are at least three large cash deposits within 10 days Let’s see how this situation is implemented using a popular SQL like open source Event Processing language
  32. 32. Event processing applications are a step further… but is this enough? (2/3) // Large cash deposit insert into LargeCashDeposit select * from Cash deposit where amount > 100,000 // Frequent (At least three) large cash deposits create context AccountID partition by accountId on Cash deposit; Context AccountID Insert into FrequentLargeCashDeposits select count(*) from LargeCashDeposit having count(*)>3; // Frequent cash deposits followed by transfer abroad Context AccountID insert into SuspiciousAccount select * from pattern [ every f=FrequentCashDeposit -> t=TransferAbroad where timer.within(10 days)]
  33. 33. Event processing applications are a step further… but is this enough? (3/3) // Large cash deposit insert into LargeCashDeposit select * from Cash deposit where amount > 100,000 // Frequent (At least three) large cash deposits create context AccountID partition by accountId on Cash deposit; Context AccountID Insert into FrequentLargeCashDeposits select count(*) from LargeCashDeposit having count(*)>3; // Frequent cash deposits followed by transfer abroad Context AccountID insert into SuspiciousAccount select * from pattern [ every f=FrequentCashDeposit -> t=TransferAbroad where timer.within(10 days)]
  34. 34. Summary of topic II In many cases – event driven functionality is expressed using the traditional request-response fashion Fundamental differences exist between the two paradigms, and benefits exist in using event-driven modeling and implementation for certain applications Next – drilling down to the essence of event driven model 6/30/2013 34
  35. 35. Agenda I Topic I: Introduction – Brief history of event processing II Topic II: The major differentiation factors of event-based thinking vs. traditional computing III Topic III: The computational independent model 35 IV Topic IV: Drill down to the model components V Topic V: Epilogue
  36. 36. The vision for event based systems: Shift governance from the programmer to the knowledge worker TODAY TOMORROW Governance occurs through development and maintenance of program code CODE LEVEL Governance occurs through development and maintenance of event models
  37. 37. The basic requirements of event modeling 1. Rigorous verifiable structure 2. Represented as a collection of tables 4. Automatic translation to code in regular or specific engine language 3. Free of implementation assumptions
  38. 38. The model driven engineering approach The event model is CIM --- translation to PIM and to PSM is automated
  39. 39. Eliminating noise from the model Current models are close to the implementation models – and from pure logic view contain “noise”. Bringing data from current state Query Enrichment Inclusion in events Other noise : workarounds Examples Determine if a customer is a platinum customer; Fetch the credit limit of a customer
  40. 40. TEM Concepts Glossary Actors Facts Logic Event Derivation Logic States Events IT elements Goals Transitions Computation Logic
  41. 41. Simple example: Top down design of event model for suspicious account derivation Suspicious Account Compliance officer Frequent large cash deposits Frequent large cash deposits Large cash deposit Large cash deposit cash amount <Cash deposit> customer threshold Bank transaction system
  42. 42. Simple example: TEM Logic Specification for deriving Suspicious Account Suspicious account Logic Row # When When Expression Start When End Partition by Filter on event Account ID 1 always Pattern Filter on pattern Frequent large cash deposits same is Detected Frequent large cash deposits Logic Row # When When Expression Start When End Partition by Filter on event Account ID 1 every 10 days Pattern Filter on pattern Count(Large cash deposit) > 3 same Large cash deposit Logic 1 When When Expression Start always When End Partition by Filter on event Customer ID Row # cash amount <Cash deposit> >= customer threshold same Pattern Filter on pattern
  43. 43. Let’s complicate the Suspicious Account story A situation of a Suspicious account is derived when any of the following three derived events is detected Frequent large cash deposits At least 3 cash deposits of the same account, within 10 days Frequent cash deposits followed by transfers abroad At least 10 occurrences of cash deposits followed by transfers abroad of the same account within 30 days30 days Suspicious account Lack of account activity no transaction of any kind, of the same account, takes place within 20 days
  44. 44. TEM in Action in Six Steps Step 1: Draw the situation Step 2: Add the situation’s skeleton Step 3: Go one step further Step 4: Complete the picture Step 5: Create the Logic Specification (TEM Tables) Step 6: Complete the Glossary
  45. 45. TEM in Action Step 1: Draw the situation Suspicious Account Compliance officer
  46. 46. The notion of situation A raw or derived event that requires reaction Toll violation Frustrated customer Sometimes the situation is determined by detecting that some pattern occurred in the flowing events. Sometimes the events can approximate or indicate with FRUSTRATED some certainty that the CUSTOMER situation has occurred
  47. 47. TEM in Action Step 2: Add the situation’s skeleton Situation Suspicious Account Compliance officer Frequent large cash deposits Participants in deriving the conclusion which are also conclusions Frequent cash deposits followed by transfers abroad Lack of account activity Context Consumer
  48. 48. TEM in Action Step 3: Go one step further Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Transfer abroad is Absent Add structures for the three required derived events Connect event producers Bank transaction system
  49. 49. TEM in Action Step 4: Complete the Diagram Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad cash amount <Cash deposit> customer threshold Cash deposit Transfer abroad is Absent Transfer abroad Bank transaction system
  50. 50. TEM in Action Step 4: Complete the Diagram Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent cash amount <Cash deposit> customer threshold Cash deposit or Transfer abroad Account ID Cash deposit Transfer abroad Bank transaction system
  51. 51. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Large cash deposit Logic 1 When When Expression Start always When End Partition by Filter on event Customer ID Row # cash amount <Cash deposit> >= customer threshold same Pattern Filter on pattern
  52. 52. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Cash deposit followed by transfer abroad Logic Row # When When Expression Start When End Partition by Filter on event Pattern Account ID 1 Cash +3 days deposit Cash deposit same Occurs Transfer before abroad Filter on pattern cash amount <Cash deposit> <= transfer amount <Transfer abroad>
  53. 53. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Frequent large cash deposits Logic Row # When When Expression Start When End Partition by Account ID 1 every 10 days same Filter on event Pattern Count(Large cash deposit) > 3 Filter on pattern
  54. 54. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Frequent cash deposits followed by transfers abroad Logic Row # When When Expression Start When End Partition by Account ID 1 every 30 days same Filter on event Pattern Count(Cash deposit followed by transfer abroad) > 10 Filter on pattern
  55. 55. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Lack of account activity Logic When Row # Expression When Start When End Partition by Account ID 1 Cash deposit , Transfer abroad +20 days same Filter on event Pattern Cash deposit is Absent Filter on pattern Transfer abroad is Absent
  56. 56. TEM in Action Step 5: Create the Logic Specification (TEM Tables) Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Large cash deposit Cash deposit followed by transfer abroad Cash deposit is Absent Large cash deposit Cash deposit followed by transfer abroad Transfer abroad is Absent Cash deposit or Transfer abroad cash amount <Cash deposit> customer threshold Account ID Cash deposit Transfer abroad Bank transaction system Suspicious Account Logic Row # When When Expression Start When End Partition by Account ID 1 always 2 3 always always same same same Filter on event Pattern Frequent large cash deposits is Filter on pattern Frequent cash Lack of account deposits followed activity by transfers abroad Detected is Detected is Detected
  57. 57. Step 6: Complete the Glossary Concepts Lexicon Concept name Concept type Concept sub-type Description Account ID Customer ID Transfer abroad large cash deposit cash amount Fact Fact Event Event Fact Universal Universal Raw Derived Concrete bank account number customer ID Details of a transfer abroad transaction A cash deposit above a given threshold The amount of the cash deposit Aliases Contained in Event Fact Types Details Fact Type name Fact Type sub-type cash amount Regular Contained in Data Actor Type Domain Universal Fact valid values Type reference Default value Cash deposit Actors Details Actor Name Role Event Compliance officer Bank transaction system Bank transaction system Consumer Producer Producer Suspicious account Cash deposit Transfer abroad All concepts should eventually be defined in the knowledge model
  58. 58. Summary of topic III Event model as a computational independent concept Suspicious Account Compliance officer Frequent large cash deposits Frequent cash deposits followed by transfers abroad Lack of account activity Frequent large cash deposits Frequent cash deposits followed by transfers abroad Large cash deposit Cash deposit followed by transfer abroad Lack of account activity Cash deposit is Absent Transfer abroad is Absent Large cash deposit cash amount <Cash deposit> customer threshold Cash deposit followed by transfer abroad Diagrams and table – top-down design Cash deposit Transfer abroad Bank transaction system Next – Drill down to the model ‘s components 6/30/2013 58
  59. 59. Agenda I Topic I: Introduction – Brief history of event processing II Topic II: The major differentiation factors of event-based thinking vs. traditional computing III Topic III: The computational independent model 59 IV Topic IV: Drill down to the model components V Topic V: Epilogue
  60. 60. Drilling down to the concept model – back to the car theft example A specific car is moving None of the locations of authorized drivers for this car are in the car: theft is concluded Either notify police or chase the car by private agency Stop the car by police
  61. 61. Players in this story Sensors: Car GPS sensor Car camera Person’s location sensor Situation: Person enters car and then Car moving Person location for all eligible drivers is not near car location Entering person does not look like any eligible driver Events: Car moving Person changed location Person enters car Actuators: Car stopper Security enforcers
  62. 62. Concepts Concepts Processing Element Fact Context Domain Situation Event Compute derivation Actor
  63. 63. Fact – a first class citizen in the model What? How? Piece of information about actor or event Examples: Car-id of Car Car-id of Moving Car Authorized-driver of Car A function of the actor/event to a domain Provides information about Car-id of Car Fact M 1 Actor Car Provides information about Car-id of Moving Car Car-id of Car Fact M 1 Event Moving Car Is a classified to Fact M 1 Domain Car-id
  64. 64. Domain What? Describes an entity type in the real world How? An abstract term, associated with data type and Name: Car Synonyms: Data type: Vehicle 2 char + 8 digits Examples: Car-id Driver-id
  65. 65. Event What? Something that happens How? Represented as a aggregation of characteristics and associated facts Name: Person enters car Characteristics: Time: 22/10/2013 22:24 Location: Barcelona, Balmes 132 Certainty: 1 Source : car camera 453430 Car id: 14321313 Picture: Examples: Moving Car Person enters car Person changes location
  66. 66. Actor What? Any entity, person, or organization that has a relevant role How? Represented through associated Fact-types and event related roles Car GPS Actor M Role n Event Examples: Car Driver Car GPS Mobile phone Moving Car
  67. 67. Roles of actor with respect to events Event producer Event consumer Car GPS Security officer Actor Actuator Car stopper Event Event subject Event descriptor Data provider Car Eligible driver Driving authorization store
  68. 68. Compute derivation Computes the value of facts associated with derived events Participating event Function Participating event Copy Aggregation Arithmetic function Derived computation
  69. 69. The notion of context is pervasive in the human culture In the play “The Tea house of the August Moon” one of the characters says: Pornography question of geography •This says that in different geographical contexts people view things differently •Furthermore, the syntax of the language (no verbs) is typical to the way that the people of Okinawa are talking When listening to a concert people are not talking, eating, and keep their mobile phone on “silent”.
  70. 70. Context has three distinct roles (which may be combined) The events that relate to each customer are processed separately Partition the incoming events Grouping events together Grouping together events that happened in the same hour at the same location Different processing for Different context partitions Determining the processing
  71. 71. Context types Segmentation Oriented Temporal Spatial Fixed interval Fixed location Event interval Entity distance location Context Sliding fixed interval Event distance location Sliding event interval State Oriented
  72. 72. Context type examples Segmentation Oriented “All Children 2-5 years old” “All platinum customers” Temporal Spatial “Every day between 08:00 and 10:00 AM” “A week after borrowing a disk” Context “3 miles from the traffic accident location” “Within an authorized zone in a manufactory” “A time window bounded by TradingDayStart and TradingDayEnd events” State Oriented “Airport security level is red” “Weather is stormy”
  73. 73. Fixed interval In a fixed interval context each window is an interval that has a fixed time length; there may be just one single window or a periodically repeating sequence of windows. Fixed interval Interval start Interval end July 12, 2010, 2:30 PM + 3 hours Recurrence Temporal ordering 08:00 10:00 08:00 10:00 08:00 10:00
  74. 74. Event interval In an event interval context each window is an interval that starts when the associated EPA receives an event that satisfies a specified predicate. It ends when it receives an event that satisfies a second predicate, or when a given period has elapsed. Event interval From patient’s admittance to patient’s release Initiator event list Terminator event list Patient’s admittance Patient’s release Expiration time offset Expiration event count Within 3 days from an earthquake Initiator policy Terminator policy Temporal ordering Earthquake + 3 days
  75. 75. Sliding fixed interval In a sliding fixed interval context each window is an interval with fixed temporal size. New windows are opened at regular intervals relative to one another. Sliding fixed interval Interval period Interval duration 2 hours 2 hours 2 hours Interval size (events) Temporal ordering 1 hour 1 hour 1 hour
  76. 76. Sliding event interval A sliding event interval is an interval of fixed size (events number) that continuously slides on the time axis. Sliding event interval Event list Interval size (events) Event period Temporal ordering Every 3 blood pressure measurements
  77. 77. Segmentation oriented context . Unrestricted number of partitions: Average of customer’s deposits over last month John Tim Helen David
  78. 78. Segmentation context – (II) Fixed number of partitions Distribution of alcohol consumption by age 18-25 26-50 50-
  79. 79. Segmentation context Within th e house Fixed Location Enti ty di stance location Event distance location Withi n 2 KM from the motel Within 10 K M fro m the accid ent
  80. 80. The notion of situation Event Patterns Situation: an event type of interest that may require a decision or reaction Events of various types are streaming in the system and we are looking at patterns – like “Lego templates” – of event combinations whose occurrence issue the conditions for deriving a conclusion. In our example the pattern is “OCCURS BEFORE”. After discussing the example we shall see more patterns.
  81. 81. Logic tables – the condition part Suspicious customer logic Row # Context When 1 Expressi Start on Every week Conditions Partition by End Customer ID same Event filter Amount <Cash deposit> >= 150K A Pattern on events Filter on patterned events Amount <Transfer Cash deposit Account <Cash Abroad> Deposit> >= 100K OCCURS Transfer IS Account BEFORE Arboad NOT <Transfer Abroad> B C D In words: We are looking at combination of two events – one of them of the type “Cash deposit”, the other of the type “Transfer abroad”, with four conditions: Condition A provides filter for the Cash deposit event – at least 150K Condition B provides filter for the Transfer abroad event – at least 100K Condition C designates the pattern – relationship among the two events – Cash deposit should occur before Transfer abroad Condition D provides condition of such combination – the two events should belong to two different accounts (of the same customer) All events need to belong to the same customer and occur at the same week (context)
  82. 82. Event filter Suspicious customer logic Row Context # When Partition by Expressi Start on 1 Every week End Customer ID same Conditions Event filter Amount <Cash deposit> >= A 150K Amount <Transfer Abroad> >= 100K B Pattern on events Cash deposit Filter on patterned events Account <Cash Deposit> OCCURS Transfer IS BEFORE Arboad NOT C Account <Transfer Abroad> D Back to the example: Conditions A and B intend to select the event that participate in the pattern matching. There can be multiple conditions, each of them refers to a single event (typically to one or more of the fact-type within this event).
  83. 83. Pattern on events Suspicious customer logic Row # Context When 1 Expressi Start on Every week Conditions Partition by End Customer ID same Event filter Amount <Cash deposit> >= 150K A Amount <Transfer Abroad> >= 100K B Pattern on events Cash deposit OCCURS Transfer BEFORE Abroad C Filter on patterned events Account <Cash Deposit> IS Account NOT <Transfer Abroad> D Pattern on events designates what the relationship between events is. In this case conditions C states that an event should occur before another.
  84. 84. Filter on patterned events Suspicious customer logic Row Context # When Partition by Expressi Start on 1 Every week End Customer ID same Conditions Filter on event Amount <Cash deposit> >= A 150K Pattern on events Amount <Transfer Abroad> >= B 100K Filter on patterned events Cash deposit Account <Cash Deposit> OCCURS Transfer IS Account BEFORE Arboad NOT <Transfer Abroad> C D Filter on patterned events are conditions among the members of the “matched set” of events and not on the individual events. In this case condition D is among the two events “Cash Deposit” and “Transfer Abroad” that participate in the pattern result.
  85. 85. Sample of pattern types all pattern is satisfied when the relevant event set contains at least one instance of each event type in the participant set any pattern is satisfied if the relevant event set contains an instance of any of the event types in the participant set absence pattern is satisfied when there are no relevant events relative N highest values pattern is satisfied by the events which have the N highest value of a specific attribute over all the relevant events, where N is an argument value average pattern is satisfied when the value of a specific attribute, averaged over all the relevant events, satisfies the value average threshold assertion. always pattern is satisfied when all the relevant events satisfy the always pattern assertion sequence pattern is satisfied when the relevant event set contains at least one event instance for each event type in the participant set, and the order of the event instances is identical to the order of the event types in the participant set. increasing pattern is satisfied by an attribute A if for all the relevant events, e1 << e2 e1.A < e2.A relative max distance pattern is satisfied when the maximal distance between any two relevant events satisfies the max threshold assertion moving toward pattern is satisfied when for any pair of relevant events e1, e2 we have e1 << e2 the location of e2 is closer to a certain object then the location of e1.
  86. 86. Summary of topic IV Concept-based model Logic tables Next – epilogue and for the rest of the picture 6/30/2013 86
  87. 87. Agenda I Topic I: Introduction – Brief history of event processing II Topic II: The major differentiation factors of event-based thinking vs. traditional computing III Topic III: The computational independent model 87 IV Topic IV: Drill down to the model components V Topic V: Epilogue
  88. 88. From Computational Independent Model to Platform Independent Model There is additional lexicon entity called “IT element”. Each concept can be mapped to IT element, which can be used to complete the missing links in the CIM model The next step is to translate the CIM model to a canonic model that still does not conform with specific implementation, The PIM model follows the model introduced in the EPIA book
  89. 89. Event Driven Architecture Event driven architecture: asynchronous, decoupled; each component is autonomic.
  90. 90. The model’s building blocks Event Channel Event Producer Event Consumer Event Type Event Processing Agent Context Global State
  91. 91. The building blocks connected
  92. 92. Event Processing Agents Event Processing Agent Filter Translate Enrich Transform Aggregate Project Split Detect Pattern Compose
  93. 93. More things to model Instrumentation Reaction decision Non functional requirements
  94. 94. Other computational independent models The decision model – a declarative model for decision management (BRMS) Artifact centric BPM
  95. 95. OUR DRIVING FORCE IS TO HELP EVERYBODY REALIZE THE POWER OF EVENTS TO CREATE A BETTER WORLD

×