programming for pervasive computing … for pervasive computing environments robert grimm, janet...

15

Click here to load reader

Upload: dinhhanh

Post on 25-Jun-2018

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

Programming for Pervasive Computing Environments

Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson,Steven Gribble, Tom Anderson, Brian Bershad, Gaetano Borriello, David Wetherall

University of [email protected]

Technical Report UW-CSE-01-06-01

Abstract

Pervasive computing provides an attractive vision forthe future of computing. Computational power will beavailable everywhere. Mobile and stationary deviceswill dynamically connect and coordinate to seamlesslyhelp users in accomplishing their tasks. However, forthis vision to become a reality, developers must buildapplications that constantly adapt to a highly dynamiccomputing environment. To make the developers’ taskfeasible, we introduce a system architecture for perva-sive computing, calledone.world . Our architecture pro-vides an integrated and comprehensive framework forbuilding pervasive applications. It includes a set of ser-vices, such as service discovery, checkpointing, migra-tion, and replication, that help to structure applicationsand directly simplify the task of coping with constantchange. We describe the design and implementation ofour architecture and present the results of an evaluation,which includes two case studies.

1 Introduction

In this paper, we explore how to build applications forpervasive computing environments. Pervasive comput-ing [17, 47] calls for the deployment of a wide variety ofsmart devices throughout our working and living spaces.These devices are intended to react to their environmentand coordinate with each other and network services.Furthermore, many devices will be mobile and are ex-pected to dynamically discover other devices at a givenlocation and continue to function even if they are dis-connected. The overall goal is to provide users with uni-versal and immediate access to information and to trans-parently support them in their tasks. The pervasive com-puting space can thus be envisioned as a combinationof mobile and stationary devices that draw on power-ful services embedded in the network to achieve users’tasks [15]. The result will be a giant, ad-hoc distributed

system, with tens of thousands of people, devices, andservices coming and going.

The key challenge for developers is to build appli-cations that adapt to such a highly dynamic environ-ment and continue to function, even if people and de-vices are roaming across the infrastructure and if the net-work provides only limited services. However, existingapproaches to building distributed applications, includ-ing client/server or multitier computing, are ill suited tomeet this challenge. They are targeted at smaller and lessdynamic computing environments and lack sufficient fa-cilities to manage constant change. As a result, devel-opers of pervasive applications have to expend consid-erable effort towards building necessary systems infra-structure instead of focusing on the actual applications.

To mitigate this situation, we introduce a system ar-chitecture for pervasive computing, calledone.world .Our architecture is based on a simple programmingmodel and provides a set of services that have beenspecifically designed for large and dynamic computernetworks. Our architecture does not introduce funda-mentally new operating system technologies or services;rather, the goal is to provide an integrated and compre-hensive framework for building pervasive applications.By usingone.world , application developers can focus onthe actual application logic and on making their appli-cations adaptable. We have validated our approach bysetting up competing teams of developers building thesame applications, with one team using Java-based tech-nologies and the other usingone.world .

This paper is structured as follows. In Section 2we motivate our work and introduce our approach tobuilding pervasive applications. Section 3 providesan overview of our architecture. Section 4 describesone.world ’s design and implementation in detail. In Sec-tion 5 we present an evaluation of our architecture, in-cluding the results of our validation case study. Sec-tion 6 discusses future work and Section 7 reviews re-lated work. Finally, Section 8 concludes this paper.

Page 2: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

2 Motivation and Approach

From a systems viewpoint, the pervasive computingspace presents the unique challenge of a large and highlydynamic distributed computing environment. This sug-gests that pervasive applications really are distributedapplications. Yet, existing approaches to building dis-tributed systems do not provide adequate support forpervasive applications and fall short along three mainaxes.

First, many existing distributed systems seek to hidedistribution and, by building on distributed file systemsor remote procedure call (RPC) packages, mask remoteresources as local resources. This transparency simpli-fies application development, since accessing a remoteresource is just like performing a local operation. How-ever, this transparency comes at a cost in service avail-ability and failure resilience, because it encourages aprogramming style in which the unavailability of a re-source or a failure is viewed as an extreme case. Butin an environment where tens of thousands of devicesand services come and go, the unavailability of some re-source is a frequent occurrence.

Second, RPC packages and distributed object sys-tems compose distributed applications through program-matic interfaces. Just like transparent access to re-mote resources, composition at the interface level sim-plifies application development. However, composi-tion through programmatic interfaces also leads to atight coupling between major application componentsbecause they directly invoke each other through their in-terfaces. As a result, it is unnecessarily hard to add newbehaviors to an application. Extending a component re-quires interposing on the interfaces it uses, which is un-wieldy for interfaces with numerous or complex meth-ods. Furthermore, extensions are limited by the degreeto which extensibility has been designed into the appli-cation’s interfaces.

Third, distributed object systems, such as Le-gion [32] or Globe [44], encapsulate both data and func-tionality within a single abstraction, namely objects. Yetagain, encapsulation of data and functionality extends aconvenient programming paradigm for single-node ap-plications to distributed systems. By encapsulating databehind an object’s interface, objects limit how data canbe used and complicate the sharing, searching, and fil-tering of data. In contrast, relational databases define acommon data model that is separate from behaviors andthus make it easy to use the same data for different andnew applications. Furthermore, objects as an encapsula-tion mechanism are based on the assumption that codeand data layout change more frequently than an object’sinterface, an assumption that may be less valid for aglobal distributed computing environment. Increasingly,

Separatedata and

functionality

Adaptableapplications

Composedynamically

Exposechange

Programming for change

Figure 1: Overview of our approach. The three principlesguide the design of our system architecture and make itfeasible for application developers to program for change,resulting in adaptable applications.

common data formats are specified by industry groupsand standard bodies, such as the World Wide Web Con-sortium, and evolve at a relatively slow pace. In contrast,application vendors compete on functionality, leadingto considerable differences in application interfaces andimplementations and a much faster pace of innovation.

Not all distributed systems are based on extensionsof single-node programming methodologies. Notably,the World Wide Web does not rely on programmaticinterfaces and does not encapsulate data and function-ality. It is built on only two basic operations, GETand POST, and the exchange of passive, semi-structureddata. In part due to the simplicity of its operationsand data model, the World Wide Web has successfullyscaled across the globe. Furthermore, the narrownessof its operations and the uniformity of its data modelhave made it practical to add new services, such ascaching [10, 41], content transformation [20], and con-tent distribution [26].

However, from a pervasive computing perspectivethe World Wide Web also suffers from three significantlimitations. First, it requires connected operation forany use other than reading pages. Second, it places theburden of adapting to change on users, for example, bymaking them reload a page when a server is unavailable.Finally, it does not seem to accommodate emerging tech-nologies that are clearly useful for building adaptableapplications, such as mobile code [42] (beyond Java ap-plets and JavaScript for enlivening pages) and servicediscovery [1, 3, 14].

This raises the question of how to structure systemssupport for pervasive applications. On one side, extend-ing single-node programming models to distributed sys-tems leads to the shortcomings discussed above. On theother side, the World Wide Web avoids several of theshortcomings but is too limited for pervasive comput-ing. To this end, we identify three principles that should

