one.world: experiences with a pervasive computing …one.world: experiences with a pervasive...

22 PERVASIVEcomputing Published by the IEEE CS and IEEE ComSoc ■ 1536-1268/04/$20.00 © 2004 IEEE

U B I Q U I T O U S S Y S T E M S O F T W A R E

One.world: Experiences with aPervasive ComputingArchitecture

Pervasive computing provides an attrac-tive vision for accessing informationanywhere and anytime.1 However, aconsiderable obstacle to realizing thisvision is the development of applica-

tions that continually adapt to an ever-changingcomputing environment and still function whenpeople move through the physical world orswitch devices. In the one.world project,2 we’vetried to create the appropriate system support sothat developers can effectively build and deployadaptable applications. We designed our archi-tecture from the ground up to address the needs

of pervasive applications. Thisarchitecture includes servicesthat simplify the task of copingwith constant change. Notably,discovery helps developers build

applications that locate and connect to serviceson other devices, and migration helps with appli-cations that follow users as they move throughthe physical world.

To better understand pervasive computing’spotential and challenges, consider researchersworking in a biology laboratory. Their goal is toperform reproducible experiments. Yet today theystill manually log individual steps in their papernotebooks, easily leading to incomplete experi-mental records. The use of notebooks also com-plicates the sharing of results with other

researchers unless biologists explicitly enter thedata in their PCs. In contrast, a digital laboratoryemploys radio frequency identification (RFID)and barcode scanners to easily capture data, loca-tion sensors to track researchers’ movements inthe laboratory, and touch screens to displayexperimental data close to the researchers. Thus,biologists working in a digital laboratory havemore complete records of their experiments andcan more easily share results with their colleagues.

However, implementing the digital biology lab-oratory with contemporary system services is dif-ficult because such services typically assume a rel-atively static and well-administered computingenvironment. Furthermore, technologies such asremote procedure call (RPC) and distributedobjects tend to hide distribution from applica-tions, so if changes occur, people must manuallyadapt the system instead of applications adapt-ing for them. For example, with contemporarysystems, it’s hard for researchers to move betweendevices in the digital laboratory. Every time, theymust manually log in, start their applications, andload their documents. Similarly, it’s hard to inte-grate visiting researchers’ devices because peoplemust first configure them—for example, to usethe correct wireless network. Finally, it’s difficultto share experimental data because researchersmust explicitly manage shared files and convertbetween different formats.

A new architecture, one.world, provides an integrated, comprehensiveframework for building pervasive applications. It targets applicationsthat automatically adapt to highly dynamic computing environments,and it includes services that make it easier for developers to manageconstant change.

Robert Grimm New York University

JULY–SEPTEMBER 2004 PERVASIVEcomputing 23

Overview of one.worldTo overcome the limitations of con-

temporary distributed systems, we’veidentified three requirements for systemsupport for pervasive applications. First,as people move through the physicalworld, either carrying their own portabledevices or switching between devices, anapplication’s location and execution con-text constantly changes. So, system sup-port must embrace contextual change, nothide it from applications. Second, usersexpect that their devices and applicationswill just plug together. Thus, system sup-port must encourage ad hoc compositionand not assume a static computing envi-ronment with just a few interactions.Third, as users collaborate, they musteasily share information. Hence, systemsupport must facilitate sharing betweenapplications and between devices.

Our architecture is centered aroundmeeting these three requirements. Itemploys a classic user/kernel split: Foun-dation and system services run in the ker-nel; libraries, system utilities, and appli-cations run in user space. One.world’sfoundation services directly addressthese individual requirements. They alsoprovide the basis for our architecture’ssystem services, which in turn serve ascommon building blocks for pervasiveapplications.

The four foundation services are a vir-tual machine, tuples, asynchronousevents, and environments. First, all codein one.world runs in a virtual machine—namely, the Java virtual machine (JVM).Because of pervasive computing envi-ronments’ inherent heterogeneity, devel-

opers can’t possibly predict all thedevices that their applications will runon, so the JVM ensures that applicationsand devices are composable. Second,one.world represents all data as tuples,which define a common data model,including a type system, for all applica-tions and thus simplify data sharing.Tuples are records with named andoptionally typed fields. Moreover, eachtuple is self-describing, so an applicationcan dynamically inspect its structure andcontents. Third, one.world expresses allcommunication, whether local or remote,through asynchronous events. Theseevents serve to explicitly notify applica-tions of changes in their runtime context.

