eSOA:A Contextual Analysis on Service Oriented

Architecture for Embedded Networks

Juan Antonio Martin Checa

Computer Science DepartmentCampus Teatinos

University of Malaga29071 Malaga, Spain

jamcheca@telefonica.nethttp://www.telefonica.net/web2/jamcheca

Abstract. Traditionally, embedded sensor networks have been exclusiveof the industrial arena. However, nowadays we are living a technologicalrevolution that may result in a future in the interconnection of all things,as envisioned by the so called Internet of Things. There are several re-search projects on the field, all of them contributing to this big puzzle.One of these projects, and focus of this article, proposes a SOA-basedmiddleware for embedded networks called eSOA. The objective of thisarticle is to analyze the eSOA middleware in the context of embeddednetworks as well as in relation to similar projects.

Keywords: Code Generation, Embedded Networks, eSOA, Internet of Services(IoS), Internet of Things (IoT), Middleware, Pattern Filling, Service Bridge, Ser-vice Broker, Service Composition, Service Oriented Architecture (SOA), ServiceOriented Computing, Service Placement, Smart Home, SOAP, UDDI, WDSL,Web Service (WS).

1 Introduction

When thinking of embedded sensor networks, one may think of independentand isolated industrial systems responsible for the automatization of a numberof tasks. Unlike embedded networks from the past, most of current embeddedsensor networks are expected to interact with the world of web services and theInternet. Indeed, the demand for this type of integration is increasing as newbusiness oportunities arise. In any case, the integration of both worlds is notinmediate and cannot be taken for granted.

In an attempt to reduce or eliminate this gap, researchers from all over theworld are searching for the best solutions that ensure the interoperability ofembedded sensor networks and traditional web services. One of these approachesdeveloped by the Computer Science Department at the Technical Universityof Munich, consists of a SOA-based middleware for embedded networks called

eSOA. In this article we will study and analyze the eSOA middleware. However,before we go that far, we need to introduce some basic concepts and ideas first.

This article is structured as follows. In this section we will introduce somebasic concepts and ideas necessary before we move on to the study of eSOA,such as the Internet of Things (IoT), the Internet of Services (IoS), eServices,Web Services, the lifecycle of services, atomic and composite services, as well asa brief overview of WDSL and SOAP.

In section-2 we will introduce the concept of Service-Oriented Architecture(SOA), which is the foundation of the eSOA platform. We will review somefundamental design terms. Also, we will comment on the Service-Oriented Com-puting. Finally, we will study the architecture, elements, and principles of SOA.

In section-3 we will focus on the eSOA middleware, which analysis is the goalof this article. We will first introduce the requirements of embedded networks.Next, we will comment on the eSOA design principles and the implementationdetails. Finally, an illustrative example will be studied.

In section-4 we will briefly discuss on the most relevant related projects,including AUTOSAR, KNX, TinyDB, Cougar, RUNES, MORE, SIRENA, andSOCRADES.

In section-5 we will outline the current research lines within the eSOA project,including those aspects that either need some improvement or still need to beaccomplished.

Finally, section-6 will draw the main conclusions derived from the studyand analysis of the eSOA middleware within the context of embedded sensornetworks.

1.1 The Internet of Things (IoT)

The concept Internet of things (a.k.a. Internet of objects) attributed to theformer Auto-ID Center, based at the MIT in 1999, year of its foundation, refersto a “self-configuring wireless network of sensors which purpose would be tointerconnect all things” [13]. In order to achieve this, every single human-madeobject in the world should be equipped with a unique identifying device (radiotag) based for example on IPv6, which supports up to 2128 addresses. Becauseof the enormous number of simultaneous events, time will no longer be used asa common and linear dimension. Instead, it will depend on each entity, makingit necessary the management of massive parallel IT systems.

Certain level of ambient intelligence would also be necessary so that objectswould be capable of, not only pursuing their own goals, but also shared objec-tives by means of interacting with other objects, while considering the currentenvironment and circumstances (e.g. food products that record the temperaturealong the supply chain, connected cars that would reduce traffic congestion, airconditioning valves that react to the presence of people, connected trees thatwould help reduce deforestation, etc. [3]).

Regarding the complexity of IoT, three main points are highlighted by theCommission of the European Communities. First, IoT should be seen as a set of

new independent autonomous systems with their own infrastructures that par-tially rely on those existing in the Internet. Second, IoT should be implementedin line with the new and upcoming services. Last, IoT should support differ-ent levels of communications: things-to-person and things-to-thing [3] either inrestricted networks (intranet of things) or in public ones (internet of things).

The result would introduce many advantages such as real-time productsstock, location, and movement control, automatic identification and inventory,etc. The Semantic Web, on its side, offers an alternative based on the idea ofmaking all things addressable by the existing naming protocols, for example bymeans of using a Uniform Resource Identifier (URI ).

1.2 The Internet of Services (IoS)

As described in [12], the Internet of services is the “next-generation of the ser-vices revolution.” [45] defines IoS as “a new business model that can radicallychange the way we discover and invoke services“. A more extended definition canbe found in [60], according to which, the Internet of services could be consideredas a “worldwide, trusted service ecosystem of service providers, consumers, andbrokers, buying, selling, repurposing, and composing services for different needsresulting in a new way of organizing the interaction between partner ecosys-tems and customer base.” In general, it is not an overhaul of the Internet, butan extension which ultimate objective is removing the classical barriers and in-efficiencies from service supply and access, so important in nowadays’ servicesector, which is the biggest and fastest-growing business sector in the world.[11]. In other words, IoS describes both the business framework and the tech-nical infrastructure (which uses the Internet) as a mean for offering and sellingservices.

The key idea is first determining which services can be managed through IT,and then figuring out new ways of combining them so that we obtain new value-added services. As explained in [45], a service-based value network is expectedto include the research, development, design, production, marketing, sales, anddistribution of any specific service. All of these phases contribute to the finalvalue of the service.

The main challenge regarding IoS is the heterogeneous of current online ser-vices, relying on different legacy applications hosted by different providers, withdifferent use policies, etc. All those handicaps have to be solved in a transparentway for the final user of the “cloud” service. It is the underlying IT perspective,the responsible for providing the necessary standards, architectures, applications,and tools to support the business view.

1.3 Types of Services

There are three main types of services:

Business Service: A service, in its traditional sense, can be understood as the“non-material” equivalent of a good. In the business arena, a business service

refers to any “business activity provided by a service provider to a serviceconsumer to create a value for the consumer” [45].

e-Service: Rowley (2006) [56] defines e-services as: “. . . deeds, efforts or perfor-mances whose delivery is mediated by information technology. Such e-serviceincludes the service element of e-tailing, customer support, and service deliv-ery”, definition that reflects three main components: service provider, servicereceiver, and the channels of service delivery [8].

Web Service: The W3C defines a web service as ”a software system designedto support interoperable machine-to-machine interaction over a network. Ithas an interface described in a machine-processable format (specifically WebServices Description Language WSDL). Other systems interact with the webservice in a manner prescribed by its description using SOAP messages,typically conveyed using HTTP with an XML serialization in conjunctionwith other Web-related standards.” [36]. More on web services in [37].

Fig. 1. Web Service Architecture

Web services are classified by the W3C [34] into two main groups:

REST-compliant Web Services: in which the primary purpose of the serviceis to manipulate XML representations of Web resources using a uniform setof ”stateless” operations.

Arbitrary Web Services: in which the service may expose an arbitrary set ofoperations.

1.4 Lifecycle of Services: Discovery, Invocation, and Execution

Two main phases can be identified along the lifecycle of services [45]:

Discovery/Invocation: are related to both the medium and the technologynecessary for perceiving and requesting a particular service.

Execution: refers to the process itself of carrying out the service.

Fig. 2. Relationship between Business Service, e-Service and Web Service

1.5 Atomic Vs Composite Services

According to their complexity, services can be classified into two categories:

Atomic Service: Service that provides a basic functionality to the end user.It normally involves a one-on-one relationship between the service providerand the customer.

Composite Service: Service consisting of two or more atomic or compositeservices, offering a superior functionality to the end user. It is normallyprovided by an aggregator, entity responsible for contracting basic servicesfrom different providers, and combining them into the composite service.The customer pays for the composite service to the aggregator, and theaggregator pays for the basic services.