Page 3: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

guide the design of a systems framework for pervasivecomputing.

Principle 1 Expose change.

Systems should expose change, including failures, ratherthan hide distribution, so that applications can im-plement their own strategies for handling changes.Leases [22] are an example of a suitable mechanism:they make time visible throughout a system and thuscleanly expose change. At the same time, systems needto provide primitives that simplify the task of adequatelyreacting to change. Examples for such primitives in-clude “checkpoint” and “restore” to simplify failure re-covery, “move to a remote node” to follow a user as shemoves through the physical world, and “find matchingresource” to discover suitable services on the network.

Principle 2 Compose dynamically.

Systems should make it easy to compose and extend ap-plications and services at runtime. In particular, interpo-sition on a component’s interactions with other compo-nents as well as the outside world must be simple. Suchfeatures make it possible to dynamically change the be-havior of an application or add new behaviors withoutchanging the application itself. This is particularly use-ful for complex and reusable behaviors, such as replicat-ing an application’s data or deciding when to migrate anapplication.

Principle 3 Separate data and functionality.

Systems need to provide a clean separation between dataand functionality, so that they can be managed separatelyand so that they can evolve independently. This separa-tion is especially important for services that search, fil-ter, or translate large amounts of data. At the same time,data and functionality depend on each other, for exam-ple, when migrating an application and its data. Systemsthus need to also include the ability to group data andfunctionality but must make them accessible indepen-dently.

Common to all three principles is the realization thatsystems cannot automatically decide how to react tochange, because there are too many alternatives. Atthe same time, a system architecture whose design fol-lows the three principles provides considerable supportfor dealing with change. Exposing change helps withidentifying and reacting to changes in devices and thenetwork. Dynamic composition helps with changes inapplication features and behaviors. Finally, separatingdata and functionality helps with changes in data formatsand implementation. Given a system that follows theseprinciples, application developers can focus on making

replicator

log

/

<;><;><;>

app

<;>

<;>

<;>Environment Tuple Components

Figure 2: An example environment hierarchy. The rootenvironment “/” hosts one.world ’s kernel and has onechild, named “replicator”, which also contains active com-ponents. The replicator environment in turn has two chil-dren, named “log” and “app”. The log environment onlystores tuples, while the app environment also containsactive components.

applications adaptable instead of creating necessary sys-tems support. This approach to building pervasive appli-cations is illustrated in Figure 1.

3 Architecture

In our architecture, each device typically runs a singleinstance ofone.world . Each suchnodeis independent ofother nodes and may be administered separately. Appli-cations run withinone.world , and all applications run-ning on the same node share the same instance of ourarchitecture. Our architecture provides the same basicabstractions and core services across all nodes and usesmobile code to provide a uniform and safe executionplatform.

3.1 Basic Abstractions

Our architecture relies on separate abstractions for ap-plication data and for functionality. Applications storeand communicate data in the form oftuples and arecomposed fromcomponents. Tuples are records withnamed fields and are self-describing in that an applica-tion can dynamically determine a tuple’s fields and theirtypes. Components implement functionality and interactby importing and exporting event handlers. They stati-cally declare which event handlers they import and ex-port but are dynamically linked and unlinked.

Environmentsprovide structure and control. Theyserve as containers for tuples, components, and other

Page 4: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

environments. Each application has at least one envi-ronment, in which it stores tuples and in which its com-ponents are instantiated. At the same time, applicationsare not limited to a single environment and may spanseveral, nested environments. Each node’s root environ-ment hostsone.world ’s kernel. Environments are alsoan important mechanism for dynamic composition: anenvironment controls all nested environments and caninterpose on their interactions with the kernel and theoutside world. Environments thus represent a combina-tion of the roles served by file system directories andnested processes [6, 18, 43] in more traditional operat-ing systems. Figure 2 shows an example environmenthierarchy.

Access to both local and remote resources is con-trolled by leases[22]. Leases limit the time applica-tions can access resources, such as an environment’s tu-ple storage or a communication channel, and force ap-plications to periodically renew their interest in the re-sources. As a result, leases make time visible throughoutthe system and cleanly expose change to applications.

3.2 Services

In pervasive computing environments, location has aprofound effect. As a user moves through the physicalworld, her applications need to be continuously avail-able. She may carry them with her on a personal device,or they may follow her from shared device to shared de-vice. At any location, applications need to be able to dis-cover local resources, such as a wall display or a printer,and interact with network services. Applications alsoneed to be prepared to operate in more limited environ-ments. They need to provide access to shared data, evenif the current location does not allow network access.Furthermore, they may have to gracefully resume after afailure, such as a user’s only device’s batteries runningout.

Since these requirements are shared between perva-sive applications,one.world provides a set of servicesthat serve as common building blocks and directly helpdevelopers in making their applications adaptable.Mi-gration provides the ability to move or copy an envi-ronment and its contents to another node. It affects anentire application, because both components and storedtuples are moved or copied.Remote event passing(REP)provides the ability to send events to remote receivers,including receivers located by service discovery.Repli-cation makes stored tuples accessible on several nodesat the same time, even if the nodes are not currentlyconnected. Finally,checkpointingcaptures the execu-tion state of an environment tree and saves it as a tuple,thus making it possible to later revert the environmenttree’s execution state.

Operation Argument Explanationput Tuple Write the tuple.read Query Read a single tuple.listen Query Read several tuples as

they are written.query Query Query for several tuples

from storage.delete ID Delete a tuple from

storage.

Table 1: The structured I/O operations. Operation speci-fies the structured I/O operation. Argument specifies howtuples are selected for that operation. Explanation de-scribes the operation.

4 Design and Implementation

In this section, we describe the design and implementa-tion of one.world in detail. We first present our archi-tecture’s facilities for data management in Section 4.1,followed by events and components in Section 4.2, andthe environment hierarchy in Section 4.3. We concludethis section with a discussion of the current status of ourJava-based implementation in Section 4.4.

4.1 Data Management

Data management inone.world is based on tuples. Tu-ples define a common data model, including the typesystem, for all applications and thus make it easy to storeand exchange data. They are self-describing, mutablerecords with named and optionally typed fields and canbe nested within each other. All tuples have an ID fieldspecifying a globally unique identifier [31] (GUID) tosupport symbolic references and a metadata field to sup-port application-specific annotations.

Structured I/Olets applications store tuples in envi-ronments and communicate tuples across the networkon top of UDP and TCP. It exposes a common inter-face to storage and communications, which is summa-rized in Table 1. Operations are atomic so that theireffects are predictable. Operations on storage can op-tionally use transactions to group several operations intoone atomic unit. Queries forread, listen, andqueryoper-ations support comparisons with the value of a field, in-cluding the fields of nested tuples, comparisons with thedeclared or actual type of a tuple or field, and negations,disjunctions, and conjunctions. To use structured I/O,applicationsbind to tuple storage or a communicationsend-point and then perform operations on the bound re-source. All bindings are controlled by leases.

We chose tuples instead of byte strings for I/O be-cause tuples preserve the structure of data. Tuples obvi-ate the need for explicit marshalling and unmarshalling

Page 5: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

