This week’s EBizQ mailshot referenced not one but 2 event processing articles – an indication of mainstream interest perhaps?
One article is by Mani Chandy and introduces the topic of Sense and Respond applications, their responsiveness and uncertainty-handling characteristics, and their relation to things like BI and BPM.
The second is a reference by Jack Vaughan on an Imperial College London / Cambridge University UK paper on a security architecture for event processing systems presented at a USENIX conference. Security is of course a big deal in SOA and messaging, although in event processing I have always considered it an application area for event processing rather than something in event processing itself – clearly the provenance of events, and security of event channels and event processors need to be understood and handled, but outside of secure signatures and encrypted events I view the area as generic to IT, not specific to event processing applications. Maybe I’m wrong…
The paper (“High-Performance Event Processing with Information Security”) abstract says:
In finance and healthcare, event processing systems handle sensitive data on behalf of many clients. Guaranteeing information security in such systems is challenging because of their strict performance requirements in terms of high event throughput and low processing latency. We describe DEFCON, an event processing system that enforces constraints on event flows between event processing units. DEFCON uses a combination of static and runtime techniques for achieving light-weight isolation of event flows, while supporting efficient sharing of events. Our experimental evaluation in a financial data processing scenario shows that DEFCON can provide information security with significantly lower processing latency compared to a traditional approach.
The paper then describes its “threat model” as processing units may contain unintentional bugs or perform intentional information leakage. … However, we do want protection from parties that may otherwise be tempted not to play by the rules, e.g. by trying to acquire information that they should not access or leak information that they agreed to keep private….
Their solution is to tag event data, and seemingly to modify the underlying JVM of event processors to ensure that the results of operations on tagged objects are also tagged. In some ways this seems similar to the TIBCO Kabira Fluency approach for adding transactions to Java objects. In both cases the approach probably works fine until someone uses some non-Java application…
