1

An Object-Centric Programming Framework forAmbient-Aware, Service-Oriented Sensor Networks

Manish Kushwaha, Isaac Amundson, Xenofon Koutsoukos, Sandeep Neema, Janos SztipanovitsInstitute for Software Integrated Systems (ISIS), Vanderbilt University{manish.kushwaha,isaac.amundson,xenofon.koutsoukos}@vanderbilt.edu

Abstract— Classical programming languages are too low-leveland not well-suited for large scale sensor network applications.Volatile connections and dynamic network topologies render thedevelopment of sensor networks very complex. In this abstract,we describe our current work on a service-oriented frameworkbased on object-centric, ambient-aware programming. Object-centric refers to the programming model wherein objects arefirst class elements that represent external physical entitiesallowing the application developer to program at a higher levelof abstraction. Ambient-aware is a paradigm that incorporatesnetwork volatility into the programming model. We outline sucha framework and describe the main individual components.

I. I NTRODUCTION AND MOTIVATION

Wireless sensor networks (WSNs) are inherently dynamic innature due to node mobility, failure, and unreliable communi-cation links. It is therefore imperative that WSN applicationsconsider dynamic network topology in order to ensure theircorrect execution. Unfortunately, tackling the issue of dynamicnetwork behavior places a substantial burden on the program-mer. In addition to an application’s core functionality, theprogrammer must implement low-level WSN operations suchas robust communication protocols, resource managementalgorithms, and fault tolerance mechanisms. Not only does theimplementation of these components require substantial timeand 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 abstract, we propose an object-centric ambient-aware programming framework, enabling the programmerto develop WSN applications without having to deal withthe complexity and unpredictability of underlying networkdynamics. In object-centric programming, objects are firstclass programming elements representing physical phenomenabeing monitored by the network. The basic idea behind sucha framework is to provide programmers with a higher levelof network abstraction, allowing applications to be developedfrom the viewpoint of the object.

Object-centric programming can be used for a variety ofapplications such as mobile vehicle tracking, fire detection andmonitoring, and distributed gesture recognition [1]. Gesturerecognition on a moving object requires logical entities forkeeping track of the object collaborating with image pro-cessing components as well. A typical sensor network willconsist of a series of slightly overlapping video surveillancenodes. When a human target is detected, the applicationspawns a tracking agent, which migrates across the network

following the real-world object. Meanwhile, image-processingcomponents are employed to identify the object’s varioushand movements and facial expressions. These algorithms aretypically resource intensive and require collaboration amongseveral nodes. While monitoring the object, the tracking agentmust simultaneously locate various remote image processingcomponents, and forward collected imaging data. After imageprocessing, other components will then use the results toperform any necessary actions.

Object-centric programming by itself does not address theissues of network failures and dynamic network topology.The programming model must be enhanced for encompassingthe dynamics of wireless networks and if possible, provideguarantees for the correct operation of software applications.Communication failures in traditional application program-ming are handled on an individual basis as exceptional events.In WSN programming, communication failures are not excep-tions, but normal operational behavior, and must therefore betreated as such. Ambient-oriented programming has emergedas a paradigm for mobile computing [2] and provides severalcharacteristics that are useful for robust sensor network ap-plications. The basic idea of ambient-aware programming forsensor networks is dynamic service discovery initiated by themonitored object in order to manage the required resources inthe changing network topology. Further, such objects shouldbe reflective to allow for reconfiguration and error recovery,organize the distribution of collaborative tasks, and ensure thatthe application cannot be blocked, for example, due to a linkfailure.

To develop such a programming paradigm, our frameworktakes a service-oriented approach to behavioral decomposition.In a service-oriented WSN application, each activity (i.e. sens-ing, analysis, aggregation, service discovery) is implementedas a separate service. The advantages of using a service-oriented architecture for WSN applications are similar tothose of web-services. Services are modular, autonomous, andhave well-defined interfaces that allow them to be described,published, discovered, and invoked over a network. Theseproperties permit services to be dynamically composed intocomplete applications. Because many WSN applications willconsist of multiple services on multiple nodes, planning,scheduling, and service discovery mechanisms are built in tothe framework. These mechanisms are designed to functioneffectively in the presence of unreliable communication links.