of data and enable system-level query processing. Sincethey provide well-defined data units, they also make iteasier to share data between multiple writers. We chosetuples instead of XML because tuples are simpler andeasier to use. The structure of XML-based data is lessconstrained and also more complicated, including tags,attributes, and name spaces. Furthermore, interfaces toaccess XML-based data, such as DOM [30], are rela-tively complex.

We chose an I/O mechanism that distinguishes be-tween storage and communications instead of a unifiedtuple space abstraction [9, 21, 49] because such a mech-anism better reflects how applications store and com-municate data. In particular, applications often modifystored data. For example, a personal information man-ager needs to be able to update stored contacts and ap-pointments. Structured I/O lets applications overwritestored tuples by simply writing a tuple with the sameID as the stored tuple. In contrast, tuple spaces supportthe addition of new tuples, but existing tuples cannot bechanged. Furthermore, exchanging tuples through a tu-ple space imposes too high a performance overhead forsome applications, such as streaming audio and video.Communications through storage also provide a seman-tic mismatch for these applications, because data shouldbe delivered right away and not be retained in storage.

While structured I/O only provides access to local tu-ple storage, replication makes tuples accessible to appli-cations on multiple nodes, even if the nodes are discon-nected. one.world ’s replication layer is patterned afterGray et al.’s two-tier replication model [23]. A mas-ter node owns all data and replicas have copies of thatdata. Replicas can either be connected or disconnected.In connected mode, updates are final and performed di-rectly on the master. In disconnected mode, updates aretentative and logged on the replica. When a replica be-comes connected again, it synchronizes with the masterby replaying its log against the master and by receivingupdates from the master. The replica may then discon-nect again or continue in connected mode.

We chose two-tier replication over Bayou’s epidemicreplication model [37, 40] for two reasons. First, two-tier replication is easier to explain to users. Tentativeupdates may only change once, during synchronization,and not repeatedly. Second, two-tier replication avoidssystem delusion [23]. Delusion occurs when large num-bers of replicas reconcile with each other repeatedly inthe absence of a master and consequently diverge furtherand further from each other.

The implementation of replication is not part ofone.world ’s kernel and makes extensive use of its coreprimitives. A replica is structured as shown in Figure 2(with the log environment also containing active com-ponents). The replicator interposes on the application’s

access to tuple storage. It logs updates in the log envi-ronment when in disconnected mode and forwards themto the master using REP when in connected mode. Onreconnection of a disconnected node, the log is sent tothe master by migrating a copy of the log environment.Similarly, updates are sent from the master to the replicaby migrating an environment containing such updates.

Our implementation has two important additionalfeatures over two-tier replication as described in [23].First, it allows for continuous operation during synchro-nization, thus improving usability. Second, the mas-ter and its replicas can migrate to different nodes with-out disrupting operation. Migrating the master is usefulwhen, for example, upgrading the computer the masteris running on; migrating a replica is useful for applica-tions that follow a user as she moves through the physi-cal world.

4.2 Events and Components

Control flow in one.world is expressed through asyn-chronous events that are processed by event handlers.Events are simply tuples. In addition to the ID and meta-data fields common to all tuples, events have a sourcefield referencing an event handler. This event handlerreceives notification of exceptional conditions duringevent delivery and processing as well as the response forrequest/response interactions. Furthermore, all eventshave a closure field. For request/response interactions,the closure of the request is returned with the response.Closures are useful for storing additional state neededfor processing responses and thus can simplify the im-plementation of event handlers. Event handlers imple-ment a uniform interface with a single method that takesthe event to be processed as its only argument. Eventdelivery has at-most-once semantics, both for local andremote event handling.

Application functionality is implemented by compo-nents, which import and export asynchronous event han-dlers. Components are instantiated within specific envi-ronments and, in their constructors, declare which eventhandlers they import and export. They can be linkedand unlinked at any time. An application’s main compo-nent has a static initialization method that instantiates itscomponents and performs the initial linking. While theapplication is running, it can instantiate additional com-ponents and relink and unlink components as needed.

To implement asynchronous event handling,each environment provides a queue of pending〈event handler, event〉 invocations as well as a pool ofone or more threads to perform such invocations. Whensending an event between components in different en-vironments, the corresponding event handler invocationis automatically enqueued in the〈event handler, event〉

Page 6: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

queue of the target environment. When sending anevent between components in the same environment,the event handler invocation is implemented as a directmethod call. This default can be overridden at link-time, so that event handlers in the same environmentuse the〈event handler, event〉 queue instead of directinvocations.

Remote event passing (REP) provides the ability tosend events to remote receivers. It supports both point-to-point communications and service discovery, includ-ing early and late binding [1], as well as anycast andmulticast, through only three simple operations:ex-port, send, and resolve. The export operation makesan event handler accessible from remote nodes througha symbolic descriptor. The resulting binding betweenthe event handler and descriptor is leased. Furthermore,when exporting an event handler for service discovery,the binding is propagated to the discovery server for thelocal network. Thesendoperation sends an event to pre-viously exported event handlers by using an exported de-scriptor or discovery query as the remote address. Whenusing late binding, the event is routed through the dis-covery server, where the discovery query is resolved.Otherwise, the event is sent directly to the node export-ing the targeted event handler. Finally, theresolveoper-ation looks up event handlers on the discovery server.

We chose to use asynchronous events instead of syn-chronous invocations for three reasons. First and fore-most, asynchronous events provide a natural fit for per-vasive computing, as applications often need to react toreal world events, such as a meeting being started or aperson leaving a room. Second, unlike threads, whichimplicitly store execution state in registers and on stacks,events make the execution state explicit. Systems canthus directly access execution state, which is useful forimplementing, for example, event priorization or check-pointing and migration. Finally, taking a cue from otherresearch projects [11, 24, 25, 36] that have successfullyused asynchronous events at very different points of thedevice space, we believe that asynchronous events scalebetter across different classes of devices than threads.

We chose a uniform event handling interface becauseit greatly simplifies composition and interposition. Forinstance, the uniform event handling interface enablesa flexible component model, which supports the linkingof any imported event handler to any exported event han-dler. Furthermore, it makes it possible to combine point-to-point communications and service discovery within asimple and narrow interface to REP. At the same time,the uniform event handling interface does not preventthe expression of typing constraints. When componentsdeclare the event handlers they import and export, theycan optionally specify the types of events sent to im-ported event handlers and processed by exported event

handlers.

4.3 The Environment Hierarchy

Environments are containers for stored tuples, compo-nents, and other environments and provide structure andcontrol in one.world . They provide structure by group-ing data and functionality, and they provide control bynesting environments within each other. At the sametime, environments always maintain a clear separationbetween data and functionality and do not hide them be-hind a unifying interface. The environment abstractionwas inspired by the ambient calculus [8]. Similar to en-vironments, ambients serve as containers for data, func-tionality, and other ambients. But, while ambients areformal constructs used to reason about mobile computa-tions, environments are actual entities in theone.worldarchitecture that are used to implement applications.

