Greg Reemler
Sun, 30 Mar 2008 03:24:06 +0000

Like the predictable ebb and flow of ocean tides, we see the rise, falling and passing away*of*lively*debates*about event procesing languages (EPLs).** For example,*you might*recall that*Louis Lovas, Progress Apama, *did an excellent job in his post, Bending the Nail, where he described why SQL or Extended SQL is not the optimal EPL for event processing.**
A few of us in the “SQL is not necessarily*the best EPL” choir started singing with Louis which motivated a counter voice the choir*with the post,*Fair and unfair criticism of an SQL EP*approach*only to have the same author counter*that post with, One down side to an SQL EP*approach.***
Many technologists, including some of my team members at Techrotech,*enjoy focusing on*linear*event processing problems with strict determinism, for example, processing a stream of market data and looking for opportunties to enter or exit the market (algo trading).*** These same technologists*tend*champion event processing problems that are basic transformations of*simple streams of time-series data.**
Many of the so-called CEP*cybertrading examples (I would argue that*these are*simple event processing, not complex event processing examples)*are not rooted in event processing*scenarios that require looking for causal linkages between seemingly unrelated events; for example, debugging complex distributed systems or detecting fraud over long periods of time where sliding time windows on continuous streaming data are only a part of the solution in the uncertain world of* cloudy event-causality relationships.
Time-series analysis with strict determinism are interesting, but I would not go so far at to call this*processing*”complex event processing” relative to the myriad challenging complex*problems in the real-world.



Source...