Event Cloud

Event Cloud



Short description The Federated Middleware aims to provide functionalities for enabling large-scale event storage, retrieval and dissemination capabilities by offering a publish/subscribe API on top of a peer-to-peer overlay network harnessing hosting nodes from possibly multiple - so heterogeneous - clouds at once.
Main research challenges Configurable, easily programmable and Cloud based solution offering the concept of event cloud, encompassing:
  1. Persistent storage and notification of Events in a large-Scale and elastic manner thanks to the use of structured peer-to-peer architectures based upon Distributed Hash Table (DHT)
  2. Quality of Service corresponding to Event Level Agreements (e.g. number of notifications delivered to subscribers per time unit, events orderings, privacy of events, event delivery guarantee even in case of non-robust or malicious hosting cloud nodes)
High degree of expressiveness for subscriptions and event publication through the SPARQL language.
Beyond state of the art:
  • Multi-cloud hosted, highly scalable, configurable and programmable DHT, thanks to the original integration of an adequate high-level middleware for grid / cloud computing, and a distributed and autonomic software component programming model.
  • Flexible distributed solution considering the heterogeneity of cloud nodes w.r.t. both performance level due to e.g. the underlying multi-core architecture, and supported fault models (crash, byzantine, altruist, rational -BAR).
The role in the whole platform The main role of the Federated Middleware in PLAY is the storage, retrieval and brokering of simple and complex events which will be used or delivered by the dCEP and by the SOA applications that rely on the PLAY middleware for being loosely-coupled along an Event Driven Architecture.
More information
Component Description

The event cloud is comprised of federated P2P overlay networks combining high-performance elastic data processing infrastructure (grids, clouds), i.e. whose nodes acquisition and relinquishment can be dynamic and subject to a pay-per-use mode. Each node participating in the overlay networks will be responsible for managing the storage of subsets of the events, and will help in matching potential looked up events and disseminating them in a collaborative manner. As such, each node is also potentially an event broker responsible for managing subscriptions and routing notifications.

In order to provide such features, the event cloud will be built on top of previous work done at INRIA by the OASIS and SARDES teams. The Semantic Space, which manages RDF data, will serve as the primary P2P substrate for the event cloud. That means events, be they simple or complex, that the event cloud will manage will be represented as RDF triples. An emphasis will be put on building the content-based publish/subscribe layer so to manage long standing subscriptions for events. Indeed, the event cloud will also offer persistence of the events, in order to allow subscriptions pertaining to past events.

To summarize, the Federated Middleware component is a fundamental part for solving the challenges of the PLAY platform in general. By offering a publish/subscribe API further used by external bricks acting as clients of the event cloud (such as the dCEP, and the ESBs), clients of the Event-Cloud will be able to subscribe to patterns of events they are interested in (using a subset of the SPARQL language) and receive notifications upon matching. Besides, the structured P2P-based solution upon which the Event-Cloud will be built upon has as goal to ensure a certain level of QoS with regards to the topology’s reliability (due to peer churn and peer failures), event dissemination reliability (correct dissemination despite peer failures) and event storage reliability (using mainly replication mechanisms for ensuring event availability in case of peer crashes).

From the usage point of view, the Federated Middleware can handle the intrinsic distribution of event sources by e.g. creating one Event-Cloud instance per event source, also called event stream. Such a mapping offers the possibility to manage heterogeneous data by dedicating a stream and hence an Event-Cloud for each kind of data (for example one stream for weather data and another one for patients medical data). Per stream associated ELA translates in QoS related configuration at the corresponding event cloud side, in order to cope with fluctuating event flow, event criticality degree, event privacy or events ordering. Note that correlation of events originating from the various and heterogeneous event streams is delegated to the dCEP layer. As such, the dCEP role is of major importance for the PLAY platform to feature its federated nature.


Related Papers


Related Documents

Name Date File size Hits    
PLAY D2.1 Requirements Event Cloud 2011-11-17 841.1 KB 2109

PLAY D2.5.1 Federated Middleware - Specification and Implementation V1 2012-04-02 727.77 KB 1279

PLAY D2.5.2 Federated Middleware - Specification and Implementation V2 2013-10-30 1.78 MB 861

PLAY D3.3 Platform - Quality of Service 2013-10-30 1.45 MB 1238

PLAY D5.2.2 Assessment of the PLAY Integrated Platform V2 2013-12-18 2.25 MB 744