The grouping of data and functionality is relevantfor loading code, checkpointing, and migration. Inone.world , application code is represented as tuples andloaded from environments. Checkpointing captures theexecution state of an environment tree, including ap-plication components and pending〈event handler, event〉invocations, in the form of a tuple that is stored in theroot of the checkpointed environment tree. The envi-ronment tree can later be reverted by reading the tupleand restoring the execution state. Finally, migration pro-vides the ability to move or copy an environment tree,including all execution state and stored tuples, to a re-mote node.

Checkpointing and migration need to capture and re-store the execution state of an environment tree. Whencapturing execution state, our architecture first quiescesall environments, that is, it waits for all threads to returnto their thread pools. It then serializes the affected appli-cation state, notably all components in the environmenttree, and the corresponding environment state, notablythe 〈event handler, event〉 queues. When restoring exe-cution state,one.world first deserializes all applicationand environment state, then reactivates all threads, andfinally notifies applications that they have been restoredor migrated. During serialization, all references to eventhandlers outside the affected environment tree are nulledout. This includes links to components outside the treeor event handlers providing access to structured I/O. Ap-plications need to restore nulled out handlers themselvesby relinking or rebinding after restoration or migration.

The nesting of environments is relevant for the fol-lowing three features. First, environments can be iso-lated from each other and are subject to hierarchical re-source controls for CPU slices, memory, and tuple stor-age, similar to those described in [5, 43]. Second, logicto control checkpointing and migration can be separated

Page 7: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

into an outer environment, because checkpointing andmigration affect an entire environment tree. For exam-ple, a migration agent that knows how to follow a user asshe moves through the physical world can migrateanyapplication, simply by dynamically embedding the ap-plication in its environment. Third, interposition givesan outer environment complete control over an innerenvironment’s interactions with environments higher upthe hierarchy, includingone.world ’s kernel.

To an application, an environment appears to be aregular component. Each environment imports an eventhandler called “main”. This event handler must belinked to an application’s main component before theapplication can run in the environment. It is used byone.world to notify the application of important events,including that the environment has been activated, re-stored, or migrated, or that it is about to be terminated.

Each environment also exports an event handlercalled “request” and imports an event handler called“monitor”. Events sent to an environment’s requesthandler are delivered to the first ancestral environmentwhose monitor handler is linked. The root environ-ment’s monitor handler is linked toone.world ’s kernel,which processes requests for structured I/O, REP, andenvironment operations. Consequently, applications usethe request handler for interacting with the kernel. Fur-thermore, by linking to the monitor handler, an applica-tion can interpose on all events sent to a descendant’srequest handler. For example, the replicator in Figure 2can intercept the application’s binding request for tuplestorage by linking to its monitor handler. It can then re-turn an event handler that not only performs structuredI/O operations on the application’s tuple storage but alsologs these operations in the log environment (see Fig-ure 2). This use of therequest/monitor mechanismisillustrated in Figure 3.

To enforce the nesting of environments,one.worldlimits access to tuple storage and operations on environ-ments to the requesting environment and its descendants.When an application sends an event to its request han-dler, the event’s metadata is tagged with the identity ofthe requesting environment. Before granting access totuple storage or performing an operation on an environ-ment, the kernel verifies that the requesting environmentis an ancestor of the environment being operated on.

We chose a hierarchical arrangement for environ-ments because, while conceptually simple, it offersconsiderable flexibility and power. In particular, therequest/monitor mechanism makes interposition trivialand thus greatly simplifies dynamic composition as illus-trated above. Furthermore, because of the uniform eventhandler interface, the request/monitor mechanism is ex-tensible; it can handle new event types without requir-ing any changes. Finally, the same mechanism can be

app

monitor

request

main

monitor

request

main

replicator

Figure 3: Illustration of the request/monitor mechanism.Boxes on the left represent application components andboxes on the right represent environments. The app en-vironment is nested within the replicator environment.The replicator environment’s monitor handler is linkedand thus intercepts all events sent to the app environ-ment’s request handler. The use of the main handler isexplained in the text.

used to provide security by interposing a reference mon-itor [2] and auditing by logging an application’s requeststream. Its thus obviates the need for fixing a particularsecurity mechanism or policy inone.world ’s kernel.

We chose to null out references to outside eventhandlers during serialization because doing so exposeschange in environments. For migration, an alternativeapproach might redirect such event handlers to the orig-inal node. However, transparently redirecting event han-dlers creates residual dependencies and thus increasesan application’s exposure to failures, while also hidingthe cause of failures from the application. Furthermore,we argue that nulling out event handlers does not placean additional burden on developers, because applicationsalready need to be prepared to reacquire resources, forexample, to rebind a structured I/O resource because thelease has expired.

4.4 Implementation

We have implementedone.world largely in Java, whichprovides us with a safe and portable execution platform.We use a small, native library to generate GUIDs, as theycannot be correctly generated in pure Java. Furthermore,we use the Berkeley DB [35] to implement reliable tuplestorage. Our architecture currently runs on Windows andLinux PCs, and a port to Compaq’s iPAQ handheld com-puter is under way. The implementation ofone.world it-self has approximately 16,000 non-commenting source

Page 8: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

statements (NCSS) with an additional 5,400 NCSS forour replication layer. Our entire source tree, includingregression tests, benchmarks, and applications, has ap-proximately 44,000 NCSS. A Java archive file with thebinaries forone.world including replication is 675 KB.The GUID generation and Berkeley DB libraries requireanother 485 KB on Windows systems.

The implementation currently lacks support fortransactions and class loading from environments, aswell as isolation and resource controls. The implemen-tation of transactions and class loading from environ-ments should be straightforward. The implementationof isolation and resource controls can either be done inpure Java [13, 46], albeit at some performance cost, orby modifying the Java virtual machine [4, 5]. We planto implement these features in the near future. Further-more, we believe that their absence does not impact theoverall results presented in this paper. After all, we fo-cus on how to build adaptable applications for pervasivecomputing environments and not on how to provide pro-tection for language-based systems.

5 Evaluation

In this section, we present a thorough evaluation ofone.world . We first characterize the basic performanceof our architecture in Section 5.1. We follow with theresults of a case study on students usingone.world tobuild real applications in Section 5.2. We conclude withan evaluation of our own experiences with implementingreplication in Section 5.3. Overall, the results show thatone.world has acceptable performance and is a viableplatform for building pervasive applications. They alsosuggest that our architecture requires additional supportfor better structuring application code.

5.1 Basic Performance

To determine the basic performance ofone.world , wemeasured the performance of microbenchmarks for tu-ple storage, tuple communications, remote messaging,and migration. Where applicable, we compare the re-sults with microbenchmarks for the underlying storageand communication services as well as related technolo-gies, including IBM’s T Spaces 2.1.2 [49]. All mea-surements were performed using off-the-shelf PCs, withPentium III 800 MHz processors and 256 MB of RAM,running Windows 2000. The PCs are connected by a 100Mb switched ethernet. We use Sun’s HotSpot client vir-tual machine 1.3.0 and Sleepycat’s Berkeley DB 3.2.9.Reported results represent the average of 100 benchmarkruns.

Test BDB Serial BDB one.worldRead 0.24 0.88 1.23Write 25 25 25Query 44 640 860

Table 2: Latency of storage operations in milliseconds.Queries retrieve all stored tuples. BDB shows perfor-mance of the Berkeley DB without serialization, and Se-rial BDB shows performance of the Berkeley DB with se-rialization.