Finally, environments are one.world’smain structuring mechanism. Like tra-ditional operating system processes,environments host running applicationsand isolate them from one another. Theyalso serve as containers for persistentdata, providing associative tuple storage

and thus making it possible to grouprunning applications with their persis-tent data. Furthermore, environmentsnest within one another, making it easyto extend and compose applications. Anouter environment has complete controlover all nested environments, includingthe ability to easily intercept and mod-ify events sent by inner environments toone.world’s kernel (which runs in adevice’s root environment) and to otherdevices. This interposition facility letsdevelopers and users dynamically changean application’s behavior without chang-ing the application itself. Moreover, it’sparticularly useful for complex andreusable behaviors, such as replicating anapplication’s data or deciding when tomigrate an application. Figure 1 showsan example environment hierarchy.

One.world’s system services build onthe foundation services and serve ascommon building blocks for pervasiveapplications. Table 1 summarizes spe-

User

ChatClock

robert<;> <;>

<;><;>

Environment Event handlersTuple<;>

Figure 1. Example environment hierarchy.The User environment hosts Emcee,one.world’s user and application management utility. User has one child,robert, which stores several tuplesrepresenting that user’s preferences. Therobert environment also has two children:Clock contains only active event handlers;Chat hosts the instant-messaging applica-tion and stores tuples representing themusic that this application broadcasts.

TABLE 1Application needs and one.world’s corresponding system services.

Application need One.world service

Search Query engine

Store data Structured I/O

Communicate Remote events

Locate Discovery

Fault-protect Check-pointing

Move Migration

cific application needs and one.world’scorresponding system services. Of theseservices, discovery and migration areprobably the most interesting.

Discovery locates resources—that is,event handlers—by their descriptions. Itleverages one.world’s uniform datamodel, in which all data, includingevents and queries, are tuples. Using thisdata model, discovery supports a rich set

of options, including early and late bind-ing, anycast, and multicast, with onlythree simple operations. Furthermore,because discovery is an essential ser-vice—without it, applications can’tadapt to a new or changing runtime con-text—it’s also self-managing. One deviceacts as the discovery server, providing themapping between descriptions and eventhandlers. All devices running one.worldthat are visible on the local broadcastnetwork automatically elect the serverfrom among themselves. To ensure avail-ability, one.world calls elections aggres-sively, and these elections complete aftera fixed time period. The individualdevices tolerate any resulting inconsis-tencies by exporting their discoverableresources to all visible servers while look-ing up resources on only one server.

Migration moves or copies an envi-ronment and all its contents to a differ-ent device, thus simplifying the imple-mentation of applications that follow aperson through the physical world.Unlike traditional process migration,3

one.world’s migration isn’t transparent,and the migrated application’s state islimited to the environments beingmigrated. During migration, one.world

automatically nulls out references toresources outside the environment tree.This practice is acceptable because appli-cations already expect change. Further-more, one.world’s migration is eager inthat it moves the entire state between thedevices in one atomic operation. Thisavoids residual dependencies andrequires connectivity between the devicesonly during migration. The result is that

one.world’s migration avoids many ofthe complexities of traditional processmigration, and migration across theInternet becomes practical.

We specifically designed one.world tohelp developers build applications thatautomatically adapt to an ever-changingcomputing environment. Discovery helpsin locating and connecting to services onother devices, and migration helps inimplementing applications that follow auser through the physical world. Theadvantage of our architecture’s servicesover other services is that they’re builtfrom the ground up to embrace change,encourage ad hoc composition, and facil-itate sharing.

Evaluation criteriaIn evaluating one.world, we tried to

determine whether focusing on the threerequirements has led to a practical archi-tecture for pervasive applications. How-ever, because this question is rather gen-eral and difficult to answer, we relied onfour more specific criteria and corre-sponding questions:

• Completeness. Can we build usefulprograms using one.world’s primi-

tives? This criterion determineswhether our architecture is sufficientlypowerful and extensible to supportinteresting user-space programs,including additional services and util-ities akin to the Unix shell.

• Complexity. How hard is it to writecode in one.world? This criteriondetermines the effort involved indeveloping programs for our archi-tecture. We’re especially interested inhow making applications adaptableimpacts programmer productivity.

