Computer Communications 35 (2012) 405–417

Contents lists available at SciVerse ScienceDirect

Computer Communications

journal homepage: www.elsevier .com/locate /comcom

Combining heterogeneous service technologies for building an Internet of Thingsmiddleware

Kiev Gama ⇑, Lionel Touseau, Didier DonsezUniversity of Grenoble, Laboratoire d’Informatique de Grenoble, France

a r t i c l e i n f o a b s t r a c t

Article history:Received 30 September 2010Received in revised form 8 September 2011Accepted 3 November 2011Available online 12 November 2011

Keywords:Service-oriented computingInternet of ThingsRFIDMiddleware

0140-3664/$ - see front matter � 2011 Elsevier B.V. Adoi:10.1016/j.comcom.2011.11.003

⇑ Corresponding author.E-mail addresses: kiev.gama@imag.fr (K. Ga

(L. Touseau), didier.donsez@imag.fr (D. Donsez).

Radio-frequency identification (RFID) is a technology that allows ordinary objects to be uniquely identi-fied by ‘‘smart tags’’ which are also capable of storing small quantities of data. The term Internet of Thingswas originated from a vision strongly coupled with supply-chain concerns and RFID tagged objects. How-ever the idea of such Internet of Things has evolved in a wider sense, referring now to a ubiquitous objectsociety combining RFID, sensor networks and pervasive computing technologies. This scenario involvesdifferent requirements such as heterogeneity and dynamicity of objects, sensors, applications and proto-cols as well as the need for allowing the dynamic evolution of such applications. These issues seemed tobe easily addressed if the principles of service-oriented computing (SOC), like loose coupling and heter-ogeneity, are used for constructing such architectures and applications. In this paper we underline whatbenefits SOC can offer to constructing a middleware for the Internet of Things. These concepts have beenapplied in a service-oriented middleware that tries to leverage the existing Internet of Things architec-tural concepts by using SOC principles in order to bring more flexibility and dynamicity. We describethe approaches used in that middleware and the lessons learned from that experience. This middlewarewas initially tested on an application for tracking and monitoring supply-chain objects, and laterextended to target wider application domains that are also described in this paper. The project describedhere has become part of the OW2 AspireRFID open-source project.

� 2011 Elsevier B.V. All rights reserved.

1. Introduction

For the last decade, technological progress has led to miniatur-ization of computer resources. Processors, memory and datastorage are now embedded on small devices spread in the environ-ment. As these devices are more and more equipped with commu-nication capabilities, they tend to be integrated to larger systems.Some objects with communication and sensing capabilities canproduce measurements and provide information systems withdata on the physical world. Radio-frequency identification (RFID)technology allows ordinary objects equipped with radio-frequencytags to be uniquely and remotely identified. RFID tags are able tostore identifiers and small quantities of data associated to a givenobject (e.g., the credit balance of a skipass, a URL in an NFC smartposter).

The MIT Auto-ID Center, one of the major actors in RFID systemsstandardization, coined the term ‘‘Internet of Things’’ [2] for refer-ring to a network where objects would be individually andinstantly identified with RFID tags to form an Internet of Things.However, the standards produced by the MIT Auto-ID center, and

ll rights reserved.

ma), lionel.touseau@imag.fr

EPCglobal (non-profit consortium that controls such standards)were strongly coupled with RFID as the means of product identifi-cation. They target mainly supply chains and goods traceability,allowing easily querying to find information about a specific prod-uct. However, RFID tags themselves are not able to provide theaforementioned sensing capabilities. Different wireless and mobiletechnologies play an important role for bringing an enhancedvision of the Internet of Things (IoT) a step further: in a widersense, the idea of an IoT evolved as to refer to a ubiquitous objectsociety where different objects are connected, combining RFID,sensor networks and ubiquitous technologies to achieve this con-cept [30]. RFID laid the initial bricks for such IoT, by allowing touniquely identify and to store information about individualobjects. However, the IoT is not only limited to RFID but could havesimilar functionality by using different types of object identifica-tion [31] such as standards like linear barcode and datamatrix.Not only objects that participate in a supply chain should be trace-able in the IoT. As many others, we believe that ordinary objectseither through their own means (e.g., smartphones) or by othermeans of connectivity should also take part in this Internet ofThings.

As a consequence of this evolution, software engineering shouldpropose innovative infrastructures fulfilling the requirementsrelated to the nature of the Internet of Things, which are among

406 K. Gama et al. / Computer Communications 35 (2012) 405–417

others: heterogeneity (e.g., different objects, sensors, protocols andapplications), dynamicity (e.g., arrival and departure of objects andsensors) and evolution (e.g., support for new protocols, sensors).

At the same time, service-oriented computing (SOC) [22] hasalso become a major research topic drawing the attention of aca-demics and industrials. A service-oriented architecture (SOA)brings loose coupling and flexibility to applications, and allowsthe seamless integration of heterogeneous platforms and applica-tions. Dynamic platforms such as the OSGi service platform, whichalso applies service-oriented principles, provide the ability ofdynamic evolution of code (i.e., component updates at applicationruntime). For these reasons, SOC seemed as a good way to tacklethe above issues. Hence the purpose of this paper, which is theexperimentation of leveraging a middleware for the Internet ofThings by using service-oriented computing (SOC) for building it.The role of the middleware is to track not only RFID-tagged objectsbut also other objects that can provide relevant information. Thedata mediation to be performed should handle the data producedby such objects forwarding them to information systems usingexisting standards.

The proposed middleware, simply called RFID suite, wasdesigned on a multi-layer architecture with SOC being present ateach tier, and as a way for integrating them. The novelties and con-tributions that can be identified in our approach are: the service-oriented and multi-layer architecture in an RFID context; thedynamicity and flexibility of the SOC approach in the data collec-tion layer; the protocol flexibility introduced in the intermediatelayer; and the web service-oriented object naming service. Thiswork has been conducted at the University of Grenoble, France,and it has been open sourced in the OW2 AspireRFID1 project, partof the ASPIRE FP7 project.2

The remainder of this paper is structure as follows: the nextsection provides some background for understanding this articleand explains the motivations behind the creation of a service-oriented middleware for the Internet of Things. Section 3 detailsthe architecture of the RFID suite, and how SOC is used to imple-ment the different middleware layers. Afterwards, Section 4 pre-sents several validation scenarios where our middleware wasused, and Section 5 discusses the effectiveness of the approachrelying on SOC as well as the lessons learned concerning theencountered limitations of our approach. Section 6 overviews otherapproaches that are related to the RFID suite, and finally, Section 7draws the conclusions and final considerations.

2. Motivations and background

Besides giving some background on some of the principles andstandards used in the realization of our RFID suite, this section alsogives some motivations on how service technologies could helpovercoming challenges emerging from the Internet of Things andpervasive computing, particularly heterogeneity, dynamicity andevolution at runtime.

