Looking at the EP blog-land, I found that two of the current postings has talked about actions: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.
1 comment:
Hi Opher, thank you very much for this post. You saved me the "trouble" to answer the posts that motivated this entry of yours. As you point out actions occur at the edge of the event processing network and are not really part of it. It's important to separate concerns here for many reasons, among them that seems to make sense to have different programming models for event consumers and event processing agents, the former being developed using well-established event-driven programming models supported by existing mainstream languages and application hosting engines, since they need to integrate with existing enterprise applications and infrastructures, the later with a complete new programming model based on a new set of abstractions that capture the specificity of event processing, as you pointed out on your excellent previous post. Another reason to separate actions from event processing is to avoid the proliferation of monolithic event processing applications, history has taught us to avoid such animals: by placing event processing capabilities, for instance on an ESB-thing, or an objectgrid-thing, and placing event consumers at the edge of the ESB/ObjectGrid interfacing by using existing technologies one can obtain an open and scalable event processing platform that truely delivers on the promise to integrate event processing and event-driven behavior into the enterprise information system as a basis to provide effective application integration and event-driven BPM. Moreover, I was also thinking about whether there's a need to review existing ESB/ObjectGrid interfacing technologies, such as web service engines, to see if they are approppriate to integrate event consumers to the event processing network or we can do better: for instance with what we could call event-driven services engines, engines specialized in associating specific actions to specific types of events, much as their web service engine cousins do by associating specific types of requests to specific actions. As web service engines, event-driven ones would provide all the necessary plumbing, interfaces and logic to execute this dispatching in a scalable and concurrent way. Without this piece of technology I fear that event consumers will need to implement a good part of that boiler-plate by themselves which I do not believe is going to be practical...
Cheers!
PatternStorm
Post a Comment