OASiS: A Programming Framework for Service-Oriented Sensor Networks

OASiS: A Programming Framework forService-Oriented Sensor Networks1

Manish Kushwaha, Isaac Amundson, Xenofon Koutsoukos, Sandeep Neema, Janos SztipanovitsInstitute for Software Integrated Systems (ISIS)

Vanderbilt UniversityNashville, TN 37235, USA

{manish.kushwaha, isaac.amundson, xenofon.koutsoukos, sandeep.neema, janos.sztipanovits}@vanderbilt.edu

Abstract— Wireless sensor networks consist of small, inexpen-sive devices which interact with the environment, communicatewith each other, and perform distributed computations in orderto monitor spatio-temporal phenomena. These devices are ideallysuited for a variety of applications including object tracking,environmental monitoring, and homeland security. At present,sensor network technologies do not provide off-the-shelf solutionsto users who lack low-level network programming experience.Because of limited resources, ad hoc deployments, and volatilewireless communication links, the development of distributedapplications require the combination of both application andsystem-level logic. Programming frameworks and middleware fortraditional distributed computing are not suitable for many ofthese problems due to the resource constraints and interactionswith the physical world.

To address these challenges we have developed OASiS, aprogramming framework that provides abstractions for object-centric, ambient-aware, service-oriented sensor network appli-cations. OASiS uses a well-defined model of computation basedon globally asynchronous locally synchronous dataflow, and iscomplemented by a user-friendly modeling environment. Appli-cations are realized as graphs of modular services and executedin response to the detection of physical phenomena. We havealso implemented a suite of middleware services that supportOASiS to provide a layer of abstraction shielding the low-levelsystem complexities. A tracking application is used to illustratethe features of OASiS. Our results demonstrate the feasibilityand the benefits of a service-oriented programming frameworkfor composing and deploying applications in resource-constrainedsensor networks.

I. INTRODUCTION

Wireless sensor networks (WSNs) are inherently dynamicin nature due to node mobility, limited resources, and un-reliable communication links. It is therefore imperative thatWSN applications consider these issues in order to ensuretheir correct execution. Unfortunately, tackling the problem ofdynamic network behavior places a substantial burden on theprogrammer. In addition to an application’s core functionality,the programmer must implement low-level operations suchas robust communication protocols, resource managementalgorithms, and fault tolerance mechanisms. Unlike traditionalnetwork programming, WSN programming requires a couplingbetween application-level and system-level logic for resourcemanagement and sensing operations. Not only does the im-plementation of these components require substantial time and

1OASiS is partially supported by Microsoft External Research, NSF grantCCR-0225610, and grant ARO SA5212-11087.

effort on behalf of the programmer, but it also increases therisk of deploying incorrect code, due to the often unanticipatedbehavior of distributed network applications.

In this paper, we present OASiS, an Object-centric,Ambient-aware, Service-oriented Sensornet programmingframework which enables the development of WSN appli-cations without having to deal with the complexity and un-predictability of low-level system and network issues. Theframework provides a well-defined model of computationbased on globally asynchronous locally synchronous dataflow[1], and is complemented by a user-friendly modeling environ-ment. OASiS decomposes specified application behavior andgenerates the appropriate node-level code for deployment ontothe sensor network.

In object-centric programming, an object is a logical el-ement which represents some physical phenomenon beingmonitored by the network. The application is driven by theobject, and its behavior is governed by the object’s currentstate. The programmer is able to specify this behavior fromthe viewpoint of the object, and need not worry about how thebehavior is implemented at the node level.

Object-centric programming by itself does not address theissues of network failures and dynamic network topology.Ambient-aware programming [2] has emerged as a paradigmfor mobile computing in which each node in the networkhas up-to-date knowledge of its neighborhood. This includesawareness of its neighbors and the services they provide.

OASiS takes a service-oriented approach to behavioraldecomposition and application execution. In a service-orientedWSN application, each activity (sensing, aggregation, servicediscovery, etc.) is implemented as a separate service. Theadvantages of using a service-oriented architecture for WSNapplications are similar to those of Web services. Servicesare modular, autonomous, and have well-defined interfaceswhich allow them to be described, published, discovered, andinvoked over a network. These properties permit services tobe dynamically composed into complete applications.

We have developed a suite of middleware services whichsupport such object-centric, ambient-aware, service-orientedapplications. The services include components for managinginternal sensor node operations, communication, service dis-covery, and object maintenance. The middleware serves as alayer of abstraction, shielding the programmer from the low-