In the Internet of Things (IoT), devices/objects are made by dif-ferent manufacturers that do not always comply with the samestandards. This inevitably results in heterogeneous devices thatcannot directly communicate because of different protocols in-volved, raising integration issues. Service-oriented computing(SOC) promotes encapsulation so that component specificities arehidden behind the concept of services, which provide a known con-tract without needing to know who provides the realization ofsuch contract (i.e., an interface implementation). By using thatapproach, strong decoupling between components in the system

1 http://wiki.aspire.ow2.org.2 http://www.fp7-aspire.eu.

can be enforced. It is therefore possible to represent things (i.e.,communicant objects) as services, without needing to know thedetails (e.g., protocol adaptation code) behind such services. Bydoing so, devices heterogeneity is hidden from the service consum-ers, allowing applications to use those devices as compatibleservices.

Another point is the dynamic nature of such types of pervasiveapplications. Each thing follows its own life-cycle. A device such asa Bluetooth smartphone might become unavailable to a system assoon as it moves out of range. Regarding autonomy concerns, asimple sensor cannot perform its task anymore if its battery isdepleted. As a consequence a system hosting IoT-based pervasiveapplications must be highly dynamic to manage the devices whichcontinuously leave or enter the system. Since these kinds of appli-cations are not static they cannot be described beforehand, whichis the typical case when using architectural description languages(ADL). SOC can achieve a coupling loose enough to manage thisdynamicity through service specifications. Moreover, dynamicservice-oriented architectures [5] allow applications to react toservice arrivals and departures, which is an issue to deal with inIoT-based applications.

Concerning evolution issues, pieces of the IoT are continuouslyevolving. This evolution may consist in replacing a physical objector upgrading the software driving or using a device. That is why asystem targeting such infrastructures must be flexible enough tosupport this kind of runtime evolution. Modularization is a firststep towards such support. A monolithic system can only evolveas a whole whereas a modular system can evolve piece by piece.Due to the loose coupling between its constitutive parts, SOC sup-ports modularity: every service composing an application canevolve independently. Moreover, in many cases the applicationhas to be stopped and restarted to perform the upgrading. This isnot the case with service platforms where it is possible for applica-tions to react to services upgrades without being stopped.

The high decoupling and ability to deal with dynamic scenarioslead us to choose the usage of SOC as a solution to answer the soft-ware infrastructure needs of an IoT. We decided to experiment thisapproach by designing and building our service-oriented middle-ware. This generic purpose middleware is extensible, dynamicallyadaptable and enables the mediation of data between the physicalworld and IT systems. Existing vendor solutions are closed solu-tions where extensibility is not the main issue, since they directlytarget supply chain customers in solutions that keep customerslocked to providers. Thus, we kept flexibility in mind when design-ing the RFID suite. It should indeed take into account availableresources and adapt to different physical infrastructures. In addi-tion to the need for a flexible architecture, the RFID suite shouldalso enable hot deployment (i.e., without rebooting the systemupon an update), and a plug’n play approach (i.e., once a deviceis connected, its features become available represented byservices). Other important features concern the ability to performinfrastructure management during execution. As a general charac-teristic, it should remain domain-independent and be usable in awide range of IoT-related contexts.

2.1. Dynamic service composition in the OSGi platform

The OSGi platform [21] provides a lightweight dynamic service-oriented architecture enabling the deployment of modular andhighly dynamic applications. Recent trends in software industryshows that OSGi has become the de facto module system for Java,being employed in diverse contexts (e.g., mobile, application serv-ers, plugin-based development environments).

OSGi applications are built in a modular way using deploymentunits called bundles. OSGi indeed considers modularity anddynamicity as major concerns. It enhances extensibility and offers

K. Gama et al. / Computer Communications 35 (2012) 405–417 407

more opportunities for application evolution through the ability toperform hot component deployment (i.e., installing, removing orreplacing components without restarting the application). Its ser-vice registry allows service consumers to be notified of servicearrivals and departures at runtime. These facilities for the deploy-ment of components and services both supporting the possibilityof application evolution makes OSGi a suitable foundation forapplications targeting pervasive computing and the Internet ofThings.

In addition, OSGi specifies several standard services such as theEventAdmin and WireAdmin services that implement the pub-lisher-subscriber and the data producer–consumer connector pat-terns, respectively. The former is event-based and matches theRFID context of tag reading events while the latter is data-based,which is a well-suited approach to represent sensors as data pro-ducers and applications as data consumers. By using OSGi we couldtherefore easily and dynamically add or remove readers and sen-sors in the platform during its execution.

We used the service composition mechanism provided byApache Felix iPOJO [13] which is a component model targetingthe OSGi platform. It is designed to handle extra-functional con-cerns like dynamic service dependency management in order tofacilitate bundle development. This service-oriented componentmodel uses a mechanism based on handlers, which are customiz-able parts of the code for dealing with non-functional concerns.Thus the components core can focus on functional concerns, notneeding to concentrate on concerns like service dynamism.

2.2. EPC global standards

Standards already exist for tracking objects identified by RFIDtags in an Internet of Things. As detailed in [28], the Auto-ID Labs(formerly MIT Auto-ID center) [3] has lead the standardization ofan electronic product code (EPC) centric context using RFID tech-nology. These standards are now under control of the EPCglobalconsortium [10], a non-profit consortium. The EPCglobal architec-ture framework [12] defines a set of standards and an architecturalframework aiming to facilitate product information exchangebetween trading partners. The architecture is modelled in layersand it is platform agnostic, thus allowing heterogeneous hardwareand software to be used. The dark boxes on Fig. 1 illustrate thebasic layers of the standard EPCglobal architecture, where the low-est level deals directly with RFID tags and the highest level providehigher level APIs for external applications accessing RFID data andevents.

Fig. 1. Relation between the RFID physical layers (within brackets) mapped toEPCGlobal architectural elements (grey boxes). The dashed lines represent data-centric concepts for grouping the different elements.

The lower layer consists of RFID middleware that collects (i.e.,reads) RFID data that is conducted toward higher layers such asthe EPC information services (EPCIS) [11] so the information canbe persisted, used by other applications, transformed into higherlevel events (e.g., business events) and so forth. The tag data ispassed from the lower to upper layers through the application levelevents (ALE) API, which uses a report-based approach for central-izing tag data gathered by several readers and consolidating themin event cycle (EC) reports. Their structure is defined in EC specifi-cations (ECSpec) where one may specify different parameters (e.g.,cycle interval, tag id pattern). The EPCIS is a component responsi-ble for receiving application-agnostic RFID data from the filteringand collection layer, allowing the translation of data into businessevents, and optionally storing them into an EPCIS repository, whichcan be implemented in a relational database manager, for instance.

The EPC network services specification define the concept of anobject naming service (ONS), similar to a DNS, for identifyingobjects in federated EPCIS among different trading partners. AnONS allows querying and finding the EPCIS instance that is hostingthe more recent information of a given object. It enables, for exam-ple, tracking the whole history of a product throughout a supply-chain from the factory to the store where it is sold to the end user.Such a layered architecture is a good approach to achieve flexibilityin our middleware.

3. RFID suite architecture

