On event processing building blocks

As response to my posting about stand alone or part of a bigger picture, Marco made a comment that in the event-driven world there is an opportunity to provide building blocks that may be used in various platforms and part of multiple bigger pictures. This is a valid point, as event processing is indeed a collection of capabilities of various types -- transformation, aggregations, pattern detection and more, each of them can also be of various types --- e.g. supporting variety of aggregating functions, variety of transformation, multiple patterns etc, coupled with the fact that event-driven computing is decoupled, thus the interfaces to these components can be quite simple --- receive events and send events, can provide an opportunity to provide variety of such components, kind of plug-and-play event processing. The key, and currently main obstacle in letting it happen is standardization and current lack of standards.

• Interoperability standards are needed for standard interfaces
• Event meta-data standards are needed so that the events exchanged between components
• Languages and meta-modeling standards so people can model and program in a seamless model.

I believe that this is the right direction going forward, and it is a direction we in Haifa Research Lab are investigating; this might be the key to make event processing a pervasive technology - more about it, later.

On EPTS Glossary 2.0

Version 2.0 of the EPTS Glossary has been posted for public review, this is an opportunity to everybody in the community to review and comment, within a few weeks, the final version will be reviewed for approval by EPTS.

Event processing - stand-alone, part of a bigger game, or both?

Following my previous posting, somebody told me that I was vague about whether I think that event processing as stand-alone technology is good or bad. Well -- when I was a student I took "image processing" course, and we worked on a graphical screens with 256 gray levels, since then I realized that even in "black and white" picture there are a lot of gray area Thus, I cannot classify it as "good" or "bad". But I'll provide some observations:

1. The event processing area started as "stand alone" engines, this has been obvious, since it started by start-ups and not by big companies as part of other frameworks
2. There is a gradual shift in the market from stand alone event processing solutions to event processing capabilities embedded in larger frameworks, when bigger companies got into the picture, and this trend has intensified.
3. "Stand alone" products may have to implement functions that "embedded" products can use existing functions in the original framework, such as: routing, transformation, filtering...
4. Unlike some software components that may need tight integration, event processing work in loose coupling relative to other components -- sending and receiving events --- thus this supports the possibility for having stand-alone EP.
5. However, there are no interoperability standards which requires to provide adapters for each producer and consumer, which makes stand-alone EP more difficult, relative to a single framework -- the level of difficulty is a functions of the quantity and diversity of producers and consumers. Enterprise integration framework may already include variety of adapters that the embedded EP can get "for free".
6. Event processing is in many cases part of a bigger application, and in this case, there is a benefit of having a single programming model for the bigger application, and not using different programming models/languages/user interfaces for the various part of the system, this also goes against stand-alone EP; In cases where the system is pure EP, this consideration may not be valid.
7. Stand-alone EP may support heterogeneous components -- e.g. work with DBMS from one vendor, messaging system from another vendor, and connect to BPM system from third vendor, while embedded EP is typically homogeneous, since it all comes from one vendor. This may be true, though today there are a lot of cross-adapters among various components that enable framework to support other components (say DBMS) from other vendors, especially where there are standard interfaces.

Is there a bottom line here? --- I guess that the gray area is that there is some segment of the market in which stand-alone EP can live, but I also think that the trend of moving from stand-alone to embedded will continue to exist.