Importance of the Web of Events for the Future Internet
An inherent characteristic of Future Internet (FI) applications is their reactive nature, as a consequence of the highly dynamic changes in the environment as well as within business systems, which these applications will operate in. Indeed, one of important characteristics of the Future Internet is the possibility to connect real-world objects and business processes, that will provide a highly-dynamic context for Future Internet applications. It will imply the need for an increased responsiveness of FI applications: they must be able to sense the changes in the environment/context and respond correspondingly, including affecting the real-world, which might generate a continual loop. In order to cope with this dynamics, FI applications should be data/event-driven, allowing pushing events from “anyone” in the FI to “anyone” in the FI. For example, the information about the development of an earthquake (an event) should emerge from the data pushed from available sensors and should be delivered automatically (push) to anyone and any process related to the emergency zone/process.
It can be achieved only if the components in an FI system are loosely coupled and communicate asynchronously, for example in a public-subscription manner: components are communicating not directly, but through a broker, whom the requests are published/subscribed to. In other words, there is a need for the event-driven architecture (EDA) in FI applications .
A very important characteristic of this architecture for FI should be its self-evolving nature that includes methods and tools for the discovery and inclusion of new event/data sources and new consumers of events that will be pushed. It must be done dynamically and in an automatic way. In the previous example it means that new event sources relevant for an early detection of an earthquake should be automatically discovered, although their primary usage might be different.
In that way an FI application becomes a living sense-response system that connects on demand (non-intrusively) every possible information/service source to itself, integrates its data with other information in real time and distributes results to every interested actor, including business processes that can be changed accordingly (and in an ad-hoc manner) in order to enable a prompt reaction on the current/emerging situation. However, from the current experience it is known that false-positive cases (e.g. false early warning in the case of an earthquake) are big problem in real situations, which requires new methods for coping with the information overload problem.
Practically, EDA is any loosely coupled middleware that focuses on handling events. However, in the real world, the ESB (Enterprise Service Bus) offers a platform on top of which an EDA is much easier to build – so, practically speaking, an EDA is an event-enabled ESB. For the FI applications this concept must be extended with several new functionalities for an event-driven system, like dynamic subscriptions, automatic publishing, real-time contextualization, advanced event processing (like finding incomplete and unusual complex events), ad-hoc service composition to name but a few.
Paradigm shift: Push-based (reactive) Internet: Instead of searching for information, information should find us
Today’s Web is pull based from the usage point of view: users explicitly search for information/services. The main drawback is that in order to find relevant information users must search continuously, since information and services are changing continuously. Future Internet should enable the paradigm shift: relevant information will find the user. In the example of an early warning earthquake system it means that every possible relevant recipient of an early-warning will be “found” in an automated way (e.g. due to context awareness). Note that this goes far beyond the RSS/Atom feeds or similar aggregators: we don’t assume an explicit subscription to a topic of interest.
The paradigm shift is to develop an infrastructure that will enable that event is the first class citizen in FI and enables that new information searches for the consumers. In that way information is an active artifact: it finds the right service where it should be used in. The information will be published from a source in an autonomous way and will find autonomously an interesting consumer. Obviously, the underlying FI infrastructure (Enablers) must enable this autonomous and active behavior of information (incl. corresponding methodologies for such information management).
Requirements for Event Management and Processing
Main challenges for the event management are: 1) high throughput (many data sources/sensors that will continually sent signals), 2) complex data (heterogeneous sources, whose signals should be intelligently combined) and 3) unreliable data (noisy, contradictory, missing data from sensors). On the other side, the processing will require scalable methods for sensing interesting situations from upcoming events in order to enable prompt reaction on them. Additionally, the discovery, representation and the management/evolution of the situation of interests is very important. The ultimate challenge will be to support the detection of interesting situations before they appear – proactive nature (like very early warning in the case of a natural disaster).
Therefore, a CEP framework should represent an end-to-end solution for event processing, starting from the definition of complex event patterns, through intelligent detection, till advanced 3-D visualization of complex events. It satisfies above mentioned requirements. The framework should be realized as a set of advanced services (CEP as a Service) for processing heterogeneous, distributed and complex stream data:
- Detection of complex events, states, situations of interest, and further controlling reactive behavior (actions/reactions) triggered by detected events;
- Reasoning about events (over time, space, context, their relations and constraints): Contradicting complex events/situations; Probabilistic events and event retraction (revision); Out-of-order events; Detection of not yet fulfilled complex patterns (e.g. 80% fulfilled situation).
- Management of complex situations to be detected, including their discovery and evolution
- Active visualization of complex events