The RFID suite architecture we propose is inspired on the phys-ical separation of the edge/premises concept presented in IBM’sRFID reference architecture [7] which at the beginning was notcompliant with EPCglobal standards. By taking into account flexi-bility, our middleware architecture was designed in a way that itcould be possible to either deploy all its elements on one singlemachine if necessary or to distribute them over a set of networkedmachines. Thus middleware users can adapt the architecture totheir needs and their resources.

We were based on EPCglobal standards for conceiving themiddleware, as depicted in Fig. 1 where the dark boxes illustrateEPCglobal elements used in our architecture. The idea was not todeviate too much from the specifications that govern the standardsof the Internet of Things. For example, we simplified the lowerlayers of the EPCglobal architecture concerning the readers, sowe could deploy them as self-contained components which couldbe able to handle communication in the physical layer for scanningtags. The next subsections gives an overview of the architecture,followed by SOC usage details on our perspective of three data-centric concepts (data capturing, data mediation, data exploita-tion) that constitute the physical layers that may be overlappingin some cases.

3.1. Architecture overview

In the case of IBM’s architecture, the RFID edge controller is con-nected to the RFID premises server. The former integrates IBMWebSphere RFID device infrastructure, while the latter representsthe enterprise tier where business intelligence is applied. We ex-tended IBM reference architecture by adding more flexibility inthe edge and data mediation layers as well as introducing the EPCISand the object naming service (ONS), both of them EPCglobal stan-dards. The EPCIS represents a physical tier above the premiseslayer as shown on Fig. 1. In our architecture the edges form thelayer that is closest to the monitored objects (i.e., things) layer,where the readers and sensors are connected.

Premises servers play the role of intermediate servers on localscale; each premise server collects and filters data coming from

Fig. 2. Architecture illustrating the communication between different parts of the system.

408 K. Gama et al. / Computer Communications 35 (2012) 405–417

edges or other premises. That way, it gives the necessary scalabilityand flexibility either connecting theses pieces together in a singlechain or in a hierarchical group of edges, premises servers andEPCIS, as shown on Fig. 2. By doing that, the middleware architec-ture can be scalable according to different needs. From a physicalpoint of view, the edges would consist of small computers with lessprocessing capability, the premise server targets small servers orPCs while EPCIS would be deployed on more robust servers.

The edge is the physical layer that is the closest to the ‘‘things’’,being linked to the devices (e.g., sensors, RFID readers). An edgeconsists of a lightweight low-cost tiny computer that can haveapplications installed to collect data, such as a warehouse scenario.Data (i.e., tag IDs, tag info, sensor readings) are collected in theedge and sent to an intermediate application in a premise com-puter. In addition to data collection, early filtering can be per-formed on the edge or premise tier to avoid network overload. Atypical example consists of different small computers, not biggerthan gateways or set-top boxes, acting as edges in a warehouse col-lecting object and sensor data, and sending them to the ware-house’s central server. The premise can add some filtering,processing or local storage (e.g., a file with all the tags read inthe day) for later sending the data to an EPCIS where they wouldbe persisted and processed. The EPCIS could even communicatewith other EPCIS to exchange data on products. Moreover if it isnecessary to scale down this solution in a simpler scenario wherethe role played by the premise is not relevant, the architecturecould be dynamically configured, via management interfaces, tosend information from the edge directly to the EPCIS. This flexibil-ity allows the middleware to be adapted to different and evolvingneeds.

As another optional element in our architecture we have theobject naming system (ONS), which is implemented as a web ser-vice. When a new tag has information stored in the EPCIS, the latterwill inform the ONS that it has ‘‘seen’’ this new tag so the ONS cananswer queries regarding this tag. Different EPCIS instances may beconnected to the ONS so they can form a federated database, allow-ing objects to be located by performing queries to the ONS.

Furthermore, since every layer uses Java-based technology, theadministration tasks can be performed through JMX (Java Manage-ment eXtension)3 at each layer. A set of management interfaces hasbeen developed in the RFID suite. They allow administrators toperform some tasks at runtime, such as:

3 http://java.sun.com/jmx

� Starting, stopping and configuring readers.� Configuring the dispatchers in order to set the protocol used for

the transmission of application level event (ALE) reports in theedge and premise layers.� Configuring the destination where the reports will be sent to,

and thus the links in order to support infrastructure evolution.

The next sections explain how we have applied SOC principlesin each middleware layer which are linked together also using ser-vice-oriented technologies.

3.2. Data capturing

At the beginning of the chain are the edges, composing the mid-dleware lower layer responsible for getting information from exter-nal devices and putting them into the system. Edges are the mostdynamic parts of the application. They act like gateways betweenphysical objects (mainly RFID readers and sensors which producedata) and other servers (premises or EPCIS) that can process the datafrom such objects. The edge is the middleware layer that is closest tothe ‘‘things’’. On the edge, a part of the intelligence will be dedicatedto the middleware tasks concerning the collection and filtering ofdata produced by readers and sensors in order to generate ALE eventcycle (EC) reports and dispatch them to premises servers or EPCIS;yet, it is also possible to run other components that constitute appli-cations that are functionally independent from the RFID suite. Theseexternal applications may use or not the data produced by readersand sensors for other purposes.

Due to the dynamic nature of objects that may enter or leavethe system in an unpredictable way, we decided to use a dynamicservices platform in order to bring SOC to the edge layer. Bothdynamicity and flexibility that allow the evolution of componentsand services at runtime, among other reasons, made the OSGiframework the platform of choice for constructing the edge layeras depicted in Fig. 3. On top of OSGi, the iPOJO component modelwas used to automate service bindings, as well as exchanges withmessage bus and JMX-based remote management through addi-tional handlers.

The collection and filtering component is the main componentof the edge layer. It relies on a local message bus to collect and dis-patch RFID events, and a producer–consumer connector to aggre-gate sensor measurements. In the next subsections we get intomore details concerning the main conceptual parts of the edgeinfrastructure.

Fig. 3. The set of components that comprise the OSGi edge application. White boxes represent the components developed as part of the RFID Suite, while the others are usedas dependencies that provide necessary services.

K. Gama et al. / Computer Communications 35 (2012) 405–417 409

We perform basic filtering in case of duplicate reads, only oneevent is sent along with the EC report. Also, the filtering definedin the ECSpec is also performed in the data collection and filteringcomponent. However if we other dirty events besides duplication(e.g., corrupt data) our middleware does not handle them. This taskis left to the readers drivers which are assumed to publish valid tagreadings on the message bus.

The EC reports have a predefined set of information (e.g., tagIDs, reader logical name, timestamps) in compliance with theECSpec standard. In the case of our middleware we extended theECSpec to support additional data, still respecting the ECSpec stan-dard, which defines a tag (‘‘extension’’, as illustrated in Fig. 1) thatcan be used for such customizations. It allows us to aggregate moreinformation concerning the object’s environment. We defined kindof extensions: sensor data inclusion, conditions on report produc-tion (e.g., on sensor values), and advance filter capabilities. Conse-quently if any sensor is attached to the edge application, theinformation it provides can be also sent along with the ALE reports.In Listing 1 we find the example of an EC report extension that pro-vides data concerning temperature sensor readings. Once gener-ated, EC reports are dispatched periodically using a timer service(Cron service in Fig. 3) through different protocols depending onthe configuration.