• Performance. Is system performanceacceptable? This criterion determineswhether our architecture performswell enough to support actual appli-cation workloads. Because our goal isto make applications adaptable, we’reespecially interested in whether appli-cations respond quickly to changes intheir runtime context.

• Utility. Have we fostered success forothers? This criterion determineswhether others can build real perva-sive applications atop one.world. Italso represents the most important cri-terion. After all, a system architectureis only as useful as the programs run-ning on top of it.

Services and applications atopone.world.

To answer these questions, we and oth-ers have built several services, utilities,and applications atop one.world. In par-ticular, we’ve built a replication service,a user and application manager calledEmcee, and a text-and-audio-messagingsystem called Chat. We’ve also supportedthe University of Washington’s Labscapeproject in porting their digital biologylaboratory assistant to one.world.4 TheLabscape team deployed this laboratoryassistant as part of the Cell Systems Ini-tiative. Besides these primary programs,students have built, atop our architecture,a music-sharing system; a messaging sys-tem for future, intelligent home appli-

24 PERVASIVEcomputing www.computer.org/pervasive

U B I Q U I T O U S S Y S T E M S O F T W A R E

In evaluating one.world, we tried to determine

whether focusing on the three requirements

has led to a practical architecture for

pervasive applications.

ances; a graphical debugger; and a Webserver. We now summarize our ownapplications and the Labscape digitalbiology laboratory assistant, and also thecorresponding experimental results; anearlier work provides more details.2

Replication serviceTo provide ubiquitous access to infor-

mation, pervasive applications mustaccess the corresponding data items, evenif several people share the same data andaccess it from different, possibly discon-nected devices. Our replication servicehelps address this need. We patterned thisservice after Jim Gray and his colleagues’two-tier replication model,5 in which amaster owns all data, and replicas hostcopies of that data. The replication ser-vice runs in user space and exploitsone.world’s environment nesting to inter-pose on an application’s access to tuplestorage. In connected mode, updates arefinal, and the system forwards themdirectly to the master. In disconnectedmode, updates are tentative, and the sys-tem logs them on the replica in a sepa-rate log environment. When a replicaconnects again, it synchronizes with themaster by replaying its log against themaster and receiving any updates fromthe master. Synchronization is imple-mented by migrating a copy of the logenvironment to the master, where anapplication-specific component replaysthe updates and, if necessary, performsconflict resolution.

User and application managerEmcee includes support for setting up

users, running applications for a user, andcheck-pointing all of a user’s applications.Emcee also lets users move or copy appli-cations and their data through a simpledrag-and-drop interface, or move all theirapplications between devices. Users caneither push applications from the currentdevice to another one or pull them from

another device to the current one. As Fig-ure 1 shows, the implementation struc-tures the environment hierarchy accord-ing to the pattern /User/user/applicationand directly builds on this environmentnesting to control users’ applications. Theimplementation relies on check-pointingand migration to save, restore, move, andcopy applications, and on discovery tolocate a user’s applications when pullingthem to a new device.

Text-and-audio-messaging systemChat is based on a simple model under

which users send text and audio messagesto a channel and subscribe to that chan-nel to see and hear the messages sent toit. The implementation sends all messagesthrough late-binding discovery, whichautomatically routes messages to all inter-ested parties by combining the lookup ofmatching event handlers with the actualevent delivery; subscribing to a channelsimply translates to exporting an eventhandler to discovery. Therefore, Chatautomatically adapts to channel subscrip-tion and subscriber location changes.Users can stream audio either from amicrophone or from sound tuples storedin an environment. One.world providesutilities that let users import sound filesfrom a traditional file system and convertthem to a sequence of sound tuples.

LabscapeA fundamental feature of the Lab-

scape application is that experimentaldata follows researchers as they movethrough the laboratory. At the sametime, there’s no need to move the entireapplication, only a small component tocapture and display experimental data.Eventually, Labscape forwards all datato a central repository—making it pos-sible, for example, to mine the data ofseveral experiments. Figure 2 shows asnapshot of the capture-and-displaycomponent’s user interface, which iscalled a guide. The Labscape team devel-oped this interface through user inter-face studies with biology researchers.The individual icons represent differentexperimental steps, and the arrows rep-resent ordering constraints. Initially, theguide functions as a plan for performingthe experiment. As researchers performa step, they annotate the correspondingicon with the results of that step. Thus,the guide eventually becomes a record ofthe experiment.