level complexities of sensor node operation.The OASiS programming framework can be used to develop

any type of dataflow application including vehicle tracking,fire detection, and distributed gesture recognition. As proofof concept, we have developed a simplified indoor trackingexperiment, which monitors a heat source as it travels throughthe sensor network. The case study highlights the variousfeatures of OASiS, and demonstrates the feasibility and utilityof a service-oriented WSN programming model.

The paper is organized as follows. Section II describesthe design principles and challenges involved in developinga programming framework for WSNs. In Section III, wedescribe the OASiS programming framework. Section IV de-scribes the OASiS programming model, followed by a detaileddescription of the middleware in Section V. We demonstratethe capabilities of OASiS in Section VI. In Section VII,we compare our research to similar work that has recentlyappeared in the literature. Section VIII concludes.

II. DESIGN PRINCIPLES AND CHALLENGES

In this section, we discuss the challenges and design choicesinvolved in WSN programming framework development. Un-til recently, WSN application programming has followed anapproach that leaves the programmer with the responsibilityof implementing many low-level details such as sensing,communication between nodes, and efficient use of energy.Not only does this extra work consume valuable time andresources, but it also increases the chances of delivering error-prone code.

A more robust approach makes use of a programmingframework which provides higher levels of abstraction, en-abling the developer to program from a global point ofview. The developer can then focus on the desired overallbehavior of the application, without having to be concernedwith the complexities associated with distributed systems. Pro-gramming frameworks typically accept a desired applicationbehavior as input and by means of compiler or interpreter,and often a framework API library, generate a functionalnetwork application as output. The output can either take theform of executable code or a byte-string instruction set to beinterpreted by a network virtual machine. The application runson top of a layer of middleware services which handle theunderlying hardware and network operations.

Design principles for traditional distributed computing mid-dleware are not directly applicable to WSNs for the followingreasons:

• Sensor nodes are small-scale devices with a limitedpower supply, directly affecting computation, sensing,and (especially) communication.

• WSN middleware services often depend on the physicalphenomenon being monitored.

• Node mobility, failure, and volatile communication linksproduce a dynamic underlying network.

• Variation in node hardware, computation, communica-tion, and sensing abilities introduces heterogeneity.

• Sensor nodes often operate unattended for prolongedperiods of time.

The design of a successful WSN middleware must addressthe various challenges imposed by the aforementioned char-acteristics. Many middleware challenges have already beenidentified [3] and are summarized below.

Limited resources: Every aspect of middleware designshould attempt to include resource optimizations, and ananalysis of resource utilization is important for preventingunintentional abuse. Power is of significant importance, espe-cially in terms of communication where a single transmissionconsumes an amount of energy equivalent to more than athousand computations.

Dynamic network topology: WSN topology is subject to fre-quent changes due to node mobility, node failure, and volatilecommunication links. A WSN middleware must support robustand reliable sensor network operations by providing mecha-nisms for fault tolerance, network awareness, and applicationself-reconfiguration.

Heterogeneity: As WSNs become more prevalent and di-verse, middleware will be required to operate gracefully inheterogeneous environments. This not only requires the mid-dleware to maintain communication and distributed computa-tion mechanisms across different architectures, but quality ofservice guarantees as well.

Real-world Integration: WSN applications interact with thephysical world and react to an evolving environment over timeand space. This requires middleware services which providespatio-temporal abstractions, as well as real-time functionali-ties.

Application knowledge: Although middleware is intendedto be application independent, knowledge of the applicationdomain may improve overall performance. Therefore, pro-viding middleware with parameterized services that acceptconfiguration options as input will increase robustness andimprove usability.

Data aggregation: The popularity of WSNs is due in nosmall part to their ability to accumulate environmental dataover a wide physical area. However, the data sampled by eachnode is often meaningless until it is combined and analyzed.Middleware can play a key role by providing an efficientmechanism for collecting data located across the network.

Quality of service: Not only should middleware be capableof maintaining network-related quality of service guarantees,but also guarantees relating to the performance of the WSNapplication. Without such guarantees, application behaviorbecomes less stable and predictable.

III. THE OASIS PROGRAMMING FRAMEWORK

This section describes the three stages of developmentwithin the OASiS programming framework, and the advan-tages of OASiS in view of the design challenges presented inSection II.

At present, users wishing to deploy WSN applications mustbe adept at developing the sensor network middleware, thedomain-specific functionality, and perhaps even an interactive