One of the advantages of using this event-driven model on topof a local message bus is that other components deployed on thesame OSGi edge could listen to this event admin topic to exploitthe information coming from RFID readers. For instance, a ware-house edge application controlling a conveyor belt could use theinformation to stop the belt if an unknown tag is read. The sameedge can have additional components that log and store the tagsread for other purposes, or can produce other types of behavior

based on read objects (e.g., turning on a green light each time atag is read).

3.2.1. Producer–Consumer connectorThe OSGi specification proposes facilities to manage connec-

tions between data producers and consumers through its WireAd-min service using a service-oriented approach. The RFID suiterelies on this producer–consumer model to represent sensors. Pro-ducers and consumers are modelled as uniquely identified OSGiservices (i.e., they are published in a service registry along with aset of properties). At runtime the connectors, namely wires, aremanaged by the WireAdmin service. This service allows wires tobe created and deleted programmatically. Once connected, produc-ers can either push data into consumers or provide data when theyare polled through the wires. In order to handle the dynamicity ofdevices such as readers or sensors, the RFID suite uses theWireAdminBinder engine [6] to manage the connections betweenproducers and consumers. Collections of wires are described in adeclarative language called wired application description language(WADL), so that the WireAdminBinder interpreter can create anddestroy the connectors between measurement producers and con-sumers as they are introduced or removed dynamically from theexecution environment.

In our middleware, measurements are polled from sensors bythe data collection and filtering component that generates the ECreport, which is the same that collects and filters RFID events. Eachtime a tag reading is received, the component polls producers toget measurements associated to this reading. Besides, other appli-cations not related to the RFID suite could run on the gateway anduse the data produced by sensors. For instance an applicationreceiving temperature measurements in a cold chain scenario will

Listing 1. Event cycle report example with additional information concerning sensor data.

4 http://www.upnp.org.5 http://wiki.aspire.ow2.org/xwiki/bin/view/Main.Documentation.Bundles/

UPnPRFIDReader.

410 K. Gama et al. / Computer Communications 35 (2012) 405–417

trigger alerts or use actuators to perform specific action, such asregulating the temperature, if the threshold is exceeded.

3.2.2. Service-oriented readersThe common way for adding an RFID reader to the RFID suite is

to write an OSGi component that accesses the reader, forwardingdata to the event admin whenever a tag is read. This componentwill either contain the actual code that accesses the reader, or itmay wrap the code that calls the library that gives access to thereader.

Motivated by the possibility of installing and configuring newreaders in a easy way, and if possible, by non-expert people (e.g.,shop employees, warehouse personnel), we introduced the conceptof service-oriented readers. The major advantage of such approachis that the low coupling achieved through service orientation facil-itates the addition of readers into the RFID suite. Currently we pro-vide two approaches: a UPnP reader and a RESTful reader. Theformer allows a plug and play approach and targets end users,while the latter targets developers and the integration with exter-nal applications.

UPnP reader. Universal plug and play (UPnP) is the de factostandard for plug-and-play appliances in small networks like theones used in small office/home office (SOHO). It comprises a set

of specifications defined by the UPnP Forum,4 targeting devices thatshould be dynamically connected or disconnected without the inter-vention of a human operator (i.e., zero configuration). To achieve thisgoal, UPnP devices are self-configurable and self-descriptive, usingservice-oriented paradigms in appliances.

In order to alleviate the end-user who is not an RFID integratoror expert, we provide a way for taking into account plug-and-playRFID readers (e.g., shop portals, portable readers) by using UPnP.This prototype initiated in the RFID suite was later integrated intothe main branch of the OW2 aspire RFID open source project,5

where the RFID suite is contained.We provide a UPnP device profile (DCP) for RFID readers com-

municating with IP (Ethernet, Wifi). Readers implementing thisprofile (urn:schemas-ow2aspire-org:service:Reader:1) can be dis-covery automatically by the edge server and dynamically regis-tered. The profile consists in a basic service for configuring(e.g.,duration of a cycle, pattern of the groupSpec) a ECSpec perreader. The tags scanned during an event cycle are listed in a statevariable named ReportMembers, as illustrated in Fig. 4. This

K. Gama et al. / Computer Communications 35 (2012) 405–417 411

variable is equivalent to the reportMember element in the ECRe-ports, and its value of the state variable is notified to subscribersusing the UPnP notification. A subscriber in our context would bean edge server in the network. In the edge, the UPnP notificationscarrying RFID identifiers are converted in internal RFID eventswhich are sent to the EventAdmin for dispatching. The conversionis done by the UPnP RFID reader component instantiated for eachUPnP RFID device discovered by the OSGi UPnP base driver, asillustrated in the edge architecture in Fig. 3.

We have validated the UPnP RFID reader profile by an imple-mentation with OSGi/Java wrapping a ACR122U NFC reader as aUPnP device, as depicted in the screenshot of the Intel UPnP Devic-eSpy tool (Fig. 4). This implementation combines also otherstandard DCPs such as the TemperatureSensor service for anembedded thermometer and the LowPower service for GreenITpurposes (e.g. the reader can be hibernated and wake up remotely).This approach enables to easily attach and use RFID readers in net-works, although it would raise security and privacy discussionssince the approach we use implies in notifying all read tags usinga broadcast model inherent from UPnP technology.

Generic RESTful reader. Another advantage brought by theusage of service-oriented principles in the edge layer was the easyand quick integration with other RFID applications. As part of theedge, we developed a component exposes a pseudo-RFID readerusing a RESTful [14] web service approach, thanks to a lightweightHTTP server accessible through the OSGi standard HTTP Service. Ifan existing application that does not execute on OSGi needs tomonopolize the communication channel with an RFID reader (gen-erally a serial COM port), we still can insert that information in theRFID suite by adapting the code of that application so it could sendHTTP requests to the RESTful reader in the edge. Aspect-orientedweavers, for example, can be a way to patch that legacy softwareand insert calls to our RESTful reader.

An HTTP PUT method simulates a tag scan by adding a new tagevent (the object id and optional sensor information) into the edgewhich will translate it, timestamp it and propagate it to the Event-Admin, and therefore across the architecture chain. This approachcan be applied to integrate legacy RFID readers or RFID applica-tions. Moreover, the RESTful reader can also be used for non-RFIDtracking applications (e.g., barcode, QR codes, mobile phones). By

Fig. 4. UPnP RFID reader visualized from within a UPnP explorer. State vari

allowing such integration of ordinary objects, we aggregated valuein the edge by allowing other applications to act as externalsources of data.

In those cases where the identifiers of the objects using theRESTful reader would not be compliant with the identificationscheme used by EPCGlobal since they do support only certain typesof product codes. For instance, a SIM card id would not be useful inan EPCGlobal architecture, although it characterizes an object witha unique identifier. However, we do not see this incompatibilitywith EPCGlobal as something negative. On the contrary, our mid-dleware allows the true ordinary objects that are part of the IoTto be tracked in our system even though they do not carry an RFIDtag.

3.3. Data mediation

