Bridge Developement

This section explains the general structure of JEPC bridges. It may help understanding the code of existing JEPC bridges and developing new ones. The general structure of all existing JEPC bridges is illustrated in Figure 1 and comprises four components that are explained in the following paragraphs.

Figure 1: Structure of JEPC Bridges

Implementation of JEPC Interface

Every JEPC bridge has to implement the interface EPProvider that defines the API of JEPC. In this part of the bridges the API of JEPC is mapped to the specific API of the underlying EP system. The implementation of this part has to guarantee that the underlying EP system conforms the defined behavior of JEPC. In general, the API of EP systems is a superset of the API of JEPC. Therefore, the API of a EP system can be easily used to implement the JEPC interface.

Compiler for EPAs

This part of JEPC bridges provides a compiler for each type of EPA. It has to guarentee that every EPA is translated into the specific query language of the underlying EP system with preservation of semantics. The primary purpose of JEPC is to overcome the heterogeneity of EP systems. The most critical heterogeneity problem is the difference in semantics. One critical issue is therefore the complexity of the compilers within the bridges. In order to facilitate the compilation of a complex EPN into structures of heterogeneous EP systems, a complex EPN is first split into its corresponding EPAs and then the corresponding compiler translates each of the EPAs separately by using a translation pattern for each type of EPA. Figure 2b illustrates the mapping of an EPN to an EP system (EPS). A connection between two EPAs is established inside JEPC by connecting the output stream of an EPA to the input of another. This fine-granular compilation not only simplifies the compiler, but also enables a federated processing of EPNs among multiple different EP systems. Because each EPA is compiled and executed independent of the others, it is possible to use multiple different EP systems in parallel for the execution of an EPN. Figure 2c shows an EPN that is executed on three different EP systems.

Figure 2: Query Translation

The translation of EPAs is challenging. It requires in-depth knowledge of the semantics of the EP system. In our fine-granular compilation approach it is sufficient to map each EPA type to either one or multiple continuous queries (CQ) of the underlying EP system. In general, multiple CQs are required to overcome the semantics mismatch between JEPC and the corresponding EPS. Figure 2a shows an example of an EPA with its associated CQ. The EPA forwards its input stream into the corresponding CQ, while the output stream of this CQ is used as output of the EPA. To adapt the semantics, the EPA applies specific functions to the input streams and output streams. These pre- and post-processing functions can manipulate the semantics in different ways. For instance, the (temporal) content of an event can be modified and events might be removed or added. However, the implementations of these functions are not only challenging, but also vary extremely between different EP systems.

Optional Help Methods

Some parts of code may be used multiple times in the implementaion of the JEPC interface or the EPA compilers. Such code is outsourced into additional methods. For example, additional help methods are used for the creation of merge sources in all bridges and for manipulating the semantics of pattern matching in Esper and Odysseus.

Optional Help Classes

Some EP systems may require additional classes. For example, Odysseus requires a webservice client that manages the communication with the Odysseus server.