In among the sessions at the recent OMG Real-Time Distributed Object workshop were 2 interesting CEP papers. The first was by the Naval Surface Warfare Center on their evaluations of CEP technologies and tools for potential Navy use. Their goal is to replace certain “hard coded” event processing logic in expensive systems with some more flexible event processing system(s), especially in “soft” (non-combat) applications such as Quality Of Service (QOS) management, fault management, status monitoring and readiness assessment. Some of the interesting points that came across included:

• The Navy had gone to industry, asking for commercial CEP tooling, in the late 90s to early 00s – and had got the reply that there was no business case for such a tool. Naturally, they were now delighted to have so many to look at and choose from (and to have had their original requirement proven correct).

• A major issue was the “lack of standards” and/or “equivalent competitive products” to avoid vendor lock-in, even though the presenter (who had attended the OMG CEP standards event in March) recognized there was no compelling business case for the smaller vendors to develop such standards. But the message was clear – without standards, CEP faces an uphill battle for adoption in the DOD. [Funnily enough I had presented a more optimistic view on this topic in the previous session (such as the development of OMG PRR and W3C RIF for representing production rules for event pattern detection).]

• A lot of work had gone into developing metrics for CEP systems. These included:

  • runtime performance
  • architecture scalability
  • fault tolerence
  • IT fit (including availability of adapters to other event providers)
  • ease of use

• Other work had gone on into runtime performance measurements and benchmarks, such as throughput and latency versus:

  • numbers of rules
  • numbers of rules used
  • rule complexity
  • rate and complexity of incoming events

• Example CEP applications that could be of interest included:

  • Semantic Event Processing, such as routing messages between systems and converting them to the appropriate measurement units and ontologies
  • Monitoring military checkpoints in realtime
  • Tactical situation monitoring.

My only caveat from this session was an impression (from some of the slides) that NSWC were still thinking in terms “event driven application servers” [*1] as the default / de facto solution for CEP. But of the major app server vendors mentioned, none use their mainstream app server products for CEP (and presumably for good reason)…

The second session was from a middleware vendor, who had teamed up with a CEP vendor to do some DOD-funded research on applying CEP to system monitoring and network intrusion. The idea here is that there may be 100s of tools on a network such as Scanners, Sniffers, System Fingerprinting, System Monitors, Vulnerability Databases, Monitoring (such as HP OpenView), and Intrusion Detectors (such as SNORT), that all contribute evidence or information that can be aggregated and correlated using CEP. This seemed an emminently “sensible” approach to applying CEP to network security -  re-using existing, proven techniques and adding value by combining them together.

Notes:

[1] Favorite quote from this Wikipedia article (at the time of writing): “Application servers are a throwback to mainframe computing”.