OMG CEP Standards event: what standards?
Posted by Paul Vincent
I am pleased to report that no blood was spilled in the latest vendor get-together at the OMG Washington meeting [*1].
Some of the interesting comments from the presentations were:
- “80% of [implementation] work is new event sources” - clearly this may be true for custom event feeds, but otherwise, subject to satisfactory performance, use of an off-the-shelf ESB + adapters clearly makes sense
- Big standardization need is for event semantics and standard formats: this is an argument for Domain Specific Languages (or rather, Domain Specific Events)
.
So the interesting standards discussed were, in order of importance / relevance to CEP:
- OMG Event Metamodel and Profile (EMP): still pre-RFP, with the challenges of bad timing with the BPMN/BPDM 2 debate, multiple UML definitions of event in existance, and the fact that CEP involves continuous event behavior.
- OMG Production Rule Representation (PRR) and W3C RIF: in finalization, with good progress made at the PRR Face2face earlier in the week. Current PRR semantics do not cover continuous quey languages, though, which are used by many other CEP vendors; possibly it could do in future.
- OMG Data-Distribution Service (DDS): OK this had 2 presentations (not sure why), from 2 vendors. Not being a middleware guy, I had not paid much attention to DDS before, but it doesn’t seem that any of the big vendors support it (which could explain why the DDS guys got upset when I mentioned JMS as a “middleware standard”). Generally pub-sub is a good idea, but I’ll leave the discussion on middleware options such as JMS/EMS and RV versus DDS to others…
.
Thanks to Robert Marcus, NCOIC and Charlotte Wales, MITRE, for organizing this event.
Notes:
[1] An interesting metric for this event was the number of vendor marketing slides (or talk) per presentation: one was near 100% (a real turn-off for attendees), yet others were <5% (so full marks to TIBCO, Rhysome, RTI and PrismTech). [OK, we shouldn't vote for ourselves - judge for yourself with the TIBCO rule standards presentation: Role of Rules and Stds in CEP].
Complex Event Processing (CEP), Meetings and events, Rules, Standards | 13 March 2008 |
4 Comments
Other Links to this Post
-
In the names of CEP and BPM « Commercial Intelligence — March 14, 2008 @ 07:30
-
Complex Event Processing (CEP) Blog » CEP sessions at the OMG Real-Time July 08 workshop — July 21, 2008 @ 10:01
RSS feed for comments on this post. TrackBack URI
By Angelo Corsaro, March 19, 2008 @ 09:31
Hello Paul,
First of all, I enjoyed your presentation at the CEP workshop. That said, I have a few comments on your wander about the two DDS presentations. As showcased during the Workshop, DDS is the “perfect” transport for CEP engines for the following reasons, (1) it is extremely natural to map CEP events to DDS Topics, especially considering DDS support for relational data modeling, (2) DDS supports some event processing capabilities which could be used by CEP engines to off-load some of the filtering to the middleware, thus ensuring that only relevant events are delivered to the CEP in first place–thus more relevant events are processed overall! (3) DDS has unparalleled support for QoS, which allow to control temporal properties, availability, persistence, reliability, etc., of data, (4) OMG DDS has on-the-wire interoperability, i.e., implementation from different vendors can speak to each other, and (5) it is very high throughput and low latency, meaning that leading DDS implementations can easily cope with Millions of messages per seconds, while retaining extra low latency and jitter.
Moreover, leading vendors provide integration with both on-memory data bases as well as RDBMS such as Oracle, MySQL, etc., (this means that you could use DDS to connect to fully transparently and two way to the a DB), as well as security solutions.
In summary, DDS is the ideal transport for any application that has to stream and process in real-time huge amount of data and “make sense” of them in real-time. As you very well know, several examples of such applications are found in Financial Markets, Defense, SCADA, etc.
By vincent, March 19, 2008 @ 14:12
Thanks Angelo: I’m not sure how (1) is more than what conventional pub-sub provides, although the SQL query mechanism in theory means you could offset some filtering and queries to the DDS middleware. Which is your point (2) I believe, and is also subject to academic research like at Univ of Toronto (see last years EPTS Meeting). (3) to (5) make perfect sense, although I can’t comment on whether DDS is better or worse than other solutions in this space.