Labscape’s implementation relies onseveral services, which all communicatethrough one.world’s late-binding dis-covery and, consequently, are isolatedfrom other services’ locations and fromtransient service and network failures.The device access service collects exper-


Figure 2. Labscape’s user interface. Anexperimental flowgraph, or guide, represents each experiment.

imental data from RFID and barcodescanners, and collects location updatesfrom infrared sensors. This service con-verts the data and the updates intoappropriate one.world events and thenforwards them to the proximity service,which tracks researchers’ locations. Forexperimental data, the proximity servicedetermines which researcher performedthe scanning operation and then for-

wards the data to the researcher’s guide.For location updates, the proximity ser-vice updates its internal data structuresand then directs the researcher’s guide tomove to the closest touch screen, usingone.world’s migration. The state serviceis the final repository for all experimen-tal data, which it receives from theresearchers’ guides. The WebDAV ser-vice then publishes this data on the Web.

Experimental resultsHaving described the main programs

built atop our architecture, we nowreturn to the four criteria and present theresults of our experimental evaluation.

CompletenessThe programs just discussed clearly

show that one.world is powerful enoughto support a variety of useful programs.Furthermore, our replication service andEmcee demonstrate that it’s possible toimplement services and utilities in userspace. The key feature for enabling user-space services and utilities is one.world’senvironment hierarchy, which makes iteasy to control other programs and inter-pose on their event streams.

ComplexityTo evaluate the effort involved in writ-

ing adaptable applications, we carefullytracked the process of implementingEmcee and Chat. Overall, implementingthe two programs took 256 hours for4,321 noncommenting source state-ments (NCSS), yielding a measured pro-ductivity of 16.5 NCSS/hr. This produc-tivity is within the range of resultsreported in the literature,6,7 suggestingthat writing adaptable applications is not

significantly harder than writing moreconventional applications.

PerformanceWe conducted measurements with

Emcee and Chat using Sun’s JavaHotSpot Virtual Machine 1.3.1 runningon Dell 800-MHz Pentium III PCs con-nected through a 100-Mbyte switchedEthernet. These performance measure-ments show that service interruptions dueto migration or discovery server electionslast less than 4 seconds, comparing favor-ably, for example, with the TransmissionControl Protocol (TCP) timing out afterseveral minutes. Furthermore, althoughmigration latency generally depends onthe number and size of stored tuples, thislatency is only 7 seconds for an environ-ment storing 8 Mbytes of audio data,which is fast enough for a person mov-ing through the physical world. Finally,our implementation of discovery per-forms well enough to route several inde-pendent streams of uncompressed audiodata. However, its scalability is also lim-ited, supporting no more than 10 streamsfor the PCs on our network.

UtilityThe Labscape digital laboratory assis-

tant illustrates the utility of one.world as

a real-world application substrate. Fur-thermore, in contrast to an earlier ver-sion, which the Labscape team imple-mented using Java sockets and the team’sown application-specific migrationinstead of the corresponding one.worldservices, the one.world port required lessthan half the development time, had anorder-of-magnitude faster migrationtime (seconds instead of minutes), had atwo-orders-of-magnitude longer meantime between failures (days instead ofminutes), and could recover piecemealfrom failures rather than requiring arestart of the entire lab every time. Weattribute these improvements to twomain factors. First, our architecture’s ser-vices—including the level of indirectionoffered by discovery rather than directTCP connections—provide a bettermatch to the Labscape application’sneeds while also exposing a cleaner API.Second, by using one.world, Labscape’sdevelopers could focus on the applica-tion itself rather than having to createnecessary system support.

Experiences and lessonslearned

On the basis of the results just discussed,we conclude that one.world does, in fact,let developers effectively build applicationsthat adapt to change. Moreover, we con-clude that our focus on embracing change,encouraging composition, and facilitatingsharing has led to a practical architecturefor pervasive applications.

Nevertheless, the user-space programswe and others have built have not onlyprovided a solid basis for evaluatingone.world, they’ve also helped us gain abetter understanding of our architec-ture’s strengths and limitations. We nowfocus on the resulting insights and iden-tify lessons that are applicable beyondour work.

