SOCA (2001) 5:71–85 DOI 10.1007/s11761-011-0083-x
ORIGINAL RESEARCH PAPER
A survey on service-oriented middleware for wireless sensor networks Nader Mohamed · Jameela Al-Jaroodi
Received: 4 March 2010 / Revised: 27 March 2011 / Accepted: 28 March 2011 / Published online: 13 April 2011 © Springer-Verlag London Limited 2011
Abstract Wireless sensor networks (WSN) are used for many applications such as environmental monitoring, infrastructure security, healthcare applications, and traffic control. The design and development of such applications must address many challenges dictated by WSN characteristics on one hand and the targeted applications on the other. One of the emerging approaches used for relaxing these challenges is using service-oriented middleware (SOM). Service-oriented computing, in general, aims to make services available and easily accessible through standardized models and protocols without having to worry about the underlying infrastructures, development models, or implementation details. SOM could play an important role in facilitating the design, development, and implementation of service-oriented systems. This will help achieve interoperability, loose coupling, and heterogeneity support. Furthermore, SOM approaches will provision non-functional requirements like scalability, reliability, flexibility, and Quality of Service (QoS) assurance. This paper surveys the current work in SOM and the trends and challenges to be addressed when designing and developing these solutions for WSN. Keywords Service-oriented middleware · Service-oriented computing · Wireless sensor networks · RFID · Middleware · Interoperability
N. Mohamed (B) · J. Al-Jaroodi Faculty of Information Technology, UAEU, P.O. Box 17551, Al Ain, UAE e-mail:
[email protected] J. Al-Jaroodi e-mail:
[email protected]
1 Introduction WSN applications have gained a strong momentum through the advances of technology in distributed computing, networking, wireless communications, sensor technologies, and embedded systems. These advances offered an exceptional opportunity for developing a wide array of WSN applications like production lines controls, shipping, pollution monitoring, disaster prevention, infrastructure security, habitat monitoring, remote health monitoring, and traffic control, which are essential for the progress of different fields such as medicine, environment protection, manufacturing, engineering, and business. In general, these applications are built utilizing different heterogeneous devices such as high-end servers, RFID components, mobile devices, storage devices, sensors, and robots. These devices communicate through a variety of wireless/wired networking technologies. In addition, these devices are usually controlled by several software components developed by different vendors and implemented using different programming languages and models. Due to the high distribution, dynamic properties, and heterogeneity of the devices, communication technologies and software components used; implementing such applications is non-trivial. There are usually integration, scalability, reliability, security, usability, QoS, and operational issues to be considered. Incorporating a middleware layer is a novel approach to attempt to meet the design and implementation issues of WSN applications. There are different middleware approaches for WSN [27]. These approaches provide important functions for different applications such as efficient software installation and data aggregation. However, more advanced functions are needed in the middleware to reduce the complexity of the design and implementation of the needed software for different WSN applications.
123
72
One of the most recent approaches that provide high flexibility for adding new and advanced functions to WSN middleware is the service-oriented approach. Service-oriented middleware (SOM) logically views WSNs as a service provider for user applications. The SOM provides abstractions for the complex underlining WSN through a set of services needed by WSN applications. These services can be data aggregation, adaptation, security, self-organization, reliability, and management services. All these and other advanced services can be designed, implemented, and integrated in an SOM framework to provide a flexible and easy environment to develop effective WSN applications. Some research efforts have been done on surveying the different aspects of middleware and programming paradigms for WSN. For example, [26] reviewed some middleware projects for WSN; different middleware challenges and approaches for WSN were surveyed in [27]; and [18] presented and classified virtual machines for WSN. Furthermore, [46] surveyed the programming models for sensor networks, while the state of the art in programming approaches for WSN were surveyed in [38]. These research efforts are for general programming and middleware for sensor networks. However, none of the existing work investigated the current state of research on the design and development of SOM for WSN. In this paper, we review and discuss different approaches of SOM for WSN, and present some of the challenges they faced. Thus, in Section 2, we provide some background information and related concepts. Section 3 discusses the general middleware challenges for WSN. The SOM requirements for WSN are discussed in Section 4 and the current SOM approaches for WSN are discussed in Section 5. Section 6 provides a discussion of the categories of application based on their different needs for middleware services. Section 7 provides a discussion of the SOM challenges for WSN, and Section 8 concludes the paper.
2 Background and concepts Recently, service-oriented computing (SOC) [9,25] has become a preferred model over the more traditional monolithic and client/server development models. It overcomes several problems and challenges these two types have faced. SOC offers a promising way for enabling software vendors to present their software applications as services. It provides a framework to represent business processes as independent modules (services) with clear and accessible interfaces. The interactions among services are done through a standard description language such as XML, which makes it easy to integrate different services to build a business application and address problems related to the integration of heterogeneous applications in a distributed environment. Services can implement a single business process or a set of different
123
SOCA (2001) 5:71–85
processes that are made available for integration with other heterogeneous services. Services can be developed using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, and Web Services. The generalized model — service-oriented architecture (SOA) — basically involves three main players: the service provider, the service broker, and the service requester. The service provider designs and develops a service. The service broker makes this service available to the rest of world through public registries such as Universal Description Discovery and Integration (UDDI) for web services. The service requester locates the entries in the public registry and binds with the service provider to invoke the web services required. There are many people (researchers and practitioners) with many different levels of understandings and uses of serviceoriented computing. According to [40], the SOA approach makes the following things possible: • Multiple applications executing in varied platforms can effectively communicate with each other • Software services are provided to end-user applications through published/discoverable interfaces • Services are loosely coupled thus reducing dependencies and facilitating reuse • Service callers are coupled with services needed for the duration of the utilization only • A relationship is created among the participants: service provider, discovery agency, and service requester • Interactions between the participants involve the publish, find and bind operations • Service consumers target-specific services through specific interfaces that are exposed by the service registry and discovery mechanisms Middleware, in general, offers the capabilities to integrate and reuse software components on demand and helps abstract the distribution and heterogeneity of the underlying computing environment and services available. It also supports the addition of non-functional values such as interoperability, load balancing, scalability, reliability, availability, usability, extensibility, manageability, reusability, services discovery, Quality of Service (QoS) stability, efficiency, autonomocity, and security. A number of middleware platforms were developed to add new values for different systems such as enterprise systems [11], cluster computing [2], mobile ad hoc networks [10,28], and robotics [37]. The mechanisms and approaches are usually based on the reuse of existing methods, protocols, software, and systems to add the needed values. There are different middleware approaches for WSN. Some of these approaches are the virtual machine, database, application driven, and message-oriented middleware [27]. The virtual machine approach contains interpreters and mobile codes written in modules that represent the
SOCA (2001) 5:71–85
application and are interpreted by the virtual machine. The system injects and distributes the modules through the network using tailored algorithms such as one for minimizing overall energy consumption. In the database approach, the whole network is viewed as a virtual database system. This approach provides an easy-to-use interface that lets the user issue queries to the sensor network to extract the sensed data of interest. The application driven approach provides an architecture that reaches the network protocol stack. This allows programmers to fine-tune the network on the basis of application requirements such as QoS, configuration, and management. Although, this approach has great performance advantages, it may provide a specialized middleware that is tightly coupled with the application instead of a general purpose middleware. Finally, the message-oriented middleware approach provides publish-subscribe mechanisms to facilitate message exchange between the sensors and the sink nodes. The strength of this paradigm lies in its support for asynchronous communication that helps in saving energy in the WSN. This approach is very suitable for WSN where most applications are based on events. The middleware approaches for WSN provide some important functions for different applications such as efficient software installation and efficient data aggregation. However, more advanced functions are needed in the middleware to reduce the complexity of designing and implementing software for different WSN applications. Examples of these advanced functions are adaptation, security, self-organization, control, QoS, reliability, context-awareness, and management. There are some successful efforts to design middleware platforms for WSN to provide one or few of these advanced functions. However, most of these are considered specialized middleware platforms that could be best used for certain types of applications and needs. This is because they offer limited functions, while most WSN applications usually need several or most of the possible advanced functions. Using SOM to support services development and utilization has been advocated by many researchers who call for using service-oriented middleware (SOM) over traditional middleware that connects diverse components and systems and provides multiple-channel access to services, e.g., via mobile and handheld-devices and sensor devices over a variety of networks including the Internet, UMTS, XDSL, and bluetooth [41]. On another aspect, the authors [36] identify the requirements and challenges of SOM for pervasive environments. Among the requirements, there are primary requirements such as message exchange, mobility support, security and service description, discovery, and coordination. There are also cross-cutting requirements including QoS support, autonomy and context awareness. Therefore, recent efforts have targeted the use of SOM for WSN to provide high flexibility for adding new functions to WSN middleware. Unlike other approaches, new functions can be added
73
to the middleware simply by adding new services. SOM logically views WSN as a service provider for user applications. SOM provides abstractions for the complex underlying WSN through a set of advanced services needed by WSN applications. These services can be designed, implemented, and easily integrated in the SOM to provide a flexible and easy environment to develop WSN applications. 3 Middleware challenges for WSN WSN middleware is a software infrastructure that glues together the sensor network hardware, operating systems, network stacks, and applications. A complete middleware solution should contain a runtime environment that supports and coordinates multiple applications and standardized system services such as data aggregation, control, and management policies that can adapt to target applications. In addition, it should include mechanisms to achieve adaptive, secure, and efficient system resources utilization to prolong the sensor network’s life. The WSN middleware layer hides the complexity of the network environment by isolating the application from the communication and hardware details. The design and development of a successful middleware layer for WSN is not trivial. It needs to deal with many challenges dictated by the WSN characteristics on one hand and the applications demands on the other. Following is a discussion of these challenges: 3.1 Hardware resources The advent in microelectronics technology made it possible to design miniaturized devices in the order of cubic centimeters end even smaller. Limited in energy and individual resources, these tiny devices could be deployed in hundreds or thousands in harsh and hostile environments, where in some cases no physical contact could be possible for replacement or any maintenance scope; therefore, wireless communication is the only way for remote accessibility. A middleware should provide mechanisms for an efficient use of the processor and memory while enabling lower power communication. A sensor node should accomplish its three basic operations (sensing, data processing, and communication) while minimizing resources utilization to avoid fast resources exhaustion. As an example of energy aware middleware, it should be able to force most of the device’s components including the radio are likely to be turned off most of the time and only activate them depending on the application needs. 3.2 Changes in network topology and size The topology of the network is subject to frequent changes due to different factors such as device failure, device
123
74
mobility, moving obstacles, and interferences. If an application gets bigger, the network should be flexible enough to allow the addition of more nodes anywhere any time without affecting network performance. In addition, if some nodes or links fail, the middleware should be able to report the failure and take automatic measures to either correct the problem or take alternative actions to maintain network operations until the failure is fixed. Also, middleware should support mechanisms for self-configuration and self-maintenance of collections of sensor nodes. Furthermore, the middleware should be able to adjust network devices properties such as transmission ranges and sleep periods to adjust to any changes in the topology. 3.3 Heterogeneity As mentioned earlier, in a WSN, devices, links, software components may be heterogeneous and require special programming models and tools to utilize and integrate them within a WSN application. Thus, the middleware should provide some mechanisms to meet the major challenge of bridging the gap between hardware technology’s raw potential and the broad needed activities. It should establish system mechanisms interfacing with the various types of hardware and networks, only supported by basic distributed primitive operating system abstractions. As a result, this should make it easier to develop the applications using the network without worrying about the low-level details. 3.4 Network organization Unlike traditional networks, sensor networks must deal with resources—energy, bandwidth, and processing power that are dynamically changing. Another important issue in sensor networks is to support long-running applications, where efficient design of routing protocols are needed to allow the network could run as long as possible. An ad hoc network resources discovery mechanism should be provided, since knowledge of the network is essential for a network to operate properly. A sensor node needs to know its own location in the network in addition to the whole network topology. Some important issues on system parameters such as network size and density per square mile affect the tradeoffs between latency, reliability, and energy consumption. A middleware should support the robust operation of sensor networks despite these dynamics by adapting to the changing network environment. 3.5 Application knowledge Another important and unique property of middleware for WSN is dictated by the design principles of application knowledge. However, middleware has to include mechanisms for injecting application knowledge in the
123
SOCA (2001) 5:71–85
infrastructure of the WSN. This will allow mapping application communication requirements to network parameters that allow fine-tuning of the network monitoring process. For example, different applications have different reliability requirements and a fixed measure is not suitable for all applications. Therefore, the middleware should be able to acquire the knowledge about the acceptable reliability levels of the application and map the needed functionality to the underlying infrastructure to maintain it. Another example is in the range of coverage where some applications cover very large geographical areas and require wide-range communication; while others are use mode dense networks thus require shorter-range communication. The middleware services should be able to adjust these needs and change transmission ranges based on each application’s requirements. 3.6 Security WSN are being widely deployed in domains that involve sensitive information and critical services such as military, healthcare, and rescue services. In such domains, it is necessary to secure communication, service execution, and service availability. Furthermore, the large deployment of WSN in harsh environments increases their exposure to malicious attacks such as denial of service and rogue nodes. In addition, the wireless medium facilitates eavesdropping and adversarial packet injection to compromise the network’s functions. All these factors make it extremely important to support security services for SOM for WSN. In such cases encryption services are required to hide critical information, WSN monitoring services are needed to protect from external attacks and report abnormal access and usage issues. In addition, it is important to deploy and enforce strong authentication and access control policies to ensure safe WSN functionality for the users. On the other hand, sensor nodes have limited power and processing resources. Therefore, standard security mechanisms that consume a lot of resources (e.g., processing and communication) are not suitable. For example, encryption/decryption processes require very high computational power and authenticating every correspondence and user also requires high communication load. These challenges increase the need to develop comprehensive and secure solutions that achieve wider protection, while maintaining desirable network performance and acceptable power consumption when necessary. Middleware efforts should concentrate on developing and integrating security functions in the initial phases of software design, hence effectively achieving different security requirements such as confidentiality, authentication, integrity, freshness, and availability. Some work in investigating possible security approaches for SOM in general is available [3]. However, more effort to adapt these security functionalities to the specific needs of WSN is required.
SOCA (2001) 5:71–85
3.7 Quality of service Quality of service is an overused term with multiple meanings and perspectives from different research and technical communities. In WSN, we can view QoS from two perspectives: application specific and network. The former refers to QoS parameters specific to the application, such as sensor node measurement, deployment, and coverage and number of active sensor nodes. The latter refers to how the supporting communication network can meet application needs while efficiently using network resources such as bandwidth and power consumption. Traditional QoS mechanisms used in wired networks are not adequate for WSN because of constraints such as resource limitations and dynamic topology. Therefore, middleware should provide new mechanisms to maintain QoS over an extended period and even adjust itself when the required QoS and the state of the application changes. Middleware should be designed based on tradeoffs among performance metrics such as network capacity or throughput, data delivery delay, and energy consumption. 3.8 Integration with other systems Most sensor network applications consist of sensor or RFID networks and their supporting software components that need to be integrated with other systems such as enterprise or web systems. This integration is necessary to achieve the intended goals of using sensor networks to begin with since collected data are useless unless it is given to its intended target to achieve the ultimate goal. Middleware can facilitate that integration by allowing enterprise and web systems to smoothly and correctly connect to, control and collect the needed information from WSN or RFID networks. This requires providing a set of interfaces that facilitate the integration and validate the exchanged information between the WSN and the external system.
4 SOM requirements for WSN SOM for WSN is necessary to support several, otherwise hard to incorporate, functionalities in the SOC model. These functionalities include not only the functional requirements, but also the non-functional requirements that different services might need to offer. In many application domains, services provide a set of specific functions based on the required application logic that will be different for each service and each application. However, those services and service providers also need to support several common functionalities that are generally irrelevant to the main application. For example, most services will have to support service registries and discovery mechanisms and they will also need to provide some level of abstraction to hide the underlying envi-
75
ronment and implementation details. Furthermore, all SOC applications need to support some levels of reliability, performance, security, and QoS. All of these can be supported and made available through a common middleware platform instead of having to incorporate them into each and every service and application developed. In general, based on our observations, an SOM for WSN should support a number of requirements (listed below). The first three are the basic and general service-oriented requirements that must be available in any service-oriented system. The rest of the requirements are enforced by the characteristic of the WSN environment on one hand and the challenge of implementing and operating applications on that environment on the other. The requirements are: 1. Runtime support for services deployment and execution: as a WSN is viewed as a set of services provided for supporting some applications, SOM should provide mechanisms to deploy, load, and execute these services. 2. Support for service consumers to discover and use registered services: SOM should enable client applications to discover and use registered services. SOM should enable the integration between applications and registered services. 3. Service transparency to client applications: SOM should allow client applications to transparently use available services without exposing the services implementation details or in some situation its detailed components locations. 4. Abstractions to hide the heterogeneity of underlying sensor environments: all heterogeneity details of WSN hardware and network should be hidden from the applications. SOM should provide high-level interfaces to utilize WSN resources without requiring the application developers to deal directly with the heterogeneity. This requirement addresses the heterogeneity and network organization challenges mentioned in the previous section. 5. Configurable services: This requirement is to help solve the hardware resources and application knowledge challenges mentioned in the previous section. SOM should provide mechanisms for client applications to configure WSN services to meet specific application requirements such as QoS, security, or reliability. Configuring WSN usually require dealing with details and parameters of some hardware and communication components. Doing this for configuring QoS for example will be a very complex task for regular users. However, SOM can provide mechanisms to be used easily by client applications to configure WSN for specific application requirements. 6. Support for self-organization mechanisms: this can include self-x properties such self-management, self-healing, self-configuration, auto-discovery, self-adaptation,
123
76
7.
8.
9.
10.
SOCA (2001) 5:71–85
and self-optimization of service providers. WSN are dynamic distributed environments where nodes can fail and new nodes can be added anytime. In addition, mobile nodes with some services can be available for some time. The availability of services in these nodes is also dynamic. Therefore, SOM should support self-management, auto-discovery, auto-change, selfoptimization, and auto-change mechanisms for efficient utilization of available services. For example, when a node provides a service for sensing a certain attribute the SOM should discover that service and allow the client applications to use it when they need it. When that node fails, SOM should automatically switch the applications to a similar service currently available on another node in the network. Furthermore, the middleware should be able to notify the applications if nothing matching their needs is currently available. This requirement helps in solving the scalability, heterogeneity, network organization, and application knowledge challenges mentioned in the previous section. Interoperability with a variety of devices: This requirement helps solve the heterogeneity challenges mentioned in the previous section. Some sensor applications require variety of devices to be operated. SOM for WSN can be design to be interoperable with different devices such as devices with different types of sensors, RFID, and mobile nodes to enable easy application development and operation. Efficient handling of large volumes of data and high communication loads: This requirement helps in solving the limited hardware resources and network organization challenges mentioned in the previous section. Some WSN applications involve large volumes of data and high communication loads. As WSN have limited resources, SOM should efficiently and carefully deal with that load through trade-offs between application requirements in terms of accuracy, bandwidth, delay, and energy consumption. Secure communication and execution: as WSN are being widely deployed in domains that involve sensitive and critical information, secure communication and execution becomes a very important aspect in SOM for WSN. SOM should provide mechanisms to secure the utilization and operations of WSN services. All communication and execution for supporting these services should be also secured. Support for QoS requirements: a large range of WSN applications have QoS requirements. Mechanisms are needed to configure and satisfy these requirements in WSN environments. Example of QoS requirements in WSN can be reporting a critical reading within a certain time frame and within a certain error level. In some situations, the QoS requirements can come from multi-
123
ple applications. SOM for WSN should provide uniform interfaces to configure the QoS requirements for these applications as well as ensuring achieving these requirements. 11. Support for integration with other systems: as WSN usually do not operate in isolation, SOM should enable the integration of WSN with other systems such as enterprise or web systems. For example, some web applications rely on WSN for their current information such as information on weather conditions, shipments locations, and traffic conditions. In this case, SOM should enable that integration such that these applications can fulfill their goals. In addition to these requirements, there are other advanced and specialized requirements that are needed for some advanced and specialized applications. One example of these requirements is support for mobility. This is important for applications with mobile sensor nodes in the WSN. Another requirement example is support for context awareness. SOM can provide some mechanisms for applications to easily and efficiently reason about and react to its environmental contexts. Some of these mentioned requirements are also required for some SOM implemented for other types of systems such as Grid and enterprise systems. However, the main characteristic that distinguishes WSN environments from others is that all these requirements must be designed and implemented on limited computation, communication, memory, and energy resources. The middleware services within the SOM must be lightweight and very efficient in resources utilization. Generally, researchers propose SOM approaches best suited for their underlying environments. Therefore, many of these approaches may provide some of the requirements described above, but most of them do not support all requirements. In the following section, we provide a discussion of some representative approaches.
5 SOM approaches for WSN While conducting our research through the different approaches researchers and practitioners are working on, we came across a large pool of examples on SOM for WSN. Several approaches are currently being investigated at the research level while a few are actually being used in practice. The main issue to handle here is the diversity and heterogeneity of the sensors being used and the networks connecting them. Several issues were addressed by this category of approaches like handling complex and/or continuous queries, data access, aggregation and management, service publishing, discovery and deployment, group management, real-time access to data
SOCA (2001) 5:71–85
and services, and limited resources. The following is a brief overview of the selected approaches:
77
SStreaMWare [33] is a sensor mediator SOM that provides a query service to access data issued by heterogeneous sensors. The main objective is to provide a hybrid solution focusing on sensor heterogeneity management, scalability, and complex query evaluation. The main elements of SStreaMWare are the sensors, the proxies and adapters, the gateways, and the control sites. Its architecture consists of three querying services and a discovery/binding service. The Query Service is deployed on the control site and is responsible for query evaluation. The Gateway Service is deployed on every gateway and provides a query service for the sensors managed by that gateway. The Proxy Service is deployed at concerned gateways and provides services to a specific type of sensors. The Lookup Service is for service discovery and binding in addition to managing the service registry.
project (NICTA Open Sensor Web Architecture (NOSA)) [17,31]. In this project, the team discusses an SOM to support data collection and manipulation across heterogeneous sensor networks. The main concern is to sustain contiguous access and use of sensor data over extended periods of time. NOSA provides service-based access to and management of sensors. It helps integrate sensor networks and distributed computing platforms such as SOA and Grid Computing. The main benefits are: Information processing can be moved from sensor networks to the backend distributed systems, individual sensor networks can be linked together as services that can be registered, discovered, and accessed by different clients using a uniform protocol. The main components defined for NOSA are composed in four layers: fabric, services, development, and application. It provides the following sensor services: (1) sensor notification, collection, and observation; (2) data collection, aggregation, and archival; (3) sensor co-ordination and data processing; (4) faulty sensor data correction and management; and (5) sensor configuration and directory service.
5.2 USEME
5.4 OASiS
USEME is a service-oriented framework to develop wireless sensor and actor networks (WSAN) applications. In [12] a middleware to support, it is presented. The main job of the middleware is to handle the publication and discovery of web services, communication related issues, group management, and real-time constraints. The architecture of the middleware is divided into five core components including configuration, publication and discovery, invocation and communication, real-time constraint management, and group management. Different parameters such as deadlines and discovery frequency can be changed through its configuration component. The publication and discovery component keeps track of the available services. The invocation and communication component takes care of translating the remote commands executed by application programmers into communication packets between remote nodes. The realtime constraint management component manages constraints like setting the priorities for activities, specifying maximum execution time for a command, and setting time intervals for periodical events. To achieve scalability and efficiency, the middleware forms groups of the nodes that share common behaviors and automatically controls the use of services provided by the groups using the group management component.
OASiS [4] is an object-centric, service-oriented, ambientaware sensor network applications development model. It defines the logical elements necessary to support a wide variety of WSN dataflow applications. It defines a programming framework that facilitates separation of concerns for application development through a multilayer development process. The core sensor network functionalities are bundled as middleware services including service discovery, service graph composition, failure detection, and node management. Using the OASiS framework, application developers do not require any expertise in sensor network programming. The framework addresses some design challenges for networked embedded sensor systems by supporting dynamic service discovery and configuration, heterogeneity, real-world integration in application design, constraints management, data aggregation and specification of both application-specific and network QoS requirements. The OASiS middleware includes services such as Node Manager, Object Manager, and Dynamic Service Configurator and provides the support to the application services.
5.1 SStreaMWare
5.3 SensorWeb 2.0 To support the Open Geospatial Consortium’s (OGC) efforts, the Cloud Computing and Distributed Systems (CLOUDS) Laboratory at the University of Melbourne (http://www. gridbus.org/sensorweb/), are working on the SensorWeb
5.5 B-VIS B-VIS (Burapha Vehicle-Infrastructure System) [45] is an SOM targeted to facilitate the utilization of distributed RFID sensor networks for vehicle-based applications. It supports real-time vehicle fleet tracking and control and also supports road traffic monitoring systems. In addition, it provides a programming model for developers to retrieve, in real-time, the data collected by the RFID sensor networks. This reduces the
123
78
complexities of the heterogeneous communication layer and data sources. The B-VIS SOA is based on open methods and loose coupling between the software and the hardware components that facilitate communication. There are two main layers, the B-Base Gateway layer and the Enterprise Application Server Layer. 5.6 MiSense MiSense [30] is a service-oriented component-based middleware designed to support distributed sensor applications with various performance requirements. It reduces complexity by imposing a structure on top of the component model in the form of composability restrictions and by offering well-defined service-specific interfaces to the rest of the system. MiSense provides a well-defined content-based publish/subscribe service, but also allows the application designer to adapt the service. The middleware is divided in three layers: The Communication Layer, which provides a well-defined content-based publish/subscribe service called MiPSCom, that allows the application designer to adapt the service by making orthogonal choices about the communication protocol components for subscription and notification delivery. The Common Services Layer, which provides services common to different kinds of applications, such as data aggregation, event detection, topology management, and routing. The Domain Layer, which aims to support domainspecific needs, such as data fusion and specific data semantic support to allow the production of application-related information from raw data processing. The programming interface provides a set of functions that will allow the user to control and program the sensor network as a whole network with different functional characteristics without worrying about the detailed placement of computation and communication.
SOCA (2001) 5:71–85
Messaging Server stores the messages in a queue; The Messaging Components will be notified by the message arrival in the message queue; The DBMS is employed to store the data coming from the DataFilter Box; The Management DashBoard allows the administrator to configure the middleware; The Business Integration Framework allows diverse components, services, legacy systems, messaging servers, and clients interfaces to intercommunicate; and The Client Interfaces allow clients to query the sensors and view the warning state in addition to the components necessary to complete M operations. 5.8 (SI)2 Smart Items Services Infrastructure (SI)2 [6] is a SOM developed to address the issues of platform-independent service description, deployment, and invocation without any knowledge of the underlying smart items network. A smart items network may consist of RFID Systems, wireless sensor networks, and/or embedded systems. Its architecture is mainly divided in two layers, platform-independent and platformdependent layer. Message Handlers are in the platformdependent layer and their main job is to convert the events generated by the smart items of a specific platform into platform independent events. The Service Lifecycle Managers, also in the platform dependant layer, are responsible for deploying, starting and stopping the services on the network of smart items. The Request Processor, Service Mapper, and Service Repository are the main components of the platform independent layer. The Service Mapper is responsible for getting the service description from the middleware and searching for a feasible deployment for it. The task of the Request Processor is to handle platform-independent requests for a specified service, transmit it to the correct Message Handler and return the respective result.
5.7 SOMDM 5.9 SOA-MM The authors propose a message-driven SOM to support ambient-aware wireless sensor networks (WSN) [39]. One of the important considerations in WSN is to keep processing overhead at a minimum. Thus, the proposed design adopts middleware and service-oriented architecture advancements to better handle the processing load. This allows the WSN to deal with the real-time demand of query processing and seamless integration and execution of process logic. The design also incorporates a data filter mechanism for filtering events of interest, which reduces the load on the processing components by using a notification service. This middleware comprises several components: the object code requires nodes of the WSN to follow the ambient programming model; The DataFilter Box separates normal and exceptional events where normal data are directed toward a database and exceptional events are forwarded to a Message Queue; The
123
In [24] an SOA-based middleware for manufacturing systems (SOA-MM) in the form of an integration layer between the shop floor equipment and the enterprise applications is presented. The layer addresses service granularity, physical distribution, and degree of coupling individually. This is done according to the actual capabilities and data flows on the field and control layer irrespective of the type of devices used. The integration layer consists of gateway entities, core services, and UDDI registry for publishing core services. A gateway entity is created to map applicationspecific requests to the core services for a specific device. The core services represent the main engine of this integration layer. Currently, there are five core services available: device identification service, information retrieval service (applying application-specific filters to reveal relevant information
SOCA (2001) 5:71–85
from device-related information), device positioning service, structure analysis service (to reveal the structure of complex devices), and event notification service. 5.10 ubiSOAP The main objective of designing ubiSOAP communication middleware [13] is to provide seamless networking of web services that may be deployed on various devices including mobile devices. The architecture of ubiSOAP consists of a multi-radio networking layer and a Web Services (WS)-oriented communication layer. The multi-radio networking layer generates and manages Multi-Radio Network Addresses (MRN), which is assigned uniquely to given applications in a network. This layer also provides the functionality to select the best available network based on the QoS requirements. The WS-oriented communication layer provides point-to-point communication that brings multi-radio multi-network routing to legacy SOAP messaging and group communication. This results in enhancing the SOAP API to meet the corresponding base requirements of pervasive networking environments such as wireless sensor networks. 5.11 TinySOA TinySOA [7] is a service-oriented architecture that provides a high-level abstraction for the development of WSN applications. It allows application developers to access SN from their applications using a simple service-oriented API via the programming language of their choice. The main advantage of TinySOA is reliving application developers from dealing with the low-level technical details of the WSN hardware and communication to get sensors data. TinySOA can be used to easily integrate Internet applications with WSN and allow them to collect information from the sensors. TinySOA has mechanisms for WSN infrastructure registry and node discovery. In addition, it has a gateway component that acts as a bridge between a WSN and external applications. Web services are used to allow applications to access WSN. 5.12 SOM architecture for WSN This SOM architecture [1] provides a mechanism for mediating data exchange between heterogonous sensor platforms and web applications and services through gateways that link the different WSN with Web applications. This exchange is done in a unified way using web services. This middleware is designed based on Devices Profile for Web Services (DPWS) [15], which is a lightweight subset of Web Services technologies. DPWS was designed to target resource constrained devices and consists of a number of components such as WS-Discovery and WS-Eventing. WS-Discovery enables plug-and-play features for sensor nodes. WS-Event-
79
ing enables asynchronous message exchange among sensor nodes through a publish/subscribe mechanism. DPWS is used in the middleware as a basis to reduce the overhead imposed by traditional Web Service technologies. For example, instead of large XML messages, binary encoding techniques are used. The messages are encoded before being transferred to reduce the communication bandwidth needed. In addition, WS-Eventing communication is used to reduce the communication load on the network, where only needed events or information are sent. The middleware architecture consists of a roaming manager that uses address mapping to enable sensor nodes to seamlessly leave one gateway and attach to another without losing the connection to the client. 5.13 MidCASE MidCASE [8] is a SOM for enabling the development of context- aware applications in smart environments. This SOM bridges the gap between the applications layer consisting of different context- awareness requirements and the hardware layer consisting of heterogeneous devices such as wireless sensor networks, RFID, and webcams. In this middleware, a service-oriented approach is adapted to achieve the goals for each awareness service domain while the aware process is achieved by applying rule-based reasoning. The traditional context-awareness systems cannot usually handle a context-awareness process that depends on many contexts coming from different entities due to the lack of communication among these entities. MidCASE uses a service-oriented approach to provide mechanisms to allow many factors to interact between each other to enable context-awareness reasoning. 5.14 SensorsMW SensorsMW [5] is an adaptable SOM for QoS configuration and management of WSN. It abstracts WSN for seamless integration into enterprise information systems, where applications can gather sensed information using Web Services. It allows high-level applications to easily configure to efficiently collect information from WSN. Low-level features in WSN are managed for guaranteeing certain QoS levels. It supports QoS requirements using a contract negotiation approach based on Service Level Agreements. It allows applications to reconfigure and maintain the network during its lifetime. For example, as nodes are powered by batteries, it is therefore important to minimize their energy consumption to extend their lifetime. Since power consumption depends on the rate of sensing and communication, it is important for high-level applications to control and trade-off sensing frequency against node lifetime. To achieve this, nodes need to be accessed to change their configurations to fit with the
123
80
applications requirements. SensorsMW provides an abstract way for high-level applications to achieve that goal. 5.15 DySSCo DySSCo [34] is a protocol for dynamic self-organizing service coverage that can be used in a SOM for WSN. Heterogeneous sensor nodes that perform different tasks and have different software and hardware components are used to increase the performance and flexibility of WSN. In these heterogeneous networks, each node provides the applications with different services based on its configurations and location. Service distribution among nodes can not be done in a static manner since the network would be inflexible to new applications requirements, mobility, node failures, and network fragmentations. DySSCo is a decentralized protocol that can be used in any SOM for WSN to achieve uniform service coverage in the network during the deployment. Because of the self-organization feature, the middleware on WSN is able to react to newly added nodes and node failures by adding and removing services at runtime without user involvement. In addition, the middleware can adapt to new user demands, like a demand for higher quality of sensed data or higher reliability. DySSCo realizes a dynamic adaptation and optimization of service distribution coverage during runtime. This is to avoid situations such as having higher coverage than required, which will waste the WSN resources or having too low coverage that may impact negatively on the monitoring applications. 5.16 Other projects In this paper, we covered a number of recent representative projects to provide a ground for the discussion of SOM approaches for WSN. However, there are other related projects that we did not cover. This due to the fact that they provide similar approaches to those we covered in our discussion. However, every SOM can support different functions for WSN and these functions can be implemented and integrated in different ways. Example of the related and early work that addressed SOM and SOA for WSN are in [19,21, 22], and [23]. Most of this work developed SOM to provide integration between WSN and high-level applications such as enterprise systems and web applications. Another example is [42] that provides a service-oriented self-configurable middleware that enables load balancing within the network.
6 Application needs WSN are not general purpose networks like the Internet, while WSN applications are spreading over a board spectrum, they are usually deployed for very specific purposes.
123
SOCA (2001) 5:71–85
The applications a WSN is targeted for would greatly affect the selection of middleware and services that support the development and operations of the application. WSN Applications can be divided into different categories that need different services from the supporting middleware. Based on the category of the application, the required services are determined. The possible categories are: scale, accessibility, criticality, complexity, traffic granularity, and use of standalone versus integrated applications. Scale: WSN can be used in a small size with few adjacent sensor nodes as in body sensor networks or in a large size with thousands of sensor nodes distributed over a large area as in battlefield surveillance. In the latter case, there is high need for middleware that provides self-organization services to deal with the challenges of reliably, efficiency, and manageability of the network. Accessibility: WSN can be used in accessible areas such as in the manufacturing domain or in inaccessible areas such as monitoring underwater pipelines that extend for hundreds of kilometers. In the inaccessible case, the need for middleware that provides energy-efficient, configurable, and self-organized services is high. This is due to difficulty of replacing nodes when they are damaged or run out of power. The configuration and management of this type of network is also a challenging problem that can be relaxed with the existence of configurable and self-organized services. In addition, it is important to have deployment service that enables the efficient installation of new and updated software. Criticality: WSN can be used for uncritical application domains such as habitat sensing or in highly critical domains that need high security and QoS for transferring sensed information such as in infrastructure monitoring and battlefield surveillance. In this type of critical applications, the requirements for security and QoS services are high and should be provided by the middleware. Complexity: WSN environments can be simple with structured distributed homogenous nodes as in WSN for monitoring buildings; or complex with high dynamic unstructured distributed heterogeneous nodes. In the latter case, there is a strong need for services that provide good abstractions to hide the heterogeneity of the underlying sensor environments. These services should be also interoperable with a variety of devices. The middleware services should be transparent to the client applications. In addition, complexity is increased in highly dynamic settings, thus we need efficient resource discovery services as well as self-organization services to efficiently utilize the available resources to meet the applications requirements on one hand and to extend the life of the network on the other. Traffic granularity: some sensor applications only need to receive information about exceptions such as a sudden change in temperature, pressure, or movement. One example of these applications is a WSN for monitoring forests for
SOCA (2001) 5:71–85
fires. WSN will only report if there is a sudden increase in the temperature (as indicator of fire near by). This type of applications will generate low communication traffic and would not impose a high demand on the communications resources. On other hand, some applications have stream sensors such as cameras and audio recorders that need to send continuous streams of information thus generating high communication load on the network. In this case, there is high need for middleware services that can efficiently handle high traffic and adapt the network operations for optimal performance. Use of standalone versus integrated applications: WSN can be developed and installed as a standalone application that does not need to be integrated with other systems. In this case, there are generally no constraints on the design and implementation. On the other hand, they may need to be integrated with other systems such as enterprise and web applications. In this case, there is a high need for a middleware service that enables that integration efficiently and without difficulty.
7 Discussion SOM platforms view WSN as a set of services distributed across the network with well-defined interfaces. These services can be easily discovered and used through the SOM by WSN applications. The job of SOM for WSN is not only to cater for functional properties (such as communication, service creation, discovery and invocation, group management, and real-time operations) but also to support non-functional properties (such as scalability, service reliability, service flexibility, interoperability, and QoS assurance). In Table 1, we summarize the different SOM approaches for WSN and identify the specific requirements each approach satisfies. To achieve this, SOM should make use of either meta-programming languages or domain-specific languages. Such an initiative has been taken in the case of ServiceOriented Context-Aware middleware that makes use of its own developed domain-specific language to express the context-based rules. The rule management strategy and notification service with the use of domain-specific language can become handy especially in case of service deployment. Since two interactive parties might communicate through multiple paths, choosing the best connecting path to serve a given interaction is a key issue to deal with, especially in SOC as this significantly affects the QoS [14]. Moreover, since SOM for WSN is based on services of heterogeneous nature, the response time of these services is one of the factors that directly affect its efficiency. To improve efficiency, the response time of the services needs to be improved. Such an improvement is possible by introducing UDP-based SOAP transport instead of HTTP based transport [32]. However, a typical SOM, which handles large
81
amounts of messages and event notifications coming from numerous services and shares them among different operating components, must have a reliable system in place that ensures a reliable flow of correct and timely messages. This can be achieved using event management techniques that implement different mechanisms to ensure QoS and reliability in WSNs. With QoS, the negative impact of different problems such as communication congestion and communication faults can be significantly reduced. Some of the surveyed projects integrated QoS as part of the proposed SOM for WSNs. Examples of these projects are OASIS [4], SensorMW [5], and ubiSOAP [13]. Although these projects deployed some QoS mechanisms such as the best available network selection based on the QoS requirements and a contract negotiation based on service level agreements, other advanced QoS mechanisms for WSNs [16] can also be integrated with SOM. In addition, fault management mechanisms for WSNs [43] can also be integrated with SOM. In addition, SOM performs the job of service orchestration. Separating the application logic from the system logic by a middleware perform helps in such activity. A middleware based on the concept of Model Driven Architecture (MDA) and SOA is introduced in [44]. SOA design patterns are design techniques that help overcome common obstacles in achieving the strategic goals and benefits associated with SOC [29]. However, the development of middleware solutions using SOA design patterns is still at its infancy. Researchers used technologies such as web services and P2P to design SOM. In terms of the requirements identified in Section 4, we found that none of the SOM approaches discussed covers all of them. In fact, very few of them address even half of those requirements. Yet, it may be possible to view this as a common practice since most SOM solutions are designed to solve a specific set of problems or to target one type or category of application domains. Therefore, it will be natural to find only those requirements that are most needed in that domain. One interesting observation we also came out with is that almost none of the approaches studied address the security issues as part of the SOM requirements. We identified this as an important challenge for SOM particularly for WSN due to the limitations in WSN resources. Several attacks and problems are possible on a WSN including, but not limited to, eavesdropping, rogue nodes, denial of service attacks, falsifying data, and redirecting traffic to disturb operations. This leaves us with a huge open question about the importance of including security features in the SOM. As it is well known, security is important for any type of distributed environments and SOC for WSN is no exception. Another one of the main challenges of implementing and operating WSN compared with other types of networks is managing the limited resources of computation, sensing, communication, and energy to satisfy application
123
82
SOCA (2001) 5:71–85
Table 1 Summary of the SOM approaches and their main features SOM
Platform/environment
Main feature
Other features
Requirements (explicitly) covered*
SStreaMWare
Sensor networks (wired and wireless)
Support for query-based data access
2, 3, 4, 6, 7 and 8
USEME
Wireless sensor and actor networks Sensor networks (wired and wireless)
Handles publication and discovery of web services Supports data collection and manipulations across heterogeneous sensors Development environment based on separation of concerns
Heterogeniety management, scalability and Complex queries handling Supports group management and real-time constraints Open source architecture, sustains contiguous access to sensor data Supports QoS, failure detection, node management and dynamic service discovery and deployment Provides a programming model to retrieve real-time data and integrates with enterprise systems Provides programming API, domain specific support, and flexible data management support Data filtering mechanism, notification mechanism and DBMS support Support for wide range of devices including sensor, RFID, and embedded devices Support for heterogeneous devices and networks and for loosely coupled services Multi-radio networking and selection of best network for QoS requirements Multiple programming languages can be supported
SensorWeb 2.0
OASiS
Wireless sensor networks
B-VIS
Distributed RFID and Sensor networks
Real-time tracking and monitoring through sensors
MiSense
Wireless Sensor Networks
Content-based publish/subscribe model
SOMDM
Wireless Sensor Networks
(SI)2
Smart items network
Multi-component architecture to reduce data processing loads Platform independent service, description, deployment and invocation
SOA-MM
Enterprise systems and shop floor equipment
ubiSOAP
General distributed env. (wired, wireless and mobile) Wireless Sensor Networks
TinySOA
SOM Arch. for WSN
Wireless Sensor Networks
MidCASE
SensorsMW
Smart environments consisting of WSN, RFID, and Cameras Wireless Sensor Networks
DySSCo
Wireless Sensor Networks
Integrating shop floor operations with enterprise applications Seamless networking of web services Providing web services for Internet apps to access WSN Based on DPWS Enabling implementation of context awareness for smart environment Providing QoS configuration by Service Level Agreements Providing dynamic self-organizing service coverage
Requirements: 1. Runtime support for services deployment and execution 2. Support for service consumers to discover and use registered services 3. Service transparency to client applications 4. Abstractions to hide the heterogeneity of underlying sensor environments 5. Configurable services 6. Support for self-organization mechanisms 7. Interoperability with a variety of devices and systems 8. Efficient handling of large volumes of data and high communication loads 9. Secure communication and execution 10. Support for quality of service requirements 11. Support for integration with other systems
123
1, 2, 4, 5, 6 and 10 4, 5, 7, 8, and 11
1, 2, 3, 4, 5, 8 and 10
4, 7, 8, and 11
3, 4, and 8
3, 4, 7, 8, and 11
1, 2, 4 and 7
4, 5,7, and 11
2, 3, 5, 7 and 10
2, 3, 4, and 11
Support sensor node mobility
2, 3, 4, 6, 8, and 11
Provide rule-based reasoning for context awareness
1, 3, and 4
Provide mechanism for applications to manage WSNs Provide some optimizations of services distribution during runtime
3, 4, 5, 7, 8, 10, and 11
1, 3, 4, 5, 6, and 8
SOCA (2001) 5:71–85
83
requirements on one hand and maximize the life of the network on the other. Resource management in WSN is not a trivial issue especially in heterogeneous and dynamic environments. This management will be more complicated by having multiple applications competing over the available services on the limited WSN resources. Although SOM platforms simplify the development process of WSN applications, these services also need careful design to satisfy application requirements with minimum resource consumption. Advanced optimization techniques are needed for resources discovery, allocation, and management. These techniques must also be energy-efficient. Some efforts were done to provide resource allocations optimization techniques in wireless sensor networks in general [20,35]. In addition, a middleware-based resource management for WSN was developed in [47]. In this work, the WSN is divided into several clusters of nodes. A cluster is a set of spatially adjacent nodes that can cooperate to monitor specific phenomena. Clustering a WSN helps the middleware to efficiently manage resources with minimum energy consumption. This middleware provides a virtual machine model with two layers: cluster layer and resource management layer. The cluster layer is responsible for forming a cluster of sensor nodes that are around the target phenomena. The resource management layer is responsible for the allocation and adaptation of resources such that specific application requirements such as QoS, reliability, and security can be met. This work was developed for non-SOM for WSN. However, similar architectures can be used with some modifications for SOM for WSN. The SOM can be designed to have three layers of services as shown in Fig. 1. These layers are cluster services layer, resource management services layer, and advanced services layer that provides direct services for the applications such as QoS, security, discovery, reliability etc. Each layer provides services for the upper layers. For example, applications can use the advanced services layer to satisfy their requirements. The advanced services layer will use the resource management layer to efficiently utilize available resources for executing different services by providing efficient resources allocation and adaption mech-
Applications SOM Advanced Services Resource Management Services Cluster Services
WSN
Fig. 1 Multilayer SOM for WSN
anisms. Furthermore, the resource management layer uses services provided by the cluster layer to efficiently deal with clusters’ resources.
8 Conclusion In this paper, we discussed the general requirements of SOM for WSN and reviewed some representative approaches in the field. SOM provides middleware services for various SOC domains and is useful for different environments such as WSN. Nowadays researchers and practitioners prefer to use the SOM approach over traditional middleware because of its trait of efficiently handling heterogeneous components using loosely coupled services. The approaches reviewed carry some similarities in the sense that all of them agree on a common goal: to effectively create, publish, discover, and use services. However, the approaches used were also significantly different in how they satisfy that goal. In addition, the target benefits of the approaches differ where targets like interoperability, QoS support, real-time support, heterogeneity support, scalability, and context-awareness are involved. We discussed a number of SOM for WSN projects and highlighted their main objectives and approaches in addition to how well they satisfy the general SOM requirements. SOM is destined to handle the publication and discovery of web services, communication, and efficient and reliable event management among different services. In addition, SOM solutions need to support efficient handling of the heterogeneous resources and the functionalities of the WSN applications. Moreover, due to the need to exchange large volumes of data, it is necessary to have a reliable and efficient system in place to ensure an uninterrupted flow of correct and timely messages. It is also necessary to maintain acceptable levels of control, security, and reliability through the SOM that will in effect reflect on the applications using it. Finally, to further enhance the SOM, we must have dynamic, adaptive and auto-configurable architectures for effective integration and reuse. References 1. Abangar H, Barnaghi P, Moessner K, Nnaemego A, Balaskandan K, Tafazolli R (2010) A service oriented middleware architecture for wireless sensor networks. In: Proceedings of future network and mobile summit conference 2. Al-Jaroodi J, Mohamed N, Jiang H, Swanson D (2003) Middleware infrastructure for parallel and distributed programming models on heterogeneous systems. IEEE Trans Parallel Distributed Syst 14(11):1100–1111 3. Al-Jaroodi J, Al-Dhaheri A (2011) Security issues of serviceoriented middleware. Int J Comput Sci Netw Secur (IJCSNS) 11(1):153–160 4. Amundson I, Kushwaha M, Koutsoukos X, Neema S, Sztipanovits J (2006) OASiS: a service-oriented middleware for pervasive
123
84
5.
6.
7.
8.
9. 10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SOCA (2001) 5:71–85 ambient-aware sensor networks. In: Pervasive and mobile computing journal on middleware for pervasive computing, October 2006 Anastasi GF, Bini E, Romano A, Lipari G (2010) A serviceoriented architecture for QoS configuration and management of wireless sensor networks. In: The 15th IEEE international on emerging technologies and factory automation. Bilbao, Spain, September 2010 Anke J, Müller J, Spieß P, Weiss Ferreira Chaves L (2006) A service-oriented middleware for integration and management of heterogeneous smart items environments. In: Proceedings of 4th MiNEMA workshop, pp 7–11, July 2006 Avilés-López, E, García-Macías, JA (2009) TinySOA: a service-oriented architecture for wireless sensor networks. Service Oriented Computing and Applications. 3(2):99–108 (Springer) Bai Y, Ji H, Han Q, Huang J, Qian D (2007) MidCASE: a service oriented middleware enabling context awareness for smart environment. In: Proceedings of international conference on multimedia and ubiquitous engineering (MUE’07) Bichler M, Lin KJ (2006) Service-oriented computing. IEEE Comput 39(3):88–90 Blaya J, Demeure I, Gianrossi P, Lopez P, Navarro J, Meyer E, Pelliccione P, Tastet-Cherel F (2009) POPEYE: providing collaborative services for ad hoc and spontaneous communities. Serv Oriented Comput Appl 3(1):25–45 (Springer) Britton C (2001) IT architecture and middleware: strategies for building large, integrated systems for building large, integrated systems. Addison-Wesley, Reading Canete E, Chen J, Diaz M, Llopis L, Rubio B (2009) A serviceoriented middleware for wireless sensor and actor networks. In: Proceedings of 6th international conference on information technology: new generations. Las Vegas, USA Caporuscio M, Raverdy P-G, Moungla H, Issarny V (2008) ubiSOAP: a service oriented middleware for seamless networking. In: Proceedings of 6th ICSOC Caporuscio M, Charlet D, Issarny V, Navarra A (2007) Energetic performance of service-oriented multi-radio networks: issues and perspectives. In: Proceedings of WOSP Chan S, Kaler C, Kuehnel T, Regnier A, Roe B, Sather D, Schlimmer J, Sekine H, Walter D, Weast J (2006) Devices profile for web services, available at http://schemas.xmlsoap.org/ws/2006/ 02/devprof/, February 2006 Chen D, Varsheny PK (2004) QoS support in wireless sensor networks: a survey. In: Proceedings of international conference on wireless networks (ICWN ‘04), pp 227–233, Las Vegas, Nev, USA, June 2004 Chu X, Kobialka T, Durnota B, Buyya R (2006) Open sensor web architecture: core services. In: Proceedings of 4th international conference on intelligent sensing and information processing. Bangalore, India, December 2006 Costa N, Pereira A, Serodio C (2007) Virtual machines applied to WSN’s: the state-of-the-art and classification. The second international conference on systems and networks communications (ICSNC 2007), August 2007 Delicato F, Pires P, Pinnez L, Fernando L, da Costa L (2003) A flexible web service based architecture for wireless sensor networks. In: Proceedings of 23rd international conference on distributed computing systems workshops, 2003 Giannecchini S, Caccamo M, Shih C-S (2004) Collaborative resource Allocation in wireless sensor networks. In: Proceeding of Euromicro conference on real-time systems (ECRTS’04), pp 35–44, June/July 2004 Gibbons P, Karp B, Ke Y, Nath S, Seshan S, Res I, Pittsburgh P (2003) Irisent: an architecture for a worldwide sensor web. IEEE Pervasive Comput 2:22–33 Gnawali O, Jang K, Paek J, Vieria M, Govindan R, Greenstein B, Joki A, Estrin D, Kohler E (2006) The tent architecture for tiered
123
23.
24.
25.
26.
27. 28.
29. 30.
31.
32. 33.
34.
35.
36.
37.
38.
39.
40.
41.
sensor networks. In: Proceedings of the 4th international conference on embedded networked sensor systems, pp 153–166, 2006 Golatowski F, Blumenthal J, Handy M, Haase M, Burchardt H, Timmermann D (2003) Service-oriented software architecture for sensor networks. In: Proceedings of international workshop on mobile computing, IMC 2003, pp 93–98, June 2003 Groba C, Braun I, Springer T, Wollschlaeger M (2008) A serviceoriented approach for increasing flexibility in manufacturing. In: Proceedings of IEEE international workshop on factory communication systems, 2008 Gu QJ, Lago P (2009) Exploring service-oriented system engineering challenges: a systematic literature review. Serv Oriented Comput Appl 3(3):171–188 (Springer) Hadim S, Mohamed N (2006) Middleware for wireless sensor networks: a survey. In: Proceedings of the first international conference on communication system software and middleware (COMSWARE 2006), IEEE, New Delhi, India, January 2006 Hadim S, Mohamed N (2006) Middleware challenges and approaches for wireless sensor Networks. IEEE Distrib Syst 7(3) Hadim S, Al-Jaroodi J, Mohamed N (2006) Trends in middleware for mobile ad hoc networks. Invited paper in the J Commun 1(4):11–21 Introducing SOA Design Patterns (2008) SOA world magazine, 8(6), June 2008 Khedo KK, Subramanian RK (2009) A service-oriented component-based middleware architecture for wireless sensor networks. Int J Comput Sci Netw Secur (IJCSNS) 9(3):174–182 Kobialka T, Buyya R, Leckie C, Kotagiri R (2007) A sensorweb middleware with stateful services for heterogeneous sensor networks. In: Proceedings 3rd international conference on intelligent sensors, sensor networks and information processing (ISSNIP 2007). Melbourne, Australia, December 2007 Lai KY, Phan TKA, Tari Z (2005) Efficient SOAP binding for mobile web services. In: Proceedings of LCN Levent G, Claudia R, Cyril L, Andre B, Vincent O (2008) SStreaMWare: a service oriented middleware for heterogeneous sensor data management. In: Proceedings of ICPS, Sorrento, Italy, July 2008 Lipphardt M, Neumann J, Groppe S, Werner C (2008) DySSCo–a protocol for dynamic self-organizing service coverage. In: Proceedings of the 3rd international workshop on self-organizing systems, pp 109–120, 2008 Liu X, Wang Q, Sha L, He W (2003) Optimal QoS sampling frequency assignment for real-time wireless sensor networks. In: Proceedings of the IEEE real-time systems symposium. Cancun, Mexico, December 2003 Maia MEF, Rocha LS, Andrade RMC (2009) Requirements and challenges for building service-oriented pervasive middleware. In: Proceedings of 2009 international conference on Pervasive services, London, United Kingdom, pp 93–102, July 2009 Mohamed N, Al-Jaroodi J, Jawhar I (2008) Middleware for robotics: a survey. In: Proceedings of IEEE international conference on robotics, automation and mechatronics (RAM 2008). Chengduo, China, September 2008 Mottola L, Picco GP (2010) Programming wireless sensor networks: Fundamental concepts and state of the art. ACM Comput Surv, 2010. To appear. Available at: www.sics.se/~luca/papers/ mottola10programming.pdf Pandey K, Patel SV (2009) A novel design of service oriented and message driven middleware for ambient aware wireless sensor network. Int J Recent Trends Eng Acad Publ 1(1):313–317 Papazoglou MP (2003) Service-oriented computing: concepts, characteristics and directions. In: Proceedings 4th international conference on web information systems engineering Papazoglou M, Traverso P, Dustdar S, Leymann F, Kramer B (2006) Service oriented computing research roadmap. In: Proceedings of Dagstuhl seminar 05462 (SOC)
SOCA (2001) 5:71–85 42. Podolski I, Rettberg A (2009) A service-oriented self-configuration middleware for autonomous sensor networks. Software Technologies for Future Dependable Distributed Systems 43. Ruiz LB, Siqueira IG, Oliveira LB, Wong HC, Nogueira JM, Loureiro AAF (2004) Fault management in event-driven wireless sensor networks. In: Proceedings of ACM international conference on modeling, analysis and simulation of wireless and mobile systems (MSWiM’04), pp 149–156, October 2004 44. Sommer S, Buckl C, Knoll A (2009) Developing service oriented sensor/actuator networks using a tailored middleware. In:
85 Proceedings of 6th international conference on information technology: new generations. Las Vegas, USA 45. Sriborrirux W, Kraipui S, Indra-Payoong N (2009) B-VIS serviceoriented middleware for RFID sensor network. World Acad Sci Eng Technol 56:770–774 46. Sugihara R, Gupta RK (2008) Programming models for sensor networks: a survey. ACM Trans Sensor Netw 4(2):8:1–8:29 47. Yu Y, Krishnamachari B, Prasanna VK (2004) Issues in designing middleware for wireless sensor networks. IEEE Netw Mag Special Issue 18(1):15–21
123
