Monday, April 13, 2009

The Emulated World

The work the glossary group (of which I am a member) of the event processing technical society is incredibly interesting.  How do you take all of the terms of a new, upcoming transformation in the way we design systems and document them in a way as to expand the usefulness and usability of the concept is what we are trying to accomplish.  To do so there are at least a couple of areas: 1) Philosophy, 2) Descriptive/Proscriptive and 3) Mechanics.  (Probably more!)

I want to write a bit about the philosophy behind events and to a certain extent computer science in general.  My contention is that what we are building with computer systems in general is an emulated world that allow us in a query-able fashion have/get/develop an understanding of the real world.

An examples to make this more clear.  

A warehouse has many objects in it.  Each set of objects (Say a pallet) has a location, quantity, item type, an owner and potential endless attributes.  In the real world, you can't stand in the middle of an isle and say "How many widget Xs do we have?" and expect an answer.  You would have to count them.  So, we develop an inventory system that keeps track of actions done to all of the sets of objects: Move, ship, receive, destroy, assemble, disassemble, etc.  The inventory system is emulating reality and allowing the events that occur in the real world to stimulate process in the emulated world that alters the persistence of this information.

So, the problem becomes how do we get the events in the real world into the emulated world?

Lets keep with the previous example.  An early ERP system would have created an order for work to be done (The move, destroy, ship, receive, assemble, disassemble events), some entity would accomplish that action and mark that it was done.  Usually this all happened on a piece of paper called a pick list.  The pick list would be turned in to a inventory clerk who would enter the new information to the inventory system and it would be updated.  This caused problems because of latency of information update, accuracy.  So people got smarter and they barcoded it so that when the forklift operator dropped it off, it would be scanned and updated quicker.  Now we attach RFID transmitters on these items so that they can be tracked with finer granularity and all movements can be even easier to capture.

This is what I call crossing the threshold between the real and emulated worlds.  We have a variety of means of getting information to pass over the threshold.  User or systemic interfaces, sensors and actuators are all means of getting these events across the border.

But what is our goal in all of this?  We want to have as accurate as possible representation of what is happening in the real world in this emulated world.  Why?  Because the emulated is what we can manipulate, model and make sense of what is happening in the very complex real world.

So, what does all of this have to do with CEP?

There are two types of events.  Those we can sense (without intervention) their occurrence in the real world and therefore react-able in the emulate world and those we can't.  The number of events that can be sensed via sensors such as RFID, biometrics, thermometers, red-light cameras are increasing daily.  A lot of research and money are being spent on increasing the ability of the emulated world to "see/sense" into the real world.

But what about those events we can't sense yet?  Traditionally,  we have built user interfaces to allow humans to intervene and "enter" the event into the emulated world.  The problem with this method is the reliance on a person to intervene?  How accurate will that be?  How timely?

Complex event processing allows a different mechanism to determine that event occurred in the real world.  We can compute it.  We derive an event that we can't directly sense through the combination of events that we can sense.  As an example, we can't directly measure that a car is speeding. (Although that is probably coming)  The speed event however has implications to events that capture-able.  The most obvious is the radar gun.  A police officer uses a radar gun, determines the motorist is speeding, writes a ticket, that ticket is entered into the system updating the emulated world.  Another method would be to have high-speed camera at certain intervals that take pictures of motorists license plates noting the car (identified by the license) and the time and the place.  Further cameras would record the same car at a different time and different place.  The math would be easy to determine how long it took to travel from point A to point B and if that would be in violation of the traffic laws.

Regardless if we have the technology to implement this particular scenario isn't important.  But it illustrates how an event is not an island.  More to the point there are potentially many ways of determining if this event occurred.  Some of them would be able to pass through the threshold between the real and emulated worlds allowing computation to determine the realization of the more interesting event.

Next post will be about how do we name events.