A middleware infrastructure for active spaces

74 PERVASIVEcomputing 1536-1268/02/$17.00 © 2002 IEEE

A MiddlewareInfrastructure for Active Spaces

P ervasive computing environments aug-ment human thought and activity withdigital information, processing, andanalysis, providing an observed worldthat is enhanced by the behavioral con-

text of its users. A spectrum of heterogeneous com-putation and communication devices aim to enhanceuser productivity and facilitate everyday tasks.

Despite the prevalence of suchdevices, however, no suitable soft-ware infrastructure with which todevelop applications for ubiqui-tous computing habitats or livingspaces exists.

To address this deficiency, wedeveloped Gaia, a metaoperatingsystem1 (detailed in the sidebar“The Gaia Operating System”)

built as a distributed middleware infrastructure thatcoordinates software entities and heterogeneous net-worked devices contained in a physical space. Gaiais designed to support the development and execu-tion of portable applications for active spaces2—programmable ubiquitous computing environmentsin which users interact with several devices and ser-vices simultaneously. Gaia exports services to query,access, and use existing resources and context, andprovides a framework to develop user-centric,resource-aware, multidevice, context-sensitive, andmobile applications.

By extending the concepts of traditional operatingsystems to ubiquitous computing spaces, we can sim-

plify space management and application develop-ment. Gaia’s main contribution is not its individualservices but rather the functionality it provides as theresult of the interaction of these services. This inter-action lets users and developers abstract ubiquitouscomputing environments as a single reactive and pro-grammable entity instead of a collection of heteroge-neous individual devices. In this article, we presentan overview of the Gaia architecture, focusing on thecomplete system rather than individual services.

Active spacesA physical space, illustrated in Figure 1a, is a geo-

graphic region with limited and well-defined physi-cal boundaries containing physical objects, hetero-geneous networked devices, and users performing arange of activities. An active space, shown in Figure1b, is a physical space coordinated by a responsivecontext-based software infrastructure that enhancesmobile users’ ability to interact with and configuretheir physical and digital environments seamlessly.Active spaces must support the development and exe-cution of user-centric mobile applications.

In active spaces, sessions associate user data andapplications with users. This lets users move acrossactive spaces and have their data and applicationsalways available. When a user enters an active space,the user’s sessions are dynamically mapped to theactive space resources. Users can define different ses-sions and can activate and suspend them as neces-sary. We refer to the collection of sessions associatedwith a user as the user virtual space. The user virtual

The Gaia metaoperating system extends the reach of traditionaloperating systems to manage ubiquitous computing habitats and living spaces as integrated programmable environments.

M I D D L E W A R E

Manuel Román, Christopher Hess,Renato Cerqueira, AnandRanganathan, Roy H. Campbell,and Klara NahrstedtUniversity of Illinois at Urbana-Champaign

OCTOBER–DECEMBER 2002 PERVASIVEcomputing 75

T he motivation behind the Gaia operating system is that oftraditional operating systems, but at another level of abstrac-

tion. The Gaia OS abstracts a space and all the resources it containsas a single programmable entity. Abraham Silberschatz and his col-leagues define seven services common to all operating systems:program execution, I/O operations, file-system manipulation, com-munications, error detection, resource allocation, and accountingand protection.1 The Gaia OS currently provides the first sixservices, and we are completing a security prototype.

Program executionThe Gaia OS component management core lets applications create,

destroy, and upload components in any execution node in the activespace. CMC uses the program execution facilities of the executionnode’s OS, which includes memory, thread, and process management.

I/O operationsGaia’s OS leverages the low-level OS I/O functionality and pro-

vides device drivers (implemented as distributed objects) to exportit to the rest of the active space. Gaia’s OS also defines default I/Ochannels (input, output, and error) and maps them to event chan-nels, allowing the creation of a default space “console.”

File-system manipulationThe context file system lets users, services, and applications

manipulate files in active spaces. CFS interacts with devices’ low-level OS file systems to access and export data to the active space.File locations are hidden from users, but users can access themfrom any device in the active space. CFS extends traditional OSswith functionality to dynamically transform data to different for-mats and to organize data by context.

CommunicationsThe Gaia OS supports direct communication, which is similar to syn-

chronous low-level OS interprocess communication (IPC), and indirectcommunication, which is similar to asynchronous low-level OS IPC. TheGaia OS supports remote procedure calls (RPC) for direct communica-tion and events (suppliers and consumers) for indirect communication.In both cases, Gaia’s OS leverages standard communication middleware.

Events, which are similar to Unix signals, notify entities in theactive space about added or removed resources, error conditions,file system changes, and application state changes. The use ofasynchronous events improves system reliability by decouplingevent producers from event listeners. Gaia entities use othermechanisms, such as RPC for remote method invocation andnonblocking streaming for audio and video transmission.

Error detectionError detection includes both software and hardware errors that

affect application execution. The Gaia OS uses the event service toreport errors. Users register services that receive error notificationsand react accordingly (for example, they might notify users, restartcomponents, or suspend applications).

Resource allocationIn a traditional OS, resource allocation relates to managing

hardware resources such as memory, CPU, and disk. The Gaia OSextends the notion of resource allocation to devices, services, andapplications in the active space.

REFERENCE

