MGT con medioambiente desde el problema del consumidor

Elvin was first introduced as an event messaging service following the publish-subscribe notification approach [Fitzpatrick99]. One of the main drives for the development of Elvin was the complete separation between the generation and the consumption of noti- fications. Specifically, Elvin allows the delivery of unaddressed notification messages. This is achieved by using content based event delivery, that is event consumers receive event notifications based on the content of the notifications. In particular, an event sub- scription includes a set of named and typed data elements that the client is interested in. The notification server evaluates incoming notifications against the client subscrip- tions. If a subscription matches a notification the related client receives a copy of the notification message.

In terms of design, Elvin uses a server acting as a notification router between mul- tiple connected clients. Clients can be both the sources and the sinks of event notifica- tions. The notification router is responsible for routing notifications from event sources to the interested event sinks. Obviously the use of a central notification router limits the scalability potentials. However, Elvin addresses this issue by supporting the operation of multiple notification servers in the form of a federation. In more detail, multiple notification servers can work together appearing to the clients as one single notification server.

Elvin supports APIs for a variety of programming languages (e.g. C, C++, Java, Python). A number of application have been developed using Elvin, mostly related to computer supported cooperative work (CSCW).

4.5.1.3 Cambridge Event Architecture (CEA)

The Cambridge Event Architecture [Pietzuch04, Pietzuch03] is a publish-subscribe based event management platform. One of the important characteristics of this work is the special consideration for composite events. Many existing publish-subscribe sys- tems restrict subscriptions to single events only, and thus lack the ability to express interest in the occurrence of patterns of events. The Cambridge Event Architecture al- lows the registration for event patterns that will result in a notification if the specified pattern is met. Specifically, the event patterns supported by the architecture are:

Atoms: individual events similar to the traditional single-event notification platforms.

Concatenation: detects the follow up of two events with possible overlapping.

Sequence: detects the occurrence of an event after another without overlapping.

Iteration: Detects any number of occurrences of event expressions.

Timing: Detects the occurrence of events within a specified time interval.

Parallelisation: Detects two events in parallel and succeeds if both are detected. No requirement for sequence or overlapping is expressed.

In terms of implementation the event architecture utilises finite state automata for the monitoring of event expressions. The FSAs are driven by atomic events and can generate new events if the composite expression they monitor is satisfied. FSAs can be cascaded using the generated events as input to higher level FSAs for the support of complex event compositions.

In summary the design of the Campbridge Event Architecture offers a powerful mechanism for the monitoring of composite events. Considering the design of the pol- icy language described in section 4.7.3 this platform could be considered as a potential candidate for an event management module. In particular the composite event expres- sions can assist the evaluation of the Event Calculus policy rules.

4.5.1.4 L2imbo

L2imbo is a distributed platform developed at Lancaster University [Davies98b]. L2imbo does not follow the client-server paradigm, proposing an alternative communication

approach especially designed to address the requirements of mobile communication. Specifically, L2imbo is based on the tuple space paradigm formerly used in parallel computing (e.g. Linda [Ahuja86]) and allows applications to communicate using the tuple space API.

Tuples are data structures that consist of a collection of typed data fields. Tuples can be dynamically inserted in and removed from a tuple space. Tuple spaces are shared between applications allowing access to the tuples contained within the tuple spaces. Considering this communication approach in a distributed environment it is clear that applications do not interact directly with each other. Each application interacts with the tuple space only and inter-application communication is achieved via the tuple space. As tuple spaces contain persistent tuple objects communication does not break when connection between applications is lost for a period of time. Disconnected applications can continue to send tuples to the tuple spaces and retrieve tuples after reconnection.

In terms of implementation, L2imbo is based on IP multicast where each tuple space is modeled as a multicast group. Each host in the distributed system maintains a local replica of the tuple space. Whenever a new tuple is inserted in the tuple space a multicast message updates the local replicas of the tuple space with the new tuple. If one of the hosts looses connection with the rest of the group, L2imbo allows disconnected communication. In more detail, applications can insert tuples to their local replica of the tuple space and retrieve tuples from the local replica. Upon reconnection L2imbo updates local replicas with the changes that took place while disconnected.