Computer Laboratory

The Active House


The OPERA group has been working on asynchronous communication using events since the early 1990's. Distributed computing platforms have used synchronous object invocation, but we have recognised that many applications need immediate notification to drive their actions. In 1998, the Object Management Group (OMG), a consortium of companies which issues specifications for distributed, open, inter-working software, most notably CORBA (the common object request broker architecture) published an event notification service, which includes many features in common with our event architecture.

System Overview

The Cambridge event architecture is based on a publish, register, notify paradigm. An event is a parametrized, asynchronous message which is an instance of an event class. Objects which are event sources publish the event types they produce. Other objects register interest in these events, possibly providing parameter values to be matched. Finally, when an event occurs, all registered parties with matching parameters are notified and may take appropriate action.

The Active House demonstration uses events to link a range of automated appliances within a virtual house. The appliances can both produce and receive events, i.e. they can act as an event source and sink at the same time, and publish, register, notify and receive events as described above. On receiving an event an appliance will typically perform some action.

The owner of the house may wish to express complex policies on how it should behave in terms of combinations of event occurrences. We provide a simple composite event algebra for this purpose, allowing more complex and useful interaction between event sources and sinks.

Interface Publication

The publication of the event interfaces in the Active House is done using a globally known advertising agency. Objects with event sources publish their interfaces with this agency.

  • advertise(source, event_type_name, event_type_def)
  • advertise("Toaster", "food_ready", "c")

Conversely, objects can also de-advertise their event interfaces.

  • de_advertise(source, event_type_name)
  • de_advertise("Toaster", "food_ready")

The source argument is similar to a network address, uniquely identifying the event source on the network. The event_type_name argument gives the name of the event. The event_type_def argument defines the arguments of the particular event type. This is similar to an IDL (Interface Definition Language), giving an abstract definition of the event interface.

Once published, clients can query the advertising agency and register interest with an event source through the service.

The appliances in the active house can both produce and receive events, i.e. they can act as an event source and sink at the same time. For example, the stereo system in an Active House may register interest with the event source (server) doorbell. When the event doorbell_rings occurs the stereo system is notified. The stereo system may also act as an event source, which can notify other devices on the network of events, such as a volume_change event.

On receiving an event an appliance will typically perform some action. The Active House has a rule system, whereby the owner of the house can specify what action an event sink takes when it is informed of a particular event occurrence. This is similar to event-condition-action rules used in active systems.

Composite Event Server

Extending the simple event paradigm, the Active House also supports composite events. This allows for the definition of complex scenarios.

Specifying a new composite event expression (CEE) creates a new composite event server (CES). For every CES, the owner of the house must specify the parameters which the CES should match on. Once the parameters are specified, the CES can begin to evaluate incoming event streams.

The system purges duplicate events upon notification. This means that only one notification takes place per event occurrence.

There is no operator precedence and the algebra is right associative. Thus, a + b + c will be evaluated as a + ( b + c ).

The following operators are supported in the Cambridge Event Algebra for the construction of composite events:

Algebraic Symbol Spoken As Meaning
A ; B followed by event A followed by event B
A - B without event A occurring without event B occurring
A | B or event A or event B occurring
A & B and event A occurring and event B occurring where order is irrelevant
FIRST(A) first occurrence the first occurrence of an event A

Further Thoughts

As described above, our Active House Demonstartion has introduced composition operators. This area still needs a lot of work to define the precise semantics of operators on streams of events; some difficulties arose even in our simple demo, such as the meaning of enter (Homer, Kitchen) & enter (Homer, Office). Practical engineering issues such as how long events should be remembered at composite event servers must be decided.

Important fundemental issues must be considered when developing an OMG-compliant event notification service. For example, events are timestamped and the meaning of time in distributed systems has to be addressed, particularly if events are to be ordered. This is an area we are also currently working on.


The Active House Demonstration can be run in a Java-capable browser. It might be helpful to read through a manual describing the functionality of our Active House, prior to running the application.