Content Copyright © 2006 Bloor. All Rights Reserved.
StreamBase has just, amidst much fanfare, announced that it is pushing for the establishment of a standard development language for event processing applications. While the company does not necessarily expect that its StreamSQL will be adopted for this purpose, it does contend that SQL should be the starting point for such a standard. This is all good marketing stuff but does it stand up to scrutiny?
Well, the first thing to say is that StreamBase is not the first company to explore such possibilities. Progress, for example, has made such moves in the past: it simply hasn’t made so much of a fuss about it. However, the real issue is technical.
Let’s step back a bit. There are four approaches commonly used for development of event processing applications: SQL, languages, scripting and codeless environments. Amongst SQL adherents there are companies that use standard SQL, extended SQL and so far extended SQL that you would hardly know it was SQL anymore; “based on SQL” is the description often used. Then there are the languages: most common is Java but you can also use C++ or Prolog (with its inferencing capabilities) for example. Scripting options are usually proprietary, as in the case of Progress Apama, but one company offers Python as an option. And, finally, there are a couple of vendors, of which AptSoft is one, which offer codeless environments that are more aimed at business analysts than developers.
So, out of all of these choices, why would you choose SQL as a place to start? The simple answers are that SQL is used to process data and that it is widely deployed and popular. However, the problem is that SQL is a set processing language and events are not processed in sets. Or, at least, they are not processed in sets unless you artificially constrain them in some way. But such constraints, processing events within a time window, for example, have their own drawbacks: what do you do if the validity of a quote expires in the middle of a time window?
The simple answer is that you can come up with a good argument for building a standard event processing language based upon more or less whatever starting point you like. The people who developed the dozen or so event processing products in the market chose a particular development approach for a reason. These people are not idiots: they had good reasons. Who am I to say that one guy’s set of reasons are better than another’s?
In any case, I don’t think this matters because I don’t think it is going to happen. Maybe IBM, or somebody similar, will buy a vendor and become a dominant player in the market and that will force a rethink but until then I can see no likelihood of any standard approach to development being adopted. So, good marketing by StreamBase but I don’t think it will amount to anything much in practice: there are too many players who won’t buy into the SQL-based approach.