PRISMA: A Publish-Subscribe and Resource-Oriented Middleware for Wireless Sensor Networks José R. Silva, Flávia C. Delicato, Luci Pirmez, Paulo F. Pires, Jesus M. T. Portocarrero PPGI-DCC/IM Federal University of Rio de Janeiro, UFRJ Rio de Janeiro, Brazil {jr.joserenato.jr, fdelicato , luci.pirmez, paulo.f.pires, jesus140}@gmail.com Taniro C. Rodrigues, Thais V. Batista DIMAp Federal University of Rio Grande do Norte, UFRN Natal, Brazil {tanirocr, thaisbatista}@gmail.com Abstract —PRISMA is a resource-oriented publish/subscribe middleware for WSN, which the main goals are to provide: (i) programming abstraction through the use of REpresentational State Transfer (REST) interfaces, (ii) services, encompassing asynchronous communication, resource discovery and topology control, (iii) runtime support through the creation, configuration, and execution of new applications in WSN, and (iv) QoS mechanisms to meet applications constraints. This paper describes PRISMA architecture, its implementation in the Arduino platform, and a preliminary evaluation. Keywords - middleware; publish/subscribe; topology control. I. INTRODUCTION Wireless Sensor Network (WSN) technology has been evolving fast in recent years. There are currently several hardware platforms available for WSN, such as the sensor motes manufactured by MEMSIC (former Crossbow [1]), Sun Spots [2] (now Oracle) and, more recently, Arduino platform [3], that is used in this work. Additionally, WSNs have gained a lot of attention in the research community and are becoming increasingly popular in the industry, due to their wide range of potential applications. Early applications developed for WSN presented simple requirements and did not demand the use of complex software infrastructures. Moreover, WSN were typically designed to meet the requirements of a single target application. In other words, the source code installed in the nodes was commonly monolithic, highly tied to the requirements of a single application and to a specific sensor platform and the protocol stack for such platform. Furthermore, the application development was highly coupled to low-level primitives provided by the WSN operational system and the design approach was focused on improving the network energy efficiency, given the limited resources of nodes. Such dependence between the application layer and the underlying layers (protocols and hardware) is not desirable for emergent applications and new trends in the field, where the same physical infrastructure of a potentially heterogeneous WSN may be used for various applications, whose requirements are not known at the network deployment time [4]. As the number of WSN physical infrastructure currently deployed is increasing, there is a trend to share and integrate the sensing data produced by these networks through different applications, as well as growing initiatives to include monitoring data as part of Web applications, integrated to other types of resources available on the Internet. In such scenario, there must be interoperability between different WSNs, possibly between different applications, and between WSNs and external networks, as the Internet. In order to meet the emerging trends of WSN scenarios, there is a need to adopt software platforms at the middleware level. A middleware can provide abstractions to build applications and to access data produced by the network, and offer generic or domain specific services. It can also provide a uniform API and standardized protocols that allow interoperability in an environment with high degree of heterogeneity. Despite of the fact that middleware platforms are widely used in traditional distributed systems, their development in the WSN context is relatively recent [4]. A WSN middleware is a layered software that lies between application code and the communication infrastructure providing, via component interfaces, a set of services that may be configured to facilitate the application development and execution in an efficient way for a distributed environment [5]. Thus, the main goal of a middleware is to enable the interaction and the communication between distributed components, hiding from application developers the complexity of the underlying hardware and network platforms, and freeing them from explicit manipulation of protocols and infrastructure services. Besides these generic requirements, a WSN middleware needs to consider some basic features, specific to this context. According to Wang et al. [4], a WSN middleware should offer four main features: (i) programming abstractions, (ii) services, (iii) runtime support, and (iv) mechanisms for Quality of Service (QoS) provision. Programming abstractions define the interface of the middleware for the application developer. Services provide implementations to achieve the abstractions; thus, services encompass the functionalities provided by the middleware and comprise the middleware core. Runtime support acts like an extension of the embedded operating system to support the middleware services. Finally, QoS mechanisms are used to meet quality constraints imposed by applications such as network lifetime, coverage, accuracy, latency, bandwidth, 87 Copyright (c) IARIA, 2014. ISBN: 978-1-61208-360-5 AICT2014 : The Tenth Advanced International Conference on Telecommunications