Qiu JF, Li D, Shi HL et al. EasiSMP: A resource-oriented programming framework supporting runtime propagation of

RESTful resources. JOURNAL OF COMPUTER SCIENCE AND TECHNOLOGY 29(2): 194–204 Mar. 2014. DOI

10.1007/s11390-014-1422-0

EasiSMP: A Resource-Oriented Programming Framework Supporting

Runtime Propagation of RESTful Resources

Jie-Fan Qiu1,2 (邱杰凡), Dong Li1,∗ (李 栋), Hai-Long Shi1,2 (石海龙), Chen-Da Hou1,2 (侯陈达)and Li Cui1 (崔 莉)

1Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100190, China2University of Chinese Academy of Sciences, Beijing 100049, China

E-mail: {qiujiefan, lidong, shihailong, houchenda, lcui}@ict.ac.cn

Received November 18, 2013; revised January 21, 2014.

Abstract In order to simplify programming for building sensor networks, macro-programming methods have been pro-posed in prior work. Most of them are designed for the dedicated networks and specific scenarios where devices are mostlyhomogeneous. Nevertheless the methods rarely consider those shared networks which are composed of heterogeneous de-vices, e.g., sensors, actuators, mobile devices, and share resources among themselves. In this paper, we present EasiSMP, aresource-oriented programming framework for these shared networks and generic application scenarios. In this framework,the devices and their functionalities are abstracted into RESTful virtual resources (VRs) each of which is labelled by a uni-form resource identifier (URI). The post-deployment VR can be globally accessed and reused to propagate new resource(s)at runtime. To support the resource propagation, programming primitives are proposed and a virtual resource engine (VRE)is studied. To perform evaluation, EasiSMP is deployed into a relic monitoring network. Experimental results show thatprogramming using Ea-siSMP is concise, and the average deployment overhead is decreased by up to 27% compared withthe node-level programming.

Keywords macro-programming, RESTful virtual resource, resource propagation, cloud-sea computing

1 Introduction

Many prior researchers have studied a large numberof applications deployed in shared networks which arecomprised of heterogeneous sensors, actuators, mobiledevices and cloud resources. However, in such sharednetworks, it is difficult to implement complex coordi-nation behaviors and construct various applications us-ing traditional node-level programming methods. Al-though some macro-programming frameworks[1-4] havebeen proposed to simplify the programming procedureand reduce the programming workload, they are de-signed for dedicated networks or specific scenarios. Inother words, most networks belong to a certain per-son or an affiliation who also assigns which applicationsrunning on the networks. Hence traditional macro-programming frameworks can guarantee concisely pro-gramming via predefining macro functions, designedconsidering the features of specific scenarios.

Meanwhile, many researchers attempted to inte-grate multiple separated networks into one compositeapplication[5-7]. Their researches demonstrate that theresource-oriented architecture (ROA) can establish aunified connectivity for shared networks and providea logical objective built on top of the connectivity.Furthermore, constrained web-like protocols based onRESTful style[8] are booming and successfully appliedin cross-network applications[9-10]. In these researches,sensors and actuators are abstracted into independentRESTful resources and located by uniform resourceidentifiers (URIs).

In this paper, we seek to merge the merits of macro-programming and resource-oriented architecture forsynergistically integrating resources in different sharednetworks. At the same time, the proposed frameworkwill face generic scenarios where various kinds of appli-cations exist, so it is necessary to provide users withcapability of defining macro functions rather than pre-

Regular PaperThis research is supported by the Strategic Priority Research Program of the Chinese Academy of Sciences under Grant No.

XDA06010403, the International Science and Technology Cooperation Program of China under Grant No. 2013DFA10690, the NationalNatural Science Foundation of China under Grant No. 61003293, and the Beijing Natural Science Foundation under Grant No. 4112054.

∗Corresponding Author©2014 Springer Science+Business Media, LLC & Science Press, China

Jie-Fan Qiu et al.: EasiSMP: A Resource-Oriented Programming Framework 195

defining macro functions by framework designers. Theuser-defined macro functions further help the user effi-ciently construct complex applications. To achieve thisgoal, we present a novel resource-oriented programmingframework — EasiSMP, which supports runtime re-source propagation to provide users an efficient mannerto define macro functions. With respect to the resourcepropagation, the new created resource as a macro func-tion can be directly derived from the current availablepost-deployment resources by reusing their functionali-ties. Once the resource has been deployed, it also canbe used to propagate other resources by sharing its localfunctionalities at runtime.

EasiSMP provides three key elements for program-ming the heterogeneous networks. First, it provides aprogramming abstraction: virtual resource (VR). EachVR represents one or a set of heterogeneous devicesand their functionalities. Second, it provides program-ming primitives to dynamically list, create, remove andmodify VRs for resource propagation. Both the pro-gramming abstraction and primitives are realized to ef-ficiently integrate separated heterogeneous devices andtheir functionalities. Third, the virtual resource engine(VRE), a runtime system, is designed to automaticallycontrol and manage VRs during the programming andrunning phases.

