Monday, July 6, 2009

On state based event processing

Early morning in Nashville. I arrived here yesterday, and after some rest, went to dinner with some of the people in the community (this was initiated by Matthew Cooper from Eventzero who invited some people). In the dinner I was sitting next to Dieter Gawlick from Oracle, one of the most active people in the community. Dieter is recently advocating the concept of "state based event processing", based on some work he is doing. Today I'll hear more about it in the use cases tutorial, and then in a later meeting with Dieter to get feedback from the use cases workgroup to the language analysis and reference architecture work groups. My initial impression is that in the term "state" he more or less means what we call "context". I have just written the first draft of the chapter in EPIA book defining and describing the term context (will be available on the Web within a few weeks I hope). It will be interesting to see if how the notion of context will further evolve. Most event processing languages have very modest support in context these days (e.g. time window as a simple case of temporal context). I'll write again about contexts and states in one of the next postings. Today -- the DEBS conference start, and the tutorial day (last year it was the most interesting day of the conference, let's see if we'll keep the standard high). Now -- going over my part in the event processing language tutorial, so I'll not mix up the English words...

1 comment:

Anonymous said...

Hi Opher,

If I can complement my colleague, this is essentially what we mean by needing an abstraction that represents (contextual) data that can be joined with the streaming events.

In our case, we are calling this data a 'relation' and we join, in one instance, through 'time', hence the need to time-stamp the relation itself.