1. A. Silberschatz and P. Galvin, Operating System Concepts, 5th ed., Addi-son-Wesley, Boston, 1998.

The Gaia Operating System

(b)(a)

Laptop

Application

PDA

Application

PC

Person (user)Physicalobject

Person (administrator)

Person (user)

Space physical boundary

Physicalspace

Softwareinfrastructure

Context

ApplicationsPerson (user)

Person(hardware administrator)

Person(software administrator)

Application

Application

Printer

Storage

Sensor

Workstation

Application

Network

Figure 1. Physical and active spaces. (a) A physical space contains physical objects, networked devices, and users within well-definedphysical boundaries. (b) An active space extends the physical space, adding coordination via a context-based software infrastructure.

space requires support to locate resourcesavailable in the user’s environment and tomap the sessions to the existing resources.

Active spaces such as the one depictedin Figure 2 challenge existing assumptionsfor traditional PC applications. As MarcWeiser observed, ubiquitous computingrequires systems that vanish into the back-ground.3 In an active space, a one-to-onerelationship between a user and keyboard,mouse, and display interfaces does notexist. Indeed, the complexity of ubiquitousapplications encourages a relationshipbetween a user and an active space. Active-space system-software support should sim-plify application programming and execu-tion. Much like PC applications rely onoperating systems, active-space applica-tions need an OS that supports access toand operation of the resources containedin the space that hosts their execution. Thesidebar “Related Work in Active Environ-ments” describes other work in this area.

System software Gaia manages an active space’s resources

and services; provides location, context,and event services; and stores informationabout the active space. Gaia has threemajor components, as Figure 3 shows: thekernel, the application framework, and theapplications.

Gaia kernelThe Gaia kernel consists of a compo-

nent management core and an interrelated

set of basic services used by all Gaiaapplications. The CMC dynamically loads,unloads, transfers, creates, and destroysall Gaia components and applications.Because they are component-based, dis-tributed, and mobile, Gaia applicationsrequire support for remote component exe-cution and management. Remote executionnodes register with the active space and hostthe execution of Gaia components.

The current implementation of Gaiauses Corba; however, the system could alsouse SOAP, RMI, or customized communi-cation middleware. Although Corba pro-vides a stable infrastructure for distributedobject interaction, active spaces requireextensions to handle soft state, dynamicresource detection, and fault tolerance.Gaia offers five basic services:

• Event manager• Context service• Presence service• Space repository• Context File System

Some of the services, such as the eventmanager, are built on top of existing mid-dleware services, while others, such as thepresence service, extend the communica-tion middleware.

Event manager. Active spaces require a flex-ible mechanism to expose changes in theircurrent state—for example, when a com-ponent starts, an application moves, or a

user enters the activespace. The event managerservice distributes eventsin the active space andimplements a decoupled

communication model based on suppliers,consumers, and channels. Event channelsforward suppliers’ events to the consumersregistered with the channel. The eventmanager has a single entry point and oneor more event channel factories. Each eventfactory creates channels for specific types ofevents—for example, high-speed or persis-tent events. A default set of event channelsnotifies interested Gaia components aboutnew services, applications, people, errors,and component heartbeats. Applicationscan also define their own event channels forapplication state changes. The event servicelets applications tap into event channels tolearn about changes in the system.

By decoupling information suppliers frominformation consumers, the event managerincreases system reliability. If a supplier fails,the service can automatically replace it witha replica that continues delivering messagesto its assigned channel without disruptingthe system. Our current event managerimplementation uses Corba’s event service4

as the default event factory. A more detaileddescription of the event manager service isavailable elsewhere.5

Context service. Gaia applications can usecontext information to adapt to user behav-iors and activities.6 Our context service letsapplications query and register for particu-lar context information, which helps themadapt to their environment. The contextinfrastructure consists of several compo-nents, or context providers, that offer infor-

76 PERVASIVEcomputing http://computer.org/pervasive

M I D D L E W A R E

(b)(a)

15 Pentium IVs at 1.2GHz4 NEC HD plasma displays (61”)1 Sharp HD projector2 Sound Web sound system4 Infrared beacons2 iButton detectors5 Touch-screen displays4 Badge detectors3 Compaq iPaq handheld devices1 Gbit Ethernet network1 Wavelan wireless network at 11 Mbps

X10 appliance controllers

Figure 2. (a) Ourprototype Gaia-enabledactive space and (b) a listof the room’s equipment.The active meeting roomserves as a testbed for oursoftware infrastructureduring meetings and seminars.

mation about the current context. Theseinclude sensors that track people’s loca-tions, room conditions (for example, tem-perature and sound), weather, and currentstock prices. Other components can infercertain higher-level contexts on the basis ofsensed information. For example, one com-ponent deduces the type of activity occur-ring in a room (a meeting, presentation, ormovie screening, for example) on the basisof who is in the room, which applicationsare running, and other cues. A registry

maintains a list of available contextproviders. Applications can use this registryto find providers of the contexts they desire.

We base our context model on first-orderlogic and Boolean algebra, which lets us eas-

ily write rules to describe context informa-tion. We represent context using a first-orderpredicate with four arguments. We borrowthis structure of a context predicate from asimple clause in the English language of the


Component management core

Spacerepository

service

Active space applications

Application framework

Eventmanagerservice

Contextfile system

Contextservice

