Structured Decomposition of Adaptive Applications

Justin Mazzola Paluska, Hubert Pham, Umar Saif,∗

Grace Chau, Chris Terman, and Steve Ward{jmp,hubert,mpchau,cjt,ward}@mit.edu

MIT Computer Science and Artificial Intelligence Laboratory, Cambridge, MA, U.S.A.∗umar@lums.edu.pk

LUMS Computer Science Department, Lahore, Pakistan

Abstract

We describe an approach to automate certain high-level implementation decisions in a pervasive appli-cation, allowing them to be postponed until run time.Our system enables a model in which an applicationprogrammer can specify the behavior of an adaptiveapplication as a set of open-ended decision points. Weformalize decision points as Goals, each of which maybe satisfied by a set of scripts called Techniques. Theset of Techniques vying to satisfy any Goal is additiveand may be extended at runtime without needing tomodify or remove any existing Techniques. Our systemprovides a framework in which Techniques may com-pete and interoperate at runtime in order to maintainan adaptive application. Technique development maybe distributed and incremental, providing a path for thedecentralized evolution of applications. Benchmarksshow that our system imposes reasonable overheadduring application startup and adaptation.

1. Introduction

Ubiquitous and pervasive computing environmentsare characterized by a richness and heterogeneity ofresources far greater than traditional computing envi-ronments. In addition to the variety of devices, thereis a high turn-over rate as existing devices leave theenvironment, either due to failure or voluntary with-drawal when new, potentially better, devices enter theenvironment. Applications executing in ubiquitous en-vironments are expected to discover relevant resources,evaluate resources, and monitor utilized resources forfailure.

Therefore, the ability to somehow adapt to newsituations is a key requirement of applications in theseenvironments. In particular, such adaptive systemsshare two main requirements:

1) They must be able to make implementation de-cisions at runtime, rather than at design-time orcompile-time.

2) They must be able to consider new informationat runtime and potentially revise previously madeimplementation decisions.

In traditional applications, these requirements man-ifest themselves as a monitor loop that discoverschanges in the computing environment (such as newcomponents or changes in the status of already knowncomponents) and a set of application-specific decisionfunctions that choose what combinations of compo-nents are appropriate. While the application program-mer may use design patterns, recursive decomposition,or other design techniques to encode decision logic,the problem remains that whatever code ships with theapplication enumerates all known ways of adapting theprogram.

1.1. Examples of Adaptive Systems

Much systems-level work in the pervasive and ubiq-uitous computing field strives to replace application-level decision logic with application-level dependencydeclarations. In these systems, application program-mers declare “what” they need and a runtime systemdetermines “how” to satisfy each requirement. For ex-ample, INS [1] and other systems like it [2], [3] provideintentional sockets whose descriptions are resolved bythe network layer. Intentional sockets provide extensi-ble decision logic because new services can be addedthat match existing intentional names.

Above the network layer, component systems likePCOM [4] or RUNES [5] allow programmers to de-clare dependencies as COM- and CORBA-like interfaceswhile runtime systems discover and match appropriatecomponents to the required interfaces. In PCOM, com-ponents can depend on other components — allowinga form of hierarchical decomposition of application

functionality — and provide component-specific codethat aids in resource selection.

1.2. Additional Requirements

The approaches to adaptivity represented by theseexample systems share the characteristic that the rangeof possible choices — e.g. of candidate devices andways in which they are used — is embedded in codeat either the application or system level. Extension ofapplication behavior requires modifying existing code,which in turn demands privileged access to the code tobe modified. The constraint of adaptive behavior to thatanticipated by a centrally-maintained codebase limitsthe evolution of adaptivity, and hence ultimately limitsadaptivity itself.

This deficiency led us to realize an additional, subtle,requirement for pervasive applications:

3) Decision-making logic must be open-ended.Adding a new device or implementation choiceto the environment should not require modifica-tion of already-existing code in the system.

In the rest of this paper, we explore a model foropen-ended decision logic as a means of programmingadaptive applications.

1.3. Open-ended Decision Making

Our work focuses on providing application program-mers with a way of managing implementation deci-sions and component writers with an extensible wayof expressing particular implementation plans in a waythat allows extensible, but domain-specific, evaluationof alternatives.

Our system relies on two main concepts. First, Goalsexplicitly identify certain critical implementation de-cision points, as well as describe the problem to besolved by the selected implementation choice. Second,Techniques are scripts describing alternative ways ofsatisfying Goals. Techniques serve two purposes: (1)they provide indirection between the known Goalsinterface and wide variety of hardware and softwareinterfaces we would like to use and (2) they implementdomain-specific evaluation code that lets our systemcompare alternative Techniques.

Our approach offers three salient features:1) Hierarchical Decomposition with Extensible