We utilize EasiSMP to construct six applications forthe relic monitoring network[11] installed in the Forbid-den City. We provide the source codes of these appli-cations to demonstrate the programming conciseness ofEasiSMP. Besides, we perform extensive experimentsto verify its performance in code size, application de-ployment overhead, and execution timeline, i.e., verifyEasiSMP’s advantages in programming conciseness anddeployment efficiency.

The reminder of this paper is organized as follows. InSection 2, we give an overview of EasiSMP. In Section3, we detail the EasiSMP implementation. In Section4, we give source codes of applications for a monitoringnetwork and evaluate EasiSMP based on these appli-cations. In Section 5, we discuss the related work andconclude this paper in Section 6.

2 Overview of EasiSMP

2.1 Cloud-Sea Heterogeneous NetworksArchitecture

The cloud-sea heterogeneous network is a typicalshared network. It generally includes three types ofdevices: sea-end device (sensor or actuator), sea portal(gateway or mobile device connecting sea-end deviceto Internet), and cloud-end device (PC or server). Sea-end devices usually have a lightweight embedded opera-tion system such as TinyOS[14] or Contiki[15]. They ex-

change information with the sea portal through multi-hop wireless communication.

The sea portal is made up by powerful gatewayor mobile devices which are connected to Internetand have their own IP addresses. As one literaturementioned[12], two solutions of accessing RESTful re-sources are feasible: direct web connectivity on the de-vice or through a proxy. In both solutions, the gate-way must exist for protocol translation. On the otherhand, mobile phone or tablet is taken as an alterna-tive sea portal. We show an example in Subsection 4.2,which demonstrates that one mobile device interactswith sea-end devices and they cooperatively completea localization task.

The cloud-end devices such as servers and PCs pro-vide visualization interaction with common users, andown almost boundless storage capacity and unlimitedcomputing power. They maintain and provide globalspecification information for all devices and virtual re-sources.

2.2 Programming Abstraction: RESTfulVirtual Resource

RESTful virtual resource (VR) is abstracted fromcomponents of the cloud-sea heterogeneous networkexample of VR including device, functionality or evencombination of available VRs. By using EasiSMP, morecomplex membership of virtual resources can be crea-ted.

The available VR usually is composed of code bi-nary, handle, status and URI. The code binary (binaryfor short) can be executed by the specific device and isgenerated from the compiled source code of EasiSMPapplication shown in Subsection 4.2. The handle is theinternal address of the binary and stored in the resourceattributes (RAs). The RA also saves the status of VRand is maintained by the VRE at runtime. At last, theURI points to the RA. The user can get the specificinformation of VR and utilize its functionalities via theURI.

The previous programming abstractions presented inmacro-programming frameworks such as uSETL[1] andPhysicalnet[2] mainly address two issues: how to reusecodes in order to simplify the application development;or how to reuse the low-level devices for supporting mul-tiple applications. In EasiSMP, it is the first time thathigh-level multiplexing is realized through the runtimeresource propagation.

2.3 Programming Primitives of VirtualResource

Corresponding to primitives used in traditionalRESTful HTTP resources, EasiSMP provides four pro-

196 J. Comput. Sci. & Technol., Mar. 2014, Vol.29, No.2

gramming primitives to support resource propagation:GETRES obtains the information of each VR, such asdevice ID or programming element handle (Subsection3.2). PUTRES creates VRs in two tiers: in the first tier,one device needs to download the new binary of the VRand install it. In the second tier, the device only needsto rebind the existed binary of VR with a specific URI.Correspondingly, DELETERES means to unbind the exi-sted binary of VR from URI or overwrite the binary ofVR. POSTRES updates status (e.g., increasing samplingfrequency) or modifies the functionality of an availableVR (e.g., changing trigger condition).

2.4 Virtual Resource Engine for Management

Virtual resource engine (VRE) manages and controlsVRs. It is a runtime system which is distributed andrunning on sea portal and sea-end devices, as shownin Fig.1. A VRE is hierarchically organized and lo-cated by a URI. During the programming phase, theVRE provides search functionality based on resourceattributes (RAs) of VRs running on the device (dis-cussed in Subsection 3.4) and helps the user select asuitable VR. During the running phase, the VRE dy-namically maintains RAs according to the device sta-tus, and executes the set of operations launched by theprogramming primitives.

3 EasiSMP Design and Implementation

3.1 Physical Component Abstraction

Previous work[9-10] has proposed several solutions toshare the sensor data, generated by these heterogeneousdevices, as a resource. However they are not sufficientto define and control the behavior of the networks. Inthis subsection, we discuss how to abstract componentsexisting in the cloud-sea networks into meaningful andcontrollable programming abstractions.

The abstraction procedure of a physical componentcan be summarized as the following three steps. First,a device registers itself in a local VRE. The local VREgenerates a summary profile according to a local RA.And then, the local VRE registers itself into an upper-level VRE and transfers the summary profile. At last,the upper-level VRE binds the local VRE with a spe-cific URI pointing to the summary profile.