Fig. 1. OASiS: Programming Framework

front-end. Application development will benefit from a pro-gramming paradigm that provides these separation of concerns(SoC). In software engineering, SoC is the process of breakinga program into distinct features that overlap in functionality aslittle as possible [4]. In the application development context itcan be redefined as the process of breaking the responsibilitiesof application development into distinct stages for program-mers with different skills. OASiS is a programming frameworkthat facilitates these SoCs for application development througha multilayer development process. Figure 1 illustrates therelationship between each development stage in OASiS.

In OASiS, core sensor network functionality is bundled asmiddleware services including service discovery, service graphcomposition, failure detection, node management, and others.We present the OASiS middleware in detail in Section V. Thedomain services development layer provides domain-specificservice libraries developed by domain experts, which can thenbe used by the application developer. OASiS then wires thedomain services onto the middleware to produce node-levelexecutable code for deployment on the network. Applicationdevelopment in OASiS does not require any expertise insensor network programming. Instead, complete applicationsare developed using model-integrated computing techniques[5].

In addition to providing multilayer development, the pro-gramming framework addresses many of the aforementioneddesign challenges in Section II. Our ambient-aware middle-ware supports dynamic service discovery and configurationto address changes in network topology due to failures andunreliable communication links. Heterogeneity is solved byour service-oriented approach, where well-defined serviceson heterogeneous platforms can be composed together in aseamless manner. For example, resource-intensive Web ser-vices can easily be plugged into OASiS applications, and aretreated as ordinary WSN domain services. OASiS supportsreal-world integration in application design by providing themeans to specify spatio-temporal service constraints. Manylocalization algorithms, for example, require sensing servicesto be situated in a precise spatial configuration, such as sur-rounding the physical phenomenon. The ability to attach suchconstraints to services before they are invoked is an importantaspect of WSN application programming. Due to the service-oriented approach of OASiS, we are able specify in-networkdata aggregation by connecting multiple sensor services toa single aggregator service. OASiS supports specification of

both application-specific and network QoS requirements. QoSviolations are gracefully handled by application reconfigura-tion to satisfy QoS requirements.

IV. OASIS PROGRAMMING MODEL

The OASiS programming model is organized into three keyparadigms: service-oriented, object-centric, and ambient-awareprogramming.

Service-Oriented Architecture

A service-oriented architecture (SOA) simplifies WSN do-main development by providing standards for data represen-tation, service interface description, and service discoveryfacilitation. By wrapping application functionality into a setof modular services, a programmer can then specify executionflow by simply connecting the appropriate services together.The resulting service graph is a concise representation of theapplication which can then be executed irrespective of thephysical location of the distributed services.

In OASiS, a service is the basic unit of application func-tionality. Services have well-defined interfaces consisting ofinput and output ports, as well as the data types supported byeach. A well-defined interface is important when binding twoservices together. A data type mismatch between the outputport of one service and the input port of the next will cause anexecution violation. OASiS catches these types of violations,preventing undesirable execution behavior.

Wiring a group of domain services together results in aservice graph describing application flow. In OASiS, servicescan be wired together to compose a service graph representingany type of data flow application. In addition to servicesand their connections, a service graph can include constraintswhich restrict where and when a service can be invoked.

Because services must communicate asynchronously witheach other, OASiS employs the globally asynchronous, locallysynchronous (GALS) model of computation [6]. GALS main-tains asynchronous communication between services, whileintra-service communication, such as method calls, exhibitsynchronous behavior.

Dynamic network topology in WSNs can cause problemsduring application execution such as service unavailabilityand violation of constraints. Querying a centralized servicerepository each time a new service instance is needed can beexpensive, especially when the repository is located multipletransmission hops away. In OASiS, each node maintains two

service repositories, a local service repository (LSR) that cata-logs the application services available locally, and a discoveredservices repository (DSR) that catalogs the remote applicationservices that have been discovered in the past. The combineduse of these two repositories allows the system to be moreresponsive in the event of service unavailability.

Service discovery is passive in that service providers waitfor a specific request before advertising a service. This passiveapproach was found to be the most energy efficient for mobilead hoc networks with limited power resources [7]. Requestsare flooded a limited number of hops throughout the network,and all providers of the requested service respond with amessage specifying their node ID, physical location, and powerlevel. This information can be used to discard any serviceprovider which fails to satisfy the constraints specified in theservice graph.