Constrained Evaluation Techniques may de-clare multiple prerequisite sub-Goals but providecode that constrains how the Planner chooses tosatisfy the sub-Goals.

2) An Additive Universe of Code Modules NewTechniques can be added to the system without

needing to change existing code, aiding the in-troduction of new device classes and new imple-mentation strategies.

3) Separation of Decision Logic from Compo-nents Techniques are separate from the com-ponents they describe, allowing both to evolveindependently.

In addition to these points, our architecture includestwo details aimed at lowering user-perceived latency:we allow incremental evaluation of decision logic,which permits our system to make decisions on earlyestimates of component performance, and we cachedecision-making, which lets our system react to typicalcomponent failures and re-plan in less than 250 ms.

2. Programming Model

Goals are bound to Techniques at runtime by thePlanner. Application programmers use the Planner tomanage adaptive state, while component programmerswrite Techniques interpreted by the Planner.

2.1. Goals and Goal Properties

A Goal is an abstraction of a parameterized decisionpoint that describes what functionality is needed with-out specifying how to implement that functionality.The Goal’s parameters serve to restrict the semanticsof the Goal, e.g., reducing a generic “play any movie”Goal to the playing of a particular movie specifiedby the name parameter. An application asserts a Goal(with bound parameters) when the application needs tohave a certain condition maintained by the Planner.

Concretely, a Goal refers to a specification file thatdescribes the formal parameters of the Goal as well aswhat Properties any Technique that satisfies the Goalmust provide. Properties are simple key-value pairsthat describe qualities of the implementations behindthe Goal. The Planner uses Properties to compareTechniques competing to satisfy the same Goal.

We adopt standard procedural syntax for the param-eterization and assertion of Goals; thus, a Goal maybe viewed as a disembodied generic procedure whoseparameters, Properties, and behavior are described byits specification. The assertion of a Goal may similarlybe viewed as an invocation of the disembodied proce-dure, leaving to the Planner the task of locating anappropriate body of code (Technique) to be executedin order to satisfy the Goal.

2.2. Techniques

A Technique is a small script mixing declarativeand arbitrary imperative code broken up into a series

1 to PlayMovie(name, language): via RTPStreams:23 ##### Exploratory Stages #####4 subgoals:5 source = RTPAVSource(goal.name, goal.language)6 sink = RTPAVSink()78 eval:9 # check for compatibility

10 if (subgoals.source.stream format not in11 subgoals.sink.supported stream formats):12 planner. fail ()13 eval:14 # set properties this combination will provide15 props.resolution = min(subgoals.source.resolution,16 subgoals.sink.resolution)17 props.screen size = subgoals.sink.screen size18 props.stream format = subgoals.source.stream format19 props. bitrate = subgoals.source.bitrate2021 ##### Commit Stages #####22 exec:23 subgoals.sink.resource.enqueue(uri=subgoals.source.uri)2425 update source from old source:26 subgoals.sink.resource.stop(subgoals.old source.uri)27 subgoals.sink.resource.enqueue(subgoals.source.uri)2829 shutdown:30 subgoals.sink.resource.quit ()

Listing 1. A Technique that satisfies the PlayMovieGoal by linking an RTP source stream to an RTPoutput device.

of stages. Techniques are not appropriate for directlyimplementing application functionality; instead, theyare used to wrap existing code modules and resourcesso that the Planner can use and compare these re-sources. Listing 1 shows one Technique that satisfiesthe PlayMovie Goal by connecting an RTP source to anRTP output device.

A Technique’s stages may include:

1) Sub-Goal Declarations Sub-Goals are sub-decision-points that must be satisfied for theTechnique to succeed. They are declared in sub-goals stages and provide a simple way of hierar-chically decomposing application functionality.

2) Evaluation Code eval stages compute the valueof the resources or strategies that the Techniquerepresents and export its computations as Proper-ties. eval stages may contain arbitrary code but,since they might be re-run as the environmentchanges, they must be idempotent.

3) Commit Code Commit stages configure andinstantiate, update, and shutdown applicationcomponents.

The stages are run (and potentially re-run) in a sched-ule determined by the Planner, subject to the constraintthat a stage cannot run before all of its predecessorshave run at least once. When the last evaluation stage

1 plan = Planner.plan(”PlayMovie”, name=”SimpsonsMovie”)2 # ”plan” is the object containing the Goal Tree for the3 # top−level Goal explored in this thread.4 while plan.is running ():56 # explore() blocks until a viable Plan is found7 new snapshot = plan.explore()89 # if the new plan is better or if the current plan has

10 # failed , commit to the new plan.11 if is better (new snapshot):12 if plan.is running ():13 # update something already running14 plan.update()15 else:16 # Start a new implementation17 plan.commit()1819 # Continue to the next iteration of the while loop to20 # see if anything has changed.

