Looking at the first generation of event processing products, one can realize very quickly, that under this name (and some variations of this name) we see different languages approaches. Today I'll try to classify the various styles of languages, and refer to the issue of standard language.
Looking at current approaches, the following classification can be made:
1. Extension of existing programming language (e.g. Java) with some abstractions, but the programming is still imperative.
2. Script languages
3. SQL based languages - based on pure or extended subset of SQL.
4. Rule oriented languages -- the term "rule" is also quite overloaded, and under rules we
can find some languages:
a. Reaction rules (ECA rules).
b. Inference rules
c. Derivation rules.
5. Pattern oriented languages
6. Visual languages.
In some cases there is no single pure language, but a combination - e.g. pattern + derivation or pattern + SQL or script + reaction rules.
Each style has its own merits and drawbacks, and since "event processing" is not a monolithic area (but this is a topic for a short article of its own) there needs to be still a study about programming style vs. type of developers, and nature of application.
Anyway, two question are being raised for this situation: Is it possible to have a standard language that will replace all current languages ? and is it feasible to have such a language ?
The answer to the first question is probably yes, the answer to the second question is not in the near future.
While there are various approaches, the functionality in all of them have large overlap, and with some effort, there is a possibility to get to a language that will unify the functions of all existing approaches (perhaps with some levels of basic language and various extensions). However, with the investment already done, and the strong belief of various vendors in their own attitude, and will take time, and market pressure to consolidate here.
In the interim period, we can devise a "meta-language" that will correspond to a "meta-model" that will include the standard functionality in this area, and translation between this "meta-language" to the various implementations, and thus a weaker way of standard compliance will be - supporting the meta-language.
More discussion in the meta-language later...