Test T Spaces one.worldRead 2.9 1.2Write 4.5 25Query 18 690

Table 3: Latency of storage operations in milliseconds.Queries are by field value and match 23 tuples on aver-age.

For tuple storage, we compare the performance ofstructured I/O with that of the Berkeley DB, the under-lying storage used by structured I/O. The Berkeley DBbenchmarks are performed both with and without seri-alization. We also compare the performance of struc-tured I/O with that of T Spaces, an in-memory tuplespace that uses periodic checkpointing for persistence.The microbenchmarks read, write, and query for tuplesrepresenting personal contacts (as might be used by apersonal information manager). All tests use a storewith 1,000 such tuples. Table 2 shows the results forthe comparison between structured I/O and the BerkeleyDB. Writes are dominated by the cost of forcing eachwrite to disk and thus perform the same in all cases. Theoverhead for structured I/O reads and queries over theBerkeley DB with serialization is a reasonable 40% andis likely due to the cost of switching threads during eventdelivery. Table 3 shows the results for the comparisonbetween structured I/O and T Spaces. Structured I/Ois in the same performance class as T Spaces for readsand writes. Writes are slower for structured I/O becausestructured I/O forces each write to disk, while T Spacesonly performs periodic checkpoints. Using similarly re-laxed durability for structured I/O, write latency drops to0.73 ms. Field queries perform considerably worse forstructured I/O, as we currently only index tuple IDs.

For tuple communications, we compare the perfor-mance of structured I/O with several other communica-tion methods. These benchmarks repeatedly send 100bytes of data from one node to another by sending a tu-ple containing a byte array or by sending the raw bytes.We use 100 bytes of data because overhead is more pro-nounced for small payload sizes. Table 4 shows the re-sults. Structured I/O over UDP and TCP each achieve

Page 9: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

Transport ThroughputDatagramIO 120UDP (tuples) 160UDP (bytes) 1,600NetworkIO 180TCP (tuples) 230TCP (bytes) 9,100T Spaces 24

Table 4: Networking throughput in kB/sec. DatagramIOis structured I/O over UDP, and NetworkIO is structuredI/O over TCP; the corresponding rows are highlighted.

System LatencyRMI 2.8REP 3.6

Table 5: Remote messaging latency in milliseconds.

throughput within 30% of sending tuples directly overthe underlying transport. However, this performance iswell below that of sending raw bytes over UDP and TCP.The overhead is due to the increased space required forserialized tuples and the low performance of Java seri-alization. Structured I/O achieves at least five times thethroughput of T Spaces. This comparison illustrates theeffects of conflicting requirements for tuple spaces. Onone side, tuple spaces are expected to provide long-termstorage for tuples. On the other side, tuple spaces arealso used for immediate communication. Structured I/Ostrikes a better balance between these requirements byseparating storage and communications but by also pro-viding a common interface.

For remote messaging, we compare the latency ofa request/response interaction using REP and Java’s re-mote method invocation (RMI). Both benchmarks sendan event to a remote node, where it is immediately sentback to the sender. For RMI, the event is the only argu-ment to the remote method and is returned as its result.The results in Table 5 show that the performance of REPis comparable to that of RMI, with REP suffering a 25%performance penalty.

For measuring the performance of migration, we use

Tuple count Move Latency0 0.39

100 0.71,000 2.7

10,000 23

Table 6: Migration latency in seconds. Tuple count is thenumber of tuples in the migrating application’s environ-ment.

a small application that repeatedly moves itself across aset of nodes in a tight loop; its environment contains avarying number of tuples. Just as with tuple communi-cations, we use tuples with 100 bytes of data becauseoverhead is more pronounced for small tuples. Table 6shows the average latency of a move from one node toanother, given a loop of three nodes. This benchmark ishard to compare with other mechanisms because of theuniqueness of our move primitive. However, we believethat its performance is reasonable, given the presence ofa human waiting for a migration to complete.

Overall, the results show thatone.world ’s primitiveshave reasonable performance, given the high cost of se-rialization. We plan to add indexing to our implementa-tion of tuple storage to improve the performance of fieldqueries. Furthermore, we are considering alternatives toreduce the overhead of serialization. Options include theuse of pre-serialized objects [48] and dynamic code gen-eration to specialize serialization.

5.2 Usability and Effectiveness

To evaluateone.world ’s usability and effectiveness forbuilding real applications, we conducted an experi-ment in the form of a senior-level undergraduate projectcourse. After ten introductory lectures, the nine studentsin the class split into two teams that developed a mu-sic sharing system and a universal inbox. Each teamsplit into two subteams, with one subteam using exist-ing Java-based technologies and the other subteam us-ing one.world . Since both subteams implemented thesame application, this experiment lets us compare our ar-chitecture with other approaches to building distributedsystems. The results presented here are based on weeklymeetings with the teams, end-of-term interviews, and theteams’ final presentations and reports.

The first team developed a music sharing system,which relies on a dynamically configured hierarchy ofdirectory nodes to organize searches. The Java sub-team implemented the application in plain Java, with-out using additional technologies. Results for the mu-sic sharing team are incomplete; students barely com-pleted the implementations, although they did demon-strate working applications. The students’ experiencessuggest that our architecture’s support for queries aspart of structured I/O and for asynchronous messagingthrough REP clearly simplified the implementation ontop of one.world . In contrast, the Java subteam im-plemented querying and asynchronous messaging fromscratch.

The second team developed a universal inbox, whichintegrates a home network of future smart appliances,such as an intelligent fridge, with email access from out-side the network. The universal inbox lets users access

Page 10: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

human-readable email, routes control messages to andfrom appliances, and provides a common data reposi-tory for email and appliance configuration state. TheJava version uses Jini [3] for service configuration and TSpaces [49] for storing repository data.

The students’ experiences support our argumentfrom Section 2 that extending programming models forsingle-node applications to distributed systems makes itdifficult to build adaptable applications. Jini relies onJava’s RMI to access remote resources and is designedto simplify the conversion of existing code into Jini ser-vices. The Java subteam exploited this and originallyimplemented individual services, such as the messagerouter or data repository, as stand-alone, single-node ap-plications. Students subsequently “jinified” the applica-tions and iteratively refined them as network services.While the conversion of an application into a bare-bonesJini service is simple, turning a minimal Jini service intoa full-blown Jini service is an arduous process. This re-finement process involved repeatedly testing the systemto identify potential failure conditions and then addingcode to account for such conditions. Students also hadto work around the synchronous design of RMI. WhileJini includes support for remote events, they are imple-mented as synchronous invocations through RMI andthus expose services to possibly indefinite delays, for ex-ample, because the service receiving an event is buggyand hangs. The completed implementation still reflectsthe difficulties of the refinement process and has rela-tively few services, with each of these services repre-senting a single point of failure for all users.