As shown in Fig.2, the VR’s URI contains two parts:the absolute/parametric path and the element of VR.The absolute path means a specific VR maintained bythe VRE. The parametric path allows users to make afuzzy selection in terms of given attribute values. Thisselection requires VREs in different levels to recursivelyretrieve the RA and search the suitable VR. If one VRis not directly registered in current VRE, retrieval re-quirement is transferred into the lower level VREs.

Fig.1. Cloud-sea heterogeneous networks architecture.

Jie-Fan Qiu et al.: EasiSMP: A Resource-Oriented Programming Framework 197

Fig.2. EasiSMP uniform resource identifier.

Using the parametric path, a group of replaceableVRs are possibly to be found. The VRE will select oneVR which meets the attribute requirements defined bythe path. In other words, the RA of the VR must satisfythese requirements. Since there possibly exist severalsuitable VRs, the VRE also provides a dynamical re-placing mechanism to replace the unavailable selectedVR with one from the rest of VRs. Taking measur-ing the humidity within an area as an example，by theparametric path, multiple humidity-measurement VRsin the area can work. However, only one VR is neces-sary, and the rest of them will be taken as backup.

The end of URI is the programming element of theVR. These elements can be orchestrated during the pro-gramming phase and accessed/modified during the run-ning phase. They are categorized into four types:

/variable: this element is used to save values dur-ing the program implementation.

/data: this element stores the history data, suchas previous sampling data, files and even the EasiSMPsource code.

The variable element is different from the data ele-ment. Freshness must be considered when the dataelement is accessed, because the data element may notbe saved in the device which generates it. In contrast,the former keeps the latest value which is changed inreal-time.

/driver: this element represents an inherent func-tionality fixed in the device and associated with low-level hardware, such as sending or receiving functions.

/method: this element means an acquired func-tionality. For example, one new method element canbe derived from multiple elements included by post-deployment available VRs or extending one element us-ing POSTRES primitive.

Different types of elements have different accessingtimeliness. Accessing the driver/method element needsto invoke functions immediately and generates the lat-est data under the current environment condition withthe highest real-time in all elements. The timelinessof accessing variable element is possibly affected by thesleeping mechanism widely used in resource-constrainedsea-end devices. The data element keeps the historyinformation and typically lives for the delay-toleranceapplication. For instance, we consider a cloud-sea hete-

rogeneous network involving mobile devices. If the ac-curacy of measurement result is associated with loca-tion, taking the sampling results as the data elementis possibly the most effective and efficient in the fourtypes of programming elements, because the moving de-vice is hard to timely transmit the value of variable orimplement the method or device.

3.2 Programming Language Paradigm

In EasiSMP, an application actually is packaged intoa virtual resource as shown in Fig.3, and thus con-structing a new application means to create a new VR.The structure of EasiSMP application is organized withthree parts: resource body, used and provided element.

Used{external v resource VRName =>GETRES /URI/;

external method metName=> GETRES /URI/;

external variable varName=> GETRES /URI/;

· · ·}

UsedElement

Provided {protect rw local variable varName;

public wx local method metName;

private -x local driver driName;

· · ·}

ProvidedElement

void v resource ResName{local variable varName;

local method metName() {· · ·};...

local method implement () {· · ·};PUTRES ResName /URI/;}

Resource Body

Fig.3. EasiSMP programming paradigm.

The elements of available external VR can be reusedfor creating a new VR and must be declared in the usedpart, and the new VR also provides elements declaredin the provided part. Both parts declare the participantelements in the resource propagation.

Used Element. Based on resource-oriented architec-ture, EasiSMP supports users to access method, driver,variable and data element within the external VR viaURI. By returning the handle of element, the exter-nal element is localized and bound to a local element.Meanwhile, localizing one external VR needs to bindall its provided elements.

Provided Element. Through espousing the local ele-ments, a post-deployment available VR may share itslocal functionality entity with others at runtime. Theprovided elements will be placed at the end of the URIshowing in the last line of PUTRES (as shown in Fig.3).

Taking into account the safety of devices and the pri-vacy of the resource owner, EasiSMP requires the ownerto specify the user-access right and the operation right

198 J. Comput. Sci. & Technol., Mar. 2014, Vol.29, No.2

of the provided elements. The user-access right deter-mines whether a given resource can be accessed by usersand includes three modes: public, private and protect.Under the public mode, the VR or its element(s) canbe freely accessed. A current element under the protectmode means that, except the resource owner, it is alsoavailable to the users who provide elements being em-ployed by the current element. Under the private mode,the resource owner monopolizes the elements, which areinvisible for other users.

The operation right determines whether the user canread, write or execute the element. With respect to thedata and variable element, only read and write rightsare optional. If a user has the read right, he/she canobtain content of the variable and data element. Thewrite right allows users to modify the content. For themethod element with the execution and write right, itcan be invoked by other applications and modified us-ing POSTRES. The driver element is fixed, and thus itswrite right is never active.

Resource Body. Functionalities of a VR are de-scribed in the resource body which defines the relation-ship among programming elements. EasiSMP requiresusers to declare or initiate elements before using themlike Java or C language.