The message passing infrastructure enables the mediation ofdata between edges and EPCIS, optionnaly passing through the pre-mises servers. The next subsections provide more information onthe different layers involved in this mediation process and howthe data is passed across these layers.

3.3.1. Local message busOur architecture uses two types of message bus, as illustrated in

Fig. 5: one that is local, used within the edge and premise servers,and another one that allows communication between edge, pre-mise and EPCIS servers. The local message bus is based on OSGi’sevent admin and is used for sending information reader data(e.g., RFID Reader). The event admin is an OSGi standard servicethat provides a mediator for the publisher-subscriber pattern.The mediator manages the publication of events on topics and dis-patches these events to the components that subscribed to the cor-responding topics. Since RFID is event-driven by nature, we choseto rely on the event admin mediator in order to propagate theinformation collected from RFID readers or other non-RFID sources.Events are then received by subscribers, among which we have thedata collection and filtering component which is responsible forgenerating the EC reports to be sent to the premises or the EPCIS,depending on our middleware configuration.

ables correspond to data elements present in event cycle (EC) Reports.

Fig. 5. Simplified view of the local message bus used in the edge for collecting ECdata.

412 K. Gama et al. / Computer Communications 35 (2012) 405–417

3.3.2. Communication between layersIn order to fulfil the requirements regarding the architecture

flexibility, we used event-driven SOA for the communicationbetween nodes, since RFID is event-driven by nature. The mediationlayer ported and adapted a concept initially developed in [9] thatresembled a distributed enterprise service bus (ESB) architecture[8], but with less functionalities. This message bus allows the mid-dleware nodes to be added, removed or replaced, thus bringingdynamicity, flexibility and scalability into the architecture. Edges,premises and EPCIS are reconfigurable at runtime via managementinterfaces so that messages can be routed and dispatched to differ-ent nodes if necessary. Moreover, the RFID suite is able to handleseveral communication protocols thanks to bridge mechanismswe provide: Java message service (JMS), web services (HTTP/ SOAP),and simple mail transfer protocol (SMTP). Bridges to other proto-cols, such as XMPP, could be easily added even during execution.

3.3.3. Premise serverOur premise server follows an architecture similar to the edge,

being also deployed on top of an OSGi platform. The primary role ofpremises servers is the filtering and collection of data at local scale.It receives EC reports, which correspond to application level events,from edges and forward them to other premises (in a hierarchicalarchitecture) or to the EPCIS. Business intelligence can also beapplied on these intermediate servers. For instance, in a warehousescenario, applications regarding the management of the warehousewhere a premise server is located can run on this server instead ofletting EPCIS manage everything. Partial storage can be performedin a Premise Server, as well as filtering of events creating newreports, or even rerouting of received EC reports. The reconfigura-tion is possible through manageable objects exposed via JMX.

Premises servers are optional in the architecture. If no interme-diary filtering or local event storage needs to be done, there is noneed to employ a premises server in the architecture. The data cap-tured on the edge layer could be sent directly to the EPCIS server. Insuch case, using a premises server would only introduce communi-cation overhead.

3.4. Data exploitation

As part of the process of reading tags, a systematic storagemechanism is needed so different client applications can access

the persisted tag data the same way. When using collected RFIDtag data, client applications need to build meaningful information(e.g., inventory check in/out, business events) out of the raw storeddata. The next subsections goes into further detail concerning theusage of the tag data collected in the data capturing layer.

3.4.1. EPCIS serverThe goal of the EPCIS is to store data coming from the physical

world (e.g., EPC, sensor measurements) in order to enable differentapplications to use and to share these data, both within and acrossorganizations. It is possible to query an EPCIS and verify, forinstance, what was the last time a given object was ‘‘seen’’. Inthe EPICS of our RFID suite the each record of an object id’s historymay also contain sensor data (e.g., temperature, humidity, globalpositioning) that is associated with that object record.

A data mediation chain for collecting RFID tag data and storingthem in a data repository provides only a set of raw data. There is aneed for extracting information out of it. For instance, creatingmeaningful higher level events as well as allowing other systemsto interface with this repository so end-user applications canaccess information stored on it. As explained in [27], the conceptof ‘‘connector’’ components is useful for abstracting the interfacebetween EPCIS and information systems. A connector layer canbe built on top of EPCIS in order to support for events, services,functionality abstraction and support for process management.Therefore, connector applications can sit on top of that layer rely-ing on its services.

The RFID suite EPCIS was built as an enterprise Java applicationthat persists the received information in a database. Our applica-tion provides services that can be accessed by other applicationsthat need to query the EPCIS. Because it is based on web services,these services can be easily accessed by other platforms. Since itprovides a limited connector layer (no high-level business eventsare produced), the client applications would be responsible forimplementing that. For instance, generating business events basedon information that is pushed into the EPCIS.

In the RFID suite we built a connector application that is archi-tecturally situated at the client level shown in Fig. 1. The applica-tion leveraged on sensor data sent along with the RFID data. Theobjective of the application, further detailed in Section 4, was toprovide a global object tracking system, and among other features,also be capable of plotting graphics that show the evolution of sen-sor data for individual objects.

3.4.2. ONWS: ONS-like web serviceThe object naming service (ONS) standard, proposed by EPC-

global, relies on the domain name service (DNS) for locating theEPCIS that stores information of a given object. The EPC networkONS infrastructure is managed by Verisign and requires a payingsubscription. This kind of monopoly brings a significant disadvan-tage for small organizations to benefit from the Internet of Thingsto share information about their objects. In addition, such ONSmainly targets EPC (electronic product code), not ordinary objectsas we propose. This RFID suite has an ONS-like approach thatrather implements what could be called an object naming web ser-vice (ONWS) built with HTTP SOAP web services instead of DNS.The coordination (in both ways) between the ONWS and EPCIS iscompletely done via web services interfaces. As in the approachused for the EPCIS, the fact of using Web services allows our ONWSto be queried by mobile devices with Internet access, and also facil-itates the integration of different partner organizations for freelysharing information through the Internet if using the samemiddleware.

Our OWNS also accumulates the role of a discovery service. Givenan object identifier, the ONWS returns a list of service endpointsrelated to this object. That is, an ONWS can provide information of

K. Gama et al. / Computer Communications 35 (2012) 405–417 413

each EPCIS that has ever stored any information concerning thegiven object id, thus enabling a traceability capability. The servicesare implemented as web services that are provided by EPCIS serversthat hold more detailed information associated with the tag scanevent. At the time of writing of this article, the EPC discovery servicesstandard was still under construction.

A federation of ONWS and EPCIS servers is possible to be config-ured. In a simpler case, a set of different EPCIS servers can share anONWS. They all send information to the same ONWS. Therefore itis possible to retrieve, for example, the history of a given objectthat has information in more than one EPCIS. In another case, dif-ferent organizations (e.g., partner organizations that participate ina supply chain) may want to store their own history of object infor-mation in independent sets of EPCIS instances. Each organizationcan have the own sets of EPCIS servers under an independentONWS server. Although servers are independent, the informationcan be easily shared and the same object identifier can be transpar-ently tracked in the two different systems as if it was only stored inone. In that case, an ONWS must be aware of the other (s) ONWSthat may be involved in the network. A configuration file listingthe ONWS of the network allows the middleware to forward thelookups to the other ONWS so the object can be tracked.