OASiS is intended for resource-constrained devices whichare unable to use current Web service standards such as SOAP,WSDL, and UDDI due to their bulky XML-based messagingformat. Instead, OASiS uses a compact byte-sequence messagestructure for accessing services and passing data betweenthem. However, the OASiS SOA does provides a straight-forward mechanism for accessing Web services, and similarly,for granting Web services access to the WSN application [8].This capability allows WSN applications to perform compu-tations and access information using methods unavailable toresource-constrained nodes.

Object-Centric Programming

Complexity in OASiS is minimized by providing the appli-cation developer with a means for specifying global networkbehavior; that is, behavior from the viewpoint of the physicalphenomenon of interest. For example, the global networkbehavior for target tracking involves nodes taking sensormeasurements of the environment until a target is detected, andthen organizing to localize the target and follow its movement.Global behavior does not involve specifying how nodes taketheir sensor measurements, which nodes communicate witheach other once the target is detected, or how target localiza-tion is accomplished.

In OASiS, a physical phenomenon of interest is representedby a finite state machine (FSM), also referred to as thelogical object. We selected the FSM representation becausethis model of computation is an intuitive method for describingthe distinct states a physical object might exhibit. Each FSMmode corresponds to a different physical state, and containsa service graph specifying the appropriate actions to take forthe specific situation. An example object FSM is shown in theapplication development stage part in Figure 1.

Before a logical object is instantiated, a physical phenom-enon must be detected. This is achieved by comparing sensordata with an object context. The object context defines thephysical phenomenon in logical terms. For example, we mightdeclare an object context for fire as

TEMPERATURE ≥ 100oC.

The object context also contains information on how fre-quently the environment should be sampled.

Because multiple nodes may detect the same physical phe-nomenon at roughly the same time, a mechanism is required toensure only one logical object is instantiated. To provide thisguarantee, OASiS employs an object-owner election algorithm,similar to that of [9]. The object creation protocol, executedby each node, is outlined in Algorithm 1.

Algorithm 1 Object Creation Protocol1: if object creation condition == TRUE then2: declare yourself a candidate3: if owner election not already in progress then4: initiate owner election5: end if6: if elected object owner then7: declare ownership8: populate the object state variables9: identify the object default mode

10: initiate dynamic service configuration11: end if12: end if

After the object creation protocol completes, exactly onenode, referred to as the object node, is elected owner ofthe logical object corresponding to the physical phenomenon.The object initiates in the default mode of the FSM andstarts the process of dynamic service configuration (see be-low), after which the application begins execution. The objectmaintenance protocol evaluates the mode transition conditionsevery time the object state is updated. If a mode transitioncondition evaluates true, the protocol makes the transition tothe new mode. The mode transition involves resetting anyobject variables, if applicable, and configuring the new servicegraph corresponding to the new object mode.

The object also has a migration condition, which if evaluatestrue, invokes the object migration protocol. The selectionpolicy for migration destination is tied to the migration con-dition that triggers the migration protocol. In tracking appli-cations, for example, an increase in the variance of locationestimate can serve as a migration condition, and the ownerselection policy will choose the node closest to the physicalphenomenon. Other migration conditions include an object-node running low on power, in which case the selection policylocates a node with a sufficient power reserve. The migrationprocess consists of first running the owner election algorithmto select the migration destination based on the selectionpolicy, and then transferring the object state to the new objectnode. The migration protocol is outlined in Algorithm 2.

When the sensor network is no longer able to detect thephysical phenomenon, the logical object must be destroyed.This is a simple matter of resetting the logical object state tonull. After an object has been destroyed, the sensor networkbegins searching for a new object context.

Algorithm 2 Object Migration Protocol1: if object migration condition == TRUE then2: remove current object node as candidate for owner3: initiate owner election4: transfer the object to new owner5: end if

Ambient-Aware Programming

Nodes in an ambient-aware sensor network always haveup-to-date knowledge of their neighborhood, including whichservices are available, and the properties of the nodes provid-ing them. Ambient-awareness is built into OASiS to ensureefficient service discovery, minimal downtime in the eventof communication failure or node dropout, and service graphconstraint satisfaction.

OASiS allows constraints to be placed on services associ-ating them to a specific physical location or to the relativelocations of other services. This is because correct executionof an application may only be possible if sensing servicesare provided by nodes surrounding the physical phenomenon.Such real-world integration requires a dynamic service con-figuration mechanism. Dynamic service configuration instan-tiates the service graph by satisfying constraints, binding theservices together, checking for any constraint violations, andreconfiguring the application when a violation is found.

