Using events for the scalable federation of heterogeneous components

The thesis of this paper is that, using our eventbased development principles, components that were not designed to interoperate, can be made to work together quickly and easily. The only requirement is that each component must be made event-based by adding an interface for registering interest in events and an interface for injecting actions. A component noti es an event to a distributed client if the parameters of an event, internal to the component, match the parameters of a particular registration. Heterogeneous components can be federated using event-based rules; rules can respond to events from any component by injecting actions into any other component. We show that the event paradigm is scalable by illustrating how event-based components can be located worldwide, using a federation of event brokers. Additionally, we illustrate with 3 event-based systems we have developed: a component-based multimedia system, a multi-user virtual worlds system and an augmented reality system for mobile users. Finally, we show how the event paradigm is also scalable enough to allow event federation of entire systems, not just single components. We illustrate by showing how we have federated the operation of the 3 featured eventbased systems. This enables, for example, real-world mobile users to appear as avatars in the appropriate locations in the VR world, and for these avatars to move in response to actual user movements. 1 Principles of Event-based Systems This section introduces distributed systems development using events. The framework presented here uses events to \glue" together components. By using events as a uniform way of informing other components of activities that have occurred, systems/applications can be built around a generic eventresponse paradigm. Using this approach, the entire Internet can become a plug-and-play domain. An event is an asynchronous message containing parametrised details of an activity that has occurred within a component, or has been detected by the component. Services publish details of classes of event they actively monitor for, clients register interest with services, and services notify clients, as appropriate. Single events, or events as part of an ordered combination of events, noti ed to clients, can be used to trigger further actions within the system/application. Using events as the uniform interchange of activity between the possibly distributed components, simplies the construction of a complex system/application. Our recent work is making fundamental contributions to the diÆcult problem of how to compose or federate existing systems to achieve interoperability. A related problem that is relevant within a single domain is how to add new object types (in our case, event classes) to a dynamically running system. In this paper, we use the term active system to describe a large system or application composed of components interoperating via event federation. 1.1 Components and Glue Event-based programming relies on two main concepts: Existing event-based components are used as the building blocks of applications. These may be distributed around the local network or Internet. They can inform interested users of pertinent events, such as a change in the location of a mobile user. The power of event-based system building is that no component is designed to work speci cally with any other component. To compose many event-based components into an active system, a federator component must be written. This is the bespoke part of the system, composed of event-based rules that describe actions to take in response to the receipt of certain events from the components within the system. Rules act as a distributed systems integration glue, using any class of event from any components to drive any other components by injecting any actions. Examples are moving a user interface to the application owner's new location in response to an event that the user has moved, or recon guring a multimedia application in response to an event detailing a change in bandwidth availability. In this paper we specify event-based rules in the following way: rule = ; {} In a multi-user application, for example a multimedia conference, each user owns a set of components, but the overall system is composed of the interacting set of all users' components. In such a situation, it is likely that each user will have a separate federator component to take care of his/her own components. In the remainder of this section, we illustrate eventbased programming concepts using two case studies. The rst shows how a stand-alone drawing board can be made event-based and then used as a component in a CSCW application. The second shows how event services allow clients to tailor their range of interest. For this we use the example of a location service, which is part of our augmented environments framework. The location service is responsible for keeping clients location-aware. 1.2 Event Taxonomy and Brokerage One event source can generate events of one or more event classes. An event class is analogous to an object class. It has typed attributes, instances of which uniquely identify a captured activity. For example, an event source that provides information about the locations of users can o er monitoring facilities for the following class of event: LocationEvent(Domain,Name,Type,Location). Class LocationEvent identi es that an entity has changed location in a speci c domain. The type of the entity can be, for example, a person or a piece of equipment. To actually detect movement of entities, we used active badges [7], a form of electronic tag. Distributed event-based objects advertise the event classes they can monitor for by exporting them to an event broker. Clients can query the event broker, to search for appropriate event sources. An event taxonomy describes the set and organisation of event classes in a particular domain. We are investigating the organisation of event classes into class hierarchies of events, to support automatic propagation of interest in sub-classes. For example, consider the class LocationEvent. If we want to track the whereabouts of user Mark.Spiteri, we register interest with a local event broker. We intend that that should be all that is required to track him wherever he goes in our domain (and even world-wide { see below). He may be tracked by many di erent means, such as active badge or login detection within a building, outside by GPS [1]; in either, by security camera image recognition etc. Each class of specialist tracking can be encoded as a sub-class of LocationEvent. The event broker will automatically register our interest with all known subclasses. Event sub-classing is also useful in allowing specialisation of event classes, whilst supporting compatibility with super-classes. For example, a new event class FineGrainedLocation can provide a 3D x on a user, rather than just a named location. This can be built on top of a GPS system or a ne-grained oÆce-based system [15], thus providing latitude, longitude and altitude information. In our design, the event broker is the custodian of the class hierarchy for its local event domain. Querying the event broker for a particular class of event returns all event sources that can monitor for the class and all its sub-classes. It is also possible to query a sub-class directly, events of which provide the specialised information not available in the super-class. By using a class hierarchy, new subclasses may be added dynamically and registration of interest in a class may be extended to a new subclass. We are investigating how to use this mechanism to add new services that notify new event classes without recompiling clients. Because event interfaces do not always describe the purpose of the event class, we are extending event brokers to support the association of free text with event classes. The broker will support searches, similar to Web search engines, returning event classes that match text queries. We are employing a locally developed search engine in our implementation [12]. 1.3 Registration for Filtering Some event sources generate thousands of events a second. Transmission of all of these is network intensive and requires a client of the event source to perform ltering to decide whether a particular event is of interest. Our event system allows interested parties to register interest in events with certain characteristics. Only events that match the registered patterns are dispatched to the interested parties, thus reducing network traÆc and ltering requirements. To register interest with an event source, clients provide an event template. This is an event instance, with elds for exact match lled in and those for wildcard match expressed as variables. Examples for class LocationEvent are as follows: LocationEvent("cl.cam.ac.uk", "John.Bates", "Person", L) { Report wherever John is seen in the Computer Lab. LocationEvent("cl.cam.ac.uk", P, "Person", "Meeting Room") { Report when anyone is seen in the Computer Lab meeting room. LocationEvent(D, P, "Person", L) { Report when anyone is seen in any of the places we receive events from. When event instances are noti ed to clients, values for all class attributes are given, e.g. the instance LocationEvent("cl.cam.ac.uk", "John.Bates", "Person", "Meeting Room") means John has been seen in the meeting room. As a comparison to another event-based component, the drawing board advertises event class LineDrawn(user,x1,y1,x2,y2). This allows us to nd out about lines that are drawn on the board. We will show how this is useful shortly. Our policy is to apply access control on event registration. We use the locally developed OASIS system [8]. We are currently investigating to what extent authorisation should extend automatically to new subclasses. For example, it might be that a given client is allowed to register with an active badge-based location service but i