3.5. Integration of different service technologies

The implementation of this middleware involved different ser-vice technologies, each one suitable to a different need. Each layerprovides the adaptation of such technologies by means of bridges.A summary of the main service technologies used is depicted inTable 1.

The edge layer uses the straightforward service-oriented archi-tecture provided by the OSGi service platform. On top of that, ituses a message-driven approach for sending RFID tag data insidethe edge, via OSGi’s EventAdmin, and a producer–consumerapproach for reading sensor data. A RESTful approach is also usedby a pseudo-RFID reader. Communication between edge and pre-mises may use service technologies such as JMS or SOAP web ser-vices, depending on the configured choice.

The Premises are also developed on top of OSGi, thus they ben-efit of that lightweight service platform. Like the edge-premisecommunication, the premises communicate with the EPCIS viaJMS or SOAP web services, either over HTTP or SMTP. The sameway, the EPCIS receives the EC reports using either JMS or SOAPweb services. The ONWS is able to establish communication eitherwith another ONWS or with an EPCIS. In both cases the communi-cation is done using SOAP web services.

Services based on JMX management interfaces are also used inall layers, although we do not list them in the table since they areemployed only for management (e.g., reader lifecycle) and configu-ration (e.g., event cycles, server addresses, protocol configuration).

4. Validation case studies

Different use cases have validated the utilization of the middle-ware and the possibility of extending it thanks to the SOC principles

Table 1The main service technologies used in each architecture layer.

Layer Wire admin (OSGi) Event admin (OSGi)

Edge x xPremise xEPCISONWS

applied, mainly at the edge level. The next sub-sections describethese different experiments.

4.1. Supply-chain management

The initial use case [17] of an application developed with theRFID suite concerned a fictitious scenario for tracking objects thattransited between different partner sites in a supply chain. RFIDtags, which characterized the products, were scanned at differentsystems (edge-premise-EPCIS mediation chains) that representeddistinct partner sites. Both of the system’s EPCIS were configuredto point to the same ONWS. The EPCIS web interface displays thegeographic positioning of the same object in different locationswhich came from two different EPCIS, as it is shown in the screen-shot of Fig. 6. After being queried by the user interface, the EPCISperforms a call to its ONWS to get the URLs of the Web Servicesthat are capable of providing information on the requested tag(i.e., the systems that ‘‘know’’ that tag). In this context, the ONWSacts as a pseudo-catalogue. It will return the information about theother URLs that are capable to answer such request (the URL of anEPCIS web service or even another ONWS) where that tag has beenlocated.

The sensor information is plotted in graphics that show the evo-lution of measured values. Temperature readings at the moment ofscanning each tag were also available, but other sensor informationcan be easily added, if needed. These are just basic data reportingcapabilities, without extracting any information from the data.We also provided cases where that extraction is performed, creat-ing higher level information from RFID events, by using a pullapproach. A functionality for detecting lost objects and lost pair-ings. For instance, if a given carton tag was not scanned along withthe pallet tag that is registered as that object’s pair, a warning istriggered in the system. Participation in a pair is not exclusive,and therefore many tags (e.g., products, pallets) may be pairedwith a common tag (e.g., a pallet, a container). The extension forsupporting sensor data also has functionality for extracting higherlevel events out of it. In the case of temperature warnings, we asso-ciate temperature thresholds with tag, so warnings can be fired ifthe thresholds are exceeded. For instance, the temperature mustbe preserved at a constant temperature between 50 and 6 F, other-wise warnings are fired.

4.2. Near-field communication applications

Near-field communication (NFC) covers very short distancecommunications between RFID tags and readers (fixed or mobile).The NFC specifications defined by NFC Forum [20] are limited to alist of supported non-EPC compliant RFID tags standards and prod-ucts, and to the information stored in the tags. The forum has notyet defined a global architecture similar to the EPCglobal one forintegrating NFC information in information systems.

We have performed the integration of NFC equipped mobilephones to the RFID suite middleware. The phones were consideredas mobile readers that were available to the RFID suite through anNFCAdapter component. This NFCAdapter appeared to the edgeserver as a pseudo-reader that received data from NFC phones

JMS REST WS Web services (SOAP)

x x xx xx x

x

Fig. 6. The RFID suite control panel illustrating objects located in different partner locations.

414 K. Gama et al. / Computer Communications 35 (2012) 405–417

connected by Bluetooth or HTTP over 3G/GPRS. Demonstrations forthe Nokia 6131 NFC have covered several scenarios: object picking[17], museum augmented visit [24], counterfeit detection, productinformation and car ride sharing. We experienced some difficultieswhen trying to integrate NFC at the end-user level with the EPC-global database, since, as pointed out by [19], the tag data formatdiffers between EPC and NFC standards.

6 h t t p : / / w w w - u f r i m a . i m a g . f r / F O R M A T I O N / u e / W e b F o r m a t i o n /ue.php?code=GINF53B9.

7 http://www.touchatag.com.8 http://www.violet.net.

4.3. Sounding balloon live tracking

The RFID suite middleware is not limited to track only RFIDtagged objects. It can be used to track objects using other identifi-cations schemes and technologies. To prove its versatility, in Aprilof 2009 we participated in an experiment [16] led by the InstitutUniversitaire (IUT) in Valence, France. It consisted of a soundingballoon that was launched at Valence and landed at Digne-les-Bains, after a 150 km and 3 h long journey, reaching an altitudeof 26500 m. The trip and the balloon sensor readings were trackedusing the RFID suite, as an example of versatility of the middlewarefor tracking information from a non-RFID source, as illustrated inFig. 7.

The balloon sent different types of data such as GPS position(latitude, longitude, and altitude), internal and external tempera-ture, and pressure to the base station in Valence via two separatechannels: Amateur radio and SMS. That information was receivedby a stand-alone application that invoked the RFID suite edge’sRESTful reader adding tag scan events into the edge. The numberof the cellular phone that transmitted SMS has been used as thetag identifier. The latter, for the same reasons than for theNFCAdapter, had to be adapted as a GUID number into the RFIDsuite. The graphical user interface also needed to be adapted tosupport general measurement information, which was initiallylimited to temperatures and positions. The RESTful web serviceallowed seamless integration with the external application, and

the balloon was successfully monitored using the RFID suitemiddleware.

4.4. Teaching in machine-to-machine classes

As part of a course project in Software Engineering at the Uni-versity of Grenoble,6 where service-oriented computing targetingMachine-to-Machine is taught, students had to integrate NFC read-ers (Tikitag/Touchatag7 and mir:ror,8) GPS sensors, weather stations(Oregon WMR 200) and IP security cameras (Axis 211) into the RFIDsuite. The assignment was the development of OSGi components,with dependencies managed by iPOJO, to wrap the sensors and tagreaders. These components were then integrated to an applicationbuilt on top of the RFID suite and had their services deployed onan edge server. The good decoupling achieved with services in theedge platforms has consequently allowed the seamless addition ofnew tag readers, sensors and actuators into the system. The studentsdid not need a full understanding of the layers that collected data.They only had to develop code that produced information (tag read-ings and sensor data) and use the RFID suite service contracts to sendthat data to the service consumers responsible for collecting suchinformation.