In order to improve the scalability of applications,EasiSMP allows to just declare a local method elementwithout explicitly invoking or take it as an empty func-tion. For instance, a user hesitates to construct a localmethod element. He/she may first declare the elementeven without function body. The element is also locatedby a URI. In the future, he/she can on-demand bindthe URI with concrete function body through primi-tive PUTRES.

One EasiSMP application actually runs from the lo-cal method implement similar to main function in Cor C++. In this way, the user orchestrates the imple-mentation of the local and external elements. Of course,method implement is optional. Without the implementmethod, launching PUTRES still creates a special VR,which only provides functionalities to others.

At the end of the resource body, a user utilizesPUTRES to deploy application and register correspond-ing VR in one VRE located by the URI.

3.3 EasiSMP Programming Primitive

In HTTP, the uniform interface has four main primi-tives, GET, PUT, POST and DELETE. In EasiSMP, theseprimitives are rather naturally mapped into GETRES,PUTRES, POSTRES and DELETERES. Different from objecton which traditional HTTP operates, EasiSMP primi-tives operate on a conceptual functionality entity: vir-tual resource, not only files, data or device.

The primitive GETRES is used to obtain informationof VR and the element handles. For example, the userhopes to learn about the specification of VR. He/shewill launch GETRES to obtain the RA as the data ele-ment. With the symbol “=>” GETRES requests the ele-ment handle and maps the external element into a localone through the handle.

The primitives DELETERES and PUTRES remove andcreate VRs in two tiers respectively. In the first tier,DELETERES is used to overwrite binaries, and PUTRESis used to download binaries and install them. Thatwill cause large communication overhead[16], and is notenergy-efficient for frequently-updating scenarios. Inthe second tier, DELETERES only cancels the bind be-tween the existed binary of VR and its URI. And cor-respondingly PUTRES needs to rebind the existed binaryof VR with URI at low energy overhead, but the binaryof VR still exists and occupies the memory space.

Local VRE will determine how to create or deletea VR via trading the communication overhead for thememory space. This determination is transparent forusers. In our previous research, we have proposed op-timized mechanism based on cache policy[17].

The primitive POSTRES can modify VR or the pro-gramming element with the write right. Nevertheless,POSTRES is idempotent. It may harm these availableVRs. For example, if one variable element is shared bymultiple VRs, using POSTRES on the variable elementneeds to consider the data consistent problem. On theother hand, using POSTRES is useful to create a new VRvia extending available one, and this procedure spendsless energy overhead than using PUTRES. When a cur-rent VR is extended via POSTRES, the local VRE willupdate the RA and transfer the updated summary pro-file to the upper-level VREs.

3.4 Resource Attributes

Resource attributes describe the specification of VRsand are serialized as an XML document, which is de-fined by a global schema shown in Fig.4. An RA is alsotaken as a data element and located by a URI.

Each RA is associated with a specific device iden-tified by DevID and Location which is meaningfulto location-aware application involved mobile devices.The rest of RA is composed of specification of variousVRs with their used and provided elements.

Attribute EleType represents the type of element(data, variable, method, or driver). The type of elementdetermines whether the element can be read (for dataor variable) or executed (for driver or method) with theinternal address given by Handle. The flag IsFree indi-cates whether current method or driver is free. In fact,parts of methods (or drivers) are possibly periodically

Jie-Fan Qiu et al.: EasiSMP: A Resource-Oriented Programming Framework 199

〈schema〉〈element name=“ResourceAttr”〉

〈complexType〉〈sequence〉〈attribute name = “DevID” type = “integer”/〉〈attribute name = “Location” type = “string”/〉〈element name = “ProvidedElement” type = “string”/〉〈complexType〉〈attribute name = “EleType” type = “string”/〉〈attribute name = “IsFree” type = “bool”/〉〈attribute name = “Handle” type = “Intweger”/〉〈attribute name = “AccessRight” type = “Integer”/〉〈attribute name = “R/W Right” type = “Integer”/〉

〈complexType〉〈element name = “UsedElement” type = “string”/〉〈complexType〉〈attribute name = “EleType” type = “string”/〉〈attribute name = “URI” type = “string”/〉

〈complexType〉〈/sequence〉

〈/complexType〉〈/element〉〈/schema〉

Fig.4. RA global schema.

and continuously busy, such as acoustic sampling[19],or volcanic/earth quake monitoring[20]. Therefore, Ea-siSMP also provides accessible variables elements whichsave the returned value from the last invoked method.

With respect to the method with periodical and shotimplementation such as temperature sampling, thereare many recent studies to support multi-applicationconcurrently reusing devices[2,18]. In EasiSMP, mostof applications are deployed at runtime. The complexsynchronization mechanism would largely increase themanagement overhead of the system. Thus, EasiSMPutilizes the first-come, first-served (FCFS) and blockmechanism to coordinate each VR. If multiple callersconcurrently invoke the method/driver in one VR, theVRE records the caller sequence, and responds the nextcall when the current one is entirely completed. Beforethat, the rest of callers are blocked.