In contrast, theone.world subteam found our archi-tecture’s primitives well matched to their needs. In par-ticular, local tuple storage, REP’s support for late bind-ing, and the signaling of exceptional conditions throughregular events simplified the implementation. As a re-sult, the completed implementation does not require acentralized data repository and separates each user’semail management into an independently running ser-vice. The biggest challenge for theone.world subteamwas managing asynchrony: the highly structured, event-based programming model clearly exposed failures andforced students to consider appropriate failure of recov-ery strategies from the beginning. From a software engi-neering viewpoint, the students found that componentsrequired too much repetition and that event handlershandling several types of events were not very modular.They thus created several abstract components to avoidcode repetition and facilities for dynamic event dispatchto make event handlers more modular. This suggests thatour architecture requires better support for avoiding coderepetition and for structuring event handlers, such as thedispatch facilities provided by MultiJava [12].

5.3 Replication Case Study

Since our replication layer (see Section 4.1) is not part ofone.world ’s kernel, we used the process of implementingit as a case study on how to structure applications in ourarchitecture. The implementation makes extensive useof one.world ’s core features and illustrates the power ofa design that follows the three principles presented inSection 2:

1. Expose change. The consistent use of leasescleanly exposes change, such as a replica gettingdisconnected from the master.

2. Compose dynamically. The nesting of environ-ments makes it easy to dynamically compose func-tionality. In particular, the request/monitor mech-anism let us interpose replication on an applica-tion’s tuple storage. Furthermore, we used the samemechanism for communication between migratedlog environments and the master.

3. Separate data and functionality. The separation ofdata and functionality provides considerable flexi-bility. Since events are tuples, we directly loggedstructured I/O events on the replica. Furthermore,it was easy to support application-specific reconcil-iation, simply by adding the corresponding compo-nent to the log environment.

Additionally, migration and REP provide powerfulprimitives that cover the spectrum between collocationand remote interaction. On one side, we relied on mi-gration to colocate a replica’s log with the master duringreconciliation; on the other side, we used REP duringconnected operation.

Figure 4 illustrates the performance of a replica un-der changing network conditions. We measure the per-formance of a benchmark that repeatedly writes a tuplein a tight loop, and use the same experimental set-up asin Section 5.1. The replica starts in disconnected modeand logs all updates locally. When the replica discoversthe master, it copies the log to the master and reconcil-iation begins (1). Throughput drops while the replica isconnected to the master because updates are forwardedto the master. After reconciliation has completed, themaster begins copying updates destined for the replicainto a separate response environment (2). After the re-sponse environment has arrived at the replica and itsupdates have been applied, the replica enters connectedmode and starts to purge old log entries (3). When purg-ing is complete, throughput improves slightly (4). Fi-nally, the master becomes disconnected again (5), andthe replica returns to disconnected mode (6).

Page 11: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

0

5

10

15

20

0 50 100 150 200 250 300

1 2 3 4 5 6T

hrou

ghpu

t (w

rites

/sec

)

Time (seconds)

Figure 4: Performance of a replica under changing network conditions. The replica starts in disconnected mode anddiscovers the master at point 1. It becomes disconnected again at point 5 and re-enters disconnected mode at point 6.The other points are explained in the text. Throughput is generally limited by structured I/O forcing each write to disk.

5.3.1 The Logic/Operation Pattern

During development ofone.world , one important con-cern was how to write applications in the face of consid-erable uncertainty. Since access to resources is leased,most operations may fail and an application must beprepared to adequately react to such failures. In ourexperience, established styles of event-based program-ming, such as state machines, are only manageable forvery simple applications. The single biggest challengein implementing replication was deciding how to appro-priately react to failures and how to structure the corre-sponding failure recovery code. After some experimen-tation, we found the following approach, which we callthe logic/operation pattern, particularly successful.

Under the logic/operation pattern, an application ispartitioned into logic and operations, which are imple-mented by separate sets of event handlers. Logic arecomputations that do not fail, barring catastrophic fail-ures. Operations are interactions that may fail, such asreading a tuple or sending a remote message. The im-plementation of operations includes all necessary failuredetection and recovery code. For example, when read-ing a tuple, the corresponding operation rebinds if thelease for tuple storage has expired. It also sets a timeoutand retries if the timeout expires. A failure condition isreflected to the appropriate logic only if recovery failsrepeatedly or the failure condition cannot be recoveredfrom in a general way.

Event handlers for logic and operations can easilybe composed with each other. Figure 5, for exam-ple, illustrates a structuring reminiscent of an if-then-else construct. Other possible structurings include go-tos and loops. More importantly, the sequence of logicand operations in the figure itself constitutes an opera-tion and can be used just like a basic operation. The

while (! success) if (expired lease) acquire lease; set timeout; put tuple;send result;

if (out of seqNo) alloc seqNo; write seqNo;else write log;

write log;

Done

write log

write log

write seqNo

Figure 5: An example of the logic/operation pattern,which writes a log record and, if necessary, also allocatesadditional sequence numbers. Boxes represent logic;the pseudo-code shows how operations are invoked bylogic. Arrows represent operations, which include nec-essary failure recovery code. The call-out illustrates theimplementation of the operations.

logic/operation pattern thus approximates a function callin traditional programming languages and provides pro-grammers with a familiar framework for building com-plex applications inone.world . At the same time, use ofthe logic/operation pattern does not relieve developersfrom deciding on appropriate failure recovery strategiesand correctly implementing an application’s logic.

6 Future Work

Future work onone.world will focus on three areas: thecore architecture, support for debugging, and applica-tions. As discussed in Section 4.4, our implementation

Page 12: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

currently lacks support for transactions and class load-ing from environments, as well as isolation and resourcecontrols. We plan to implement these features in the nearfuture and also add support for indexing to tuple storage(see Section 5.1). More importantly, having identifiedthe logic/operation pattern as a viable way to structureapplications in our architecture, we will integrate it intothe core architecture. We will also build a library ofcommon operations that can be parameterized by failurerecovery strategy.

While debugging distributed applications is difficultenough, debugging applications inone.world is evenharder due to its asynchronous programming model andinadequate support for tracing application events. Ourarchitecture logs unhandled events, including a stacktrace, and provides a runtime option to log all kernelevents. Additionally, both we and the students in ourcase study have made extensive use of the debug-by-printf approach to log relevant application events. How-ever, instrumenting applications to log events is cum-bersome. Furthermore, analyzing event logs is hard be-cause, in an asynchronous system, events may be re-ordered and causal relationships may not be obviousfrom the log. Therefore, we plan to add better debuggingsupport toone.world . The request/monitor mechanismlets us easily interpose a debugger on an application,and events can already be annotated with metadata, mak-ing it possible to track causal relationships even acrossnodes.

Finally, to gain more experience with our architec-ture, we plan to build additional applications. We willfocus on applications that actually enhance our own pro-ductivity, for example, by better integrating our comput-ing environments at home and at work. Furthermore, weplan to collaborate with other researchers and supportthem in building their own pervasive applications on topof one.world . To this end, we distribute source releasesof our architecture and will hold workshops. One re-search group is already usingone.world to implement apervasive environment for a biology laboratory.

7 Related Work

one.world relies on several technologies that have beensuccessfully used by other systems. The main differ-ence is that our architecture integrates these technolo-gies into a simple and comprehensive framework tar-geted at the pervasive computing space. Leases havebeen used to control write access to cached files [22],access to remote resources in general [3], and even thelifetime of stored objects [21]. Starting with Linda, tu-ple spaces have been used to enable coordination be-tween loosely coupled services [9, 21, 49]. The Informa-