Clear successesThe central role played by environ-


U B I Q U I T O U S S Y S T E M S S O F T W A R E

Our implementation of discovery performs well

enough to route several independent streams of

uncompressed audio data.

ments in our architecture implies a moregeneral pattern—namely, that nesting isa powerful paradigm for controlling andcomposing applications. Nesting pro-vides control, as both Emcee and thegraphical debugger illustrate. Moreover,developers and users can use nesting toextend applications, as our replicationservice illustrates. Nesting thus makes itpossible to easily factor important, pos-sibly complex behaviors and providethem as common application buildingblocks. Furthermore, nesting is attractivebecause it preserves the relationshipsamong environments. For example,when we stored audio tuples in a childenvironment of Chat’s environment, theformer remained a child, even if Chat’senvironment moved between devices.This nesting flexibility is also present inthe Ambient Calculus,8 which, similar toone.world’s environments, groups com-putations and data in nested containers.

The use of migration in Emcee andLabscape illustrates that migration pro-vides a general building block for struc-turing pervasive systems. Migration canbe an internal tool, as with our replica-tion service, where it replaces a net-worked reconciliation protocol. It canalso be an application-level tool—eithercontrolled from the outside (as withEmcee) or self-initiated (as with Lab-scape’s guides). Furthermore, migrationcan be used simultaneously as an internaland application-level building block. Forexample, our replication service’s masterand its replicas are migratable. Migratingthe master is useful when, for example,upgrading the computer on which themaster runs; migrating a replica is usefulwhen the user is switching devices. How-ever, migration’s widespread use alsorequires support for discovery so thatmigrating services and applications canreconnect after a location change.

Besides representing a central appli-cation building block, one.world’smigration service also leverages our

architecture’s other services as much aspossible to avoid complexity and to pro-vide a clean model for its operation. Forexample, it relies on the JVM to providea uniform execution environment acrossdifferent devices and hardware architec-tures. It also relies on environments toclearly delineate which state to movebetween devices and which state not tomove. Furthermore, the migration ser-

vice relies on asynchronous events tocapture an application’s execution statein the form of its event queues and tonotify the application of a completedmove or copy operation. More funda-mentally, however, one.world’s migra-tion can avoid many of the complexitiesassociated with providing such a servicebecause applications already expectchange.3 In other words, exposing dis-tribution enables not only more adapt-able applications but also more power-ful system services.

Need for user-space supportConsistent with our goal of exposing

change, all communications in one.world,whether local or remote, occur throughasynchronous events. Furthermore, eventdelivery has at-most-once semantics. Forremote communications, at-most-oncesemantics are appropriate because, in lieuof transactional delivery protocols, aremote device might fail after acceptingan event but before delivering it to theintended application. For local event han-dling, exactly-once delivery is the norm.However, at-most-once semantics letone.world’s implementation recover frompathological overload conditions by selec-

tively shedding load.Although we still believe that best-

effort, asynchronous events are the appro-priate kernel-level services for pervasivecomputing, many applications rely onsynchronous request-and-response inter-actions. This raises the question of howto best implement these interactions—aconcern Labscape’s developers specificallynoted. After some experimentation, we

found the following approach, which wecall the logic/operation pattern, particu-larly successful. Under this pattern, anapplication is partitioned into logic andoperations, which are implemented byseparate sets of event handlers. Compu-tations that don’t fail are logic; interac-tions that may fail—notably all I/O—areoperations. A user-level operation librarysimplifies the implementation of eventhandlers representing operations by main-taining the state associated with request-and-response interactions and by detect-ing and recovering from failures throughtimeouts and retries. The operationlibrary conveys a failure condition to theappropriate logic only if recovery failsrepeatedly or a failure cannot be recov-ered from in a general way. Although theoperation library can’t hide one.world’sevent-based programming model fromdevelopers, it does enable a more famil-iar synchronous programming style andreduces the complexity of building event-based applications.

To enforce protection, our architec-ture prevents applications from access-ing Java’s java.lang.System class, and it makesselect methods (notably arraycopy() to copythe contents of arrays and getProperty() to


The central role played by environments in our

architecture implies a more general pattern—

namely, that nesting is a powerful paradigm for

controlling and composing applications.

access system properties) accessiblethrough its own SystemUtilities class. Using adifferent class to access these methodsdoesn’t restrict applications written fromscratch; developers can simply use a dif-ferent class name in the source code.However, it does prevent existing Javalibraries, which frequently employ thesemethods, from running on one.world.As a result, the Labscape team had dif-