Listing 2. Application code from a movie playerthat uses the Planner.

Figure 1. A partially explored Goal Tree for thePlayMovie Goal. Yellow boxes are Goals and showthe Goal parameters. Red circles are Techniquesand are displayed with their exported Properties.Thick lines represent the chosen Plan for the Play-Movie Goal.

completes, the Planner considers the Technique readyfor commitment. Techniques may have many subgoalsand eval stages, allowing the Technique programmer toincrementally estimate and refine Property values.

2.3. Goal Lifecycles and the Planner

Applications invoke the Planner and are responsiblefor deciding when the Planner may make changesto the application’s runtime configuration. Listing 2shows typical application code while Figure 1 illus-trates how the Planner expands the PlayMovie Goal.

In Listing 2, an application first asks the Planner toassert a Goal; in return the application gets a handleto the planning process associated with that Goal.

Next, the application asks the Planner to explore() thepossible ways of satisfying the Goal.

2.3.1. Goal Exploration. Goal exploration consists ofbuilding a Goal Tree and evaluating Techniques. ThePlanner builds the Goal Tree by finding Techniquesthat satisfy the asserted Goals and recursively matchingthe sub-Goals of each Technique it finds. Figure 1illustrates the Goal Tree for a top-level PlayMovie Goal.

The Goal Tree represents all known strategies forimplementing the top-level Goal. A “path” from theroot Goal node to leaf Techniques represents a par-ticular strategy that implements the Goal. The GoalTree is an and-or tree: a Goal can be satisfied by anychild Technique, but a Technique requires satisfactionof all of its sub-Goals. The Planner runs Techniqueeval stages to extract Properties from each Technique.These properties allow the Planner to heuristicallychoose a “best” Technique, called the chosen Tech-nique, for each Goal. In Figure 1, the bold-facedpath shows the chain of chosen Techniques that bestimplement the top-level PlayMovie Goal. We call thisbest path the Plan for the Goal.

Although the Planner is required to make heuris-tic choices among the Techniques competing to sat-isfy each Goal in the tree, it does so by a simple,application-generic process that maps Property valuesreported by each Technique to a single scalar value;the chosen Technique is simply the Technique thatmaximizes this value. (Section 3.1 elaborates on thisprocess.) The actual heuristics and application-specificpolicies are dictated by Goal specifications and Tech-nique code, allowing the evolution of these relativelytransient aspects of the system without changes to thePlanner or the system architecture surrounding it.

2.3.2. Goal Commitment. If a Plan is found, theapplication may ask the Planner to commit the Plan.Commitment of the Plan proceeds by running the execstages of chosen Techniques in a bottom-up fashion.This way, the exec stages of higher-level Techniquescan rely on already-configured components supplied bylower-level Techniques. Techniques whose exec stageshave been run are said to be committed. After commit-ment, the application may continue to call explore() tocause the Planner to explore, expand, and update itsGoal Tree without affecting the committed Plan.

2.3.3. Goal Monitoring and Shutdown. Once gen-erated, the Goal Tree serves as a cache of availableimplementation strategies: startup, failover, upgrade,or shutdown of components in the system simply be-comes the activation or deactivation of branches of the

Goal Tree. The Planner updates the Goal Tree cachefor as long as the top-level Goal is active, permittingrapid re-evaluation of alternative implementations of aGoal throughout the lifetime of the top-level Goal.

The application may also modify the arguments tothe Goal to better reflect its changing needs. If a newset of Techniques better satisfies the Goal than thecurrent Plan or if a Technique in the current Plan fails,the Planner notifies the application, which may askthe Planner to upgrade the currently committed Plan.The application has complete control over the upgradeprocess so that upgrades do not happen at sensitivetimes.

When the application decides to quit, it tells thePlanner to shutdown the Goal: the shutdown stages ofcommitted Techniques are called, and the Goal Tree isgarbage collected.

3. Architecture

Our system allows (1) an additive universe of Tech-niques, (2) appropriate selection of Techniques withinter-dependent sub-Goals, (3) runtime adaptivity, and(4) separation of decision logic from components with-out restricting the open-ended nature of Goals.

3.1. Additivity

We deliberately avoid constraints on the set ofTechniques applicable to each Goal in order to supporta conceptual model of that set as a strictly “addi-tive” universe. Each Technique describes a way ofachieving some Goal — a way which may becomeunused (either because its sub-Goals fail or becausecompeting Techniques promise better results) but isnever “wrong”. An advantage of this additive universeis that we can extend the behavior of our systemwithout changing any existing code, but by simplymaking new Techniques available.