tion Bus provides similar functionality based on a pub-lish/subscribe paradigm [34]. While it nominally usesobjects, exchanged information is represented by self-describing data objects, which are similar to tuples inone.world . Asynchronous events have been used acrossa wide spectrum of systems, including networked sen-sors [25], embedded systems [11], user interfaces [38],and large-scale servers [24, 36]. Finally, several projectshave investigated the use of service discovery to simplifythe configuration of distributed systems [1, 3, 14].

A significant number of projects have explored mi-gration in distributed systems [33]. Notable examplesinclude migration at the operating system level, as pro-vided by Sprite [16], and at the programming languagelevel, as provided by Emerald [27, 39]. In these sys-tems, providing support for a uniform execution envi-ronment across all nodes and migration of applicationand execution state has resulted in considerable com-plexity. In contrast, many mobile agent systems, such asIBM’s aglets [29], avoid this complexity by implement-ing what we call “poor man’s migration”. They do notprovide transparency and only migrate application stateby serializing and deserializing an agent’s objects. Be-cause of its programming model,one.world can strike abetter balance between the complexity of fully featuredmigration and the limited utility of poor man’s migra-tion. While one.world does not provide transparency, itdoes migrate an application’s persistent data. Further-more, its use of asynchronous events greatly simplifiesthe migration of execution state.

Several efforts, including Globe [44], Globus [19],and Legion [32], are exploring an object-oriented pro-gramming model and infrastructure for wide area com-puting. They share the important goal of providinga common execution environment that is secure andscales across a global computing infrastructure. How-ever, by extending models for distributed computingoriginally developed for small and relatively static com-puter networks, these systems are too heavyweight andnot adaptable enough for pervasive computing environ-ments. Furthermore, as argued in Section 2, we believethat their reliance on objects to encapsulate data andfunctionality is ill-advised.

Several other projects are exploring aspects of sys-tems support for pervasive computing. Notably, In-Concert, the architectural component of Microsoft’s Ea-syLiving project [7], provides service composition in adynamic environment by using location-independent ad-dressing and asynchronous event passing. The Paths sys-tem [28] allows diverse services to communicate in ad-hoc networks by dynamically instantiating mediators tobridge between the services’ data formats and protocols.

Page 13: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

8 Conclusions

In this paper, we have identified three principles forstructuring systems support for pervasive computing en-vironments. First, systems need to expose change, sothat applications can implement their own strategies forhandling changes. Second, systems need to make it easyto compose applications and services dynamically, sothat they can be extended at runtime. Third, systemsneed to separate data and functionality, so that they canbe managed separately and so that they can evolve inde-pendently.

We have introduced a system architecture for per-vasive computing, calledone.world , that adheres tothese principles. Our architecture uses leases to ex-pose change. It uses nested environments as well aslate binding to dynamically compose applications. Itcleanly separates data and functionality: tuples repre-sent data and components implement functionality. Ad-ditionally, our architecture provides a set of powerfulservices, namely migration, remote messaging, replica-tion, and checkpointing, that serve as building blocksfor pervasive applications. Our evaluation ofone.worldshows that our architecture is a viable platform for build-ing adaptable applications. More information on ourarchitecture, including a source release, is available athttp://one.cs.washington.edu .

Acknowledgments

We thank Ben Hendrickson for implementing parts ofthe storage subsystem. We thank Vibha Sazawal andDavid Notkin for their advise and assistance in our com-parative evaluation ofone.world and the students of Uni-versity of Washington’s CSE 490dp course for servingas test subjects. We thank Mike Swift for his valuablecomments on an earlier version of this report.

References

[1] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, andJ. Lilley. The design and implementation of an inten-tional naming system. InProceedings of the 17th ACMSymposium on Operating Systems Principles, pages 186–201, Dec. 1999.

[2] J. P. Anderson. Computer security technology planningstudy. Technical Report ESD-TR-73-51, Vol. I, Elec-tronic Systems Division, Air Force Systems Command,Bedford, Massachusetts, Oct. 1972. Also AD-758 206,National Technical Information Service.

[3] K. Arnold, B. O’Sullivan, R. W. Scheifler, J. Waldo, andA. Wollrath. The Jini Specification. Addison-Wesley,1999.

[4] G. Back, W. C. Hsieh, and J. Lepreau. Processes inKaffeOS: Isolation, resource management, and sharingin Java. InProceedings of the 4th USENIX Symposiumon Operating Systems Design and Implementation, pages333–346, Oct. 2000.

[5] G. Back, P. Tullmann, L. Stoller, W. C. Hsieh, and J. Lep-reau. Techniques for the design of Java operating sys-tems. InProceedings of the 2000 USENIX Annual Tech-nical Conference, pages 197–210, June 2000.

[6] P. Brinch Hansen. The nucleus of a multiprogrammingsystem. Communications of the ACM, 13(4):238–241,250, Apr. 1970.

[7] B. Brumitt, B. Meyers, J. Krumm, A. Kern, and S. Shafer.EasyLiving: Technologies for intelligent environments.In Proceedings of the 2nd International Symposiumon Handheld and Ubiquitous Computing, pages 12–29,Sept. 2000.

[8] L. Cardelli. Abstractions for mobile computations. InVitek and Jensen [45], pages 51–94.

[9] N. Carriero and D. Gelernter. The S/Net’s Linda kernel.ACM Transactions on Computer Systems, 4(2):110–129,May 1986.

[10] A. Chankhunthod, P. B. Danzig, C. Needaels, M. F.Schwartz, and K. J. Worrell. A hierarchical Internet ob-ject cache. InProceedings of the 1996 USENIX AnnualTechnical Conference, pages 153–163, Jan. 1996.

[11] P. Chou, R. Ortega, K. Hines, K. Partridge, and G. Bor-riello. ipChinook: An integrated IP-based design frame-work for distributed embedded systems. InProceedingsof the 36th ACM/IEEE Design Automation Conference,pages 44–49, June 1999.

[12] C. Clifton, G. T. Leavens, C. Chambers, and T. Millstein.MultiJava: Modular open classes and symmetric multipledispatch for Java. InProceedings of the ACM Conferenceon Object-Oriented Programming Systems, Languages,and Applications ’00, pages 130–145, Oct. 2000.

[13] G. Czajkowski and T. von Eicken. JRes: A resourceaccounting interface for Java. InProceedings of theACM Conference on Object-Oriented Programming Sys-tems, Languages, and Applications ’98, pages 21–35,Oct. 1998.

[14] S. E. Czerwinski, B. Y. Zhao, T. D. Hodes, A. D. Joseph,and R. H. Katz. An architecture for a secure service dis-covery service. InProceedings of the 5th ACM/IEEE In-ternational Conference on Mobile Computing and Net-working, pages 24–35, Aug. 1999.

[15] M. L. Dertouzos. The future of computing.ScientificAmerican, 281(2):52–55, Aug. 1999.

[16] F. Douglis and J. Ousterhout. Transparent process mi-gration: Design alternatives and the Sprite implemen-tation. Software—Practice and Experience, 21(8):757–785, Aug. 1991.