5. Discussion

We have achieved significant flexibility especially at the edgelevel where the integration of devices is facilitated by a dynamicservice-oriented architecture. Adding a new sensor basicallyconsists in deploying a component controlling the sensor and

Fig. 7. Sounding balloon experiment data. On the left, the map locations and on the right the evolution of altitude over time.

K. Gama et al. / Computer Communications 35 (2012) 405–417 415

implementing the WireAdmin producer service. In a similar waynew reader components just need to publish events on the rightEventAdmin topic to be integrated in the RFID suite. External appli-cations can also provide information by using the RESTful pseudo-reader over HTTP to provide the middleware with information.

The discovery services and object naming service that weremerged in a same web services server had a significant advantageof providing a higher level interface that could be easily integratedwith external applications. Also, this concept allows partner insti-tutions to exchange information and track their objects withoutdepending on a paying service of a global ONS like Verisign.

Although the data mediation of the RFID suite has some flexibil-ity, it is not as powerful and customizable as an ESB. At the timethis project had its architecture conceived, ESB was still an evolv-ing topic and the state of the art in free open source ESB was notas solid as today. RFID middleware is based on event processing(e.g. tag scans) thus easily adding rules and some meaning to theseevents is of extreme importance. The usage of an ESB since thebeginning would have been a better solution for handling issuessuch as protocol adaptation, complex event processing and serviceorchestration.

Even at the ‘‘things’’ level, using a highly dynamic approach isnot an optimal solution in some scenarios. The binding policiesdefined by iPOJO allow applications to adapt to devices comingand leaving the system. Nevertheless, in some cases sensor dataare crucial and a disconnected sensor (e.g., a heartbeat monitorin a healthcare scenario) should not be simply considered as a ser-vice departure. These issues regarding service disruptions in mis-sion-critical applications are studied in previous work [29] thatproposes different binding policies based on service-level agree-ments through iPOJO handlers, and which has been validated in asensor-based application deployed on the RFID suite.

As a side result, this experiment also pointed out that the iden-tification of objects in the Internet of Things should not be limitedto EPC (electronic product code). We had difficulties for integratingin a standards compliant manner (since such translations have notbeen standardized yet) other identifiers such as NFC tags andphone numbers. A possible improvement would be the implemen-tation of a service for tag data translation (TDT) which is anotherEPCglobal standard but limited to different EPC coding schemes.The TDT service would be deployed on the edge and used bynon-RFID readers. However, as previously mentioned there is noagreement yet on the translation of non-EPC identifiers to be com-pliant with the EPC encoding used by the EPCglobal standards. Theusage of EPC as identifiers is really supply chain oriented but forenabling a true Internet of Things, and not only an ‘‘Internet of

Products’’, there would be a need for a truly universal identificationsystem when finally these things will have access to the networkand exchange information via an Internet of Services.

The fact of having services facilitates maintenance and thereplacement of readers components, especially if using the ser-vice-oriented readers we propose. Also the architecture can be rec-onfigured during execution, without needing to restart theapplication. For instance, during execution the middleware canbe configure to no longer use the premises layer, or in the oppositecase, by configuring it to start using the premises server. Similarreconfiguration is possible in the EPCIS level, where it is possibleto start using a different ONWS.

6. Related work

Fosstrak, formerly known as Accada, is an open source RFIDmiddleware that implements EPCglobal specifications, but pre-sents a rather monolithic approach for implementing the differentarchitectural elements. The utilization of SOC is not evident andany replacement of modules could not be done at runtime (i.e.,hot deployment). A brief overview of solutions and challenges[26] relating RFID and existing RFID middleware presents somedata integration platforms mostly closed source and targeting sup-ply chain related customers. Although some of these solutions likeSun’s and BEA’s middleware (both incorporated by Oracle) utilizeSOA, extensibility and dynamicity are points that are not explored.

A more recent approach called supply chain visualizer [1] alsoallows to visually track objects of a supply chain. They have con-nected that application to Fosstrak’s [15] EPCIS, collecting datafrom different EPCIS instances analyzing the data and presentingthe results (e.g., inference of how much time a product stayed ina partner site) in a higher level interface in a map. However it isnot clear how the object positioning is done (which could possiblybe based on static configuration of each EPCIS or warehouse geo-graphic location) or how they use SOC.

A discovery service specification is still under development byEPCglobal at the time of writing of this paper. Other efforts suchas [4] have also used a web services approach for implementingdiscovery services, but using a simplistic approach. Another effort[18] tries to tackle higher level issues such as data ownership,security, business relationship independence, organic growth,and quality of service, and propose an alternative design toEPCglobal’s approach. Concerning a universal identifier translationmechanism, there is no agreement yet for supporting such schemawhere ordinary object IDs (MAC address, phone number) could beused under a common identification standard in the Internet of

416 K. Gama et al. / Computer Communications 35 (2012) 405–417

Things. However, isolated efforts such as [25] propose mechanismsaimed at supporting other object identifiers like ISO 14443 and ISO15693, respectively.

The OSGi platform is also seen as an enabler technology for theInternet of Things in [23], where OSGi’s modular approach can beused in a distributed context. However, that work provides a viewof a distributed system with cooperative services taking advantageof OSGi and its modular architecture. No concrete example con-cerning RFID usage in that context is given though.

7. Conclusions

Internet of Things is a term initially related with RFID taggedobjects. This concept has evolved in a wider sense, referring nowto a ubiquitous object society combining RFID, sensor networksand pervasive computing technologies. The usage of service-oriented computing is suitable for such a highly dynamic scenariowhere a strong decoupling between components, as well asbetween applications, is imperative for allowing evolutive systemsand architectures. This report aimed at evaluating the benefits ofservice-oriented computing principles for conceiving and realizinga middleware designed to enable an Internet of Things, leveragingthe dynamicity and flexibility of such middleware. Besides theRFID identifiers typically supported, our middleware also supportsordinary objects uniquely identified to be tracked.

The usage of SOC brought positive results turning out to be asuitable solution to tackle issues raised by pervasive computingand the Internet of Things. Our RFID middleware achieved a signif-icant level of flexibility in different levels of the architecture. At theedge level for the seamless integration of sensors and readers. Add-ing or removing readers at runtime in a running edge already pro-vides a good level of flexibility. The service-oriented readersprovide higher flexibility since they can adapt non-RFID objectsand data from external application, when using the RESTful reader,as well as plug and play readers, when using the UPnP approach.The middleware architecture itself allows layers to communicateusing service-oriented technologies, introducing a high level ofdecoupling between the different system layers and allowing toeasily replace entities reified as services (e.g., readers, sensors,servers) with minimal system disruption. The data mediation chainbetween information systems and pervasive systems is easily anddynamically adaptable, allowing protocol changes on the fly andreconfiguring the message routing. The utilization of web servicesfor integrating servers also brought significant results, enabling astronger decoupling between the different applications that com-pose the architecture, and allowing reuse of EPCIS information bythird-party applications. However some improvements could bemade by adapting an ESB in the middleware mediation layer incontexts, where complex event processing or service orchestrationwould be more appropriate than our custom mediation approach.However on the bright side we support several transport protocolsand do not rely only on HTTP/SOAP, which is the typical (as well aslimiting) choice in service-oriented architectures.