4 Evaluation

4.1 Experimental Setup

In this subsection, we firstly introduce the exper-iments environment. The hardware available for theexperiments includes: 1) Eight Telosb sensor nodes asthe sea-end device which draw their energy from 2AAbatteries. The sensor node has MSP430f1611 MCU, ra-

dio data rate of 250Kbps, a 48KB programming flash,10KB RAM, and 256KB external flash for storing thesampling data. The VRE running on the sensor needs8KB program flash and 2KB RAM. 2) Two ARM7boards as the sea-portal gateway which are poweredvia cable and have IP addresses. One board namedWestGW gateway is connected to the sensor nodesthrough 802.15.4 wireless manner and to the otherboard through WiFi. The other board named Wuying-Palace gateway has access to Internet and is connectedto PC. 3) One Motorola Xoom tablet as the mobiledevice connected to PC or gateway through Internet.At the same time, it can directly interact with thesesensor nodes through 802.15.4 radio micro SD-card①

which is plugged in the tablet. 4) One desktop PC asthe cloud-end device helps users geographically edit thesource code and maintains a top-level VRE Forbiden.Rest VREs run on each device and are hierarchicallyorganized as shown in the following URI (Fig.5):

Fig.5. Example of URI path.

4.2 Application Examples

In this subsection, we illustrate the source codesof EasiSMP for representative applications shown inFig.6. App(1) provides basic functionalities of singlesensor node. App(2)∼App(4) are chosen to introducethe resource propagation derived from multiple VRsSensorNode. App(5) is a more complex applicationrunning on the mobile tablet. App(6) is interesting inthat it attempts to influence the action of human be-ings according to the physical environment.

App(1) illustrates the basic components of EasiSMP.The used part of App(1) is empty, because SensorNoderuns on single sensor node and realizes the basic sam-pling and transmission functionalities, etc. In contrast,the provided part contains one method element, threebasic driver elements, and three variable elements.

The method RceivRssiVal returns the received sig-nal strength indication (RSSI) of the last received mes-sage. This method possibly needs to be modified suchas changing the gain of RSSI. Thus, this method ele-ment needs the write right. Three driver elements areabout sensing light strength, temperature and humidi-

①Spectec Zigbee SD-card, http://www.spectec.com.tw/zigbee.html, December 2013.

200 J. Comput. Sci. & Technol., Mar. 2014, Vol.29, No.2

Fig.6. EasiSMP application example for the relic monitoring network. App(1): SensorNode, App(2): ComputAvgHum, App(3):

ComputAvgTemp, App(4): ComputAvgLight, App(5): ElectronicGuide, and App(6): ControlCrowd.

ty, which are installed during initiating the device andcannot be modified, so their write rights are not ac-tive. With respect to the three driver elements, threevariable elements correspondingly save these returnedvalues from drivers and avoid the fail of invocation ofa busy driver. At the last line, the VRs are registeredin VRE Node* which locally runs on a sensor node asshown in Fig.5.

The VRs described in App(2)∼App(4) are propa-gated from App(1). They compute the average value ofhumidity, temperature and light strength respectivelyand send a warning message when an exception occurs.Since the three applications are similar, we only detailApp(4).

In App(4), external elements are bound with localmethods through GETRES and symbol “=>” (see lines1∼2). According to the URI with parametric path,VRE WuyingPalace searches VR SensorNode locatedat the west of the Wuying Palace. Then, if one driverSampleAirligh is free, its handle is reserved in an ar-ray LightSampleArray. If the driver is busy, the han-

dle of variable LightVal is still reserved in an arrayLightValArray.

Local method ComputAvgL invokes driver Sample-Airlight provided by SensorNode, and itself is alsoinvoked by other VRs. When multiple applicationsconcurrently share the method ComputAvgL, it possi-bly happens that frequently invoking SampleAirlightcauses the request timeout.

Therefore, we adopt a best-effort manner to im-plement this computation: invoking locally driverLightSampleArray[i] (App(4): line 12), or readinglight strength value from variable LightValArray[i](App(4): line 14) given that the corresponding item ofLightSampleArray is null. Considering slowly chang-ing the physical environment, sacrificing the data fresh-ness improves measurement accuracy and avoids long-time waiting.

App(5) shows the source code for electronic guide.In this application, we assume that a visitor’s mobiledevice can directly interact with these regular sensornodes. The mobile device analyzes the RSSI from mul-

Jie-Fan Qiu et al.: EasiSMP: A Resource-Oriented Programming Framework 201

tiple sensor nodes to locate itself. And then, it transfersthe location information to cloud-end PC which sendsback the location-based relic information from cloudDatabase to the mobile device. The visitors open user-access rights to allow the sensor node and gateway toaccess their devices, enriching their journal at the sametime.

In order to locate the mobile device, this applica-tion implements the following three steps : 1) explicitlyinvoking a local driver send802.15.4 to send a mes-sage to the sensor node; 2) and then, remotely callingRceivRssiVal, a method of VR SensorNode, to obtainthe radio strength of sensor node receiving; 3) finally,utilizing local method TriEdgeTracing to get the visi-tor’s location.