We have identified several different types of constraintsthat can be placed in the service graph. Depending on thescope of the constraint, it can be atomic (applying to a singleservice) or compositional (applying to a group of services).Constraints can be further categorized as either property-basedor resource-allocation-based. Property constraints specify arelation between the properties of the scoped services, whileresource-allocation constraints define a relation between nodesthat provide the scoped services. For example, ’the node pro-viding SERVICE-A must have power level more than 85%’ is anatomic property constraint, while ’SERVICE-A and SERVICE-B must run on the same node’ is a compositional resource-allocation constraint.

An important constraint for real-world integration is en-close. The constraint ENCLOSE(L) over S = {s1, s2, s3},specifies that the location L must be enclosed by the sensornodes that provide services s1, s2 and s3. The definition ofENCLOSE varies for different sensor domains. For example,one domain can define an enclosed region to be the overlap ofmember sensing ranges. The enclosed region in case of camerasensors with orientation and limited field-of-view (FoV) is theintersection of FoVs recorded by all member cameras.

We model service graph configuration as a constraint sat-isfaction problem (CSP). A feasible solution to the CSP isthe provider sensor node assignment for each service in theservice graph. The main idea of the algorithm is to prune theservice graph design space as much as possible for all differenttypes of constraints, followed by backtracking until a feasiblesolution is found. The specific pruning method depends on

the constraint under consideration. Additional details on types,representation, and satisfaction of service constraints can befound in [8].

V. THE OASIS MIDDLEWARE

We have developed a suite of middleware services thatsupport the programming model features presented in SectionIV. The OASiS middleware comprises a set of services whichincludes a Node Manager, Composer, Service Discovery Pro-tocol, and Object Manager. Figure 2 shows the relationship be-tween the OASiS middleware and the sensor network. Figure3 shows the connections between the different middleware ser-vices and domain services at the sensor node level. Note that

Fig. 2. Middleware

Figure 3 follows the TinyGALS [1] notation of actors, ports,components, and interfaces. Each of the middleware servicesare implemented as TinyGALS actors. Actors communicateasynchronously by placing messages on their output ports. Theoutput ports are connected to the input ports of other actors,and the messages are transferred to the event queues of theseinput ports. The scheduler removes each message from theevent queue and calls the method linked to the input port,passing the message as its argument. Components residinginside an actor communicate using synchronous method calls.

Fig. 3. Middleware node architecture

Node Manager: The Node Manager is responsible formessage routing between services, both local and remote, andis essentially a dispatching service. The Node Manager sendsand receives radio messages using the sender and receivercomponents, respectively. All messages handled by the NodeManager contain a control structure which contains source anddestination node IDs (2 bytes each), source and destinationservice IDs (1 byte each), and message type (1 byte). The NodeManager resolves the appropriate destination for the messagebased on this control structure and forwards the message tothe proper node.

Service Program memory(bytes)

Required RAM(bytes)

Node Manager 8500 367Service Discovery Protocol 3858 313Composer 8036 509Object Manager 3560 151GALSC queues & ports 702 1013Total 40248 2820

TABLE IIMPLEMENTATION CODE MEMORY REQUIREMENTS

Service Discovery: The Service Discovery module im-plements the service discovery protocol described in sectionIV. The component locates domain services by broadcasting aservice request message. The request message contains the IDof the desired service, as well as the ID of the node requestingit. Any node providing the requested service will return areply message containing its ID, and other node attributes.This information gets recorded in the Discovered ServicesRepository for rapid future access.

Object Manager: The Object Manager is responsible for1) parsing the object-code byte string, 2) detecting the objectcontext and evaluating the object creation condition at eachsample period, 3) invoking the object creation protocol andowner election algorithm, and 4) maintaining the object statevariables and evaluating the migration condition. Essentially,the Object Manager implements the object-centric program-ming described in section IV.

Composer: The Composer is responsible for 1) parsingthe service graph and sending service requests to the Ser-vice Discovery module, 2) instantiating a service graph bysatisfying all specified constraints, and 3) creating a bindingmessage for each instantiated service in the service graph. Thebinding message informs each service where to send its outputdata. The constraint satisfaction and dynamic reconfigurationfunctionalities of the Composer facilitates the ambient-awareprogramming paradigm of OASiS.

Prototype Implementation

