Administrative REST services

There are REST services that allow managing the CEP definition repository that holds the CEP application definitions available to the CEP engine instances at run time. These services allow putting a new definition file to the repository, getting a specific definition from the repository, updating a repository definition file or deleting a definition from the repository. In addition, there are REST services that allow controlling the CEP engine instances at run time. These services allow starting and stopping a CEP engine instance, updating CEP engine instance definitions and reading the state of the CEP engine instance (started/stopped and its definition url).

9.7 Basic Design Principles

 The EPN application definition can be done using a user interface without the need to write any code, with intention for visual programming.

 The CEP application is composed of a network of Event Processing Agents. This allows the agents to run in parallel and to be distributed on several machines.

 Logical EPN definition which is decoupled from the actual running configuration. The same EPN can run on a single machine or be distributed on several machines.

 The event producers and event consumers can be distributed among different machines.

 Event producers and consumers are totally decoupled.

 Adapter framework that is extensible to allow adding any type of custom adapter for sending or receiving events.

 The expression language is extensible and functions can be added if needed.

9.8 References

[EPIA] O. Etzion and P. Niblett, Event Processing in Action, Manning Publications, 2010.

9.9 Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as

"PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

9.9.1 Open API Specifications

 Complex Event Processing Open RESTful API Specification

9.10 Re-utilised Technologies/Specifications

9.11 Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

 Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FI-WARE has associated a data type and avalue. FI-WARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FI-WARE are referred as basic data values. As an example, basic data values like

‘2’, ‘7’ or ‘365’ belong to the integer basic data type.

 A data element refers to data whose value is defined as consisting of a sequence of one or more

<name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.

 Context in FI-WARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FI-WARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters”

and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.

 An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".

 A data event refers to an event leading to creation of a data element.

 A context event refers to an event leading to creation of a context element.

 An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.

10 Complex Event Processing Open RESTful API