The VR described in App(6) is propagated fromApp(2)∼App(4) and App(5). It bridges the gap be-tween the physical environment and common visitors.With respect to the used elements, all VRs of comput-ing average value of temperature, light strength andhumidity in Wuying Palace are respectively reservedin three VR arrays. Local method IsJamCheck deter-mines whether it is necessary to warn more visitors.And then, local method Controller determines whichvisitor should be warned according to his/her currentlocation. Consequently, a congestion warning messageor a welcome message is pushed to the visitor’s mobiledevice.

App(6) is the most complicated among the six appli-cations. It integrates multiple VRs involved with sens-ing physical environment and controlling the crowd. Al-though these elements in SensorNode are not explicitlyused, App(6) also indirectly accesses them by invok-ing the method TriEdgeTracing and three methodsComputAvg*.

4.3 Application Code Size

In this subsection, we evaluate the code size ofApp(1)∼App(6). The results are presented in Table1. The code size reported here is larger than the codesize observed in Fig.5. Due to space constraints, we usea more compact code representation and omit some de-tails of methods and drivers such as IsJamCheck. How-ever, the length of codes for each application does not

Table 1. Code Size of the Six Applications

Application Lines of Code

App(1): SensorNode 93

App(2): ComputAvgHum 56

App(3): ComputAvgTemp 52

App(4): ComputAvgLight 63

App(5): ElectronicGuide 102

App(6): ControlCrowd 187

exceed 200 lines. This is an important observation thatmost part of codes are not necessarily to be rewrittenand deployed. They are directly implemented throughmultiplexing available VRs.

4.4 Application Deployment Overhead

In this subsection, we study the impact of applica-tion deployment on the communication overhead. InEasiSMP, each virtual resource is packaged into eachapplication, so we consider the communication over-head based on the execution of primitive PUTRES.

We assume that App(1), as the father resource,has been installed in sensor nodes by in-system-programming manner. We deploy App(2)∼App(6) inthe experiment environment. Actually, the process ofcreating a VR is similar to an over-air reprogramming:the execution binary is transferred and loaded into thedevice.

We also utilize a node-level programming languagesuch as C/nesC to construct each application and anover-air reprogramming method Stream[16] to deploythem. Fig.7 shows the transmitted data size in orderto deploy each application. We find the node-level pro-gramming causes high deployment overhead, because itneeds to completely transmit each part of binaries ofnew applications to different devices. In contrast, Ea-siSMP only takes into account of the functionalities ofnew applications through reusing the post-deploymentavailable VRs.

Fig.7. PUTRES communication overhead: node-level programming

vs EasiSMP.

For example, in order to deploy App(6), usingthe node-level programming actually includes five exe-cution files: three computing average values (lightstrength, humidity and temperature) for WestGW gate-way, one mobile device display for the tablet, and onecontrol crowd for WuyingPalace gateway. With respect

202 J. Comput. Sci. & Technol., Mar. 2014, Vol.29, No.2

to EasiSMP, given App(2)∼App(5) which have beendeployed, App(6) directly invokes the methods pro-vided by the available external VRs. Thus, only VRControlCrowd described in App(6) needs to be trans-ferred.

4.5 Execution Timeline

In this subsection, we illustrate the execution time-line of App(6) shown in Fig.8. The whole executionperiod can be classified into the compilation, deploy-ment, and implementation phase. The EasiSMP sourcefile is translated into execute files during the compi-lation phase, transmitted to and installed in specificdevice during the deployment phase, and actually exe-cuted in the implementation phase. The three phasesoccur on different devices. We still pre-install App(1)in the sensor node by in-system-programming man-ner. Before propagating the VR described in App(6),App(2)∼App(5) need to be deployed through wirelesscommunication.

At time point A, we input the EasiSMP source codeof App(6) into PC and compile it for 15.2 seconds. Thisphase includes launching GETRES to query informationfrom the VRE on WuyingPalace gateway (spending 1.5seconds from point A1 to point A2).

The time elapsed between point B and point C isthe deployment phase. During this phase, complied bi-naries of App(2)∼App(6) are transferred and installedin two gateways and the mobile tablet. We continu-ously change the location of the tablet. That causesunstable transmission. Therefore, although more bina-ries need to be installed in gateway than in tablet, thetime spending on tablet is 3.2 seconds longer than thaton WestGW gateway.

At point C, the method Implement of ControlCrowdon WuyingPalace gateway starts; at point D, the meth-ods Implement of ComputAvgLight, ComputAvgHum,ComputAvgTemp on WestGW gateway start. At last,the average sampling value of six sensor nodes is sentback at point E.

Then, the method IsJamcheck is immediately in-voked to update flag variable IsJam. The tablet startsto locate itself almost at same time point E. Thislocalization process requires the participatory of sen-sor nodes from point E to point e. The methodController determines whether to send warning mes-sage to the tablet at point G.