ficulties reusing third-party libraries. Toaddress this issue, we developed a sim-ple utility that, using binary rewriting,transforms existing libraries and replacesinvocations to System’s methods with thecorresponding one.world methods.

The larger lesson behind both ouroperation library and the binary rewrit-ing tool is that, to be effective, a systemarchitecture should provide a program-ming environment as close as possible tofamiliar development platforms. Other-wise, application developers will focuson working around the system architec-ture’s peculiarities rather than focusingon their applications.

Overdesigned featuresWhen designing one.world’s interfaces,

we took a cue from Unix and designedstructured I/O to expose the same basicinterface for both storage and communi-cations (although they’re distinct services,just like files and sockets are distinct ser-vices in Unix). However, none of the pro-grams we and others have built use struc-tured I/O networking; they all rely onremote events and discovery for net-worked communications. Only theimplementation of remote events and dis-

covery in the kernel builds on structuredI/O networking. Developers tend to favorremote events and discovery becausethey’re higher-level, more flexible ser-vices. So, we believe we overdesignedstructured I/O. We could have omittedstructured I/O networking and insteadused a simpler, internal networking layerfor implementing remote events and dis-covery. In other words, storage and com-

munications are orthogonal to each otherand best implemented by separate ser-vices with distinct interfaces.

Because structured I/O storage pro-vides a record-based interface to persis-tent storage, we also took a cue from con-ventional databases and providedatomicity, isolation, and durability for alloperations. However, our performanceevaluation of the replication service sug-gests that the durability guarantees cangenerate excessive overhead for someapplications. In particular, immediatelyforcing each write operation to disk isunnecessary when logging updates in dis-connected mode because all updates arealready tentative. To address this prob-lem, we designed (but have not imple-mented) a simple extension to structuredI/O, under which applications can requestthat the destructive write and delete oper-ations provide only relaxed durability andare lazily written to disk. Just as with tra-ditional file systems, applications usingthis option must explicitly perform a flushto force pending updates to disk. Whenwe consider our experience with struc-tured I/O contrasted with operations toprovide reliable event delivery, we con-clude that, just as with other end-to-end

guarantees, it’s best to provide reliabilityguarantees in user space rather than as thedefault within the kernel. That way, appli-cations that don’t need such guaranteesneed not pay the overhead.

LimitationsThe biggest limitation of our archi-

tecture is that like Jini9 and Lime10 butunlike iROS11 and L2imbo,12 one.worldimplements tuples through Java classes,using public fields to represent a tuple’svalues. Implementing tuples throughJava classes provides a convenient inter-face to data for applications becauseaccessing a value is a simple field access.However, it also poses a considerableproblem for services such as discovery,which process many different types ofdata for many different applications andmust access the corresponding class files,in addition to the actual tuples. The fun-damental problem is that we’ve taken asingle-node programming methodol-ogy—a programmatic data model—which expresses data schemas in the formof code, and applied it to a distributedsystem. This suggests that we need toabandon the programmatic data modelaltogether and instead use a data-centricdata model, such as XML Schema, whichexpresses schemas as data rather thancode. With a data-centric data model,applications and services must still accessa data item’s schema to manipulate thedata item. However, because the schemasare data themselves and not code, they’reeasier to distribute and share, and theyaren’t tied to a specific execution plat-form. Hence, data-centric data modelsprovide better interoperability than pro-grammatic data models.

Defining an appropriate data-centricdata model is an important topic forfuture research. The challenge is to definea data model that meets conflictingrequirements. On the one hand, to sup-port the pervasive sharing of information,the data model must be general and sup-



Defining an appropriate data-centric data model

is an important topic for future research. The

challenge is to define a data model that meets

conflicting requirements.

ported by a wide range of platforms. Onepossible starting point is XML Schema.It already defines the data model forSOAP, the emerging standard for remotecommunications between Web servicesthat, for example, Microsoft’s .NET plat-form uses. On the other hand, the datamodel must be easy to program and effi-cient to use. For an XML-based datamodel, this means avoiding the com-plexities of a general data access inter-face, such as the Document ObjectModel, and providing a more efficientencoding. Ideally, a data-centric datamodel should be as easy to program asfield access for tuples in our architecture,while also avoiding the need forexchanging class files between devices.