In order to create our additive universe, our decision-making algorithm must be generic, i.e., it cannotexplicitly enumerate and choose Techniques. Instead,our system computes a score called Satisfaction foreach Technique based on the Technique’s self-reportedProperties. Thus, Properties can be viewed as themulti-dimensional cost using the Technique and theSatisfaction calculation as a dimension-reducing func-tion to produce a scalar score to allow easy, open-ended competition [6] among alternative Techniquesaddressing each Goal. The Planner need only choosethe Technique with the highest Satisfaction score ateach Goal decision point.

Each Goal specification provides a default formulafor computing its Satisfaction from Properties reportedby Techniques. However, local policy may dictate adifferent Satisfaction scheme — e.g., users may preferhigher resolution video at a lower frame rate whilethe Goal specification may prefer the reverse. For thisreason, the Planner includes an API to change theSatisfaction formula for a particular Goal instance atruntime to accommodate local policy variation.

We require Goals to be immutable, as the semanticsof a Goal are built into Technique code and changesto the Goal specification will render Techniques obso-lete. Consequently, evolution of a Goal’s specificationrequires that a new specification with a new Goalname be created. The new specification may note itas a replacement for the old Goal, that the latteris now deprecated, or even that the new version isstrictly narrower than the old (in the sense that anyTechnique satisfying the new Goal is guaranteed tosatisfy its predecessor). Existing Techniques citing theold Goal will continue to use the (possibly deprecated)version until updated, although some updates could beautomated in certain cases.

3.2. Technique sub-Goal Search and Selection

The planning process of building and evaluatingGoal Trees discussed in Section 2.3 is essentiallya search through a hierarchical Technique space for“paths” through the Goal Tree that best satisfy the top-level Goal. The Planner, by default, uses a heuristicsearch algorithm where each Goal is independentlybound to the Technique with the highest Satisfactionvalue, until forced by a subsequent failure, or otherevent, to expand the search. If two or more sub-Goalsare incompatible, eval stages in Techniques call fail()to signal to the Planner that the current set of sub-Goals is unacceptable. For example, the RTPStreamsTechnique of Listing 1 calls fail() on line 12 if thesource and sink do not support mutually acceptablestream formats. fail() terminates exploration of thecorresponding subtree.

Often this declaration of failure is too radical. In thepresent example, there may be source-sink pairs withcompatible formats which will be neglected simplybecause the pair reflecting the highest Satisfactionshappened to be incompatible. Thus, the approach rep-resented in Listing 1 suffers from a combination ofdeficiencies: (1) that the heuristic choice of sub-Goalsdoes not reflect critical dependencies between sub-Goals; and (2) that a single bad combination of sub-Goal choices will occlude the exploration of lower-rated but potentially viable solutions using this Tech-

1 to PlayMovie(name, language): via RTPStreams2:23 subgoals:4 source = RTPAVSource(goal.name, goal.language,5 stream format=”H.264”)6 sink = RTPAVSink(stream format=”H.264”)

Listing 3. Goal parameters passed down the GoalTree limit sub-Goals to H.264-compatible streamsonly.

Figure 2. The RTPStreams Technique sets thestream format parameter to H.264, causing bothMPEG-2 Techniques to fail.

nique. The following paragraphs describe mechanismfor guiding the search breadth.

3.2.1. Search-narrowing Goal parameters. Insteadof checking for mis-matched parameters after the fact,one simple alternative involves making decisions highin the Goal Tree and passing search-narrowing param-eters down the tree for each subgoal. Listing 3 sketchesa revised search for a source and sink, each specifyingH.264 as the media format (restricting solutions todevices that accept or emit this media type). SuchTechniques lead to a Goal Tree of the form of Figure2. If multiple formats are to be explored, this approachrequires that an alternative node be established for eachplausible format combination, each requiring a separateTechnique.

3.2.2. Dependent Subgoal Binding. We may improvesub-Goal search performance by ordering sub-Goalsearches. For example, we might (1) search for asource emitting an arbitrary format, and then (2) searchfor a sink whose format is compatible with that ofthe source we’ve found. To that end, we allow mul-tiple subgoals stages within a single Technique. Theattributes of sub-Goal bindings from earlier stages maybe used to direct searches in subsequent ones. Listing4 illustrates the use of this mechanism to constrain thesearch of our example. Figure 3 shows the resultingGoal Tree.

1 to PlayMovie(name, language): via RTPStreams3:23 subgoals:4 source = RTPAVSource(goal.name, goal.language)5 subgoals:6 sink = RTPAVSink(7 stream format=subgoals.source.stream format8 )

Listing 4. The second subgoals stage can useProperties from the first to guide the Planner’sTechnique search.