The middleware presented in this paper has been validated andused in various scenarios. It allowed us to verify its extensibility,flexibility, and the quick learning curve considering its usage inpractical classes. The integration and support of devices whichare available on the public market, and the facilitated integrationof new devices has shown that this RFID suite is particularlywell-suited for rapid application prototyping. Especially whenthere is a need to design sensor-based and RFID-based applicationsthat need both a well-grounded lower layer to manage devices anda management infrastructure to collect and use the data, with thepossibility to remotely administrate each component of the mid-dleware, and to visualize data through higher level administrationconsoles (e.g., web console) that could be easily replaced.

The RFID suite has been contributed in the OW2 AspireRFIDmiddleware open-source project, which is part of the ASPIRE Euro-pean project. AspireRFID had its architecture partly influenced bythe principles used in the RFID suite here described. Ongoing andfuture work includes migrating into AspireRFID the positive archi-tectural points highlighted by this experiment, including the entiresensor infrastructure, from the edge layer to extended ALE EC specsand reports, and the GUI for tracking and monitoring objects andmeasurements.

Acknowlegments

Part of this work has been carried out in the scope of the ASPIREproject (http://www.fp7-aspire.eu), which is co-funded by theEuropean Commission in the scope of FP7 programme under con-tract number 215417. The authors acknowledge help and contribu-tions from all partners of the project. The RFID suite was mainlydeveloped by Master students that did their internship in the Adèleresearch team of the Laboratoire d’Informatique de Grenoble. Theauthors acknowledge help and contributions from all interns, with-out whom this middleware would not exist.

References

[1] A. Ilic, T. Andersen, F. Michahelles, Increasing supply-chain visibility with rule-based RFID data analysis, IEEE Internet Computing 13 (1) (2009) 31–38.

[2] K. Ashton, That ‘‘TInternet of Things’’ thing, RFID Journal (2009).[3] AUTO-ID Labs. <http://wwwautoid.mit.edu/cs/>.[4] S. Beier, T. Grandison, K. Kailing, R. Rantzau, Discovery services – enabling RFID

traceability in EPCglobal networks, in: 13th International Conference onManagement of Data, 2006.

[5] H. Cervantes, R.S. Hall, Autonomous adaptation to dynamic availability using aservice-oriented component model, in: International Conference on SoftwareEngineering (ICSE), 2004, pp. 614–623.

[6] H. Cervantes, D. Donsez, L. Touseau, An architecture description language fordynamic sensor-based applications, in: 5th IEEE Consumer Communicationsand Networking Conference, 2008.

[7] J. Chamberlain et al, IBM Websphere RFID handbook: A solution guide. <http://www.redbooks.ibm.com/redbooks/pdfs/sg247147.pdf> 2006.

[8] D. Chappell, Enterprise Service Bus, 1st ed., O’Reilly, 2004. ISBN 0-596-00675-6.

[9] D. Donsez, G. Thomas, Propagation d’ vnements entre passerelles OSGi OSGiworkshop, in: Ubimob’06, 3e Journes Francophones Mobilit et Ubiquit, 2006.

[10] EPCglobal. <http://www.epcglobalinc.org>.[11] EPC information services (EPCIS) specification, Version 1.0.1 <http://

www.epcglobalinc.org/standards/epcis> September 21, 2007.[12] EPCglobal architecture framework, Version 1.2 <http://www.epcglobalinc.org/

standards/architecture/architecture> September 10, 2007.[13] C. Escoffier, R.S. Hall, P. Lalanda, iPOJO: an extensible service-oriented

component framework, in: IEEE International Conference on ServicesComputing, 2007.

[14] R.T. Fielding, R.N. Taylor, Principled design of the modern web architecture,ACM Trans. Internet Tech. 2 (2) (2002) 115–150.

[15] Fosstrak. <http://www.fosstrak.org/>.[16] S. Jean, K. Gama, D. Donsez, A. Lagrèze, Towards a monitoring system for high

altitude objects, in: 6th ACM Mobility Conference, 2009.[17] N. Kefalakis, N. Leontiadis, J. Soldatos, K. Gama, D. Donsez, Supply chain

management and NFC picking demonstrations using the AspireRfidmiddleware platform, in: ACM/IFIP/USENIX Middleware ’08 ConferenceCompanion, 2008.

[18] C. Krschner, C. Condea1, O. Kasten, F. Thiesse. Discovery service design in theEPCglobal, in: The Internet of Things 1st International Conference 2008.

[19] F. Michahelles, F. Thiesse, A. Schmidt, J.R. Williams, Pervasive RFID and nearfield communication technology, Pervasive Computing 6 (3) (2007) 94–96.

[20] NFC Forum. <http://www.nfc-forum.org>.[21] OSGi service platform. Specification, Release 4 <http://www.osgi.org>.[22] M.P. Papazoglou, Service-oriented computing: concepts, characteristics and

directions, in: Keynote for the IEEE CS 4th International Conference on WebInformation Systems Engineering (WISE 2003), December 10–12, 2003.

[23] J.S. Rellermeyer et al. The software fabric for the Internet of Things, in: TheInternet of Things 1st International Conference, 2008.

[24] W. Rudametkin, K. Gama, L. Touseau, D. Donsez, Towards a dynamic andextensible middleware for enhancing exhibits, in: IEEE CCNC 2010, ConsumerCommunications and Networking Conference, January 9–12, 2010.

[25] L. Schmidt, N. Mitton, D. Simplot-Ryl, Tag data translation for the Internet ofThings, Information Theory and Aerospace and Electronics SystemsTechnology (VITAE’09) (2009).

[26] Q.Z. Sheng, X. Li, S. Zeadally, Enabling next-generation RFID applications:solutions and challenges, Computer 41 (9) (2008) 21–28.

K. Gama et al. / Computer Communications 35 (2012) 405–417 417

[27] J. Soldatos et al., ASPIRE middleware and programmability specificationsaspire project, WP2 Requirements and specifications (2008).

[28] F. Thiesse, F. Michahelles, An overview of EPC technology, Sensor Review 26(2) (2006) 101–105.

[29] L. Touseau, W. Rudametkin, D. Donsez. Towards a SLA-based approach tohandle service disruptions, in: 5th IEEE International Conference on ServicesComputing 2008.

[30] L. Yan, Y. Zhang, L.T. Yang, H. Ning, The Internet of Things; from RFID to theNext-Generation Pervasive Networked Systems, Auerbach Publications,2008.

[31] B. Williams, What is the Real Business Case for the Internet of Things?,Synthesis Journal Information Technology Standards Committee 2008 (2008)27–135