Presenceservice

Gaia kernel

Figure 3. Gaia architecture. The architecture consists of a kernel, whichincludes a component management coreand a set of basic services, a component-based application framework, and activespace applications.

T he Microsoft EasyLiving project focuses on home and workenvironments.1 The main properties of these environments

are self-awareness, casual access, and extensibility. The projectinfrastructure lets interfaces move with the user. Easy Living usescomputer vision to recognize gestures and users and to detectuser location. The system uses this information to customize theroom. Whereas Easy Living sees the desktop as the primary userinterface, Gaia allows application partitioning on different devices.

The i-Land2 and Roomware3 research projects present infra-structures that digitally augment meeting rooms. Both projectsaim to make it easy for users to exchange ideas, digitally recordmeeting results, and search knowledge bases, and both providemultimedia data exchange tools for group collaboration.Stanford’s Interactive Workspaces presents an augmented meetingroom that promotes group work.4 The room contains wall-sizedtouch screens, projectors, microphones, speakers, laptops, andPDAs. Coordinating the entities in the room requires a high-leveloperating system.

Roomware, i-Land, and Interactive Workspaces look at users’interactions with physical spaces (mostly meeting rooms) and col-laborative work groups. Like the developers of Roomware andInteractive Workspaces, we believe that a need for a supportinginfrastructure exists. However, we focus on generic spaces (officeand house, for example), which might or might not imply collabo-rative work. While some active spaces define a collaborative envi-ronment, others are mostly single-user based. Furthermore, Gaiaexpects mobile users to move their applications and data acrossdifferent active spaces.

Aura shares several design goals with Gaia.5 It emphasizes thenotion of mobile users moving among environments and defines an

environment similar to our active spaces. Tasks identify user-asso-ciated applications that can migrate from one environment toanother. A software infrastructure supports task execution, maximiz-ing available resources and minimizing user distraction. The main dif-ference between Gaia and Aura is that Gaia emphasizes space pro-grammability. Gaia allows users to configure their applications tobenefit from the resources in their current space. Users can interactwith multiple devices simultaneously, reconfigure applicationsdynamically, suspend and resume groups of applications, and pro-gram application behavior based on context attributes.

REFERENCES

1. B. Brumitt et al., “EasyLiving: Technologies for Intelligent Environ-ments,” Proc. Handheld and Ubiquitous Computing (HUC), Springer-Verlag, Heidelberg, 2000, pp. 12–29.

2. P. Tandler, “Software Infrastructure for Ubiquitous Computing Environ-ments: Supporting Synchronous Collaboration with HeterogeneousDevices,” Proc. Ubiquitous Computing (Ubicomp 2001), Springer-Verlag,Heidelberg, 2001, pp. 96–115.

3. N. Streitz, J. Geissler, and T. Holmer, “Roomware for Cooperative Build-ings: Integrated Design of Architectural Spaces and Information Spaces,”Proc. Workshop on Cooperative Buildings (CoBuild 1998), Springer-Verlag,Heidelberg, 1998, pp. 4–15.

4. A. Fox et al., “Integrating Information Appliances into an InteractiveWorkspace,” IEEE Computer Graphics & Applications, vol. 20, no. 3, May2000, pp. 54–65.

5. J.P. Sousa and D. Garlan, “Aura: An Architectural Framework for UserMobility in Ubiquitous Computing Environments,” Proc. IEEE Conf. Soft-ware Architecture, IEEE CS Press, Los Alamitos, Calif., 2002, pp. 29–43.

Related Work in Active Environments

form <subject><verb><object>. An atomiccontext predicate is defined as Con-text(<ContextType>, <Subject>, <Relater>,<Object>). The context type refers to thecontext the predicate is describing; the sub-ject is the person, place, or thing with whichthe context is concerned; and the object is avalue associated with the subject. In ourimplementation, ContextType maps to anevent channel. The relater associates the sub-

ject and the object much like a comparisonoperator (=, >, or <), verb, or preposition.Example context predicates are Context(tem-perature, room 3231, is, 98 F) and Context(printer status,srgalw1 printer queue, is, empty). In some cases, oneor more predicate elements might be empty.

We can construct more complex contextsby performing first-order logic operationssuch as quantification, implication, con-junction, disjunction, and context predicatenegation. One example of a rule is Context(num-ber of people, room 2401, >, 4) AND Context(application,Powerpoint, is, running) => Context(social activity, room2401, is, presentation).

Anind K. Dey’s and Gregory Abowd’sContext Toolkit inspired our context infra-structure.7 We structure the expressivepower of contexts with first-order logic toframe rules and queries and to infer prop-erties involving context using mechanismssimilar to those of Prolog and other auto-mated theorem provers. We can determinehigh-level context information from low-level context information, much like theContext Toolkit’s aggregators. Our systemalso formalizes the exchange of contextinformation among system componentsand lets us describe component properties.

Presence service. As a resource-aware infra-structure, Gaia must maintain updatedinformation about active space resources.Our presence service differs from existingcontext infrastructures (such as the Context

Toolkit) in that it detects and maintains soft-state information about software compo-nents, devices, and people. The service isdivided into two main subsystems: digital-entity presence and physical-entity presence.

Gaia currently defines four basic typesof entities: application, service, device, andperson. The digital entity presence subsys-tem detects service and application entities,which periodically send heartbeats to

