The fact that I am concentrating on event processing is true, I would not equate "event" with "moving data", since event has some semantic meaning of something that happens, and has some time dimensions associated with it, so I would classify is as a kind of moving data, some moving data are not events.
There are indeed some benefits to use event processing concepts over stored data, I'll talk about one aspect which is the notions of pattern and context.
An expression like:
The vehicle moving in consistent direction south within the temporal context that starts with surveillance start and ends with vehicle stops partitioned by vehicle.
This is (more or less -- it should be done with a visual language rather than textual) a combination of pattern and context. This is somewhat easier than writing the same in SQL. There were attempts to mix SQL and patterns, but keeping the SQL semantics makes it somewhat complex. If we can use such a language, programming may be easier, this can be translated to SQL in the background.
There are some other benefits to use EP concepts for databases as well as for messaging systems, BRMS, and other related technologies.
On another matter: I am reading with interest Mark Palmer's nine predictions for the future of event processing, I promise a review after he'll finish to write all nine (now he is in #3).
More - Later.
2 comments:
I would say that stored events also are moving events, only difference is that they have moved on.
When we are at time t, an event at t+10 is is a moving event; but when we have moved to t+20, the event at t+10 became a stored event.
Or am I missing something? :-)
Hi Maniy.
The issue is not so "moving data" vs. "stationary data", as said I don't view events as "moving data", but as a distinct semantic entity.
The main issue is events vs. data that are not classified as "events", and the claim is that concepts created for events, can be usable in some way to the more general "data" universe, the same applies for "messaging".
cheers.
Opher
Post a Comment