From the above timelines of the three phases, we ob-serve that during the deployment phase, binaries trans-mission costs 3.8 seconds at least. In contrast, duringthe implementation phase, the period of the data trans-mission between the fixed devices (such as gatewaysand sensor nodes) almost can be ignored. The periodof sampling data in the sensor node and the period oflocating the tablet occupy the most of the implementa-tion phase. And during the above periods, the methodimplement of ControlCrowd is actually blocked.

5 Related Work

To guarantee the global and uniform access tothe device in heterogeneous networks, various perva-sive computing frameworks were proposed. SensorAndrew[5] makes the experimentation with the ubiq-uitous computing environments simple and scalable.The development of lightweight web services like SOAPand EBHTTP have been applied in embedded devicesand sensor networks in order to improve scalability[6-7].However, these solutions are still heavy for sea-end de-vices. COAP[10] and sMAP[9] use lightweight web ser-vices to realize the RESTful architecture which allowsdevices to directly publish their data and globally ac-cess each other. However these studies lack program-ming method, so the functionalities of the system arestatic and cannot be changed.

On the other hand, traditional node-level program-ming method such as nesC[13] used with TinyOS[14], Cwith Contiki[15] provide the access to low-level hard-ware. However, the node-level programming abstrac-tion is seldom enough to easily express complex appli-cations and hard to be applied in a heterogeneous ne-

Fig.8. EasiSMP execution timeline.

Jie-Fan Qiu et al.: EasiSMP: A Resource-Oriented Programming Framework 203

twork. In order to address the issue, a number ofmacro-programming solutions were proposed. AbstractRegion[3] and Hood[4] define subset of nodes in a pro-gramming abstraction according to the physical dis-tance or the number of wireless hops. Physicalnet[2]

is a service-oriented programming framework which ab-stracts various of functionalities into each service. How-ever these programming abstractions are merely mean-ingful in the programming phase, and the user cannotglobally access and modify them in the running phase.Naturally, the available functionalities also cannot bemultiplexed by other applications. To the best of ourknowledge, EasiSMP is the first method that abstractsfunctionalities into RESTful virtual resources and sup-ports resource propagation at runtime.

Other researches, such as Pixie[21] and virtual sen-sor networks[22], also propose resource concept. In theformer work, each resource represents a physical para-meter such as CPU demand and radio bandwidth. Inthe later work, mentioned virtual resource is a changedcombination of sensor nodes with the change of themonitoring object such as poison gas. It is differentfrom EasiSMP virtual resource.

6 Conclusions

In this paper, we designed and evaluated EasiSMP,a resource-oriented programming framework which fa-cilitates the programming for the cloud-sea heteroge-neous networks. We proposed the novel programmingabstraction — virtual resource, to provide global accessto components in the networks. Through four primi-tives, EasiSMP allows users to multiplex the availableVRs and continually propagate new one at runtime.Furthermore, the management of various VRs is madepractical by the virtual resource engine.

To evaluate the performance of EasiSMP, we alsoapplied EasiSMP to the relic monitoring network in-stalled in the Forbidden City. We extended the cur-rent functionalities of the monitoring network throughdeploying new EasiSMP applications. The experimen-tal results prove that EasiSMP can satisfy the applica-tion requirements with concise programming and lowdeployment overhead. In future work, to improve theexecution efficiency, we will design more efficient syn-chronization mechanism instead of the current FCFSand block mechanism.

References

[1] Hossain M S, Alim Al Islam A B M, Kulkarni M, Raghu-nathan V. uSETL: A set based programming abstraction forwireless sensor networks. In Proc. the 10th InternationalConference on Information Processing in Sensor Networks,April 2011, pp.354-365.

[2] Vicaire P A, Xie Z, Hoque E, Stankovic J A. Physicalnet:

A generic framework for managing and programming acrosspervasive computing networks. In Proc. the 16th IEEE Real-Time and Embedded Technology and Applications Sympo-sium, April 2010, pp.269-278.

[3] Welsh M, Mainland G. Programming sensor networks usingabstract regions. In Proc. the 1st Conference on Symposiumon Networked Systems Design and Implementation, March2004, pp.29-42.

[4] Whitehouse K, Sharp C, Brewer E, Culler D. Hood: A neigh-borhood abstraction for sensor networks. In Proc. the 2nd In-ternational Conference on Mobile Systems, June 2004, pp.99-110.

[5] Rowe A, Berges M, Bhatia G et al. Sensor Andrew: Large-scale campus-wide sensing and actuation. IBM Journal ofResearch and Development, 2011, 55(1/2): 66-79.

[6] Priyantha N B, Kansal A, Goraczko M, Zhao F. Tiny web ser-vices: Design and implementation of interoperable and evolv-able sensor networks. In Proc. the 6th ACM Conference onEmbedded Network Sensor Systems, November 2008, pp.253-266.

[7] Souza L M S, Spiess P, Guinard D et al. SOCRADES: A webservice based shop floor integration infrastructure. In Proc.the 1st International Conference on The Internet of Things,March 2008, pp.50-67.

[8] Fielding R T, Taylor R N. Principled design of the modernWeb architecture. ACM Trans. Internet Technology, 2002,2(2): 115-150.