notify the service that they are in the activespace. When a digital entity fails to sendthe heartbeat, the digital-entity presencesubsystem assumes that it is no longeravailable—either it was stopped or itcrashed—and notifies the rest of the spacethat the entity left.

The physical-entity presence subsystemdetects devices and people present in theactive space. This subsystem uses differenttypes of sensors to proactively detect phys-ical entities and, if possible, their locations.The physical-entity presence subsystemimplements a beaconing mechanism onbehalf of the physical entities, acting as aproxy. It is implemented as an open infra-structure in which we can incorporate dif-ferent sensor device drivers and algorithms.

Space repository. Active space entitiesneed to know the resources present in theactive space and their properties. The spacerepository stores information (name, type,owner, and so on) about all software andhardware entities in the space and letsapplications browse and retrieve entitieson the basis of specific attributes. The spacerepository learns about entities enteringand leaving the active space through thepresence service channels.

Applications use the space repositoryduring instantiation to find suitableresources. When an application starts exe-cuting, for example, it uses the space repos-

itory to find appropriate resources (suchas execution nodes, displays, and speak-ers). This level of indirection lets usdescribe applications generically (active-space independent) and map them toresources in different active spaces.

All active-space resources are associatedwith an XML description that containstheir properties. When a new resourceenters the active space, the space repositorycontacts it to obtain its XML description.The current version of the space repositoryuses a Corba Trader4 to store entity data.We currently use the Trader’s constraintquery language, but we plan to extend itwith a generic language that could bemapped either to the Corba Trader con-straint language or to standard SQL. Forexample, the query Category = = ‘Device’ and Type= = ‘Display’ returns a list of all displays in theactive space.

Context File System. Active spaces areoften designated for specific tasks. Appli-cations can use task context to distinguishmeaningful from irrelevant information.Long-running processes might not havethe luxury of human intervention to locaterequired data, which can vary over timeowing to context changes. In addition,users are highly mobile in active spacesand should not have to manually transferfiles or data between environments. Theenvironment should assist users in mak-ing personal storage automatically avail-able in the users’ current location.

To address these issues, we have devel-oped Context File System, a context-awarefile system that uses application-definedproperties and environmental context infor-mation to simplify many of the tasks that aretraditionally performed manually or requireadditional programming. More specifically,the CFS uses context to

• Make personal data automatically avail-able to applications, conditioned on userpresence

• Organize data to facilitate locating rel-evant material for applications and users

• Retrieve data in a format based on userpreferences or device characteristicsthrough dynamic data types


M I D D L E W A R E

When a digital entity fails to send the heartbeat,

the digital entity presence subsystem assumes

that it is no longer available and notifies the rest

of the space that the entity left.

The CFS constructs a virtual directoryhierarchy,8 based on the types of contextassociated with particular files, and aggre-gates related material. We implement thedirectory hierarchy layout using a mount-ing mechanism in which users own mountpoints, which contain context tags. Userscan merge their personal mount pointsinto a space to make their data availableto applications and other users. The CFSis aware of different types of context,which the context service, users, andapplications define.

The CFS presents context as directories,in which path components represent con-text types and values. The file system pathsyntax uses the context service’s quaternarypredicate structure, in which the relaterdefaults to equality. We can attach contextto files and directories by copying data to acontext directory, which associates the con-text with the data. The virtual directoryhierarchy forms a simple query language todetermine what types of context areattached to files. For example, to determinewhich files have the associated context loca-tion == RM2401 && situation == meeting, we enter/location:/RM2401/situation:/meeting directory. Thesystem is a hybrid database and file system;the database functionality offers the flexi-bility to search for relevant information, andthe file system functionality provides a famil-iar interface for application developers.

The CFS combines the environment’scurrent context properties (location, time,situation, and so on) with user-specifiedproperties to display the correct applica-tion data. For example, a seminar applica-tion might require all papers to be dis-cussed during a seminar. A calendar or themoderator’s arrival can trigger the appli-cation; thus, the application must be ableto locate the correct files to display. Theapplication simply opens the directory forthe current papers (say, /type:/papers/current).The file system uses the current location,situation, and time along with the user-spec-ified request, “papers,” to find the correctfiles for the application. The directory’s con-tents might change automatically everyweek, as new papers are added and otherstime out. From the application’s viewpoint,however, it simply opens the same directory

every week and finds the relevant material. The space might also define a context that

is irrelevant to the current task. The context“the weather is sunny,” for example, mightbe meaningless to the seminar application,but might make sense for a telepresenceapplication. The system resolves this issueby ignoring any context that is valid in theenvironment but not explicitly associatedwith the data. Although we view the con-text directory structure as a hierarchy, con-text directories impose no fixed ordering.Context paths can be traversed in any order.

The CFS architecture is composed ofmount and file servers. One mount servermaintains an active space’s namespace. Thenamespace changes as users physicallymove in and out of the space. File serversexport storage to the local space from localor remote locations. We implement ourservers at the application-level and lever-age existing native file systems to accessfiles and directories. You can find moredetails about the CFS elsewhere.9

Application frameworkIn a Gaia active space, applications are

partitioned among a group of coordinateddevices.10 Applications receive inputevents from devices, services, users, andother applications; present their state usingdifferent types of devices (for example,sound system, display, and temperature-control devices); and adapt to changes in