1.6 WSDL (Web Services Description Language)

The Web Services Description Language (WSDL) is an XML-based lan-guage that provides a model for describing web services as a collection of related

endpoints or ports (defined by associating a network address with a reusable bind-ing) that operate on messages containing either document-oriented or procedure-oriented information [41]. Port types are abstract collections of supported op-erations. Both the operations and the messages (abstract descriptions of theexchanged data) are first described as abstract entities, and then bound to aconcrete network protocol and message format, making WDSL extensible whileallowing the reuse of these definitions [35].

Fig. 3. Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents

When a client program connects to a web service offered by a server, it can readthe WSDL file in order to determine what operations are supported by thatparticular server. Special datatypes, if any, are embedded in the WSDL file inthe form of XML Schemas. Finally, the client can use SOAP to call the desiredoperation (one of those listed in the WSDL file).

1.7 SOAP (Simple Object Access Protocol)

The Simple Object Access Protocol (SOAP) is “a protocol specificationfor exchanging structured information in the implementation of web services incomputer networks” [29]. An alternative definition is offered by the W3C whendescribing it’s latest version: “SOAP Version 1.2 (SOAP) is a lightweight protocolintended for exchanging structured information in a decentralized, distributedenvironment.” [33]. SOAP forms the foundation layer of a web services protocolstack, by means of providing a basic messaging framework (which relies on XML

for the message format as well as on other application layer protocols for messagenegotiation and transmission, such as RPC and HTTP) upon which web servicescan be built.

SOAP can be divided into three main components: an envelope (includinga description of the content and instructions on how to process it), a set ofencoding rules (for expressing datatypes), and a convention (for specifying theformat of both procedure calls and responses).

Fig. 4. The SOAP Structure

Regarding the messaging framework, it consists of the following elements:

The SOAP processing model: establishes the rules for SOAP messages tobe processed.

The SOAP extensibility model: specifies SOAP modules and features.

The SOAP underlying protocol binding framework: defines bindings.

The SOAP message construct: determines the structure of a SOAP mes-sage.

2 Service-Oriented Architecture (SOA)

2.1 Overview

The Organization for the Advancement of Structured Information Standard (OA-SIS ) defines SOA as “a paradigm for organizing and utilizing distributed capa-bilities that may be under the control of different ownership domains.[...] Itprovides a uniform means to offer, discover, interact with and use capabilities toproduce desired effects consistent with measurable preconditions and expecta-tions.” [1]. In October 2009, the SOA Manifesto Working Group, a group of SOApractitioners and vendors, published the “SOA Manifesto”, which gives prior-ity to business value, strategic goals, flexibility, interoperability, shared servicesand evolutionary refinement [24]. At present, it is supported by more than 700signataries worldwide.

2.2 Fundamental Design Terms

Before we focus on SOA in more detail, we need first to cover some basic designterms that establish a basic taxonomy used throughout this article. Figure 5illustrates the main modules of a basic design framework, as well as the relation-ships between them.

Fig. 5. Fundamental design terms

Design Characteristic: The term design characteristic refers to a specific at-tribute of a body of solution logic documented in a design specification whichis expected to be implemented. In the field of service-orientation the usualobjective is the creation of design characteristics that are common, veryspecific, consistent, predictable, and reliable.

Design Principle: A design principle is a generalized, accepted industry prac-tice, normally based on past experience. Design principles are highly rec-ommended guidelines for decomposing and shaping solution logic into dis-tributable units when pursuing a specific goal.

Design Paradigm: A design paradigm is a governing approach to designingsolution logic, usually consisting of a set of complementary principles thatdefine the overarching approach represented by the paradigm itself.

Design Pattern: A design pattern is a description of a common problem andits corresponding solution expressed as a generic template so that it can be

reused for similar problems. A set of design patterns that solve a more com-plex problem is called a “compound pattern”. Finally, a series of interrelatedpatterns is called a “pattern language”.

Design Standard: Design standards are design conventions, usually manda-tory, that allow organizations to consistently deliver solutions customized totheir environments, resources, goals, and priorities.

Best Practice: The term best practice can be defined as an (industry) tech-nique or approach to either solving or preventing certain problems, based onpast experience.

2.3 Service-Oriented Computing

Service-oriented computing is a new generation distributed computing platformcharacterized by its distinct architectural model, design paradigm, and designprinciples, that includes design pattern catalogs, pattern languages, as well asrelated concepts, technologies, and frameworks. Let’s review briefly its main el-ements.

2.3.1 Elements of Service-Oriented Computing

Service-Oriented Architecture: A SOA is an architectural model with thegoal of improving productivity, efficiency, and agility within a particularcompany by means of positioning services as the primary means throughwhich solution logic is represented, supporting the creation, execution, andevolution of service-oriented solutions in the pursue of strategic goals [40].A SOA implementation may consist of a number of technologies, products,APIs, as well as other parts.

Services and Service-Orientation: Service-orientation is a design paradigmconsisting of a set of design principles, that, when applied to the design ofsolution logic, results in service-oriented solution logic, which basic unit is theservice, which is an independent software program with a functional contextand a set of invocable capabilities, expressed in the form of a publishedservice contract (API).

Service Compositions: A service composition is a coordinated set of relatedservices.

Service Inventory: A service inventory is an independent collection of stan-dardized complementary services.

2.3.2 Goals and Benefits of Service-Oriented Computing

The main goals and benefits derived from the use of Service-Oriented Computingare:

– Increased Intrinsic Interoperability– Increased Organizational Agility– Increased Business and Technology Alignment

Fig. 6. The individual description documents that can comprise a service contract fora Web service.

– Increased Federation– Increased Vendor Diversification Options– Increased ROI– Reduced IT Burden

2.3.3 Service-Oriented Computing in the Real World

Web Services: Nowadays, the technology platform most associated with SOAis Web services, which is defined through a number of industry standardsand provides a communications framework based on physically independentservice contracts, which can be standardized independently from their par-ticular proprietary implementation details. There are two main generationsof web services.

1st-Generation Web Services Platform: Built upon the following core opentechnologies and specifications:– Web Services Description Language (WSDL)– XML Schema Definition Language (XSD)– SOAP (formerly the Simple Object Access Protocol)– UDDI (Universal Description, Discovery, and Integration)– WS-I Basic Profile

2nd-Generation Web Services Platform (WS-* extensions): Build uponthe first-generation messaging framework, and with the goal of solving someof its main QoS-related issues, the second generation provides a rich feature-set far more complex both in technology and in design. Some of the mostimportant specifications are:– WS-Security (and WS-SX)– WS-Coordination– WS-AtomicTransaction– WS-BusinessActivity (and WS-TX)– WS-ReliableMessaging (and WS-RX)– WS-Policy– WS-Addressing

2.4 Service-Oriented Architecture (SOA)

2.4.1 Introduction

In [20], a Service-oriented architecture (SOA) is defined as “a flexible set ofdesign principles used during the phases of systems development and integrationin computing. A system based on a SOA architecture will package functionalityas a suite of interoperable services that can be used within multiple separatesystems from several business domains.” In [54], Sun Microsystems defines SOAas “an information technology approach or strategy in which applications makeuse of (perhaps more accurately, rely on) services available in a network suchas the World Wide Web.” OASIS on its side defines SOA as “a paradigm fororganizing and utilizing distributed capabilities that may be under the controlof different ownership domains” [1].

SOA provides a way for consumers of services (web-based applications, etc.)to be aware of available services, defining how to integrate disparate applicationsusing multiple implementation platforms. A service is a software resource withan externalized description available for searching, binding, and invocation by aservice consumer.

SOA does not define an API. Instead, it is based on the concept of endpoint(the entry point for a particular SOA implementation) being the interface definedin terms of protocols and functionality. The way the client of a service (whichcan be another service) communicates with the service does not depend on theimplementation of the service. This is usually referred to as loose coupling. Aservice can provide both a single discrete function or a set of related functions.Also, services can be combined into aggregated or composite services that satisfymore complex requirements. To sum up, a SOA is “an approach to connectingapplications (exposed as services) so that they can communicate with (and takeadvantage of) each other” [54].

