Having opened a veritable 'can of worms' with my post dated the 2 March entitled, Event Processing gets 'complex', my curiosity regarding the debate surrounding the use of Structured Query Language (SQL) in some complex event processing (CEP) applications, was further aroused.
The debate that post generated can more or less be summed up as the pro-SQL vs non-SQL camp, with CEP vendors like StreamBase Systems putting its case for an SQL-based standard for querying real-time event streams and stored data, while other vendors such as Kaskad and Progress Apama stated that there was little support for a SQL-based standard for event stream processing (in terms of companies offering this approach).
That may well be the case, but if so many CEP vendors do not support SQL, it made me wonder why some were sticking to their guns and implementing SQL-based languages anyway? I was interested to read an article penned by John Morrell of complex processing software provider, Coral8, reproduced on the Complex Event Processing web site.
Coral8 has developed an SQL-based Continuous Computation Language. In the article Morrell writes, "This [SQL] provides a familiar programming environment, speeding the creation of event processing applications." He later adds that as SQL is a 'pervasive' language, it lowers the learning curve for developers of CEP applications.
So there you have it. The highly competitive CEP space is dominated by vendors pushing different approaches, and after all choice is a good thing. But is there a right or wrong approach, and can SQL in CEP applications be discounted altogether if it does do what its proponents say it does in terms of speeding up development?