[9] Dawson-Haggerty S, Jiang X F, Tolle G et al. sMAP — Asimple measurement and actuation profile for physical infor-mation. In Proc. the 8th ACM Conference on EmbeddedNetwork Sensor Systems, November 2010, pp.197-210.

[10] Bormann C, Castellani A P, Shelby Z. CoAP: An applicationprotocol for billions of tiny Internet nodes. IEEE InternetComputing, 2012, 16(2): 62-67.

[11] Li D, Hui C L, Huang X, Zhao Z, Cui L. Application case ofwireless sensor networks: Museum. Communications of CCF,2006, 2(5): 72-74.

[12] Guinard D, Trifa V, Wilde E. A resource oriented architecturefor the Web of Things. In Proc. the 2nd International Con-ference on The Internet of Things, November 29-December1, 2010.

[13] Gay D, Levis P, Von Behren R et al. The nesC language: Aholistic approach to networked embedded systems. In Proc.the ACM SIGPLAN 2003 Conference on Programming Lan-guage Design and Implementation, June 2003, pp.1-11.

[14] Levis P, Madden S, Polastre J et al. TinyOS: An operatingsystem for sensor network. In Ambient Intelligence, WeberW, Rabaey J M, Aarts E (eds.), Springer Berlin Heidelberg,2005, pp.115-148.

[15] Dunkels A, Gronvall B, Voigt T. Contiki — A lightweightand flexible operating system for tiny networked sensors. InProc. the 29th Annual IEEE International Conference onLocal Computer Networks, November 2004, pp.455-462.

[16] Panta R K, Khalil I M, Bagchi S. Stream: Low overheadwireless reprogramming for sensor networks. In Proc. the26th IEEE International Conference on Computer Commu-nication, May 2007, pp.928-936.

[17] Qiu J F, Li D, Shi H L, Du W Z, Cui L. EasiCache: Alow-overhead sensor network reprogramming approach basedon cache mechanism. Chinese Journal of Computers, 2012,35(3): 555-567.

[18] Tavakoli A, Kansal A, Nath S. On-line sensing task optimiza-tion for shared sensors. In Proc. the 9th International Con-ference on Information Processing in Sensor Networks, April2010, pp.47-57.

[19] Cerullo M, Fazio G, Fabbri M et al. Acoustic signal processingto diagnose transiting electric trains. IEEE Trans. Intelligent

204 J. Comput. Sci. & Technol., Mar. 2014, Vol.29, No.2

Transportation Systems, 2005, 6(2): 238-243.[20] Suzuki M, Saruwatari S, Kurata N, Morikawa H. A high-

density earthquake monitoring system using wireless sensornetworks. In Proc. the 5th ACM Conference on EmbeddedNetwork Sensor Systems, November 2007, pp.373-374.

[21] Lorincz K, Chen B R, Waterman J et al. Resource awareprogramming in the Pixie OS. In Proc. the 6th ACM Confer-ence on Embedded Network Sensor Systems, November 2008,pp.211-224.

[22] Jayasumana A P, Han Q, Illangasekare T H. Virtual sensornetworks — A resource efficient approach for concurrent ap-plications. In Proc. the 4th International Conference on In-formation Technology, April 2007, pp.111-115.

Jie-Fan Qiu is currently a Ph.D.candidate of Institute of ComputingTechnology (ICT), Chinese Academyof Sciences (CAS), Beijing. He re-ceived his B.S. degree in electronicand information engineering fromHenan Normal University, Xinxiang,in 2007, and his M.Sc degree in physi-cal electronics from Zhejiang NormalUniversity, Jinhua, in 2010. His main

research interests include programming language, embeddedoperation system, sensor network, and Internet of Things.

Dong Li is currently an associateprofessor of ICT, CAS. He receivedhis Ph.D. degree in computer archi-tecture from ICT, CAS, in 2009. Hisresearch focuses on wireless sensornetworks, networked embedded sys-tem, and Internet of Things.

Hai-Long Shi is currently aPh.D. candidate of ICT, CAS. He re-ceived his B.S. degree in communica-tion engineering and his M.Sc degreein communication and informationsystem in 2008 and 2010 respectively,both from Wuhan University. Hismain research interests include em-bedded system, wireless sensor net-work, and Internet of Things.

Chen-Da Hou is currently aPh.D. candidate of ICT, CAS. Hereceived the B.S. degree in com-puter science from Xidian University,Xi’an, in 2010. His main researchinterests include embedded system,wireless sensor network, Internet ofThings, and Web of Things.

Li Cui received her undergrad-uate degree from Tsinghua Univer-sity, Beijing, and the M.Sc. degreefrom the Institute of Semiconductors,CAS. She received the Ph.D. degreein bioelectronics from the Universityof Glasgow, UK, in 1999. She re-ceived “The 100 Talents Program ofCAS” award in 2004 and is currentlya professor and the leader of an in-

terdisciplinary research group at ICT, CAS. Her current re-search is focused on sensor technology and wireless sensornetworks.