the environment. Active spaces let usersdecide how to interact with applicationsusing a number of inputs, outputs, andprocessing devices.

Developing applications for activespaces is challenging. For example, anapplication might need to move the outputdata from one display to another, duplicatethe output to different displays, transforma visual representation into speech, and

switch from a mouse to a voice input sen-sor (a hardware or software entity that trig-gers changes in the application), all ofwhich it must perform while providingapplication-consistency guarantees. Ourapplication framework lets users construct,run, or adapt existing applications to activespaces. The framework consists of

• A distributed component-based infra-structure, which reuses the applicationpartitioning proposed by the traditionalModel-View-Controller (MVC)11 andintroduces new functionality to exportand manipulate the application compo-nent bindings.

• A mapping mechanism, which cus-tomizes applications to active spaces.

• A group of policies that defines sets of rulesfor customizing several aspects of applica-tions, including instantiation, mobility, reli-ability, and composition (number of com-ponents and their bindings).

Infrastructure. The application infrastruc-ture has four components. The first threeare the building blocks for any application:

• The model implements the applicationlogic.

• The presentation exports the applicationdata.

• The input sensor lets the user interactwith the application.

• The controller maps input sensor events(such as touch-screen events and contextchanges) into method requests for themodel.

• The coordinator manages the first fourcomponents.

The model, presentation, and controllerare strictly related to application-domainfunctionality, while the coordinator pro-


Active spaces are often designated for specific

tasks. Applications can use task context to

distinguish meaningful from irrelevant

information.

vides the application’s metalevel function-ality. Figure 4 illustrates the frameworkinfrastructure.

Mapping mechanism. Active-space hetero-geneity requires a mechanism for customiz-ing applications to different scenarios. Forexample, a calendar application running inan active office might simultaneously use aplasma display to show the week’s appoint-ments, a handheld to display the day’sappointments, and an input sensor runningon a PC to enter data. The same calendarrunning in an active car might use the car’ssound system to broadcast informationabout the next appointment, and a speech-recognition-based input sensor to query thecalendar and to enter and delete data.

The mapping mechanism defines twoapplication description files: an applica-tion generic description and an applica-tion customized description. An AGD,which is created by the application devel-oper, is an active space-independentdescription listing the application compo-nents, the minimum and maximum num-ber of instances allowed, and componentrequirements (for example, audio outputand Windows OS). An ACD contains a listof application components, including theirassociated execution nodes (chosenaccording to component requirements)and initialization parameters. An ACD isimplemented as a script that coordinatesthe instantiation and assembly of the dif-ferent components. A specialization mech-anism uses an AGD and the target activespace’s space repository service to generate

ACDs. The mapping mechanism uses thespace repository to find devices and ser-vices that meet AGD requirements.

Customization policies. The applicationframework infrastructure and the map-ping mechanism provide the tools to buildand instantiate applications. The applica-tion framework relies on policies toaddress reliability, adaptation, mobility,and related issues. Users can define theirown policies or can use the framework’sdefault policies.

MVC extensions. In addition to adding acoordinator component to manage appli-cation component composition, we haveintroduced three changes to MVC toaccommodate our requirements for envi-ronmental awareness, application parti-tioning, context sensitivity, user-centrism,and mobility:

• We define a new component, presenta-tion, that models any output represen-tation, not only graphical representa-tions as the MVC view proposes.

• We generalize the definition of the MVCinput sensor (a hardware device) toincorporate software components (acontext input sensor, for example).

• We generalize the input sensor time-sharing model defined by the MVC intoa space–time-sharing model.

In MVC, all application views and con-trollers share input sensors (a mouse anda keyboard, for example), and thus the OS

must schedule the input sensors. Graspableinterfaces12 enable space sharing, whichavoids input sensor scheduling by assign-ing different input sensors to the applica-tion’s different functions. We combine thetwo approaches into space–time sharing tomodel active space applications. A musicapplication running in an active spacemight use a PDA to control the currentsong and speech recognition to control thevolume (space sharing); however, the samespace might host a calendar applicationthat uses the PDA to browse appoint-ments and uses speech recognition to con-trol the calendar’s functionality (time shar-ing). Space–time sharing allows more thanone active controller and presentation.This is unlike MVC, in which only onecontroller–view pair can be active at anytime. More details about the applicationframework are available elsewhere.13

Gaia management toolsGaia relies on a scripting language to

coordinate the digital entities running inan active space. This language simplifiesoverall active-space management. Forexample, we use a script to implement thebootstrap mechanism that starts the GaiaOS execution in a physical space.

Scripting languageGaia uses a high-level scripting lan-

guage, LuaOrb, to program and configureactive spaces and to coordinate the activeentities they contain.14 LuaOrb is basedon the interpreted language Lua, whichsimplifies management and configurationtasks and allows for rapid prototyping andtesting.15 The Lua interpreter is fast andhas a small memory footprint, whichmakes it suitable for resource-constraineddevices. LuaOrb implements languagebindings between Lua and Corba, COM,and Java. LuaOrb’s ability to communi-cate with various component models letsit easily interact with our system compo-


M I D D L E W A R E

Application metalevel

Active space application

Controller

Application base level

PresentationInput sensor

