Is graphical modeling for domain experts outside information technology (IT) the better choice in complex event processing (CEP) than doing it in some (text-based) event processing language (EPL)?

There are two steps to prove this. First, develop a suitable graphical editor and demonstrate that the graphical models may be transformed into artifacts executable on a real CEP engine. Then, evaluate and compare the usability within and between chosen target groups.

The paper excels in the first step. In a really superb, lucid, concise, and at the same time easy-to-follow way (even for novices in the CEP realm), the authors describe CEP basics, their modeling metamodel, and the graphical model editor they have developed; give two examples of such graphical models; and demonstrate the viability of this approach down to the level of the automatically generated Esper EPL code.

Even though the authors openly claim in several places that their graphical models are “understandable” and “user-friendly,” and that domain experts with no EPL knowledge are “able to make use of the developed editor easily,” they fail to give any proof of this second step. As a matter of fact, the featured graphical models even seem to demonstrate the exact opposite: eight lines of concise EPL code need a diagram with approximately 50 different elements (boxes, lines, rectangles, circles, and so on) scattered over the model’s “canvas.”

On the technical side, the broad claim that the developed graphical model editor would work for “all” types of EPLs is also validated only for stream-oriented EPLs and not for rule-oriented, or imperative, EPLs (like Software AG’s Apama).

Nevertheless, due to the high quality of the work in the other parts, any reader interested in bridging the business/IT gap in the CEP domain should consult this paper and see and judge for herself.