Another talk at DEBS that threatened to be on-the-ball was Douglas Schmidt’s keynote [*1] on model-driven event processing. Although it was not mentioned, most commercial CEP software systems [*2] can be considered model-driven (e.g. draw a diagram, and the system generates the appropriate code or engine controls).
Every EP researcher has an “angle”, and Vanderbilt’s appears to be “Distributed and Realtime Embedded (DRE) systems”, defined as resource-constrained, typically microcontroller-based, systems. The presenter introduced “Model Driven Engineering” as a common solution, traditionally using state models, process/data flows, and petri nets, all of which (20-40 years ago) had a large semantic gap
to the Fortran / Assembler etc. code of yesteryear. Recent developments in compilers etc have given us fast Java and associated frameworks; the problem (for this domain) is that too much still needs to be coded “outside of the model”, and exploiting the libraries and frameworks is too much like a lesson in complexity management. So the “semantic gap” remains.
Well, somewhat. In the CEP space for business systems, that gap is targeted by the commercial CEP-tool community (and filled, with varying degrees of success).
The presenter mentioned 2 possible solutions: one is the OMG MDA-based approach, which unfortunately he termed “UML Profiles” (aka subsets of UML for a specific domain or use). These combinations of activity diagrams, state models, and “action semantics” [*3] are considered by Vanderbilt as “domain independent languages”. Well they can be, but they can also be domain-specific (and to prove the point, an email just arrived in my inbox announcing the development of an UML profile for XBRL financial reporting – about as “domain specific” as you get).
Instead, the team at Vanderbilt proposes domain specific languages which they call “metamodels”. Which is confusing, as in reality metamodels can be domain independenent *or* specific. The OMG Model Integrated Computing group was mentioned as a guiding light for semi-automated translations of models to code [*4]. Also mentioned were examples of technologies that supported DSLs, such as Eclipse GMF.
The next notion was that of being “distributed” – in DRE parlance this translates to “Ultra Large Scaleability” systems, which in turn sounds very related to the commercial notion of XTP… and hence the work on the following technology pieces to assist with managing complex distributed systems [*5] and which may also be relevant to CEP:
- Runtime performance evaluation from models, sort of in-situ performance verification, through things called System Execution Modeling (SEM) tools [*6]
- These express design rules (as constraints) that can be tested in the model
- Configuration of large numbers of components (100s of 1000s etc) managed via XML configuration files
- Hence the Platform Independent Component Modeling Language or PICML that uses OCL constraints to provide visualization of system dependancies [*6 again]
- Middleware configuration models using constraints for QOS (Quality of Service), transmit times, etc etc
- Hence a QoS Modeling Lang called DQML
The title of this keynote was “Meeting the Challenges of Mission-Critical Distributed Event-Based Systems with Q0S-enabled Middleware and Model Driven Engineering”, but was really an introduction to Vanderbilt (et al)’s work on these (somewhat specialist) DRE systems. No harm in that, as it was interesting to learn what they are up to, even it turns out to be orthogonal to CEP per se.
Notes
[1] From Vanderbilt University in good ‘ole Nashville, who also happen to be hosts for DEBS 2009. Some of the Europeans were a little bemused by the announcement for DEBS 2009’s location, due to comments like “… and we have such-and-such, which is really great to visit, only 350 miles away…”. So better bring your pushbike, then.
[2] Unless you are having to hand-code a streaming query, of course!
[3] One example of commercial MDE is TIBCO BusinessEvents, using UML-based models for concepts (UML Class models), and state (UML State models). In lieu of action semantics (which I guess are directly equivalent to what we call Rule Functions) we prefer to use declarative production rules (and queries). Which are transformed into compiled constructs for efficient event-driven runtimes…
[4] Compare and contrast with the Knowledge-Based Engineering group in the manufacturing part of OMG.
[5] Sounds awfully like those pesky agents again…
[6] Not a common enough term to have a Wikipedia description, though…
