Matt Rathera from Apama and Marco from Rulecore both talking about actions as part of CEP functionality.
So - let me make some observations:
There are two types of what people refer as "actions" --
- "actions" that actually process events (enrich, transform etc..);
- "actions" that use events as trigerrs to do something outside the "event world" .
Thesese two types are semantically different:
- The first type is part of the "event processing network", in the sense that it gets one or more events as an input, process the input, and produces one or more events as an output. This may be - simple, mediated or complex event processing, but there are "internal" actions -- and I would not call them actions - but classify them according to what they are doing (e.g. XSLT is doing transformation).
- The second type is the real "actions" - they occur outside the event world -- and are trigerred by the events. It is true that they can be arbitrary complex, but then set of actions with relationship among them is not really something that is unique to event processing -- this is known by workflows (or BPM in their contemporary name).
As good software engineering practices talk about "seperation of concerns", I don't view actions of that type as part of "event processing", but as part of the activities of event consumers (and producers). Of course, they may interact with the event processing part by receiving and emitting events - thus, causality relations among events can go across such actions -- however, there is no need to re-invent the wheel here, as event processing is part of a bigger whole - the bigger whole also contain BPM.
Of course, there may be justification in some cases to have mini-workflow attached to EP engine - but architecturally this logical seperation will help the model and thinking about it to be cleaner.
More - Later.