Nice to see a paper on IBM Developworks on some of the theory of “event processing”, authored (amongst others) by the Chair of the Event Processing Technical Society, IBM Labs’ Opher Etzion, and fellow EPTS Reference Architecture team member Catherine Moxey. The paper is of course somewhat of a “broad brush” view of event processing, as indeed you might expect from a team representing such a diverse range of event-handling software as Tivoli, CICS, MQ and so forth from the broad (and, from a TIBCO perspective at least, heavyweight 
) IBM software stack.
Some thoughts:
- The paper implies a need to model, in any significantly large event processing system, the types and roles of the event processing agents and how they interact. Some such agents will be tightly coupled (such as co-operative rulesets in a TIBCO BusinessEvents inference agent), whereas others will have more identifiable interfaces and roles (such as separate inference and query agents in a distributed TIBCO BusinessEvents application). Tables 6 and 7 for example are almost metamodel definitions for an event processing agent.
- Possibly a better name for the paper would be “A Conceptual Model for Event Processing Networks“, given the emphasis on event pathways through processing agents.
- IBM Developerworks (like this blog) has an unattributable “scoring mechanism”, and shows today that one reader was unimpressed enough to profer a low score – but why? I also can’t explain why this is described as aimed at an “intermediate” audience, as the principles seem basic and well explained…
We here at gemstone have extensively worked on the CEP system, the challenging part of the CEP mechanism is highly available event delivery system; guaranteeing the event delivery in case of the system failure (failure in the node processing the event). Which are critical in financial sectors that track the event matching high risk criteria (Risk management systems). I would have liked to see more comments from author on this subject.
Hi Anil – good points, but probably these are too detailed for a “Conceptual Model”.
There are 2 aspects to “guaranteed event delivery”:
- source event distribution failover support: this is typically a middleware issue, and where TIBCO EMS extensions to the JMS spec come into play
- event processing failover support: this is where the event processing component failover features are required. In effect there are 2 sub aspects here:
– event store failover support: this is where tools like TIBCO ActiveSpaces, the TIBCO BusinessEvents cache, and your Gemstone cache provide relevant features
– event processing agent failover support: this is where many of the TIBCO BusinessEvents reliability features hit (things like hot standby agents, etc)
Naturally all the above has to be coordinated: the event processing agent failure modes have to be coordinated with the middleware failure modes etc. For example, it could be considered that one of the “special advantages” of TIBCO BusinessEvents is that it can exploit the reliability and resilience features of TIBCO EMS messaging…
Cheers
I see IBM has issued this paper now as a RedBook…