[17] M. Esler, J. Hightower, T. Anderson, and G. Borriello.Next century challenges: Data-centric networking for in-visible computing. InProceedings of the 5th ACM/IEEE

Page 14: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

International Conference on Mobile Computing and Net-working, pages 256–262, Aug. 1999.

[18] B. Ford, M. Hibler, J. Lepreau, P. Tullmann, G. Back,and S. Clawson. Microkernels meet recursive virtual ma-chines. InProceedings of the 2nd USENIX Symposiumon Operating Systems Design and Implementation, pages137–151, Oct. 1996.

[19] I. Foster and C. Kesselman. Globus: A metacomputinginfrastructure toolkit. International Journal of Super-computer Applications and High Performance Comput-ing, 11(2):115–128, 1997.

[20] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer, andP. Gauthier. Cluster-based scalable network services. InProceedings of the 16th ACM Symposium on OperatingSystems Principles, pages 78–91, Oct. 1997.

[21] E. Freeman, S. Hupfer, and K. Arnold.JavaSpaces Prin-ciples, Patterns, and Practice. Addison-Wesley, 1999.

[22] C. G. Gray and D. R. Cheriton. Leases: An efficientfault-tolerant mechanism for file cache consistency. InProceedings of the 12th ACM Symposium on OperatingSystems Principles, pages 202–210, Dec. 1989.

[23] J. Gray, P. Helland, P. O’Neil, and D. Shasha. The dan-gers of replication and a solution. InProceedings of the1996 ACM SIGMOD International Conference on Man-agement of Data, pages 173–182, June 1996.

[24] S. D. Gribble, E. A. Brewer, J. M. Hellerstein, andD. Culler. Scalable, distributed data structures for in-ternet service construction. InProceedings of the 4thUSENIX Symposium on Operating Systems Design andImplementation, pages 319–332, Oct. 2000.

[25] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, andK. Pister. System architecture directions for networkedsensors. InProceedings of the 9th ACM InternationalConference on Architectural Support for ProgrammingLanguages and Operating Systems, pages 93–104, Nov.2000.

[26] K. L. Johnson, J. F. Carr, M. S. Day, and M. F.Kaashoek. The measured performance of content dis-tribution networks. InProceedings of the 5th Inter-national Web Caching and Content Delivery Workshop,May 2000.http://www.terena.nl/conf/wcw/Proceedings/S4/S4-1.pdf .

[27] E. Jul, H. Levy, N. Hutchinson, and A. Black. Fine-grained mobility in the Emerald system.ACM Trans-actions on Computer Systems, 6(1):109–133, Feb. 1988.

[28] E. Kiciman and A. Fox. Using dynamic mediation tointegrate COTS entities in a ubiquitous computing envi-ronment. InProceedings of the 2nd International Sym-posium on Handheld and Ubiquitous Computing, Sept.2000.

[29] D. B. Lange and M. Oshima.Programming and Deploy-ing Java Mobile Agents with Aglets. Addison Wesley,1998.

[30] A. Le Hors, P. Le Hegaret, L. Wood, G. Nicol, J. Robie,M. Champion, and S. Byrne. Document object model

(DOM) level 2 core specification. W3C recommenda-tion, World Wide Web Consortium, Nov. 2000.

[31] P. J. Leach and R. Salz. UUIDs and GUIDs. InternetDraft draft-leach-uuids-guids-01.txt, Internet Engineer-ing Task Force, Feb. 1998.

[32] M. Lewis and A. Grimshaw. The core Legion objectmodel. InProceedings of the Fifth IEEE InternationalSymposium on High Performance Distributed Comput-ing, pages 551–561, Aug. 1996.

[33] D. Miloji cic, F. Douglis, and R. Wheeler, editors.Mobility—Processes, Computers, and Agents. ACMPress. Addison-Wesley, Feb. 1999.

[34] B. Oki, M. Pfluegl, A. Siegel, and D. Skeen. The Infor-mation Bus — an architecture for extensible distributedsystems. InProceedings of the 14th ACM Symposium onOperating Systems Principles, pages 58–68, Dec. 1993.

[35] M. A. Olson, K. Bostic, and M. Seltzer. Berkeley DB. InProceedings of the FREENIX Track, 1999 USENIX An-nual Technical Conference, pages 183–192, June 1999.

[36] V. S. Pai, P. Druschel, and W. Zwaenepoel. Flash: Anefficient and portable Web server. InProceedings of the1999 USENIX Annual Technical Conference, pages 199–212, June 1999.

[37] K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer,and A. J. Demers. Flexible update propagation forweakly consistent replication. InProceedings of the16th ACM Symposium on Operating Systems Principles,pages 288–301, Oct. 1997.

[38] C. Petzold.Programming Windows. Microsoft Press, 5thedition, Nov. 1998.

[39] B. Steensgaard and E. Jul. Object and native code threadmobility among heterogeneous computers. InProceed-ings of the 15th ACM Symposium on Operating SystemsPrinciples, pages 68–77, Dec. 1995.

[40] D. B. Terry, M. M. Theimer, K. Petersen, A. J. Demers,M. J. Spreitzer, and C. H. Hauser. Managing updateconflicts in Bayou, a weakly connected replicated stor-age system. InProceedings of the 15th ACM Symposiumon Operating Systems Principles, pages 172–183, Dec.1995.

[41] R. Tewari, M. Dahlin, H. M. Vin, and J. S. Kay. Designconsiderations for distributed caching on the Internet. InProceedings of the 19th IEEE International Conferenceon Distributed Computing Systems, pages 273–284, June1999.

[42] T. Thorn. Programming languages for mobile code.ACMComputing Surveys, 29(3):213–239, Sept. 1997.

[43] P. Tullmann and J. Lepreau. Nested Java processes:OS structure for mobile code. InProceedings of the8th ACM SIGOPS European Workshop, pages 111–117,Sept. 1998.

[44] M. van Steen, P. Homburg, and A. S. Tanenbaum. Globe:A wide-area distributed system.IEEE Concurrency,7(1):70–78, 1999.

Page 15: Programming for Pervasive Computing … for Pervasive Computing Environments Robert Grimm, Janet Davis, Eric Lemar, Adam MacBeth, Steven Swanson, Steven Gribble, Tom Anderson,

[45] J. Vitek and C. D. Jensen, editors.Secure Internet Pro-gramming: Security Issues for Distributed and MobileObjects, volume 1603 ofLecture Notes in Computer Sci-ence. Springer-Verlag, 1999.

[46] T. von Eicken, C.-C. Chang, G. Czajkowski, C. Haw-blitzel, D. Hu, and D. Spoonhower. J-Kernel: acapability-based operating system for Java. In Vitek andJensen [45], pages 369–393.

[47] M. Weiser. The computer for the twenty-first century.Scientific American, 265(3):94–104, Sept. 1991.

[48] M. Welsh and D. Culler. Jaguar: Enabling efficient com-munication and I/O in Java.Concurrency: Practice andExperience, 12(7):519–538, June 2000.

[49] P. Wyckoff, S. W. McLaughry, T. J. Lehman, and D. A.Ford. T Spaces.IBM Systems Journal, 37(3):454–474,1998.