This is the illustration of the event processing network for the Fast Flower Delivery example that accompanies the EPIA book we are writing, don't spoil your eyes reading it. We'll provide the readers with an open source editor to the EPN meta-language we have developed (developed by Ronen Vaisenberg, a Ph.D. student in UCI). I'll have posting about it with more instructions in one of the next postings.
In this posting I would like to go back to the nodes in EPN and discuss why do we need multiple nodes and what are these nodes. One version is that there is a single type of node called EPA -- event processing agent, but my preference is to have multiple nodes, since they have different roles. Here are the types of nodes in our EPN model:
- Event Processing Agent (EPA): a node that gets one or more events as an input and produces one or more event as an output.
- Event producer: An entry point to the event processing system that emits events to the EPN.
- Event consumer: An exit point from the event processing system that receives events from the event processing system
- Event channel: A node that make routing decisions within the EPN, I have recently discussed event channels in this Blog.
- Global states: This is a node that holds various type of state (reference data, global variables)
- EPN node: An EPA can represent an EPN, and thus make the EPN recursive.
One of the frequent questions is whether an event producer which is also an event consumer is considered an EPA. In my opinion, the answer is no. Event producers and consumers operate on the borderline of event processing network, and is actually have have two nodes one for each of its roles. The information that a consumer is also a producer is important for traceability and lineage, but we'll discuss this aspect another time.
Christoph Emmesberger, whom I met in Trento, has proposed to extend the notion of channel to provide aggregation and filtering, this idea is rooted in pub/sub systems where event processing seems as an extension of some event processing functionality. However, when we deal with event processing system, I prefer to make a clear distinction between event processing agents that is doing -- filtering, aggregation, transformation and event pattern detection , and leave channel as a routing mechanism. thus we'll ensure proper separation of concerns, and have a cleaner model. We are now finishing the chapter about pattern detection, and I'll write about patterns soon.
This is Escher's famous picture "relativity" reporduced in Lego blocks. I reminded of the relativity issue while reading Paul Vincent's Blog entitled: "Is CEP subset of BPM"?
Well, if you ask the BPM marketing persons they will probably say yes, as today we can see event processing as part of a BPM stack (well, for some vendors). However, this does not say that event processing is a subset of BPM, the same question can be asked about databases, BPM suites store stuff on databases, so databases can be, by the same token, considered as subset of BPM. In the 5th Event Processing symposium, last week in Trento, we had sessions dedicated to the relationships of event processing with BPM, IT management and Robotics. IT management also viewed, for years, anything that has to do with events as a subset of IT management, and they are also right, since IT management deals with events, again, it also deals with databases. Talking with a simulation person he told me that event processing, of course, is a subset in simulation, and actually invented in the world of simulation (I thought that it has been present also in ancient operating systems). So everybody have their own relativistic view about event processing being a subset of something.
IMHO, Event processing, like databases, is a generic technology (BTW, some database people view event processing as a subset of data management, which IMHO is also not true) that can be embedded in various frameworks. The question is whether we need one generic event processing technology for say - all three domains I mentioned: BPM, IT Management and Robotics, or does each of them need its own variation, maybe they need different (possibly overlapping) subsets of the same technology as seen in this Venn Diagram? More about it - later.
Chameleon is an adaptive animal, it can adapt it color to the environment. In the next few weeks my main task will be to complete a proposal for EU project that deals with adaptive services. I have (mistakenly?) agreed to coordinate a consortium that creates a proposal. We had a meeting in Trento following the EPTS event processing symposium. EU project has a benefit of getting funding for research that can explore more advanced topics then can be funded by commercial corporates, and also provide an opportunity to collaborate with some very good people both in industry and academia. The down side is that there should be much investment in the proposal, since it became extremely competitive.
The proposal is about the idea of adaptive services -- which means in plain words that the behavior of the system should be adapted to (unexpected?) events. This adaptation may require human interaction (e.g. modifying medical treatment protocols), or self-adaptation (e.g. change of emergency handling protocol on the fly). The research challenges here are in area of event processing -- having more advanced features that are beyond the state-of-the-art; adaptation, modeling and methodology of how to build such systems. More about this topic - later.
This is the illustration of the event processing network for the Fast Flower Delivery example that accompanies the EPIA book we are writing, don't spoil your eyes reading it. We'll provide the readers with an open source editor to the EPN meta-language we have developed (developed by Ronen Vaisenberg, a Ph.D. student in UCI). I'll have posting about it with more instructions in one of the next postings.
