{center}
{flash:file=Architecture^soceda_architecture.swf|width=581px|height=486px}
{center}

h2. Description

 As described in the Complex Event Processing state of the art document ([D4.1.1|soceda:Work packages and deliverables]) we would like to simplify the CEP design aspect with graphical tools. This document is about the CEP Editor which is supposed to facilitate the CEP rules creations.

In the SocEDA project we do rely on the Esper engine, so we will be talking about EPL as event processing language. The main goal is to translate a designed model and a high level definition of conditions into EPL Rules (Esper-EPL as a first step).

In order to make this EPL rule design aspect easier, we want to provide a drag & drop tool where the user can use event types coming from an event type repository. Basically, it allows to design a small diagram representation of rules in order to push EPL queries within an Esper instance without having to interact with any IDE.

!EPLEditor.JPG|border=1!

h2. First implementation

We do simulate an event type repository and an esper instance with databases. In order to use those event types in the EPL editor we need to retrieve event type descriptions. The EPL editor contains an input stream component where the user will define or select an existing event type. We will then have to retrieve the properties of this event type in order to allow the user to manipulate those properties within the next components of the diagram connected to this input stream component.

 This first architecture stands for the first implementation but the idea behind is to get a first stable version that we could bind with the rest of the soceda architecture.

!CEPEditorDependency.JPG|border=1!

h2. {color:#9a2d15}{*}EPL Generation & Validation{*}{color}


h4. EPL generation

From an EPL diagram the tool is supposed to generated all the needed queries to run the whole diagram scenario. It means when the user click on the “generate rule” button the tool has to parse the whole diagram and generate the window creations in case it is necessary as well as the insertion to update those windows. It also has to generate the join, aggregation and queries details previously setup in the configuration panels.

{color:#9a2d15}{*}EPL validation{*}{color}

It would also be interesting if the tool could offer an EPL validation. In order to do so, the EPL editor should communicate with a servlet where an esper engine is plugged. This esper engine will have access to the event type repository in order to be aware of available event types and validate this query aspect. Then when the user click on the “validate epl” button the queries should be sent to this servlet, so to an Esper instance running behind. Then the error output or the validation message should be sent back to the tool which will advise the user.

The architecture below is the current implementation !EPL Editor architecture.JPG|border=1!