Coordinator

Model

Figure 4. Application frameworkinfrastructure. The coordinator overseesthe composition of the model, presentation, and controller components.

nents. We use Lua to implement the boot-strap algorithm, instantiate applications,interact with execution nodes to create com-ponents and easily glue them together, andquickly test components and applications.

The example script in Figure 5 instanti-ates and assembles an MP3 application. Thescript uses the Gaia space repository toobtain a handle to an audio output device(line 1); an execution node for the model (line2); an execution node for the coordinator(line 3); and a touch screen, “plasma 1,” forthe input sensor (line 4). It then uses theCMC functionality to create the coordina-tor (line 5), model (line 6), presentation (line7), and input sensor (line 8). Finally it assignsthe model to the coordinator (line 9) and reg-isters the presentation (line 10) and the inputsensor (line 11) with the application, usingthe interface exported by the coordinator.

Although we achieve the same resultwith C++ and Java, they require morecode, time, and user effort. Lua effectivelysimplifies the manipulation and coordina-tion of entities.

Bootstrap protocolGaia implements a bootstrap protocol

that interprets a configuration file (Luascript) and starts the kernel services accord-ingly. The configuration file contains infor-mation about the Gaia kernel services,such as the service name, the name of theservice interface, the Gaia node or nodesthat will host the service, the service instan-tiation policy, and start parameters. Indi-vidual Gaia kernel services can also spec-ify additional configuration parameters.Currently, the active-space administratorprovides the list of devices in the space. In

the future, we expect automatic device dis-covery via different sensor technologies.

Figure 6 illustrates a state transition dia-gram with the instantiation order of theGaia kernel services. The configuration filelists primary and backup Gaia nodes foreach Gaia kernel service; the bootstrapprocess uses the dependencies diagram andthe configuration file to decide whether ornot to start a service in a particular Gaianode. Gaia uses a time-out mechanism anda probing protocol to ensure that each Gaiaservice is started in at most one machine (asspecified in the configuration file).

Using GaiaWe developed the presentation manager

application to demonstrate Gaia’s func-

tionality. The application lets users presentslides in multiple displays simultaneously,move and duplicate slides to different dis-plays during the presentation, and moveand duplicate the input sensor controllingthe presentation to different devices.16 Thepresentation manager uses Microsoft’sPowerPoint to manipulate slides (using theCOM interface).

Our experience with the applicationshows that most users edit the presentationin their offices and use the CFS to importthe data into the active meeting room. Themost common interaction mechanism is awireless-enabled handheld device (usingBluetooth) running a software input sen-sor with buttons for start, stop, next, andprevious.


Figure 5. An example Lua script for instantiating and assembling an MP3application.

1. local presentationExNode = Gaia.getEntity(“Category == ‘Device’ and Type == ‘AudioOut’ “)2. local modelExNode = Gaia.getEntity(“Category == ‘Device’ and Type == ‘ExecutionNode’

and Name == ‘aspc1.uiuc.edu’”)3. local coordinatorExNode = Gaia.getEntity(“Category == ‘Device’ and Type == ‘ExecutionNode’

and Name == ‘aspc2.uiuc.edu’”)4. local inputSensorExNode = Gaia.getEntity(“Category == ‘Device’ and Type == ‘Touchscreen’

and Name == ‘plasma1’”)5. local coordinator = coordinatorExNode:createComponent(“Coordinator”, “-name MP3Coordinator”)6. local model = modelExNode:createComponent(“MP3Model”, “-name MP3Model”)7. local presentation = presentationExNode:createComponent(“MP3Presentation”, “-name MP3Player”)8. local inputsensor = inputSensorExNode:createComponent(“VCRInputSensor”,”-name MP3InputSensor”)9. coordinator:setModel(model)

10. coordinator:registerPresentation(presentation)11. coordinator:registerInputSensor(inputsensor)

Interfacerepository

Remoteexecution

node

Namingservice

Presenceservice

Spacerepository

Componentrepository

Contextfile system

Gaia service Corba required service

(For devices capable of hosting Gaia components)

Contextservice

Gaia kernelconfiguration

file

Eventmanager

Figure 6. Gaia kernel bootstrap sequence.Solid green circles denote Gaia kernel services, and dotted yellow circles denotemiddleware-specific services.

Registering with the active spaceWhen a speaker enters a Gaia-enabled

room carrying a handheld device and an RFactive badge, the presence service detects thebadge and sends an event to the person-presence channel. This event contains infor-mation about the speaker, including a ref-erence to his or her profile. The space repos-itory receives the event, retrieves an XMLdescription for the user entity, and stores theinformation. The CFS also receives the eventabout the new user, accesses the user pro-file, obtains the speaker’s mount points, andmounts the data in the space. The slide showfile stored in the speaker’s active office isnow accessible from the active meetingroom (see Figure 2).

Next, the speaker registers the handheldwith the space, so that he or she can use itto control the presentation. The room isequipped with infrared beacons that broad-cast the space name and a handle to a direc-tory service. This directory service (a Corbanaming context) contains references to theGaia kernel services. The handheld devicepicks up the infrared beacon, resolves theevent manager from the directory, and ini-tiates the beaconing mechanism, which peri-odically sends a heartbeat event to the deviceheartbeat channel. The presence servicereceives the event and sends a new event tothe device presence channel to notify the restof the space about the new device. The spacerepository receives the event, contacts thedevice to retrieve the XML description, andstores the information. Both the speaker andthe handheld device are now entities of theactive space. They are stored in the spacerepository; other entities can contact them;and they can use the space resources.