We implemented our middleware on the Mica2 mote hard-ware platform [10], running TinyOS [11]. The code wasdeveloped using galsC [1], a GALS-enabled extension of nesC[12], the programming language for the motes. Table I listseach middleware service, with its code size and memoryrequirements. These memory requirements are sufficient forexecuting an application on the motes, which has approxi-mately 128 KB of programming memory and 4 KB of RAM.It should be noted that these components can be optimizedto further reduce memory size, however there is a trade-offbetween an application’s compactness and its robustness.

VI. CASE STUDY: HEAT-SOURCE TRACKING

As a concrete example of using OASiS, we consider asimplified indoor sensor network for tracking a heat source.The case study can be viewed as an example of a moregeneral class of applications for tracking an object such as avehicle or a chemical cloud. Tracking is a representative sensornetwork application that illustrates a number of interestingchallenges, such as application-specific QoS metrics including

detection accuracy and latency, in-network data aggregation,and ambient-aware adaptation.

Fig. 4. Experimental Setup

Our experimental setup consists of the sensor networkshown in Figure 4. There are five sensor nodes in the fieldeach having a unique ID. Each node also contains a numberof pre-loaded services. Table II summarizes the sensor nodeattributes. The heat source follows the trajectory along the pathshown in the figure. The path is a straight line from [180, 180]to [670, 670] with Gaussian process noise (N [0, 10]).

Node ID Position Preloaded Services143 [200 0] READ TEMP, NOTIFY113 [0 500] READ TEMP, NOTIFY, LOCALIZE TRACK109 [700 400] READ TEMP, NOTIFY101 [400 800] READ TEMP, NOTIFY109 [800 1000] READ TEMP, NOTIFY

TABLE IIEXPERIMENTAL SETUP

The object context is set to “TEMPERATURE ≥ 30”. Theobject FSM consists of a single mode with a service graphshown in Figure 5. Sensor nodes equipped with a temperature

Fig. 5. Heat-source tracking applicationsensing service, called READ TEMP, are capable of samplingthe local temperature, which indicates the proximity of the heatsource. READ TEMP is a wrapper service for the temperaturesensing component on the sensor nodes. Once a heat sourceis detected, three temperature sensing services report theirlocation and temperature measurement to a node providingthe localization service, called LOCALIZE TRACK, which cal-culates the estimated heat source location based on the sensorinput data and the previous estimate. For this experiment, weimplemented the localization service as an extended Kalmanfilter. The localization service sends the location estimate to

a notification service, NOTIFY, which reports the estimatedlocation to the user.

Constraints are associated with each service, limiting thenumber of allowable application configurations. The alldiffer-ent constraint shown in Figure 5 on the three READ TEMPservices requires them to be on three different sensor nodes.The enclose-fire constraint requires the locations of the threeREAD TEMP provider nodes to surround the heat source. Byspecifying such geometric constraints we can improve theprobability of localization accuracy. Atomic constraints on allthe services (not shown) require the provider nodes to have aminimum amount of energy, providing the application with adegree of power-awareness.

In addition to property and resource-allocation constraints,quality of service (QoS) constraints can be specified in anapplication. For our tracking example, an application-specificQoS constraint requires the variance of the location estimatefrom the localization service to be below a certain threshold.

Our goal is to demonstrate the feasibility and effectivenessof OASiS to create, maintain, and migrate an object in theexample object-centric tracking application. We present thenumber of messages communicated, which is an indicator ofbandwidth utilization and energy consumption for the sensornode. We also present the delay for each stage, which indicatesthe responsiveness of the application.

Experiment 1: Object creation and application execution

The heat source is originated at [180, 180]. Node 143 and113 register temperatures higher than the detection thresh-old and start the object creation protocol. Since node 143registered a higher temperature, it is elected as the object-node and instantiates an object. The object then parses theobject-code, retrieves the service graph for the current objectmode, and initiates dynamic service configuration. Dynamicservice configuration includes service discovery, constraintsatisfaction and service binding. The application is configuredby invoking instances of the READ TEMP service on nodes143, 113, and 109, the LOCALIZE TRACK service on node 113,and the NOTIFY service on node 143. Once the service graphis configured, application execution commences. The numberof message transmissions for object creation and applicationconfiguration is summarized in table III. The delay for objectcreation and application configuration is 2000 and 3000 timeunits, respectively (1024 time-units = 1 second). The timedelay for each action depends on predefined timeout values;owner-election timeout for object creation, and service config-uration timeout for service graph configuration. The timeoutvalues must be large enough to ensure completion of the objectcreation and application configuration processes, but smallenough to respond rapidly to the monitored phenomenon, andwere selected based on experimental tests.