In contrast to iROS, which includessupport for HTTP in addition to its owntuple-based protocol, one.world exclu-sively builds on its own networking pro-tocols in the form of remote events anddiscovery. In our experience, theseremote-events and discovery protocolshave clearly simplified the implementa-tion of pervasive applications runningon our architecture. At the same time,using nonstandard protocols has madeit harder to integrate one.world withother distributed systems, notably Web-based applications.

Although we’ve successfully imple-mented a Web server atop our architec-ture, integrating outside applicationswith one.world through remote eventsor discovery is impractical, especially ifthe outside applications aren’t written inJava. Because of our programmatic datamodel, an outside application wouldhave to reimplement large parts of Java’sobject serialization, which would beunnecessarily complex. However, to pro-vide ubiquitous information access, per-vasive applications must easily interactwith one another and with Internet ser-vices, independent of the underlying sys-tem platform. Moving to a data-centric,XML-based data model and using stan-

dardized communication protocols suchas HTTP will help provide better inter-operability between pervasive applica-tions, even if they run on different sys-tem architectures. To put it differently,modern distributed systems must becompatible with Internet protocols firstand offer additional capabilities second.

MetricsOur experimental evaluation of

one.world certainly represents a first steptoward thoroughly evaluating a perva-sive computing architecture. But it alsoillustrates that we need better metrics fordesigning and evaluating pervasive com-puting systems. In particular, althoughwe’ve used NCSS/hr as a productivitymetric, we’ve found only a few refer-ences in the literature to calibrate ourmeasurements. Furthermore, the soft-ware engineering community seems tohave adopted function-point counting asa preferred metric.13 Function-pointcounting attempts to capture an appli-cation’s logical inputs, transformations,and outputs, requiring the developmentof a higher-level model to measure thesoftware. Thus, function-point countingprecludes the automated collection ofapplication statistics, which raises thequestion of how objective this metricreally is. Consequently, we still believethat NCSS/hr provides an appropriatestarting point for measuring program-mer productivity. However, to determinethis metric’s accuracy, we need moreexperience using it across a wider rangeof applications, system platforms, andprogramming languages.

We’ve also characterized one.world’sadaptability by following the frameworkdescribed by Brian Noble and his col-leagues and measuring how our archi-tecture’s applications and services reactto different stimuli.14 However, we lackstandardized benchmarks that can cap-ture the scalability and adaptabilityrequirements of pervasive computing

environments. We’re especially inter-ested in the number of people anddevices that pervasive computing envi-ronments must support, the differentclasses of devices people use, and the cor-responding arrival and departure ratesof people moving through the physicalworld. We believe that wireless mobilitystudies, such as the one performed atDartmouth University,15 can provide agood starting point for developing suchbenchmarks, but there’s clearly a needfor similar studies to characterize mobil-ity for different organizations and targetaudiences, and to track changes asmobile devices and wireless technologiesdevelop over the years.

Our experiences with one.worldsuggest several topics forfuture research into systemsupport for pervasive applica-

tions. Notably, defining data models andcommunication protocols to better inte-grate pervasive systems with one anotherand with Internet services remains a chal-lenge. Additionally, metrics for designingand evaluating pervasive systems are stilllacking. Our experiences also suggestthat, given appropriate system support,pervasive applications are fairly stylizedin their implementations, mostly encodinghow to route and transform data andwhere to make their services available.Hence, we envision a different approachto the development of pervasive appli-


the AUTHOR

Robert Grimm is an assis-tant professor of computerscience at New York Univer-sity. His research interestsfocus on how to useprogramming language andcompiler technologies tomore effectively build distrib-

uted systems that scale and evolve more grace-fully. Grimm received his PhD in computer sci-ence and engineering from the University ofWashington. He is a member of the IEEE, theACM, and Usenix. Contact him at New YorkUniversity, Dept. of Computer Science, 715Broadway, Room 711, New York, NY 10003;[email protected]; www.cs.nyu.edu/rgrimm.