The object-centric paradigm has been successfully usedin the EnviroSuite programming framework [3]. EnviroSuite

2

provides a high level of abstraction, however its modularitycan be enhanced following a service-oriented approach foradding software components. In EnviroSuite, fault-tolerance isachieved by employing periodicheartbeatmessages to nodessurrounding an object of interest and can be improved byincorporating ambient-aware functionalities.

II. PROGRAMMING FRAMEWORK

Fig. 1. Architecture

In our proposed framework (Figure 1) there are four maincomponents, viz. end-user programming interface, serviceplanner, network service scheduler and node manager.Programming interface is responsible for injecting servicerequests into the sensor network. The end user writes anobject application using the services registered in the servicerepository. The service repository keeps a registry of all theservices discovered in the network. The repository can besimilar to the UDDI registry that is used for most web-services.The output of this component is a service request in a service-request-query-language.Service planner takes the service request as the input andgenerates a service graph of constituent services listed inservice repository. In general, a service request isexpandedinto constituent services until no more services need to beexpanded. Services are expanded based on the inputs theyrequire to run.

Consider a vehicle tracking application in which the userwishes to track any vehicle in an area of interest. Figure 2shows the service graph for the vehicle tracking service. Theservice requires vehicle classification and position as inputs.A vehicle classification service provides classification andposition data but requires a logical object for the vehicle. Avehicle is sensed by a vehicle sensing service, after which thelogical object is created.Network service scheduler(NSS) will schedule services atthe sensor nodes that provide target sensing functionalitieswhile satisfying certain constraints, for example on the numberand locations of the nodes. NSS requires runtime informationof the services provided by nodes as well as their properties,such as location, remaining power, etc. The output of NSSconsists of service configuration messages which are sent tonodes for composing the service graph.

Fig. 2. An example service graph and its schedule on sensor nodes

Node manager is responsible 1) configuring the node ser-vices based on a configuration message, 2) initiating servicediscovery, and 3) managing the local runtime service andresource information required by the NSS. The node managerwill initiate service discovery to locate the services to runon the object following the current service. An integral partof the node manager is aservice discovery protocol. Thenode running service discovery sends out a publish messageindicating its interest in discovering services in the network.All the nodes that receive the message respond with aninformation message containing information for the availableservices and the cost for using these services, for example,with respect to power. The receiving node processes thisinformation and builds a local service database.

III. I MPLEMENTATION

Currently, we are developing the runtime infrastructure thatis necessary for supporting the execution of object-centric,ambient-aware applications. Our target platform is Mica motesrunning TinyOS. The services include object related servicessuch as objection creation, management, and migration serviceas well as node manager and network level components suchas network service scheduler, service planner, and servicerepository. We use TinyGALS [4] for sensor node program-ming because it provides an actor abstraction for sensor nodesthat handles elegantly asynchronous communication. Usingthe actor abstraction provided by TinyGALS, we can employactors as the building blocks of services.

REFERENCES

[1] C. H. Lin, T. Lv, W. Wolf, and B. Ozer, “A peer-to-peer architecturefor distributed real-time gesture recognition,” inIEEE InternationalConference on Multimedia and Expo (ICME), 2004.

[2] J. Dedecker, T. V. Cutsem, S. Mostinckx, T. D’Hondt, and W. D. Meuter,“Ambient-oriented programming,” inOOPSLA ’05: Companion to the20th annual ACM SIGPLAN conference on Object-oriented programming,systems, languages, and applications, 2005.

[3] L. Luo, T. Abdelzaher, T. He, and J. Stankovic, “Envirosuite: Anenvironmentally immersive programming system for sensor networks,”in ACM Transaction on Computational Logic, October 2005.

[4] E. Cheong, J. Liebman, J. Liu, and F. Zhao, “Tinygals: a programmingmodel for event-driven embedded systems,” inSAC ’03: Proceedings ofthe 2003 ACM symposium on Applied computing, 2003.