Experiment 2: Object migration

Once the physical object moves out of the enclosure ofnodes 143, 113, and 109, the variance in the location estimatestarts to grow. This increase in location estimate variance

number of messagesobject creation 5 (owner-election messages)service graph configuration 15 (3 service request messages)

(9 service information messages)(3 service binding messages)

TABLE IIIEXPERIMENT 1 RESULTS

causes a QoS violation and triggers object migration. Aspart of the migration protocol, node 143 starts a new ownerelection by broadcasting a migration message. Nodes replyto the migration message with their most recently sampledtemperature values. The current owner elects the node with thehighest temperature value as the migration destination, sendsthe object to it, and unbinds all other services. In this case,node 143 sends the object to node 109. Table IV presentsthe number of messages communicated for object migrationand service graph unbinding. Object migration latency isapproximately 2000 time units.

number of messagesobject migration 8 (5 migration messages)

(1 object-migration)(1 object-migration ack)(1 object-migration notification)

service graph unbinding 3 (un-binding messages)

TABLE IVEXPERIMENT 2 RESULTS

Our experiments indicate that OASiS incurs an overheadon the number of messages required and the time delay forobject creation, maintenance, migration and service graphmaintenance. The tables above demonstrate that the number ofmessages communicated is reasonably small. The admissibletime delays, which are dependent on various timeout intervalsexhibit the responsiveness of our ambient-aware OASiS.

A comparative analysis of OASiS with EnviroTrack [13]for our tracking case study is presented in [14], along witha scalability analysis based on comprehensive simulations.Currently, we are developing a target tracking application fornetworks with tens of sensor nodes.

VII. RELATED WORK

Recently, the WSN community has seen the emergence ofa diverse body of macroprogramming languages, frameworks,and middleware which provide solutions for various aspectsof sensor network programming [3].

SONGS [15] is a declarative service-oriented programmingmodel which dynamically specifies application functionalityin response to user-generated queries. While this techniqueworks well as an information retrieval system, SONGS wasnot designed to alter its behavior based on a change inenvironmental conditions.

The object-centric paradigm has been successfully usedin the EnviroSuite programming framework [9]. EnviroSuiteand OASiS provide a similar layer of abstraction to theapplication developer, however by employing a SOA, OASiS isable to incorporate aspects of modular functionality, resourceutilization, and ambient-awareness more efficiently.

Ambient-awareness is the primary focus of AmbientTalk[2]. The AmbientTalk programming language provides primi-tives for ambient-aware application behavior, however its useis intended for mobile ad hoc networked devices that are moreresource-constrained than the motes.

Agilla [16] adopts a mobile agent-based paradigm. Au-tonomous agents, each with a specific function, are injectedinto the network at run-time, a technique referred to asin-network programming. For this approach, the underlyingnetwork middleware is uploaded once onto the node hardware,after which applications can be swapped out or reconfiguredat any time, even after the nodes have been geographicallydispersed in the field. In-network programming in Agilla isrealized using a virtual machine instruction set architecturebased on that of Mate [17].

The Abstract Task Graph (ATaG) [18] is a macroprogram-ming model which allows the user to specify global applicationbehavior as a series of abstract tasks connected by datachannels for passing information between them. Currently, theATaG is only a means for describing application behavior.A model interpreter must be employed to decompose thisbehavior to node-level executable code. In addition, the ATaGprovides no means for delegating tasks to sensor nodes whichsatisfy specific property or resource constraints.

VIII. DISCUSSION

The ability to specify application behavior from an object-centric viewpoint in terms of modular dataflow blocks makesOASiS a powerful tool for WSN programming. The use of aservice-oriented architecture benefits all aspects of the applica-tion development process. Application functionality is neatlydistributed across the network as services with well-definedinterfaces which are easily discovered and invoked. Similarly,middleware functionality is bundled into services which usethe same invocation mechanisms as their domain service coun-terparts. The service-oriented architecture provides efficientsolutions for many WSN programming challenges. Dynamicnetwork topology, heterogeneity, and data aggregation issuesare simplified due to service modularity and autonomy. Byfollowing the object-centric programming paradigm, OASiSprovides the application developer with a layer of abstractionthat simplifies programming and reduces the opportunity fordeploying error-prone code. Object-centric programming is alogical approach because most WSN applications are driven bythe state of the physical object. The object’s internal function-ality such as creation, migration, and destruction are handledby the run-time system, leaving the developer to focus solelyon the application’s overall behavior. Programming from theviewpoint of the object also facilitates real-world integrationand maintaining quality of service guarantees. This is becausethe application is driven by the object, which monitors and re-acts to changes in the environment. The ambient-aware OASiSmiddleware supports application development by providingprotocols for service discovery, constraint satisfaction, andcommunication. Furthermore, these protocols ensure efficient

