On Actions

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" --

1. "actions" that actually process events (enrich, transform etc..);
2. "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.

From manual event processing to event-based programming

Do you remember typewritters ? It became obsolete before some of you were borne, but I have used it a lot in my youth, since my handwriting required some efforts to interpret, I preferred to submit projects from junior high upwards using typewriter. Not very convinient in "word processing" - changes sometimes required re-typing of the page, sometimes fixes could be done with Tipp-Ex which also became a forgotten artifact. Today's word processing is much more convinient.

Paul Vincent has written in a recent Blog about "manual event processing". The example brought is certainly an event processing, there are many examples of event processing -- everytime that somebody calls and I pick up the phone, it is event processing, or if I am in a middle of a meeting, looking at the screen of my cellphone and decides not to take the call - it is also an event processing. In fact, manually we are doing a lot of event processing, and this is something very typical to human behavior. However, the programming paradigms that have been constructed, did not really intend to model the human behavior, and programming was developed, starting from Assembly languages and upward, in the assumption that we are first put values into - registers, variables, buffers, databases etc - and later when we wish to do something specific we retrieve it from wherever it is and use these values. Events in old programming languages such as PL/1 (my programming mother tongue) where used to handle exceptions. We have discovered the usefulness of teaching information systems how to process events only at a later phase -- first, by using (or abusing) regular programming to process events, and recently by various COTS that help process events -- however, the tools used are still rooted in the "store and then process" world -- SQL, business rules, scripts -- are all part of the traditional programming paradigm.

This is similar, in a sense, to do word processing using a typewriter --- we still need to invent event processing tools whose primary programming paradigm will be based on event processing as a major set of abstractions - and not as implemented on top of programming paradigm that don't match ---- well, still a lot to do on this --- more later.