SOA allows users to build ad hoc applications from existing software services(modules) which interact via interfaces. The key at this point is granularity: themore complex the services, the less interfaces needed but the less reusable, andviceverse.

2.4.2 Architecture

Architectures can operate independently of specific technologies. Designers canimplement SOA using a wide range of technologies, including SOAP, RPC,REST, CORBA, Web Services, DCOM, and WCF.

Elements of SOA

Figure 7 shows the tree-based relationship schema between SOA, services, im-plementations, interfaces, and data.SOA Meta Model

Fig. 7. Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama.

Figure 8 presents the SOA meta-model which is an abstraction of a SOA struc-tured into a number of layers. A more detailed model, shown in Figure 9 isavailable in [21].

Layer-1. Operational systems layer: Existing legacy systems (custom builtapplications), object-oriented systems and intelligence applications.

Layer-2. Enterprise components layer: Enterprise components responsiblefor realizing functionality and maintaining the QoS.

Layer-3. Services layer: Exposed (discoverable, invocable) services.Layer-4. Business process composition or choreography layer: Compo-

sitions of exposed services.Layer-5. Access or presentation layer: Application interface or presenta-

tion level.Layer-6. Integration (ESB): Integration of services through the introduction

of a reliable set of capabilities.Layer-7. QoS: Monitoring, managing, and maintenance of QoS (security, per-

formance, availability, etc.

2.4.3 Principles

SOA is based upon a number of specific principles, necessary for its develop-ment, maintenance, and usage. [27] enumerates the following eight principles asmandatory for any SOA implementation:

Standardized Service Contract: Services adhere to a communications agree-ment, as defined collectively by one or more service-description documents.

Service Loose Coupling: Services maintain a relationship that minimizes de-pendencies and only requires that they maintain an awareness of each other.

Fig. 8. SOA meta-model, The Linthicum Group, 2007.

Fig. 9. Layes of a SOA.

Service Abstraction: Beyond descriptions in the service contract, serviceshide logic from the outside world.

Service Reusability: Logic is divided into services with the intention of pro-moting reuse.

Service Autonomy: Services have control over the logic they encapsulate.Service Statelessness: Services minimize resource consumption by deferring

the management of state information when necessary.Service Discoverability: Services are supplemented with communicative meta

data by which they can be effectively discovered and interpreted.Service Composability: Services are effective composition participants, re-

gardless of the size and complexity of the composition.

According to [20], three additional principles can also be commonly found inliterature:

Service Optimization: High-quality services are generally preferable to low-quality ones.

Service Relevance: Functionality must be presented at a granularity level rec-ognized by the user as a meaningful service.

Service Encapsulation: Many services are consolidated for use under the SOA,even when this was not planned beforehand.

More on SOA in [48], SOA specifications in [28], SOA patterns in [26], WS andSOA in [38] and [46].

3 e-SOA: SOA for Embedded Systems

3.1 Overview

Traditionally, many devices were designed to work as isolated embedded sys-tems [43]. As already commented in the introduction of this article, nowadaysthe trend is to connect and integrate daily-life devices into distributed embed-ded networks [43], as it is envisioned by the Internet of things (a.k.a. Internetof objects), which purpose is to interconnect all things [13]. The service-orientedparadigm, based upon the Service-Oriented Architecture (SOA), explained in theprevious section, is the most extended and widely adopted strategy for imple-menting complex, heterogeneous, and large IT systems worldwide, mostly basedon web services. However, due to the particular characteristics of embedded sys-tems, traditional SOA cannot be apply directly to them [43].

Connecting web services and embedded devices is essential, since the de-mand for systems capable for dealing with both worlds is rapidly increasing([43], [59]), specially in the fields of automotive, factory automation, and build-ing management, in part, as a consequence of the ongoing decline in prices fornetwork-enabled hardware devices. In this section we will introduce the maincharacteristics that make embedded systems different from WS-based systems.Also, we will analyze different existing approaches to save the gap between bothwords: the world of web services and the world of embedded services.

3.2 Embedded Networks Requirements

According to [10], an embedded system is “a computer system designed to per-form one or a few dedicated functions often with real-time computing constraints[. . . ] embedded as part of a complete device often including hardware and me-chanical parts.” An embedded network is a network composed of embeddedsystems, which can be very diverse both in hard- and software components.Throughout this article, when we talk about embedded networks we will refer toembedded sensor-actor networks, this is, those used in control and automationtasks. Following, there is a list of requirements for embedded networks, availablein [57].

Heterogeneity: Network nodes usually have a diversity of processing, storage,sensing, and acting capabilities, and are built upon hardware componentsfrom different manufacturers. Also, there are multiple types of end-user de-vices (PCs, PDAs, cellphones, etc.).

Distributed Architecture: A decentralized network structure avoids bottle-necks as well as the network collapse in the event of a failure in an hypothet-ical central node, while optimizing data transferences, by means of placingthe data consuming control logic nearby the data producing sensors.

Reconfigurable Architecture: The network must be reconfigurable at run-time so that new nodes with previously unknown functionality can be con-nected at any time. Also, existing nodes must be reconfigurable by installingnew applications on them. All of this requires a life cycle management mod-ule responsible for maintaining a repository of available devices as well asfor tracking any change in any node of the network (installations, startups,shutdowns, and removals of applications).

Resource Limitations: The underlying hardware of embedded networks is fre-quently quite resource-limited, making it necessary to optimize both theexecution of applications and the involved network protocols.

Scalable Functionality: Small devices should be lightweighted so that theyonly perform the very essential task they were conceived to. More complexdevices on their side, should be capable of adapting during run-time.

Error Detection and Recovery: Wireless links and battery-powered devicesare the focus of a number of issues on embedded networks, such as com-munication problems, which can be corrected by the network protocol, oreven node failures, which can be solved by means of introducing redundanthardware.

End-User Programming: In order to achieve the so-desired mass market forembedded networks, it is first necessary to ease the entire process of instal-lation and configuration of the devices, allowing the average non-expert finaluser to buy, install, configure, re-configure, program, extend, monitor, orremove nodes and applications at any time as pleased.

Bridging: Embedded networks and WS-based networks are required to be eas-ily interconnectable and interoperable. In order to achieve this, WS-basedinterfaces along with the introduction of semantic information (for the back-end systems to understand the data sent by the sensors) are needed.

3.3 eSOA

Embedded networks can take advantage of traditional SOA’s benefits, discussedin section 2.4.3 in order to meet some of the requirements commented in section3.2. However, and as we already mentioned, traditional SOA (based on webservices) cannot be applied directly to the world of embedded networks, butsome adaptations are previously needed [57].

Data-Driven Services: Unlike traditional SOAs which are based on a request-response message pattern, most of embedded applications are data-drivenin a way that sensors acquire data on a periodic fashion and send it toconnected services, which process it and produce new data that is sent tothe next service in the so-called process chain.

Service Life Cycle: Commonly, in traditional SOAs web services instances arenot shared, so changes occurred in one instance are invisible to other ap-plications. As a contrast, in the world of embedded networks, services arefrequently used simultaneously by multiple applications, thus, requiring theservices states to be shared.

Resource Constraints: Traditional SOAs normally rely on robust hardwareinfrastructures, supplying enough CPU cycles, memory, bandwidth, batterypower, etc. so that web services run with few limitations. In contrast, embed-ded networks are typically characterized by relying on small devices, whichare quite limited both in processing and storage capabilities. Because of this,the efficiency of message formats is critical.

So, what’s an eSOA then? An eSOA is an embedded SOA, meaning a tradi-tional SOA adapted for embedded networks. While on a SOA we have ser-vices (web services), on an eSOA we have eServices, which can be classifiedinto sensor-eServices (producing data), logic-eServices (processing data), andactuator-eServices (consuming data). The communication model used by e-Services is based on the concept of data stream, which is a sequence of datapackets connecting two eServices via their corresponding output and input ports.A logic-eService waits in “sleep mode” for certain events that trigger its execu-tion, such as incoming data, measurement values exceeding certain thresholds,etc. Both sensor-eServices and actuator-eServices are abstractions of the under-lying hardware, while logic-eServices on their side, executed on programmablecontrol devices, are independent of the concrete hardware implementation.

Once we have seen an overview of eSOA, let us now focus on a particularimplementation, to be concrete, that covered in [57], which analysis and study isthe main objective of this article. [58], [43], [57], and [59], are all articles writtenby the same authors on the eSOA topic offering a chronological evolution oftheir research activity on the field. In the next two sections we will analyzethe authors’ proposal: an eSOA middleware. Section 3.4 explains the designprinciples of such a middleware, while section 3.5 focuses on its implementation.Additionally, we will comment on other proposals and projects by other researchgroups in the field of SOAs for embedded systems, so that the reader can get awider perspective on the current status of the field.

3.4 eSOA Middleware Design Principles

As explained by the authors themselves, the middleware proposed in [57] is basedon the 3-layers embedded networks hierarchy depicted in Figure 10. Each layercorresponds to a different view. Next, let us comment on all of them in moredetailed.

Abstract Infrastructure Layer: This layer provides a unified model of theunderlying hardware components (nodes) and a serie of 1-hop network con-nections between nodes (links). Nodes can be classified into two types: pro-grammable nodes - those capable of executing arbitrary code - (gray boxes)and non-programmable nodes - those with limited configuration capabilities- (white boxes). Furthermore, some nodes may consist of one or more sen-sors/actuators while others – e.g. gateways or programmable control units- may have none. On their side, links, provided by the underlying networkprotocols, include a number of properties modeling the transport mediumand the communications characteristics.

Service Layer: This layer provides a service-oriented view of the underlyingsensors/actuators. Each sensor/actuator is mapped to a different service.In addition, this layer also provides a repository of available logic services,each of them described by a set of metadata. The are three types of meta-data: hardware/logic services metadata (specified by the manufacturer andthe programmer respectively, e.g. inputs, outputs, measurement rates, sup-ported data types, kind of data measured, e.g. “Relative Humidity”, etc.),installation metadata (introduced by the installer, e.g. position/orientationof sensors/actuators, inventory numbers, etc.), and dynamic metadata (rep-resenting the actual state of the node, e.g. battery level, energy consumption,etc., monitored during run-time). However, it is important to highlight that,due to the fact that metadata fields depend heavily on specific applications,the proposed middleware makes no assumptions regarding the existence ofsuch metadata. Instead, the middleware provides filtering algorithms so thatthe final user can extract, monitor, and configure a subset of nodes that fita specific criteria.

Application Layer: This layer provides an overview of the installed applica-tions, the involved services instances, as well as of the information exchangedbetween instances. It is responsible for controlling and monitoring the appli-cations running within the system at any time. Moreover, it also provides anapplication patterns repository that facilitates the installation and configura-tion of applications. An application pattern is a description of an applicationas a composition of abstract services (slots) described in terms of metadataand the data connections between them. At run-time, the abstract servicesof an application pattern are matched against the available hardware servicesand logic services stored in the service repository, so that it can be deter-mined whether or not that specific application can be installed. There arethree different cases when installing a new application. First, the mapping ofservices to slots is unambiguous, allowing the automatic installation of the

application. Second, the mapping of services to slots is ambiguous, so thatthe user has to manually select the appropriate service candidate (amongthe different options) for a specific slot. Third, not all slots in the patterncan be filled, case in which the user is provided with a “shopping list” thatincludes the necessary hardware devices for that specific application.

Fig. 10. Embedded Networks Layers Architecture.

The process of installing a new application consists of three steps: pattern filling,service placement and code generation.

1. Pattern Filling: Consists of the selection of a pattern and the assignmentof available and suitable services to all of the involved slots.

2. Service Placement: The middleware optimizes the mapping of services tophysical nodes, according to certain parameters of interest, such as an ho-mogeneous resource utilization on all nodes, or the minimization of networkload.

3. Code Generation: Includes the generation of platform-specific code for thetargeted nodes, as well as the proper installation of that code in those nodes.It is important to notice that the characteristics of each node - such as CPU,memory, etc -, are considered in order to generate an efficient service imple-mentation. Finally, the services are instantiated and configured according tothe information available in the application pattern.

3.5 eSOA Middleware Implementation

In this section we will analyze and study the implementation details of the pro-totypical eSOA middleware proposed in [57]. As described in [58], “the resultof [the] code generation [...] is an optimized, tailored middleware with embed-ded and already configured services that implement the application logic. Themain task of the middleware is to connect the different services involved inde-pendent[ly] of their location (local or remote).” Figure 11 depicts the role of themiddleware within the network architecture. Also, we will comment on the tech-nical solutions suggested to meet the requirements already seen in section 3.2.Four main aspects are covered: efficient distributed data processing, metadataaided service composition, run-time adaptability, and integration with externalservices. Let us now review all of these aspects.

Fig. 11. Network Architecture.

3.5.1 Efficient Distributed Data Processing

Due to strict CPU, memory, bandwidth, and battery limitations, it is essential forthe proposed middleware to efficiently collect, process, and distribute data. Thisis achieved by means of generating efficient platform-specific code, together withan event-based data processing, as well as a distributed execution of applications.

Efficient Platform-Specific Code Generation: Thanks to the model-basedcode generation the middleware is capable of dealing with heterogeneousunderlying hardware. Figure 12 depicts the general node architecture. The(Service) Broker is the is the central component of the system and is re-sponsible for managing the data flow at the application level. All the config-uration logic within the system is concentrated in one component per node:the Broker. Consequently, it is the Broker the component to be addressed

Fig. 12. Node Architecture.

in those cases in which the system has to be reconfigured during run-time[58]. The Network element, on its side, is in charge of the data routing aswell as of handling with the physical communications. On the other hand,the Node Manager implements the service life cycle management, includingthe service announcements. The key idea here is that services are mappedinto the specific platform by means of generating a service stub. Services areeasily mapped into any other platform that provides the necessary compiler.Furthermore, the middleware functionality can be scaled down to only thatstrictly needed on a specific node.

Event-Based Data Processing: When it comes to embedded networks, datais frequently acquired, transmitted, and processed at periodic intervals. Inorder to maximize the energetic efficiency of the system, a number of strate-gies, many of which are already contemplated by e-OSs (operating systemsfor embedded devices), can be applied, such as putting the CPU to sleepmode, or even turning off the sensor hardware during the inactivity periodsin which the sensor is on idle state. The middleware under study supportsthis feature by providing an event-based processing model, in which theexecution of application logic can be triggered in three different ways: peri-odically, by incoming data, or due to environmental changes.

Distributed Execution of Applications: In order to optimize the executionof applications, eSOA allows hardware-independent eServices, i.e. commonlyall logic services, to be allocated at any programmable node. This approachimproves aspects such as resource utilization, reliability, responsiveness, etc.Communications between eServices may include both simple or complex datatypes. The key idea at this point is that the proposed middleware intention-ally only provides data binding interfaces for XML-schema simple types [42]so that the overhead on small devices is minimized. On the other hand, more

powerful devices may require complex data types. If that is the case, cus-tom data binding code is generated and shipped along with the service. Thisstrategy of storing the metadata descriptions of the specification of boththe representation and meaning of simple data types on the nodes them-selves, allows to reduce the transmitted data, to only the raw data payload ifonly simple types are involved, optimizing the bandwidth usage. The uniquedownside is that, obviously now, transmitted data is not self-descriptive any-more. There are two ways of dealing with this. The first option is checkingthe compatibility between connected inputs and outputs during the processof service composition, which can be automated thanks to the metadata de-scriptions. The second option, not recommended for CPU-limited nodes, isinspecting the metadata description of the corresponding output so that thedata type of the incoming data stream can be dynamically inferred.

3.5.2 Metadata-Aided Service Composition

The metadata-based description of services, commented above, introduces twoadditional advantages: end-user programming support and (semi-)automatic ser-vice composition.

End-user Programming: In order to facilitate non-experts users the use ofthe suggested middleware, an intuitive end-user programming interface isprovided. The average non-expert user will have a good understanding ofthe application domain, but little to no knowledge about implementationdetails, such as the installed hardware and software, and the used middle-ware.The proposed end-user programming interface allows the user to easily chosethe most suitable application pattern from a repository of pre-existing pat-terns compatible with his/her hardware. Once a specific pattern has beenchosen, the user can assign hardware services, among those available, to theslots defined by the selected pattern on a drag-and-drop fashion. Finally, theuser can also select the required logic services from a list of services withcompatible metadata. The key idea is that all of the user’s selections arebased uniquely on domain knowledge, which is represented in the metadatadescription.In the case of more experienced users with some basic understanding of thedata types and services properties, it is possible to develop their own appli-cation patterns, which can be even published and shared in the internet withthe entire users/developers community. Application patterns can be devel-oped in two ways: by extracting them out of available service compositions,or by building them up by grouping services. It is important to point out thatapplication patterns should have only the strictly necessary requirements, sothat they are compatible with as many specific services as possible, whileensuring the functionality of the entire application.Finally, in the case of a programmer, it is possible to develop logic services,just by filling a generated stub with some application-specific code. Simple

services, such as a temperature control service, may be composed of basicservices – adders, comparators, etc. – so no manual programming is nec-essary at all. On the other hand, more complex services may require someprogramming. More on the different types of users and roles can be found in[58].

(Semi-) Automatic Service Composition: Some application fields are char-acterized by including lots of subnets of either identical or similar structure,e.g. rooms with similar equipment in a large building. In cases like these, theprocess of (re-)configuration of every single subnet can be quite tedious. Itseems evident that some kind of automation would facilitate such a process.Application patterns allow certain level of automation due to the followingreasons. First, changes done in a single installation are easily propagable toother installations, on condition that all of them are based on the same pat-tern. Second, since patterns can be easily inferred by simply inspecting theservices available in a particular installation, it is possible to make sugges-tions based on those patterns for new installations. This can be achieved bya “copy & paste” functionality. If there are no ambiguities in the availablemetadata, the entire process is done automatically. Otherwise, the user hasto solve the existing ambiguities.

3.5.3 Run-Time Adaptability

Embedded networks are frequently dynamic: new nodes can be added at anytime, existing nodes can be reconfigured, become temporarily unavailable, oreven removed, mobile nodes can enter and leave the network, etc. The proposedmiddleware provides a discovery mechanism based on the (semi-)automatic ser-vice composition, which is capable of integrating the hardware on the newlydiscovered node with the running applications.

Regarding the failures of nodes, there are two ways in which they can bemanaged: locally or globally. Local recovery is possible only when redundanteServices and/or communication channels are available to replace those withfailure. Global recovery on its side, is based on a (semi)-automatic network re-configuration, e.g. by switching to an application that does not need the failednode. The main advantage of this approach is keeping the network functioning,even at a reduced functionality level, instead of simply collapsing.

In relation to the adaptation of nodes to new applications, this requires neweServices to be added to nodes at run-time. In order to achieve this, the pro-pounded middleware includes a management service responsible for the (de-)installation, startup, instantiation, reconfiguration, and shutdown of services.At this point, there are two options, depending on the underlying operatingsystem. If the OS supports the execution of dynamically loaded code, the com-piled service is transmitted over the embedded network and loaded by the OS.If this is not the case, only those services previously installed on a node can beinstantiated and started. In any case, the new service instance is started andconfigured as required by the application itself. In the event of an applicationremoval, all those services used only by that application are conveniently shut

down and de-installed, facilitating the maintenance of the services repository.

3.5.4 Integration with External Services

As explained in section 3.1, nowadays there is an increasing demand for inte-grating the world of web services and that of eServices, specially in the fieldsof manufacturing and logistics, in which a break in the information exchangebetween both worlds is not tolerable anymore. As illustrated in Figure 13, theintegration has to be designed so that it ensures that users from any of bothworlds are allowed to interact with services from the other world in the sameway they interact with those services from their own world. In other worlds,users familiar with the WS world should be allowed to interact with eServicesin the same way that they interact with WS. On the other hand, users from theembedded world should be allowed to interact with WS in the same manner asthey interact with eServices.

Fig. 13. Integration of Web Services and Embedded Worlds.

Next, let us focus on three aspects of interest: the interaction schemes, the IP-compatible addressing, and the Service Bridge.

3.5.4.1 Interaction Schemes

The mediation between both worlds is performed by a Service Bridge (gateway),responsible for converting incoming and outgoing messages, as well as for pro-viding WSDL interfaces for eServices. The Service Bridge must support fourdifferent types of communications:

Continuous Interaction with the Embedded Network: This case occurswhen an external WS interacts in a continuous fashion with one or more eS-ervice(s). Services communicate via subscriptions. A subscription is a mech-anism that connects the input of a WS to the output of an eService, or theinput of an eService to the output of a WS. Two main advantages are de-rived from the use of subscriptions: low communication overhead and supportof non-periodic interactions. Subscriptions can be managed by technologiessuch as WS-Eventing.Let us now review WS-Eventing in more detail. As explained in [39], “Webservices often want to receive messages when events occur in other servicesand applications. A mechanism for registering interest is needed because theset of Web services interested in receiving such messages is often unknown inadvance or will change over time.” And continues: “This specification [WS-Eventing ] defines a protocol for one Web service (called a ”subscriber”) toregister interest (called a ”subscription”) with another Web service (calledan ”event source”) in receiving messages about events (called ”notifications”or ”event messages”). The subscriber may manage the subscription by inter-acting with a Web service (called the ”subscription manager”) designatedby the event source.”

Ad-hoc Interaction with the Embedded Network: Unlike in the previouscase, in this scenario the interaction between services is not planned before-hand via subscriptions, but spontaneous. This type of communication isbased on RPC-style WS invocations. As detailed in [18], “an RPC [RemoteProcedure Call] is initiated by the client, which sends a request message to aknown remote server to execute a specified procedure with supplied param-eters. The remote server sends a response to the client, and the applicationcontinues its process.”

Continuous Interaction with the External Web Services: Characterizedby the necessity of retrieving and/or sending data from/to an external WSon a periodic basis. The communication exchanges are based on the stream-based paradigm used on the embedded network.

Ad-hoc Interaction with the External Web Services: This scenario is notnecessary, and thus not contemplated in the proposed middleware. SinceeServices have no knowledge about the specific wiring, reconfigurations ofapplications are only triggered by either WS end-users or the middlewareitself, but never by the eServices themselves.

3.5.4.2 IP-compatible Addressing

In order to ensure a seamless integration between the WS and the embeddedworlds, and due to the worldwide extensive use of the Internet Protocol (IP)[14], all the devices in the eSOA world have an IP address, even in those casesin which the underlying network uses a different addressing scheme. The ServiceBridge is responsible for monitoring all incoming messages at the Network Layer.When an incoming message is targeted at a certain eService, it is convenientlytranslated into the suitable packet format and forwarded to the corresponding

eService. An illustrative example is depicted in Figure 14. The incoming WSmessage is translated into the ZigBee protocol by means of analyzing the WSDLdescription.

Fig. 14. Service Bridge.

3.5.4.3 Service Bridge

As already commented in section 3.5.4.1, the Service Bridge acts as an interfacebetween the WS world and that of embedded systems, converting incoming andoutgoing messages and providing WSDL [41] interfaces for eServices. Let us nowanalyze in more detail the translation process realized by the Service Bridge forall of the already introduced communication schemes.

Continuous Interaction with the Embedded Network: With the goal ofmaking an eService accessible from the WS world, a WSDL generator createsa WSDL document which contains a description of the eService’s interfaces,including a Notification type port for every output as well as a One-way portfor every input. The correlation between these ports is conveniently storedin a mapping table. Finally, the newly created WSDL document is madeavailable via a UDDI-based discovery interface, allowing the eService to besearchable by users from the WS world.

Ad-hoc Interaction with the Embedded Network: In this scenario, theService Brigde has to mediate between the WS pull-based request/responseinvocation scheme and the push-based communication scheme that governsembedded systems. In order to achieve this, the Service Brigde installs acaching service, consisting of two inputs - a data input and a trigger input -and one output. The data input is connected, as expected, to the correspond-ing output of the target service. The caching service only stores the very lastincoming data, received from from the data input. Only in the event of anincoming message arriving to the trigger input, the caching service sends thestored data through the cache output. In conclusion, when a WS requires ameasurement from the embedded world, this request arrives to the ServiceBrigde, which will trigger the necessary measurement at the target service

and send the reply back to the originating WS. The trigger input is thus justa synchronization mechanism.

Continuous Interaction with the External Web Services: External WScan be accessed from the embedded world too. In order to achieve this, theWS is represented by a virtual eService, created by the Service Brigde, andwhich inputs and outputs are created according to the WSDL description ofthe target WS. An output is created for every Notification type port, whilean input is created for every One-way port. The correlation between theseports is conveniently stored in a mapping table. When an eService wants tosend data to an external WS, it actually sends it to the input of the virtualservice, which is running in the Service Brigde node. The Service Brigdeintercepts the incoming message, converts it to a SOAP call, and forwardsit to the destination WS, which is previously determined by consulting themapping table. Analogously, incoming SOAP messages are captured by theService Brigde, which converts them to the corresponding messages in theembedded world, and forwards them to the destination eService through thevirtual service output.

Ad-hoc Interaction with the External Web Services: As already seen insection 3.5.4.1, this scenario is not supported by the proposed middleware.However, in case it would be needed, it could be mimicked by means ofinstalling temporary data streams for the duration of the invocation.

The main advantage of the presented communications approach is the fact thatit is independent of services, so that no changes are needed when new servicesare added to the system.

3.6 eSOA Middleware Example: Smart Home

Once we have analyzed the eSOA middleware design principles and implemen-tation on detail, let us finish this section with a real example of implementationcalled Smart Home. As explained in [43], one of the most salient and demandedapplications of embedded networks is building automation. While in the in-dustrial and business arena there is an notorious and increasing demand forsystems that automate part of the common activities, building automation hasnot reached yet a critical mass of users in the private household sector, in part,due to the high installation costs. One of the main objectives of Smart Homeis reducing installation costs, by facilitating the installation process so that endusers themselves can setup their own automated systems at home.

A Smart Home demonstrator is depicted in Figure 15. The system consistsof a power supply, a battery, two lights, a refrigerator, and a phone. All of theseelements are thought of as they would exist in a future home. Another advantageof Smart Home is the fact that it is designed to save energy. It is assumed thatfuture homes will have some kind of energy storage system, such as a battery,or similar. By having two energy sources, the traditional power supply and thebattery, the system can switch from one to the other as pleased. It is well knownthat energy cost varies throughout the day. The key idea is obtaining the energy

from the power supply when the price is low, and switching to the battery whenprice is high, so that the householders save money in their monthly bills. Whenthe prices are low again, the system automatically switches again to the powersupply. Of course, it is taken for granted that the energy would be obtained fromthe power supply if the battery runs out of energy, no matter the current price.In addition to this switching feature, in those occasions when prices are high,the system can also put the refrigerator in ‘stand by’ or adjust its temperaturethreshold so that it consumes less energy during price peaks. The used ZigBee-based motes consists of a number of I/O devices capable of reading signals fromthe switches, and turning on or off the loads - lights, phone, refrigerator, etc. -.

Fig. 15. Smart Home Demonstrator.

An intuitive and easy-to-use user interface is, as mentioned above, essential tofacilitate end users the installation, (re-)configuration, and use of Smart Home.In order to favour the user’s experience with the system, it is provided withsome graphical tools. For instance, the electricity prices can be retrieved fromthe Internet in real-time.Finally, Smart Home also includes a graphical user interface (see Figure 16)that eases enormously the processes of (re-)configuration, or management of thesystem.

4 Related Work

4.1 Introduction

As explained in [43], [57], and [59], there are a number of standardized mid-dleware architectures oriented to concrete domains, such as AUTOSAR [4] forautomotive applications and KNX [15] for building automation. The main down-sides of these approaches are derived from their very low abstraction level, which

Fig. 16. GUI for Pattern Installation.

does not allow end-user programmability. Furthermore, their data processingparadigm is not compatible with that of service-oriented systems, making itdifficult to integrate them with external services.

Regarding the field of sensor networks, there are also certain middlewarescapable of monitoring them. Two salient examples to be mentioned are TinyDB[53] and Cougar [63]. The main disadvantage of these systems are the potentialbottlenecks and the single points of failure for those control-oriented applicationsconsisting of multiple sensors and actuators. This is due to their hierarchicalnetwork structure, since the amount of necessary data increases as we ascendfrom level to level within the hierarchy.

In relation to SOA, there are other projects, apart from the middlewareproposed in this article, which also take advantage of this approach for embeddednetworks. Some of the most representative are OASIS [51], RUNES [47] andMORE [16]. The main drawback of these projects is that they do not supportneither the generation of tailored code nor the optimization of the placement ofservices. As a direct consequence, unlike the suggested eSOA middleware, theydo not explote the intrinsic characteristics of a particular network.

Additionally, there are other projects such as SIRENA and SOCRADES [30]also based on SOA which adopt a different approach based on DPWS ([7], [17])with the objective of making embedded services and eServices directly accessiblefrom the WS world. The main weakness of such approach is the fact that, evenwhen it may work fine with certain types of devices, it is not suitable for small

lightweighted ones, since these are not capable of dealing with the overheadintroduced by the WS technologies and protocols.

Once we have briefly commented on the most relevant projects related to theeSOA-based middleware object of this article, let us now study in more detaileach of them. Since an extensive analysis of these projects is out of the scopeof this work, we will make only a brief introduction to each of them so that itserves as a general overview.

4.2 AUTOSAR

As defined in [4], AUTOSAR (AUTomotive Open System ARchitecture) is “anopen and standardized automotive software architecture, jointly developed byautomobile manufacturers, suppliers and tool developers.” AUTOSAR supportsall vehicle domains and will serve as a platform standard upon which futurevehicle applications will be implemented, minimizing current barriers betweenfunctional domains.

4.2.1 Goals

The main goals of AUTOSAR are:

– Implementation and standardization of basic system functions as an OEMwide ”Standard Core” solution

– Scalability to different vehicle and platform variants– Transferability of functions throughout network– Integration of functional modules from multiple suppliers– Consideration of availability and safety requirements– Redundancy activation– Maintainability throughout the whole ”Product Life Cycle”– Increased use of ”Commercial off the shelf hardware”– Software updates and upgrades over vehicle lifetime

4.2.2 Key Features

The key features of AUTOSAR are:

– Modularity and configurability– Standardized interfaces– Runtime environment

4.2.3 Technical Goals

– Modularity– Scalability– Transferability– Re-usability– Standardized interfaces

4.2.4 Software

Figure 17 shows the aspect of AUTOSAR software application.

Fig. 17. AUTOSAR software application.

4.2.5 Architecture

Figure 18 shows the architecture of AUTOSAR, based upon the concept of onSW-Cs (software components) which encapsulate applications, and have well-defined standardized interfaces.

The AUTOSAR architecture consists of the following elements:

– Software Component (SW-C)– Software Component Description (SW-C description)– Virtual Functional Bus (VFB)– System Constraint Descriptions– ECU Descriptions– Mapping on ECUs– Runtime Environment (RTE)– Basic Software

4.3 KNX

As described in [15], KXN is the “worldwide standard for all applications inhome and building control, ranging from lighting and shutter control to various

Fig. 18. AUTOSAR architecture.

security systems, heating, ventilation, air conditioning, monitoring, alarming,water control, energy management, metering as well as household appliances,audio and lots more. The technology can be used in new as well as in existinghome and buildings.”

4.3.1 Goals

– Convenience– Safety– Energy savings

4.3.2 Key Features

– A single, manufacturer independent design and commissioning tool (ETS)– A complete set of supported communication media (TP, PL, RF and IP)– A complete set of supported configuration modes (system and easy mode)– Low operating costs resulting in considerable energy savings– Time saving– Flexibility and adaptability to future developments

4.4 TinyDB

As defined in [53] and [32], TinyDB is “a query processing system for extract-ing information from a network of TinyOS sensors.” The main difference be-tween TinyDB and other solutions for data processing in TinyOS is the fact

that TinyDB does not require the programmer to write embedded C code forsensors but it provides a simple SQL-like interface to specify the data to beextracted, along with additional parameters. TinyDB collects that data frommotes in the environment, filters it, aggregates it together, and routes it out toa PC. TinyDB does this via power-efficient in-network processing algorithms.

4.4.1 Goals

– Facilitating the programming (no need for low-level code)– Allowing quick development of data-driven applications

4.4.2 Key Features

– Metadata management– High level queries– Network topology– Multiple queries– Incremental deployment via query sharing– Java API for writing PC applications– Graphical query-builder and result display

4.4.3 Architecture

Figure 19 shows the architecture of TinyDB in which the TinyDB query processoris installed in every single mote of the network.

Fig. 19. TinyDB architecture.

4.5 Cougar

According to [63], existing sensor networks are based upon an structure of pre-programmed sensors that send data to a central front-end where the data isaggregated and stored for offline quering and analysis. The main downsides ofthis approach are the fact that the behaviors of the system cannot be modifiedduring runtime, as well as the lack of in-network programming. The Cougar ap-proach aims to solve these issues by means of using declarative queries.

4.5.1 Key Features

– Query optimizer: generates an efficient query plan for in-network query pro-cessing

– Reduction of resources usage– Extended life of sensors– Queries expressed in declarative language– Independence from the underlying physical network

4.6 RUNES

Nowadays embedded systems constitute a major technological revolution foundin multiple fields such as smart buildings, industrial automation, power distribu-tion, etc. The resulting applications are more efficient, accurate or cost effective.In order to ensure interoperability of sensors between applications, a commonlanguage for all systems is necessary [47].

As explained in [19], “the RUNES (Reconfigurable Ubiquitous Networked Em-bedded Systems) project has a vision to enable the creation of large-scale, widelydistributed, heterogeneous networked embedded systems that interoperate andadapt to their environments.”

4.6.1 Goals

– Simplify the programming– Simplify the application creation process– Cut the costs of new applications development– Fasten the time to market

4.6.2 Key Features

– Standardised architecture– Self-organisation to suit changeable environments– Adaptive middleware platform– Common language

4.6.3 Architecture

Figure 20 shows the architecture of RUNES, consisting of applications, a component-based middleware, and the hardware devices. The middleware itself is structuredinto four layers: services and application-specific mechanisms, the middlewareAPI, cross-platform components, and hardware abstractions.

Fig. 20. RUNES architecture.

4.7 MORE

The MORE (Network-centric Middleware for GrOup communication & ResourceSharing across Heterogeneous Embedded Systems) project aims to “implementnew technology to facilitate communication and distributed intelligence acrossgroups of users using different wireless standards” [16].

4.7.1 Goals

– Provide a SOA-based middleware deployable on the device level– Efficient interactions between humans and embedded systems– Customization to meet specific needs of diverse organizations– Alleviate heterogeneity of devices

4.7.2 Key Features

– Simplified APIs– Management mechanisms– Independence from the underlying physical network– Policy driven group communication– Resource sharing between devices/services– Security of communications for secure data exchanges– Enabling gateway services

4.7.3 Architecture

Figure 21 shows the architecture of MORE, including the MORE middlewareconsisting of a Core Management Service (CMS) along with a number of En-abling Services.

Fig. 21. MORE architecture.

4.8 SIRENA

As stated in [22], the SIRENA project was “a European research and advanceddevelopment project, from 2003 to 2005, with the objective to develop a Ser-vice Infrastructure for Real time Embedded Networked Applications.” The maincontribution of SIRENA was the application of the SOA paradigm to communi-cations and interworking between components at the device level. The SIRENAproject served as the foundation for projects such as SODA and SOCRADES.

4.9 SOCRADES

According to [31], “the SOCRADES project is a European research and advanceddevelopment project. Its primary objective is to develop a design, execution andmanagement platform for next-generation industrial automation systems, ex-ploiting the Service Oriented Architecture paradigm both at the device and atthe application level.”

4.9.1 Goals

– Development of a comprehensive device-level SOA infrastructure – based onthe Devices Profile for Web Services (DPWS) – for encapsulating intelligenceand sensing or actuating skills as services, as well as to specify associatedframeworks for management and orchestration of device-level services.

– Definition of a methodology for describing services with semantic mark-upthat can be interpreted and processed by agents (Semantic Web Services),for the discovery, selection and composition of resources.

– Specification of a framework for service-enabled intelligent physical agents.

4.9.2 Architecture

Figure 22 shows the architecture of SOCRADES.

Fig. 22. SOCRADES architecture.

4.10 Additional Works

There are a number of related references that the reader may find of interest,some of which are briefly summarized here. [25] and [9] are studies about SOAon embedded systems. [44] gives an overview of the trends and roadmaps onSOA-based embedded networks for industrial automation, while [61] and [23] in-troduce SOA-based embedded systems development environments for industrialautomation. [49] illustrates a practical implementation of SOA for embeddedsystems in the context of harbours automatic management. [50] refers to theintegration of SOA-ready networked devices in enterprise systems via a cross-layered web service infraestructure, while [6], [5], and [2] introduce Web ServicesBusiness Process Execution Language (BPEL). [55] suggests a constraint-basedcomponent system for synthesizing scalable software systems, called BOTS. [64]on it side, proposes SOA-toolkits for making embedded systems ready for webservices. On the other hand, [52] focuses on embedded software system testingbased on SOA for mobile service. Finally, [62] is a critique of ambient technologyand the all-seeing network of RFID.

5 Future Work

Once we have briefly introduced the main projects related to the eSOA middle-ware focus of this article, let us now comment on the eSOA authors’ ongoing

work. As discussed in [57], [43] and [59] there are a number of possible improve-ments to the proposed platform.

Fist, the application execution can be improved by applying data streammanagement technologies. Second, there is the need for evaluating differentservice placement strategies. Third, it may be interesting researching ways toachieve the automatic learning of service patterns based on a repository of ex-isting applications. Forth, the development of application level connectivity atthe routing layer is necessary for routing optimization with low overhaead forprotocols and routing tables. Fifth, the enrichment of the semantic descriptionsof services would allow obtaining metrics that may allow to select the mostsuitable service out of a service repository. Sixth, further research has to be ac-complished regarding the requirements of an intuitive interface for the discoveryand integration of field-level devices and web services, as well as to find out ifsuch requirements can be met with existing technologies such as UDDI registriesor query interfaces such as TinyDB.

6 Conclusions

While traditionally many devices were designed to work as isolated embeddedsystems, nowadays the trend is to connect and integrate daily-life devices intodistributed embedded networks, as it is envisioned by the Internet of Things(a.k.a. Internet of Objects), which purpose is to interconnect all things. Con-necting web services and embedded devices is essential, since the demand forsystems capable for dealing with both worlds is rapidly increasing, specially inthe fields of automotive, factory automation, and building management, in part,as a consequence of the ongoing decline in prices for network-enabled hardwaredevices.

The service-oriented paradigm, based upon the Service-Oriented Archi-tecture (SOA), is the most extended and widely adopted strategy for im-plementing complex, heterogeneous, and large IT systems worldwide, mostlybased on web services. The SOA paradigm offers numerous advantages suchas standardized service contract, service loose coupling, service abstraction, ser-vice reusability, service autonomy, service statelessness, service discoverability,service composability, service optimization, service relevance, and service encap-sulation. However, due to the particular characteristics of embedded networks- heterogeneity, distributed and reconfigurable architecture, resource limitations,scalable functionality, error detection and recovery, end-user programming, andbridging - traditional SOA cannot be applied directly to them.

There are several research projects which attempt to integrate the worldsof embeddded sensor networks and that of web services. One of these projects,developed by the Computer Science Department at the Technical University ofMunich, and focus of this article, proposes a SOA-based middleware for em-bedded networks called eSOA, which architecture consists of three layers. TheAbstract Infrastructure Layer provides a unified model of the underlyinghardware components (nodes) and a serie of 1-hop network connections between

nodes ( links). The Service Layer provides a service-oriented view of the un-derlying sensors/actuators. The Application Layer provides an overview ofthe installed applications, the involved services instances, as well as of the infor-mation exchanged between instances. The process of installing a new applicationconsists of three steps: pattern filling, service placement, and code generation.

The eSOA middleware implementation supports the following features: Ef-ficient Distributed Data Processing , including Efficient Platform-SpecificCode Generation, Event-Based Data Processing, and Distributed Execution ofApplications, Metadata-Aided Service Composition , including End-userProgramming and (Semi-) Automatic Service Composition, Run-Time Adapt-ability , as well as Integration with External Services, including support forcontinuous/ad-hoc interaction between the embedded and the WS worlds, IP-compatible Addressing, and a Service Bridge.

An illustrative prototype of the eSOA middleware called Smart Home ,was developed and meets most of the mentioned requirements. However, furtherresearch is being done in order to to improve the system.

References

1. Reference model for service oriented architecture 1.0. Technical report, OASIS,2006.

2. Web services business process execution language version 2.0. Technical report,OASIS, 2007.

3. Internet of things: An action plan for europe. Technical report, Comission of theEuropean Communities, 2009.

4. Autosar, 2010. http://www.autosar.org/.5. Bpel: Business process execution language specifications, 2010.

http://www.ibm.com/developerworks/library/specification/wsbpel/.6. Bpel: Business process execution language wikipedia, 2010.

http://en.wikipedia.org/wiki/Business Process Execution Language.7. Devices profiles for web services wikipedia, 2010.

http://en.wikipedia.org/wiki/Devices Profile for Web Services.8. e-services wikipedia, 2010. http://en.wikipedia.orgwikiEServices.9. Embedded service oriented architecture, 2010.

http://www.davidgreco.it/MySite/Blog/Entries/2008/5/13 Embedded SOA.html.10. Embedded systems wikipedia, 2010. http://en.wikipedia.org/wiki/Embedded system.11. Internet of services wikipedia, 2010. http://en.wikipedia.orgwiki-

Internet of Things.12. Internet of services: Home & news, 2010. http://www.internetofservices.com/.13. Internet of things wikipedia, 2010. http://en.wikipedia.orgwiki-

Internet of Things.14. Internet protocol wikipedia, 2010. http://en.wikipedia.org/wiki/Internet Protocol.15. Knx, 2010. http://www.knx.org/.16. More, 2010. http://www.istmore.org/.17. Oasis devices profile for web services (dpws), 2010. http://docs.oasis-

open.org/wsdd/ns/dpws/2009/01.18. Remote procedure call wikipedia, 2010. http://en.wikipedia.org/wiki/Remote procedure call.19. Runes, 2010. http://www.istrunes.org/.

20. Service oriented architecture wikipedia, 2010. http://en.wikipedia.orgwiki-

Serviceoriented architecture.21. Serviceoriented modeling and architecture, 2010.

http://www.ibm.com/developerworks/webservices/library/wssoadesign1/.22. Sirena, 2010. http://www.sirenaitea.org/.23. A soabased embedded systems development environment for industrial automation,

2010. http://www.hindawi.com/journals/es/2008/312671.html.24. Soa manifesto, 2010. http://www.soa-manifesto.org/.25. Soa on embedded systems, 2010. http://soalib.com/index.jsp?page=embedded.26. Soa patterns, 2010. http://www.soapatterns.org/.27. Soa principles, 2010. http://www.soaprinciples.com/.28. Soa specs, 2010. http://www.soaspecs.com/.29. Soap wikipedia, 2010. http://en.wikipedia.orgwikiSOAP.30. Socrades, 2010. http://www.socrades.eu/Home/default.html.31. Socrades, 2010. http://www.socrades.eu/Home/default.html.32. Tiny db, 2010. http://telegraph.cs.berkeley.edu/tinydb/.33. W3c soap version 1.2, 2010. http://www.w3.org/TR/soap12part1/.34. W3c web services architecture, 2010. http://www.w3.org/TR/wsarch/.35. W3c web services description language (wsdl) 1.1, 2010.

http://www.w3.org/TR/wsdl.36. W3c web services glossary, 2010. http://www.w3.org/TR/wsgloss/.37. Web service wikipedia, 2010. http://en.wikipedia.org/wiki/Web service.38. Web services and oriented architecture, 2010. http://www.service-

architecture.com/.39. Web services eventing (ws-eventing), 2010. http://www.w3.org/Submission/WS-

Eventing/.40. What is soa, 2010. http://www.whatissoa.com/.41. Wsdl wikipedia, 2010. http://en.wikipedia.orgwiki-

Web Services Description Language.42. Xml schema part-2: Datatypes second edition, 2010.

http://www.w3.org/TR/xmlschema2/.43. Sommer S. Sholz A. Buckl, C. Services to the field: An approach for resource

constrained sensor actor networks. In The Fourth Workshop on Service OrientedArchitectures in Converging Networked Environments (SOCNE 2009), 2009.

44. Gerosa M. Taisch M. Cannata, A. Trends and roadmaps on soa-based embeddednetworks for industrial automation systems: a review. 13th IFAC Symposium onInformation Control Problems in Manufacturing (INCOM 2009), 13 (1):., 2009.

45. Voigt K. Winkler M. Cardoso, J. Service engineering for the internet of services.In ICEIS(2008), pages 15–27, 2008.

46. J.C. Cortizo Prez. Serviceoriented architecture. Escuela Superior Politecnica.Universidad Europea de Madrid.

47. Coulson G. Costa, P. The runnes middleware: A reconfigurable component-basedapproach to networked embedded systems. PIMRC, 2:806–810, 2005.

48. T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. PearsonEducation, Inc, 2009.

49. Jonischkat T. Helter, S. Soharbour: Soa for embedded systems. Duisburg EssenUniversity.

50. Baecker O. de Souza L. Karnouskos, S. Integration of soaready networked devicesin enterprise systems via a crosslayered web service infraestructure. In 12th IEEEConference on Emerging Technologies and Factory Automation, 2007.

51. Amudson I. Kushwaha, M. Oasis: A programming framework for service-orientedsensor networks. In COMSWARE, 2007.

52. Cheol J. Jang O. Lee, M. Embedded software system testing based on soa formobile service. International Journal of Advanced Science and Technology, 1:55–64, 2009.

53. Franklin J. Madden, S.R. Tiny db: An acquisitional query processing system forsensor networks. ACM Transactional Database Systems, 30:122–173, 2005.

54. E. Ort. Serviceoriented architecture and web services: Concepts, technologies andtools. Technical report, Sun Microsystems, 2005.

55. Wu J. Pandey, R. Bots: A constraintbased component system for synthesizingscalable software systems. LCTES, 1:189–198, 2006.

56. J. Rowley. An analysis of the e-service literature: Towards a research agenda. In-ternet Research13th IFAC Symposium on Information Control Problems in Man-ufacturing (INCOM 2009), 16 (3):339–359, 2006.

57. Gapanova I. Sommer S. Buckl C. Sholz, A. esoa service oriented architecturesadapted for embedded networks. In Proceedings of the 7th International Conferenceon Industrial Informatics, 2009.

58. Buckl C. Knoll A. Sommer, S. Applying the service oriented paradigm to developsensor actuator networks. In Junior Researcher Workshop on RealTime Computing(JRWRTC 2008), 2008.

59. Sholz A. Buckl C. Sommer, S. Towards the internet of things: Integration of webservices and field level devices. In International Workshop on the Future Internetof Things and Services Embedded Web Services for Pervasive Devices (at FITS2009), 2009.

60. Y. Sure. The internet of services: Systematic thought leadership for innovativebusiness. Vienna, Austria. May 8th, 2008.

61. Doukas G. Koumoutsos G. Thramboulidis, K.C. A soabased embedded systemsdevelopment for industrial automation. EURASIP Journal on Embedded Systems,1:., 2008.

62. R. Van Kranenburg. The Internet of Things: A Critique of Ambient Technologyand the AllSeeing Network of RFID. Institute of Network Cultures, Amsterdam,2008.

63. Gehrke J. Yao, Y. The cougar approach to innetwork query processing in sensornetworks. SIGMOD Record, 31 (3):9–18, 2002.

64. Bobek. A. Bohn H. Zeeb, E. Ws4d: Soatoolkits making embedded systems readyfor web services. In Open Source Software and Productlines 2007 (OSSPL07), 2007.