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.
3 comments:
Hello Opher,
I totally agree with your statement about standardization. To me it seems that there is a lack in definition of a "standardized on the wire protocoll" which means there need to be:
* Defined methods how to access the events accross several event processing systems
* Strukture how an event should be designed without any functional aspects (functional aspects depends to much in different industries and there are many efforts investigating industry specific data models where - without the focus on getting a defined protocoll like metadata strukture)
* Languages e.g. UML profiles that support the users in designing and devloping event processing applications. The underlying technology that implements the models may differe from my point of view, but there need to be at least a common description
My guess is, that we'll might getting there in the future.
Best regards,
Christoph
I think an effort to create some kind of standard on events should focus on the events themselves. Leaving out how they are transported, stored, processed or created. By peeling of just about everything except a very simple event format with some syntax is enough to get things started.
We need to get this event standard thing started, not creating the best possible standard.
Hello Marco,
you are absolutly right and maybe I just did not express myself right.
When I was talking about the structure, I meantioned that an event needs basic "protocoll" methods like create, send, destroy, aggregate, correlate, or whatever...
I did not want to design a super protocoll over http, jms, direct database connections, ... just the basic operations you can do on an event.
What I wanted to emphasize is, that we should not go too much into industry domain stuf, because everyone has it's own object model called type of thing, and we should not conflict with domain specific knowledge.
Best regards,
Christoph
Post a Comment