cations—one that favors higher-level,declarative specifications rather thanexplicitly programming behaviors. Forexample, such an approach would letdevelopers specify data integrity con-straints for replicated storage and poli-cies for migrating pervasive applications.The key insight is that a declarative spec-ification can concisely describe a system’sproperties, which can then be automat-ically translated into appropriate actions.In effect, such an approach would treata pervasive systems platform, such asone.world, as the assembly language forimplementing complex behaviors. Assuch, it could significantly simplify thedevelopment of complex systems.

ACKNOWLEDGMENTSJanet Davis, Eric Lemar, Adam MacBeth, StevenSwanson, Ben Hendrickson, Tom Anderson, BrianBershad, Gaetano Borriello, Steven Gribble, andDavid Wetherall all contributed to the developmentof one.world. On their behalf, I thank the membersof the Labscape project, the students of the Univer-sity of Washington’s CSE 490dp, Daniel Cheah,and Kaustubh Deshmukh for using one.world tobuild their applications. Also, Armando Fox, BenGoldberg, David Mazières, and the anonymousreviewers provided valuable feedback on earlierversions of this article. For more information onone.world, including its source release, see www.cs.nyu.edu/rgrimm/one.world.

REFERENCES1. M. Weiser, “The Computer for the Twenty-

First Century,” Scientific Am., vol. 265, no.3, 1991, pp. 94–104.

2. R. Grimm, System Support for PervasiveApplications, doctoral dissertation, Dept.of Computer Science and Eng., Univ. ofWashington, 2002.

3. D. Milojicic, F. Douglis, and R. Wheeler,eds., Mobility: Processes, Computers, andAgents, Addison-Wesley, 1999.

4. L. Arnstein et al., “Systems Support forUbiquitous Computing: A Case Study ofTwo Implementations of Labscape,” Proc.Int’l Conf. Pervasive Computing, LNCS2414, Springer-Verlag, 2002, pp. 30–44.

5. J. Gray et al., “The Dangers of Replicationand a Solution,” Proc. ACM SIGMODInt’l Conf. Management of Data, ACMPress, 1996, pp. 173–182.

6. P. Ferguson et al., Software ProcessImprovement Works!, tech. report CMU/SEI-99-TR-027, Software Eng. Inst.,Carnegie Mellon Univ., 1999.

7. L. Prechelt, “An Empirical Comparison ofSeven Programming Languages,” Com-puter, vol. 33, no. 10, 2000, pp. 23–29.

8. L. Cardelli, “Abstractions for MobileComputations,” Secure Internet Pro-gramming: Security Issues for Distrib-uted and Mobile Objects, LNCS 1603, J.Vitek and C.D. Jensen, eds., Springer-Verlag, pp. 51–94.

9. K. Arnold et al., The Jini Specification,Addison-Wesley, 1999.

10. A.L. Murphy, G.P. Picco, and G.-C. Roman,“Lime: A Middleware for Physical and Log-ical Mobility,” Proc. 21st IEEE Int’l Conf.Distributed Computing Systems (ICDCS01), IEEE CS Press, 2001, pp. 524–533.

11. B. Johanson, A. Fox, and T. Winograd,“The Interactive Workspaces Project: Expe-riences with Ubiquitous ComputingRooms,” IEEE Pervasive Computing, vol.1, no. 2, 2002, pp. 67–74.

12. N. Davies et al., “L2imbo: A DistributedSystems Platform for Mobile Computing,”Mobile Networks and Applications, vol. 3,no. 2, 1998, pp. 143–156.

13. D. Garmus and D. Herron, Measuring theSoftware Process, Prentice Hall, 1995.

14. B.D. Noble et al., “Agile Application-AwareAdaptation for Mobility,” Proc. Symp.Operating Systems Principles (SOSP 97),ACM Press, 1997, pp. 276–287.

15. D. Kotz and K. Essien, “Analysis of aCampus-Wide Wireless Network, Proc. 8thAnn. Int’l Conf. Mobile Computing andNetworking (MobiCom 02), ACM Press,2002, pp. 107–118.

Any products your peers should know about? Write a review for IEEEPervasive Computing, and tell us why you were impressed. Our New Products department features reviews of the latestcomponents, devices, tools, and other ubiquitous computing gadgetson the market.

Send your reviews and recommendations [email protected]

today!

Tried any new gadgets lately?

one.world: experiences with a pervasive computing …one.world: experiences with a pervasive...

Documents