2.2.3 Service-Based Middleware
Service-based m iddlew are publishes sensor d ata to external service consum ers via service oriented interfaces. There are tw o different approaches w hich can be observed in this field. D irect Service A b straction w hich provides a proxy or gatew ay an d directly creates a service p rovider on top of a sensor device. The other ap proach is to p rovide services w hich abstract from the sensor n od e an d give access to higher-level functions such as already aggregated d ata or virtual sensors only. The O pen G eospatial C onsortium (CGC) [107] defines stan d ard s for geospatial services an d is an exam ple for how generic services can be defined. CG C divides its service platform into differ ent high-level services. Sensor O bservation Services abstract from the un d erly in g n etw ork an d offer m ethods to q u ery the netw ork. Sensor P lanning Service m anages the device inform ation about the netw ork a n d defines how to p u sh tasks to the sensors.
2.2.3.1 ^ service oriented middleware for heterogeneous sensor data man
agement (SSTREAMWARE)
SStreaMWare [53] utilises the OSGi service fram ew ork. SStreamMW are does n o t provide services linked to a particular sensor or a virtual sensor g rou p b u t offers services to q uery an d access d ata stream s of heterogeneous sensors. To provide an access to different types of sen sors, SStreamMW are introduces adapters w hich translate betw een the p ro p rietary sensor protocols an d the m iddlew are. Gateways are u sed to spatially m anage the sensor devices in a particular region. The services offered b y this approach are integrated into the OSGi fram e w ork. This uses available services such as service registry an d ser vice event-m anagem ent. SStreamMW are focuses on stream process
2 . 2 M I D D L E W A R E A P P R O A C H E S F OR S E N S O R N E T W O R K S 33
ing an d d ata continuously send by the sensors. A declarative SQL-like language is u sed to access the data.
2.2.3.2 An infrastructure for connecting sensor networks and applications
(HOURGLASS)
H ourglass [117] is a service infrastructure to interconnect sensors an d applications via services. H ourglass em ploys a publish-subscribe m echanism . The service providers pu b lish their services an d con sum ers subscribe to the relevant services. H ourglass introduces a d ata collection netw ork (DCN) w hich provides discovery of sensor nodes th a t are n o t accessible th ro u g h the internet (e.g. abstraction) an d en ables interoperability an d load-balancing betw een the heterogeneous devices. D CN m aintains several services on dedicated netw ork nodes (e.g servers). The service descriptions are pub lish ed in a service reg istry th a t stores the available services of the netw ork, a buffer service w hich buffers d ata d u rin g reconnection an d unavailability of sensor nodes, a filter service w hich perform s d ata processing on stream s an d the circuit m anager w hich defines the flow from sensor nodes th ro u g h filters to the application endpoint. H ourglass is im plem ented in the M odelNet^ Em ulator for large-scale netw orks.
2.2.3.3 Shaman
S ham an [111] is a scalable service gatew ay w hich uses proxies to inte grate sensor devices into hom ogeneous platform s. The proxy ru n s on the gatew ay side an d includes drivers to connect to different heteroge neous sensor nodes. The proxy acts as a tran slator betw een the sensor n od e an d external requests. O ne im p o rtan t aspect of Sham an is p ro vid in g services w ith o u t m anu al configuration. The identification of sensors abilities is pro vided by the sensor itself. A sensor receives a specific lease tim e an d if the lease tim e is expired an d the sensor d id n o t request a new lease (similar to the D H CP Protocol), the ser vice associated to the sensor is closed. The Sham an service gatew ay uses a boo t protocol ru n n in g on each node. The protocol establishes a connection to the nearest gateway. D ata g athered by the gatew ay is provid ed by several interfaces. It provides a Jini interface to inte grate the nodes into existing Jini b ased platform s. Sham an provides a G raphical U ser Interface to access a sensor n o d e for adm inistrative purpose.
2.2.3.4 DSWare
DSWare [81] is a service-centric approach w hich provides an abstrac tion from the capillary netw ork by introducing services b ased on a group of sensor nodes. A service therefore consists of several nodes
gro up ed by specific g rou ping param eters. These param eters are p ri m arily defined as the observed region b u t they also can be extended to other attributes on a sem antic level such as typ e of sensing de vices (e.g. tem peratu re sensor) or sam e observed phenom ena. The group m anagem ent can be u sed to detect faulty n o des in a group an d com pensate the erroneous devices w ith other devices from the sam e group. In a group, som e devices can be set into sleep m ode to save energy as long as the overall result is n o t com prom ised. To increase the response tim e, a d ata caching is introd uced w hich im plies th a t certain sensor values are stored in a cache. To m anage the trade-off betw een the stored value copies an d the freshness of the data a feed back m echanism is applied. Event detection is u sed to trigger alarm s or n ew events according to the application logic. However, it seems th a t the im plem entation never left the GloM oSim [140] sim ulation en vironm ent. DSWare enhances other data-centric approaches such as C ougar an d SINA w ith features for event detection, group m anage m ent, d ata caching an d d ata subscription to the topics. To reduce the com m unication traffic, nearby nodes or groups try to aggregate data. Q ueries are only dissem inated to certain groups according to the ap plication. W ith the aggregation an d qu ery dissem ination, DSWare in troduces a subscribe m echanism w here a u ser can subscribe to a cer tain event. In case several users subscribe to an event, the m iddlew are can cache several values to reduce the energy consum ption.
2.2.3.^ SenseWrap
SenseW rap [33] introduces virtual sensors th a t abstract from the u n derlying sensor device. Sensors can be accessed via a generic API. The m iddlew are sup po rts re q u est/resp o n se access via G ET/PO ST like m ethods. It also su p p o rts the p u b lish /su b scrib e m echanism . The novelty of this approach is th a t sensors an d their offered services are discovered th ro u g h a Zero C onfiguration netw orking. The virtu al sen sors act as w rap p ers to the physical devices an d offer generic API and the ZeroC onf [110] discovery protocol support. The use-case scenario for SenseW rap is the Sm art H om e Environm ent. The authors describe th a t there are less th an 100 nodes to be linked together in the sce nario. Therefore no special com m unication protocols for WSN have been considered. A ccordingly to Evensen an d M eling the ZeroConf appro ach lim its the nu m ber of connectable nodes to 1000; therefore the app ro ach cannot be u sed for large-scale environm ents.
2.2.3.6 Service Approach
The Service Approach [27] focuses on how to enable interoperability betw een W SN an d a large range of applications by leveraging the ex
isting concept of service-oriented architectures. The sensor sink nodes play the role as service provider. They p rovide the description an d ac-
2 . 2 M I D D L E W A R E A P P R O A C H E S FOR S E N S O R N E T W O R K S 3 5
cess of the available services to external service requester. The sink no des also act as an internal service registry; sensor nodes register their services to the sink no des registry. The w ork uses WSDL [17] an d SOAP-messages [15] to interact w ith th e external environm ent. This enables easy integration of sensor netw orks into existing web- based solutions. However, WSDL an d SOAP are usually designed for heavy-w eight internet applications an d do n o t consider the con straints an d features of WSN such as processing an d b attery lim ita tions an d also hig h n um b er of n o de distribution.
2.2.3.7 Discussion
Service-based m iddlew are enables the integration of the WSN w ith existing applications th ro u g h stan d ard interfaces. This type of m id dlew are solution relies on w ebservice technologies such as SOAP an d RESTful stan dard s to integrate an d orchestrate services in the business w orld as show n in Table 7. The use of service oriented ar chitectures relies currently on technologies such as SOAP an d REST th a t have n o t been developed for the use in sensor netw orks an d m ay be unsuitable for the application in constrained environm ents. SenseW rap [33] covers this integration for WSN. Jini is a netw ork architecture for m o d u lar co-operative services b ased on Java. The Sham an m iddlew are introduces integration for this approach. SStreaMWare allow s the integration into the OSGi w hich allow s interaction w ith other m odules inside the OSGi fram ework. M ost of the exam ined ap proaches never left the theoretical n o r sim ulator stage as show n in Table 6.
Table 6: Service-based middleware
M id dlew are P latform
SStreaMWare N one
H ourglass M odelN et Sim ulator
SHAM AN IPaq
DSWare GlomoSim
SenseW rap N one
Table 7: Features of service-based middleware
SStreaMWare H ourglass Sham an DSWare SenseW rap S ervice Approach |
1 Self-H ealing N o N o N o Yes N o N o 1
1 Ota C od e d ep loym en t N o N o N o N o N o N o 1
1 H eterogeneous N o d e Support Yes Yes yes N o Yes Yes 1
1 Sensor Discovery N o Yes y es N o Yes N o 1
1 D eclarative Q uery Yes N o Yes ? - N o 1
1 Event-based triggering Yes N o Yes Yes - Yes 1
1 SOA Integration Yes N o Yes N o Yes Yes 1
1 Energy-efficient C om m unication N o Yes N o Yes - N o 1
1 Program m ing Abstraction Sql-like - N o ? - Yes 1
1 Large-Scale Support Clustering Yes N o C lustering N o -
1
1 Data A g g r eg a tio n / Data Fusion Yes Yes N o Yes - -
1
Zero configuration N o N o Yes N o Yes -
1
1 D irect N o d e A ccess Yes Yes Yes ? - Yes 1
1 QoS N o N o N o N o - N o 1
1 Structure D ynam ic, m obility given Static - - - -
1
2.24 Application Deployment Specific Middleware
M iddlew are u sed to distribute applications d u rin g the ru ntim e of the sensor netw ork is referred to as application deploym ent specific m id dlew are in this w ork. C om m on approaches p rovide n o t only a fram e w ork for code distribution, b u t also code execution environm ents. This category of m iddlew are discerns itself from the developm ent specific m iddlew are in w hich the focus is on how to distribute the application logic over the netw ork. The developm ent specific m iddle w are solutions often introduce new developm ent solutions an d focus how to p ro g ram the netw ork. The following sections discuss som e of the m ost com m on application deploym ent specific m iddlew are solu tions
2.2.4.1 MacroLab
M acroLab [63] is a d eploym ent specific code decom position approach in w hich a single M atlab-like p rog ram is w ritten for the entire sensor netw ork. M acroLab introduces a n abstract vector b ased program m ing language u sed to describe the overall goal of the application. The m acro p ro g ram is passed to a decom poser w hich breaks the m acro pro g ram d o w n into several com ponents. It uses the u nd erlyin g topol ogy to distribute the m acro p rog ram w hich can be m ore centralised or fully distributed. The sm aller com ponents are analysed by a cost analyser w hich, based on statistical data, related to the nodes such as available b an d w id th , pow er an d latency develops a deploym ent p la n for the m icro com ponents. The code is translated into Em bed d ed M atlab, a M atlab dialect for constrained devices. A com piler from M athW orks ^ is u sed to com pile the M atlab code for TinyOS enabled devices.
2 . 2 M I D D L E W A R E A P P R O A C H E S FOR S E N S O R N E T W O R K S 37
2.24.2 M ATE
M ate [76] introduces a virtual m achine as execution environm ent for a high-level program m ing interface w ith only 24 instructions. The m ain goal of M ate is to reduce the energy consum ption m large-scale sensor netw orks. The virtual m achine allows reprogram m ing of the netw ork d u rin g runtim e. The sm all instruction set reduces the overall m em ory an d transm ission footprint. The ap proach allows to deploy the code d u rin g ru ntim e as it is very close situ ated to the TinyOS operating system. N ew code is deployed by sending code capsules to the nodes. The m essaging follows a flooding approach: If a node re ceives a capsule w ith a new er version inform ation it w ill forw ard the code to its local neighbours. The M ate developm ent aim s to provide the abstraction for h ig h p rogram m ing languages so th a t for exam ple code from user-land program m ing environm ents can be translated into M ate byte code.
2.2.4.3 M agnetos
M a g n e to s [9] introduces a Java virtu al m achine w hich ru n s on all nodes in the entire netw ork. The application logic is split into several program m ing objects w hich can be m oved across the netw ork d u rin g runtim e. Objects th a t need stronger processing power, or are specif ically related to sensing, can be m oved to the suitable node. M agne- tOS states itself as a distrib uted operating system s. In com parison to M ate, M agnetO s relies on the high-level language Java. The objects are translated into byte code for the v irtu al m achine an d d istributed over the netw ork.
2.2.4.4 Impala
Im pala [86] is a m iddlew are solution for W SN created for the special needs of the Z ebraN et project 7. Z ebranet is a w ildlife tracking project using its ow n im plem entations of h ard w are nodes including GPS receiver to retrieve location inform ation. Im pala focuses on energy- efficient application deploym ent in h arsh environm ents. The m id dle w are is located betw een the h ardw are an d the applications, therefore Im pala is m ore of an operating system , b u t also provides higher-level event filter functionalities. The novelty of Im pala is th a t softw are u p dates are m anaged by the m iddlew are itself. A pplications are p ro vid ed as m odules. M odules can be u p d a te d on p articular nodes, an d only the changed code is transm itted. This m od ularity offers energy savings by reducing the size of transm issions. To develop applica tions on the Im pala m iddlew are, an event-based application pro g ram m ing m odel is introduced. O ne significant draw back in Im pala is th a t the im plem entation of the m odel only su p p o rts local states of sensor nodes an d no global coordination is offered.
2.24.5 Discussion
In changing environm ents an d w h en new requirem ents an d tasks for sensor netw orks are dynam ically introduced, application-deploym ent specific m iddlew are can be utilised to exchange n ew application logic an d code in the netw ork w ith o u t redeploying the physical node. Their features are show n in Table 9. This type of m iddlew are ensures that the new code is fo rw arded to the rig ht n ode an d in case of n ode failure, other nodes are u sed to com pensate the functionality a n d /o r data. M ate an d M agnetO S introduce a netw ork-w ide v irtu al m achine in w hich applications from higher languages such as C or Java are com piled into optim ised byte code an d tran sm itted to the nodes. M acroLab uses M atlab-like program s over the netw ork. The applica tion deploym ent specific m iddlew are solutions can decide according to application-requirem ents if the deploym ent sho uld be aligned in a centralised or distribu ted way. Im pala does n o t focus on a global goal for the application an d does n ot include balancing of code according to no de capabilities an d each n ode is u p d a te d separately. The differ ent solutions are m ostly available on the TinyOS platform as show n in Table 8.
Table 8: Application-deployment specific middleware
M id dlew are P latform MacroLab Tm ote Sky
M ate TinyOS
M agnetO s TmyOS
Im pala IPAQ
Table 9: Features of application-deployment middleware
MacroLab Mate M a g n e to s Im pala |
1 Self-H ealing N o - - - 1
1 Ota C od e deploym en t Yes Yes Yes Yes 1
1 H eterogeneous N o d e Support Yes N o - -
1
1 Sensor Discovery N o N o N o N o 1
1 D eclarative Q uery N o N o - - 1
1 Event-based triggering N o Yes - Yes 1
1 SO A Integration N o N o N o N o 1