Figure 3. The RTPStreamsTechnique passes thestream format Property of its source sub-Goal as aparameter to its sink sub-Goal, causing the LaptopTechnique to fail and forcing selection of the HDTV.

Figure 4. Goal Tree with cloned Techniques. TheRTPStreams Technique is cloned for each com-bination of source and sink. The two pairs withmatching stream formats succeed while the othertwo fail.

3.2.3. Tree Search and Exploration. Alternatively,the Planner may alter the search for an acceptable setof Goal/Technique bindings from the default single-pass heuristic to exhaustive exploration of all possiblechoices. Full search involves testing each combina-tion of sub-Goal bindings. However, instead of test-ing each combination sequentially, the Planner uses

a Goal Tree manipulation called Node Cloning tosearch all sub-Goal combinations while maintaininga record of the Satisfactions of each combination.Node Cloning allows the Planner to revisit particularsub-Goal combinations as the computing environmentchanges without running through the entire sequenceof combinations. During Node Cloning, the Plannermakes a copy of a Technique node but binds its sub-Goals to particular Techniques rather than to an open-ended Goal node. Figure 4 illustrates Node Cloningwith the original RTPStreams Technique from Listing1. The RTPStreams Technique is cloned four times,once for each combination of its sub-Goal bindings.Two choices have matched stream format parametersthat allow their clones to succeed; the other two clonesfail.

Of course, the Planner’s overuse of Node Cloningmay lead to a worst-case exponential explosion in thenumber of choices, so complete combinatorial searchis only feasible for small Goal Trees. For large GoalTrees, the Planner only clones small, heuristicallychosen sub-Trees, increasing the number of choicesavailable without affecting running time adversely.

3.3. Runtime Adaptivity

Techniques are sequential scripts, yet they need torespond to changes in Properties of sub-Goals forcedby the environment and changes in Goal parametersforced by the top-level application. For example, avideo Technique must respond to requests for newtitles as well as bitrate changes of its sub-Goals.A naı̈ve apparoach to this problem is to simply re-run the Technique from its first stage; however, thishas performance implications for Techniques with alarge number of stages or stages that must access thenetwork.

Instead, the Planner keeps track of what Goal pa-rameters and sub-Goal Properties each stage of eachTechnique uses and rolls-back the Technique onlyas far as it needs to account for changes in thesetracked variables. In order to implement roll-back, thePlanner saves the pre-execution state of each stage inthe Technique. When a tracked variable changes, thePlanner finds the first stage that depends on the variableand resets the state of the Technique to whatever pre-execution state was associated with that stage. Thusreset, the Planner re-runs the stage and any subsequentstages. For example, in Listing 1, a change to the sink’sresolution property will only re-run the Techniquestarting at line 13. We find this roll-back strategy savescomputation and network traffic and contributes to the