resource utilization and were designed to function in thepresence of a dynamic network topology.

At present, the OASiS middleware only provides support formanaging a single object at a time. This functionality can begreatly enhanced by enabling the detection of multiple objects,of multiple object contexts. Such a mechanism should becapable of disambiguating between two similar objects in closeproximity to each other. The volatility of communication linksin WSNs necessitates reliable communication failure detectionand recovery mechanisms. Failures can occur for various rea-sons including network congestion, insufficient transmissionpower, transmission interference, and node dropout. Becausemost WSN applications must exchange data in an efficient andtimely manner, handling these types of failures gracefully isessential. Although the OASiS middleware currently tacklescertain aspects of dynamic network behavior, it requires arobust failure detection component to allow an application tocontinue execution in the presence of unpredictable networkbehavior. This is the subject of our current work.

REFERENCES

[1] E. Cheong and J. Liu, “galsC: A Language for Event-Driven EmbeddedSystems,” in DATE, 2005.

[2] J. Dedecker, T. V. Cutsem, S. Mostinckx, T. D’Hondt, and W. D. Meuter,“Ambient-Oriented Programming,” in OOPSLA, 2005.

[3] S. Hadim and N. Mohamed, “Middleware: Middleware Challenges andApproaches for Wireless Sensor Networks,” in IEEE Distributed SystemsOnline, vol. 7, no. 3, 2006.

[4] Multi-Dimensional Separation of Concerns: Software Engineer-ing using Hyperspaces. IBM Research. [Online]. Available:http://www.research.ibm.com/hyperspace/

[5] G. Karsai, J. Sztipanovits, A. Ledeczi, and T. Bapty, “Model-IntegratedDevelopment of Embedded Software,” in Proc. IEEE, vol. 91, no. 1,2003.

[6] E. Cheong, J. Liebman, J. Liu, and F. Zhao, “TinyGALS: A Program-ming Model for Event-driven Embedded Systems,” in SAC, 2003.

[7] P. Engelstad and Y. Zheng, “Evaluation of Service Discovery Architec-tures for Mobile Ad Hoc Networks,” in WONS, 2005.

[8] I. Amundson, M. Kushwaha, X. Koutsoukos, S. Neema, and J. Szti-panovits, “Efficient Integration of Web Services in Ambient-awareSensor Network Applications,” in BaseNets, 2006.

[9] L. Luo, T. Abdelzaher, T. He, and J. Stankovic, “EnviroSuite: AnEnvironmentally Immersive Programming System for Sensor Networks,”in TECS, 2006.

[10] TinyOS Hardware Designs. U.C. Berkeley. [Online]. Available:http://www.tinyos.net/scoop/special/hardware#mica2

[11] P. Levis and et. al., “The Emergence of Networking Abstractions andTechniques in TinyOS,” in NSDI, 2004.

[12] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler,“The nesC Language: A Holistic Approach to Networked EmbeddedSystems,” in PLDI, 2003.

[13] T. Abdelzaher and et. al., “Envirotrack: Towards an environmentalcomputing paradigm for distributed sensor networks,” in ICDCS, 2004.

[14] I. Amundson, M. Kushwaha, X. Koutsoukos, S. Neema, and J. Szti-panovits, “OASiS: A Service-Oriented Middleware for PervasiveAmbient-Aware Sensor Networks,” Institute for Software IntegratedSystems, Vanderbilt University, Tech. Rep. ISIS-06-706, 2006.

[15] J. Liu and F. Zhao, “Towards Semantic Services for Sensor-RichInformation Systems,” in Basenets, 2005.

[16] C.-L. Fok, G.-C. Roman, and C. Lu, “Rapid Development and FlexibleDeployment of AdaptiveWireless Sensor Network Applications,” inICDCS, 2005.

[17] P. Levis and D. Culler, “Mate: A Tiny Virtual Machine for SensorNetworks,” in ASPLOS X, 2002.

[18] A. Bakshi, V. Prasanna, J. Reich, and D. Larner, “The Abstract TaskGraph: A Methodology for Architecture-Independent Programming ofNetworked Sensor Systems,” in EESR, 2005.