Starting the applicationThe active meeting room runs an appli-

cation that triggers actions according touser-specified conditions. We configure thisapplication to automatically start the pre-sentation manager application when thespeaker enters the room. The applicationregisters with the context service to be noti-fied when the room context meets this con-dition. The trigger service entry is a Luascript that gets the presentation file’s namefrom the /type:/presentation/current: context

directory and starts the presentation man-ager. The context associated with the slideshow presentation file includes the entrylocation=2401. Therefore, when the user datais mounted in Active Meeting Room 2401,the file is visible from /type:/ppt/current:. TheLua script stored in the trigger servicerequires a valid ACD to start the applica-tion. The script uses the file system andaccesses /type:/lua/acd:/gpm/current:, which con-tains presentation manager ACDs cus-tomized for 2401. The Lua script choosesthe ACD “default.”

The ACD is also a Lua script that inter-acts with the CMC to instantiate the com-ponents. The ACD contacts the applicationcoordinator and registers the model, the pre-sentations, the controllers, and the input sen-sors. The model interacts with the eventmanager to create a channel that it uses tosend update messages to the presentationsand registers the presentations with the chan-nel. The coordinator assigns the model’s ref-erence to the presentations, and the con-troller’s reference to the input sensors. All theapplication components initiate the beacon-ing mechanism and are therefore detected bythe presence service, introduced to the spaceusing an “entered” event, and registered inthe space repository.

Interacting with the applicationThe default presentation manager ACD cre-ates the application input sensor in one ofthe room’s touch screens. Say the speakermoves the input sensor to his or her hand-held device. To move application compo-nents, we provide a library that interactswith the space repository to locate the hand-held and create a new instance of the inputsensor using the CMC. Next, the librarylocates the application coordinator in thespace repository, registers the new input sen-sor, unregisters the original sensor, and thenuses the CMC to delete the original inputsensor. The presence service stops receivingheartbeats from the original input sensorand sends an event to the service-presencechannel to notify it that the entity has left.The space repository removes the informa-tion about the entity. Using the library, thespeaker can move the presentation slides tonew displays in the middle of a presenta-

tion. New displays might be the PDAs ofpeople entering the meeting room.

The presentation manager uses fourplasma displays simultaneously. When theuser selects “start” on the handheld’s inputsensor, the input sensor sends a request tothe application controller, which sends astartPresentation request to the model. Themodel sends a start event to the applica-tion updates channel. As a result, all pre-sentations contact the model to obtain ahandle to the presentation file. Leveragingthe CFS, the model opens the file andreturns a handle. The presentations get thefile and display the first presentation slide.When the users selects “next,” the inputsensor sends a request to the controller,which sends a nextSlide request to the model.The model sends a next event to the appli-cation channel, which instructs presenta-tions to display the next slide.

W e plan to develop new appli-cations to validate differentaspects of Gaia. We willalso extend the infrastruc-

ture with a security service and expand ourcurrent service implementation to supportthe notion of a virtual-space abstraction.The virtual space lets users create active-space templates that the Gaia OS candynamically map to real spaces. For exam-ple, a virtual active meeting room containsa projector, auxiliary displays, and a touchscreen, and has an associated context modelwith properties relevant to a meeting. Userscan assign applications to the virtual spaces,which are mapped to virtual devices in theroom. The virtual-space mapping mecha-nism interacts with an active space to findappropriate resources on the basis of thevirtual space requirements and moves theapplications from the virtual space to theactive space. Finally, we are also studyinghow to federate Gaia services to aggregatedifferent active spaces.

ACKNOWLEDGMENTSThis research is supported by the US National Sci-ence Foundation grants 98-70736 and 9970139,and NSF infrastructure grant EIA 99-72884.


M I D D L E W A R E

REFERENCES1. F. Kon et al., “2K: A Reflective, Compo-

nent-Based Operating System for RapidlyChanging Environments,” Proc. ECOOP98 Workshop Reflective Object-OrientedProgramming and Systems, Springer-Verlag,Hidelberg, Germany, 1998, pp. 388–390.

2. M. Román and R.H. Campbell, “GAIA:Enabling Active Spaces,” Proc. 9th SIGOPSEuropean Workshop, ACM Press, NewYork, 2000, pp. 229–234.

3. M. Weiser, “The Computer for the Twenty-First Century,” Scientific Am., 1991, pp.94–101.

4. M. Henning and S. Vinosky, AdvancedCorba Programming with C++, Addison-Wesley, Boston, 1999.

5. B. Borthakur, Distributed and PersistentEvent System for Active Spaces, master’sthesis, Computer Science Dept., Univ. of Illi-nois at Urbana-Champaign, 2002.

6. B.N. Schilit, N. Adams, and R. Want, “Con-text-Aware Computing Applications,”Proc. IEEE Workshop Mobile ComputingSystems and Applications, IEEE CS Press,Los Alamitos, Calif., 1994, pp. 85–90.