1 def monitor entity loop( tf , # Technique Factory2 type): # extra arg passed by sub−Goal34 finder = find entities of type (type)5 known resources = {}6 # now update as things change7 while True:8 event = finder .get event()9 if (event.type == ’new device’):

10 vteq = tf .new teq()11 known resources[event.resource] = vteq12 vteq.resource = resource13 vteq. resolution = resource.resolution14 vteq.liveness = ’ alive ’15 vteq. notify ()16 elif (event.type == ’dead device’)17 vteq = known resources[event.resource]18 vteq.liveness = ’dead’19 vteq. fail ()20 else:21 pass2223 to FindRTPSink(stream format): via VLCHost:2425 subgoals:26 vlc host = TechniqueFactory(code=monitor entity loop,27 type=’VLCHost’)2829 eval:30 if subgoals.vlc host.liveness != ’ alive ’ :31 planner. fail ( ”%s not alive” % subgoals.vlc host)32 ...

Listing 5. The monitor entity loop function createsTechniques for each resource it finds.

Figure 5. The VLCHost Technique uses the Techniq-ueFactory to call discovery system code. The Plan-ner clones the VLCHost Technique for each Tech-nique the TechniqueFactory’s code creates. Thelaptop represented by CODE#2 has disappeared,causing the created Technique to fail.

Planner’s ability to quickly switch among differentPlans in the Goal Tree.

3.4. Technique Factories and External Events

While Techniques may call arbitrary code in theireval stages, these calls are “one-shot” — their changesare not tracked by our roll-back system. However, for

certain kinds of code, including resource discoveryand monitoring, outside changes should propagate tothe Planner and cause re-evaluation of Techniques.To handle these cases, we provide a special sub-Goalcalled TechniqueFactory that allows external code tocreate and control Techniques directly. For example,Listing 5 shows how our VLCHost Technique uses themonitor entity loop function to create Techniques forresources found with a long-running discovery system.

The external code has complete control over theTechniques it creates with its factory. The code mayset and re-set its virtual Technique’s Properties aswell as fail Techniques that are no longer applicable.In contrast to “one-shot” function calls, changes tothe code-based Technique Properties are tracked likenormal sub-Goal Properties, invoking the Planner’sTechnique restart mechanism.

If the code associated with the TechniqueFactorysub-Goal creates more than one Technique, rather thanchoosing the best Technique, the Planner clones theTechniqueFactory sub-Goal to expose all of its Tech-niques to higher-level Techniques. Figure 5 illustrateshow the Goal Tree changes.

4. Applications

In order to test the general applicability of Goals andTechniques, we built several applications. Some relyentirely on the Planner to make all decisions, whileother use the Planner only for parts of the applicationthat need to be adaptive.

4.1. JustPlay Audio and Video

The JustPlay Audio [7] and Video application is anadaptive media player designed to reduce the amountof configuration users must do in order to use theirvarious A/V-capable devices. Users control the systemthrough a simple “voice shell” application that usesspeech recognition to translate voice commands intotop-level Goals. These Goals are then passed to thePlanner, which continually monitors for changes in theenvironment and user commands that alter the top-levelGoal. The JustPlay system started as audio-only, butas we built a video infrastructure, we were able to addTechniques that made the Planner aware of these newcapabilities.

The Techniques used as examples in this papercome from the JustPlay application because JustPlayincludes many of the technical challenges we soughtto solve. For example, our video selection Techniqueuses sequential sub-Goal binding to more clearly definewhat combinations of A/V streams are acceptable for

the system. We also make use of the TechniqueFactorysub-Goal to connect the Planner to discovery sub-systems. In a testament to the additivity of our system,the JustPlay application has worked with two distinctdiscovery systems — one with a custom in-houseprotocol and one based on DNS-SD — with slightlydifferent APIs and semantics. Changing between thesystems just required creating new low-level “finder”Techniques (like Listing 5). Moreover, Techniquesfor both systems could co-exist in the same Plannerprocess, making it easy to gradually introduce the newdiscovery system.

4.2. User Proxies

We have also used the Planner to maintain user-level applications in the face of changing hardware,similar to the aims of Gaia [8], [9] and Aura [10]. Inparticular, we tested this with a text chat applicationand a teleconference application. Users modified thesystem by adding new Techniques that better suitedtheir desires. For this application, a trusted machineruns a network-exported Planner that maintains userGoals. As the Planner discovers client devices (stan-dard desktops as well as PDAs), it re-configures thetext chat and/or teleconference applications to use theresources of new devices: if a user turned on his PDAafter leaving his office, the system would reconnect hischats and allow him to continue as though he were stillat his office computer.

4.3. Other Applications

The Planner also powers a few other applicationsoutside of the pervasive computing field. Our crisismanagement application simulates several crises af-fecting a small city. The crisis management applicationbenefits from the open-ended nature of the Plannerbecause it allows new strategies to be added to thesystem as crises unfold. We also implemented a Recipeapplication that uses the Planner to choose amongrecipes depending on (1) what ingredients are availableand on (2) the user’s food preferences. Each recipe iswritten as a Technique, with sub-Goals for each utensil,appliance, and ingredient that the recipe requires. AGUI allows users to alter the Planner’s choices byexplicitly rejecting certain ingredients (which causeTechniques depending on those ingredient sub-Goalsto fail) or by altering the Satisfaction formula tofavor certain Properties (like caloric content, flavor, orcooking time).

Finally, we are currently exploring the use of thePlanner in a hardware design “compiler”. We use Goals

to represent each class of hardware element, such asan adder or register, and Techniques to provide waysof stitching the circuits together. The final output isVerilog code. The Planner allows us to explore alter-native implementations of the same circuit, test theirperformance in simulation, and more rapidly iteratehardware designs.

5. Implementation and Performance Eval-uation

The Planner is written in pure Python and hasbeen tested on GNU/Linux, Apple os x, and MicrosoftWindows (under cygwin).1 The Planner can run as botha stand-alone command-line tool as well as be linkedinto traditional applications. Applications that importthe Planner have access to an extended API that letsthe application more finely control the execution of thePlanner, as well as integrate the Planner’s evaluationloop with its own mainloop and/or threads.

5.1. Latency Evaluation

The Planner does not interpose itself in the datastreams between individual components, so it does notslow down an application once it is running. However,the Planner necessarily takes part in application start-up and adaptivity since the Planner drives the decisionmaking of these phases; the rest of this section detailsthe user-visible latency that the Planner adds to theapplication.

All tests were run on a desktop Pentium 4/3.2GHzwith 1 GiB of RAM running GNU/Linux 2.6.22 andPython 2.5.1.

Our start-up latency test measures how long it takesthe Planner to build, evaluate, and execute trees ofvarious sizes. After the Planner has converged on asolution and idled, we introduce a variety of satis-faction changes to the leaf nodes to simulate failures.Our swap latency test measures how long the Plannertakes to converge to a new plan after the failures areintroduced.

5.2. Results

Figure 6 summarizes our latency tests. Overall,startup latency scales linearly with the number of nodesin the Goal Tree. On normal size trees (≈50 nodes),

1. Full source code to the Planner is available under a free licensefrom http://o2s.csail.mit.edu/. A small library of Goal specifications(as well as an HTML interface to the specs) can be found at http://o2s.csail.mit.edu/system.html.

0.01

0.1

1

10

100

1 10 100 1000 10000

Bui

ld ti

me

[s]

Number of nodes in Goal Tree

queueprecqueue

Figure 6. The latency to fully build and explorethe Goal Tree as a function of the total numberof nodes. The precqueue scheduler is about 14%faster than the normal queue scheduler.

0

0.05

0.1

0.15

0.2

0.25

1 1.5 2 2.5 3 3.5 4

Sw

ap ti

me

[s]

Number of Techniques failed

255 Nodes63 Nodes15 Nodes3 Nodes

Figure 7. Goal Tree swap latency, separated bythe size of the tree. The x-axis is the numberof Techniques we failed in order to induce thechange.

the Planner adds 1 s of startup latency. In real-worldapplications, we find that the Planner’s startup latencyis dwarfed by service discovery latencies.

In early tests, we found that performance of thePlanner is tied to the order in which the Planner runsthe evaluation stages of Techniques. We developedtwo stage schedulers: one that maintained a simplework queue (called the queue scheduler) and another,the precqueue scheduler, that would only scheduleTechniques higher in the tree after lower-level Tech-niques finished evaluation. The precqueue schedulerwas usually about 14% faster.

Figure 7 shows how long the Planner takes toreact to changes in its environment and swap in newTechniques, using our precqueue scheduler. Note thatthis does not measure average application downtime,

but rather how long the Planner takes to determinewhat changes need to be made and then instantiatethose changes. We found that even a large, 255-nodetree could be updated in less than 250 ms. We attributethis fast speed to our Goal Tree cache and roll-backmechanism.

6. Related Work

Many systems provide abstractions that ease theburden of programming adaptive applications. At thenetwork level are systems like MIT’s Intentional Nam-ing System [1], Service-oriented Network Sockets [2],and Lightweight Adaptive Network Sockets [3]. Thesesystems allow applications to opportunistically connectto the best resources in a given environment and leaveadaptation to the application.

Other frameworks provide high-level abstractions.CMU’s Aura system [10] uses tasks to capture user-level intent. Aura uses tasks to map user intent toavailable resources without requiring user interactionand to optimize resource allocation according to user-specified QoS parameters. Similarly, UIUC’s Gaia [8]provides event and context services for managing ap-plications in “ActiveSpaces”. We concentrate on thelower level of composing applications once context andintent have been discovered. Olympus [9] extends Gaiawith a programming model for writing code portablebetween ActiveSpaces. Our system and Olympus solveslightly different problems. Olympus maps abstract de-scriptions to ActiveSpace entities using hierarchicallydefined ontologies in order to avoid the tedium of link-ing entities manually (as is required by Gaia). Goals,on the other hand, are a generic programming constructaimed at allowing open-ended decision making aboutany component, algorithm, or resource a pervasiveapplication may need.

Semi-automatic service composition systems suchas NinjaPaths [11] or SWORD [12] complement ourapproach. Such systems can be used to generate Tech-niques and aid in rapid development of Technique-based applications.

Declarative and implicative programming ap-proaches, especially rule-based systems [13] and event-condition-action (ECA) systems, provide programmingconstructs at levels of abstraction similar to our system.For example, InterPlay [14] uses a derivative of theJess rule system [15] to provide a pseudo-English userinterface to a consumer electronics environment. Thescope of InterPlay is different than our work — it doesnot target adaptive applications, but rather concentrateson ease of use. Our work may benefit from the UIinnovations of InterPlay.

SOCAM [16] and Chisel [17] are ECA frameworksfor managing events in context-aware applications.ECA systems are designed to react to changes inthe environment or context while our system aims toevaluate available choices in the environment to fulfilabstract requirements. ECA systems may provide analternative user interface to invoking Goals, e.g. “whenI arrive at home, invoke PlayMusic(genre=Jazz)”.

7. Conclusion

Emerging computing environments require new ab-stractions that permit increased levels of runtimeadaptivity while still maintaining extensibility. Goalsand Techniques meet both requirements by providinga structured way of decomposing adaptive applica-tions. Goals represent open-ended choice points thatcan be compared by an application-generic Planner.Techniques provide specially prepared code modulesthat embody domain-specific knowledge. Our sys-tem allows hierarchical decomposition of applica-tions through Technique-declared sub-Goals, but unlikecompeting systems, provides programmers a frame-work for declaring dependencies between sub-Goals.Our system is additive: new Techniques can be addedwithout requiring changes in existing Techniques. Inorder to evaluate our system, we implemented fourwidely-varying applications using Goals and Tech-niques. In performance testing, we found that our sys-tem adds only a small amount of latency to applicationstart-up and fail-over.

We are currently working on ways for users to cus-tomize the Planning process without needing to resortto programming. We are approaching this problem intwo ways. First, we are working on a Satisfaction plug-in that lets users customize the Satisfaction calculation.Second, we are implementing a GUI “sand box” whereusers can explicitly reject choices the Planner hasmade, providing an easy-to-use interface to deviceconfiguration.

8. Acknowledgements

This research is sponsored by the T-Party Project,a joint research program between MIT and QuantaComputer Inc., Taiwan.

References

[1] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, andJ. Lilley, “The design and implementation of an inten-tional naming system,” in SOSP, 1999, pp. 186–201.

[2] U. Saif and J. Mazzola Paluska, “Service-oriented net-work sockets,” in MobiSys 2003, 2003.

[3] U. Saif, J. Mazzola Paluska, and V. P. Chauhan, “Prac-tical experience with adaptive service access,” SIGMO-BILE Mob. Comput. Commun. Rev., vol. 9, no. 1, pp.27–40, 2005.

[4] C. Becker, M. Handte, G. Schiele, and K. Rothermel,“PCOM - a component system for pervasive comput-ing.” in PerCom ’04. IEEE Computer Society, 2004,pp. 67–76.

[5] P. Costa, G. Coulson, R. Gold, M. Lad, C. Mascolo,L. Mottola, G. P. Picco, T. Sivaharan, N. Weerasinghe,and S. Zachariadis, “The runes middleware for net-worked embedded systems and its application in adisaster management scenario,” in PerCom. IEEEComputer Society, 2007, pp. 69–78.

[6] V. Poladian, S. Butler, M. Shaw, and D. Garlan, “Timeis not money: The case for multi-dimensional ac-counting in value-based software engineering,” in FifthWorkshop on Economics-Driven Software EngineeringResearch (EDSER-5), May 2003.

[7] J. Mazzola Paluska, H. Pham, U. Saif, C. Terman, andS. Ward, “Reducing configuration overhead with goal-oriented programming.” in PerCom Workshops. IEEEComputer Society, 2006, pp. 596–599.

[8] M. Roman, C. Hess, R. Cerqueria, A. Ranganathan,R. H. Campbell, and K. Nahrstedt, “A middlewareinfrastructure for active spaces,” IEEE Pervasive Com-puting, pp. 74–83, October-December 2002.

[9] A. Ranganathan, S. Chetan, J. Al-Muhtadi, R. H.Campbell, and M. D. Mickunas, “Olympus: A high-level programming model for pervasive computing en-vironments,” in PerCom. IEEE Computer Society,2005, pp. 7–16.

[10] D. Garlan, D. P. Siewiorek, A. Smailagic, andP. Steenkiste, “Project aura: Toward distraction-freepervasive computing,” IEEE Pervasive Computing, pp.22–31, April-June 2002.

[11] S. Chandrasekaran, S. Madden, and M. Ionescu,“Ninja paths: An architecture for composingservices over wide area networks,” 2000,http://ninja.cs.berkeley.edu/dist/papers/path.ps.gz.

[12] S. R. Ponnekanti and A. Fox, “Sword: A developertoolkit for building composite web services,” in TheEleventh World Wide Web Conference (Web Engineer-ing Track), 2002.

[13] NASA, “Clips reference manual,” in NASA TechnologyBranch, 1993, October 1993.

[14] A. Messer, A. Kunjithapatham, M. Sheshagiri, H. Song,P. Kumar, P. Nguyen, and K. H. Yi, “Interplay: Amiddleware for seamless device integration and taskorchestration in a networked home,” in PerCom. IEEEComputer Society, 2006, pp. 296–307.

[15] Sandia National Laboratories, “Jess rule-based system,”in Jess User Manual, 2003.

[16] T. Gu, H. K. Pung, and D. Zhang, “A service-orientedmiddleware for building context-aware services,” J.Network and Computer Applications, vol. 28, no. 1,pp. 1–18, 2005.

[17] J. Keeney and V. Cahill, “Chisel: a policy-driven,context-aware, dynamic adaptation framework,” inPOLICY 2003., 4-6 June 2003, pp. 3–14.