7. A.K. Dey and G.D. Abowd, “The ContextToolkit: Aiding the Development of Con-text-Aware Applications,” Proc. WorkshopSoftware Eng. for Wearable and PervasiveComputing, ACM Press, New York, 2000,pp. 434–441.

8. D.K. Gifford et al., “Semantic File Sys-tems,” Proc. 13th ACM Symp. OperatingSystems Principles (SOSP13), ACM Press,New York, 1991, pp. 16–25.

9. C.K. Hess, A Context File System for Ubi-quitous Computing Environments, tech.report UIUCDCS-R-2002-2285 UILU-ENG-2002-1729, Computer Science Dept.,Univ. of Illinois at Urbana-Champaign, July2002.

10. B.A. Myers, “Using Hand-Held Devicesand PCs Together,” Comm. ACM, vol. 44,no. 11, Nov. 2001, pp. 34–41.

11. G.E. Krasner and S.T. Pope, A Descriptionof the Model-View-Controller User Inter-face Paradigm in the Smalltalk-80 System,tech. report, ParcPlace Systems, MountainView, Calif., 1988.

12. G.W. Fitzmaurice, Graspable User Inter-faces, doctoral thesis, Computer ScienceDept., Univ. of Toronto, 1996.

13. M. Román and R.H. Campbell, A User-Centric, Resource-Aware, Context-Sensi-tive, Multi-Device Application Frameworkfor Ubiquitous Computing Environments,

tech. report UIUCDCS-R-2002-2284UILU-ENG-2002-1728, Computer ScienceDept., Univ. of Illinois at Urbana-Cham-paign, July 2002.

14. R. Cerqueira, C. Cassino, and R. Ierusa-limschy, “Dynamic Component Gluingacross Different Componentware Systems,”Proc. Int’l Symp. Distributed Objects andApplications (DOA 99), IEEE CS Press, LosAlamitos, Calif., 1999, pp. 362–373.

15. R. Ierusalimschy, L. Figuereido, and W.Celes, “Lua: An Extensible Extension Lan-guage,” Software: Practice and ExperienceJ., vol. 26, no. 6, 1996, pp. 635–652.

16. C.K. Hess, M. Román, and R.H. Campbell,“Building Applications for UbiquitousComputing Environments,” Proc. Int’lConf. Pervasive Computing (Pervasive2002), Springer-Verlag, Heidelberg, Ger-many, 2002, pp. 16–29.


the AUTHORS

Manuel Román is a PhD candidate at the University of Illinois at Urbana-Champaign.His research interests include ubiquitous computing, middleware, operatingsystems, and interactive and programmable active spaces. He received his BS andMS in computer science from the La Salle School of Engineering (Ramon Llull Univ.).Contact him at 3134 DCL, 1304 W. Springfield Ave., Urbana, IL 61801; [email protected].

Christopher Hess is a PhD candidate in the Computer Science Department at theUniversity of Illinois at Urbana-Champaign. His interests include ubiquitous comput-ing systems, streaming media, networking, operating systems, and object-orienteddesign. Hess received his BS and MS in mechanical engineering from Tufts Univer-sity and an MS in computer science from the University of Illinois. Contact him at3134 DCL, 1304 W. Springfield Ave., Urbana, IL 61801; [email protected].

Renato Cerqueira is an assistant professor of computer science at the PontificalCatholic University of Rio de Janeiro. He is also a research scientist and project man-ager at the Computer Graphics Technology Group of PUC-Rio (Tecgraf/PUC-Rio).His research interests include component-based development, object-oriented lan-guages, middleware platforms, distributed programming, software architectures,and distributed simulation. He received his MSc and PhD in computer science fromthe Pontifical Catholic University of Rio de Janeiro. He is a member of the ACM andthe IEEE Computer Society. Contact him at the Computer Science Dept./PUC-Rio,

Rua Marques de Sao Vicente 225, 407-RDC, Rio de Janeiro - RJ, Brazil 22453-900; [email protected].

Anand Ranganathan is pursuing a PhD in computer science at the University of Illi-nois at Urbana-Champaign. His research interests include context gathering andmodeling, using contextual information to make applications more intelligent in theirinteractions with humans, security and data management in pervasive computingenvironments, mobile computing, and wearable computing. He received a BTech incomputer science from the Indian Institute of Technology in Madras, India. Contacthim at 3134 DCL, 1304 W. Springfield Ave., Urbana, IL 61801; [email protected].

Roy H. Campbell is a professor of computer science at the University of Illinois atUrbana-Champaign. His research interests include operating systems, distributedmultimedia, network security, and ubiquitous computing. He received his BSc inmathematics from the University of Sussex, and his MSc and PhD in computingfrom the University of Newcastle upon Tyne. Contact him at 3134 DCL, 1304 W.Springfield Ave., Urbana, IL 61801; [email protected].

Klara Nahrstedt is an associate professor and Fisher Professor at the University of Illi-nois at Urbana-Champaign. Her research interests include multimedia middleware,protocols, operating system support for multimedia, software engineering for distrib-uted multimedia applications, and availability and quality of service on high-speedand mobile networks, as well as on high-end and handheld computers. She receiveda PhD from the University of Pennsylvania. Contact her at 3134 DCL, 1304 W. Spring-field Ave., Urbana, IL 61801; [email protected].

Documents

A middleware infrastructure for active spaces