eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks
eSOA: A Contextual Analysis on Service Oriented Architecture for Embedded Networks Juan Antonio Martin Checa Computer Science Department Campus Teatinos University of Malaga 29071 Malaga, Spain firstname.lastname@example.org http://www.telefonica.net/web2/jamcheca Abstract. Traditionally, embedded sensor networks have been exclusive of the industrial arena. However, nowadays we are living a technological revolution 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 ﬁeld, all of them contributing to this big puzzle. One of these projects, and focus of this article, proposes a SOA-based middleware for embedded networks called eSOA. The objective of this article is to analyze the eSOA middleware in the context of embedded networks 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 IntroductionWhen 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 ﬁrst. 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 ﬁrst 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 brieﬂy 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-conﬁguring wireless network of sensors which purpose would be tointerconnect all things” . 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 traﬃc congestion, airconditioning valves that react to the presence of people, connected trees thatwould help reduce deforestation, etc. ). 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 diﬀer-ent levels of communications: things-to-person and things-to-thing  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 identiﬁcation and inventory,etc. The Semantic Web, on its side, oﬀers an alternative based on the idea ofmaking all things addressable by the existing naming protocols, for example bymeans of using a Uniform Resource Identiﬁer (URI ).1.2 The Internet of Services (IoS)As described in , the Internet of services is the “next-generation of the ser-vices revolution.”  deﬁnes IoS as “a new business model that can radicallychange the way we discover and invoke services“. A more extended deﬁnition canbe found in , 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 diﬀerent 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-eﬃciencies from service supply and access, so important in nowadays’ servicesector, which is the biggest and fastest-growing business sector in the world.. In other words, IoS describes both the business framework and the tech-nical infrastructure (which uses the Internet) as a mean for oﬀering and sellingservices. The key idea is ﬁrst determining which services can be managed through IT,and then ﬁguring out new ways of combining them so that we obtain new value-added services. As explained in , a service-based value network is expectedto include the research, development, design, production, marketing, sales, anddistribution of any speciﬁc service. All of these phases contribute to the ﬁnalvalue of the service. The main challenge regarding IoS is the heterogeneous of current online ser-vices, relying on diﬀerent legacy applications hosted by diﬀerent providers, withdiﬀerent use policies, etc. All those handicaps have to be solved in a transparentway for the ﬁnal 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 ServicesThere 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 service consumer to create a value for the consumer” .e-Service: Rowley (2006)  deﬁnes e-services as: “. . . deeds, eﬀorts or perfor- mances whose delivery is mediated by information technology. Such e-service includes the service element of e-tailing, customer support, and service deliv- ery”, deﬁnition that reﬂects three main components: service provider, service receiver, and the channels of service delivery .Web Service: The W3C deﬁnes a web service as ”a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (speciﬁcally Web Services Description Language WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” . More on web services in . Fig. 1. Web Service ArchitectureWeb services are classiﬁed by the W3C  into two main groups:REST-compliant Web Services: in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of ”stateless” operations.Arbitrary Web Services: in which the service may expose an arbitrary set of operations.1.4 Lifecycle of Services: Discovery, Invocation, and ExecutionTwo main phases can be identiﬁed along the lifecycle of services :
Discovery/Invocation: are related to both the medium and the technology necessary 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 Service1.5 Atomic Vs Composite ServicesAccording to their complexity, services can be classiﬁed 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 provider and the customer.Composite Service: Service consisting of two or more atomic or composite services, oﬀering a superior functionality to the end user. It is normally provided by an aggregator, entity responsible for contracting basic services from diﬀerent providers, and combining them into the composite service. The customer pays for the composite service to the aggregator, and the aggregator 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 (deﬁned by associating a network address with a reusable bind-ing) that operate on messages containing either document-oriented or procedure-oriented information . Port types are abstract collections of supported op-erations. Both the operations and the messages (abstract descriptions of theexchanged data) are ﬁrst described as abstract entities, and then bound to aconcrete network protocol and message format, making WDSL extensible whileallowing the reuse of these deﬁnitions .Fig. 3. Representation of concepts deﬁned by WSDL 1.1 and WSDL 2.0 documentsWhen a client program connects to a web service oﬀered by a server, it can readthe WSDL ﬁle in order to determine what operations are supported by thatparticular server. Special datatypes, if any, are embedded in the WSDL ﬁle inthe form of XML Schemas. Finally, the client can use SOAP to call the desiredoperation (one of those listed in the WSDL ﬁle).1.7 SOAP (Simple Object Access Protocol)The Simple Object Access Protocol (SOAP) is “a protocol speciﬁcationfor exchanging structured information in the implementation of web services incomputer networks” . An alternative deﬁnition is oﬀered 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.” . 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 StructureRegarding the messaging framework, it consists of the following elements:The SOAP processing model: establishes the rules for SOAP messages to be processed.The SOAP extensibility model: speciﬁes SOAP modules and features.The SOAP underlying protocol binding framework: deﬁnes bindings.The SOAP message construct: determines the structure of a SOAP mes- sage.2 Service-Oriented Architecture (SOA)2.1 OverviewThe Organization for the Advancement of Structured Information Standard (OA-SIS ) deﬁnes SOA as “a paradigm for organizing and utilizing distributed capa-bilities that may be under the control of diﬀerent ownership domains.[...] Itprovides a uniform means to oﬀer, discover, interact with and use capabilities toproduce desired eﬀects consistent with measurable preconditions and expecta-tions.” . 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, ﬂexibility, interoperability, shared servicesand evolutionary reﬁnement . At present, it is supported by more than 700signataries worldwide.
2.2 Fundamental Design TermsBefore we focus on SOA in more detail, we need ﬁrst 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 termsDesign Characteristic: The term design characteristic refers to a speciﬁc at- tribute of a body of solution logic documented in a design speciﬁcation which is expected to be implemented. In the ﬁeld of service-orientation the usual objective is the creation of design characteristics that are common, very speciﬁc, 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 speciﬁc goal.Design Paradigm: A design paradigm is a governing approach to designing solution logic, usually consisting of a set of complementary principles that deﬁne the overarching approach represented by the paradigm itself.Design Pattern: A design pattern is a description of a common problem and its 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 interrelated patterns is called a “pattern language”.Design Standard: Design standards are design conventions, usually manda- tory, that allow organizations to consistently deliver solutions customized to their environments, resources, goals, and priorities.Best Practice: The term best practice can be deﬁned as an (industry) tech- nique or approach to either solving or preventing certain problems, based on past experience.2.3 Service-Oriented ComputingService-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 brieﬂy its main el-ements.2.3.1 Elements of Service-Oriented ComputingService-Oriented Architecture: A SOA is an architectural model with the goal of improving productivity, eﬃciency, and agility within a particular company by means of positioning services as the primary means through which solution logic is represented, supporting the creation, execution, and evolution of service-oriented solutions in the pursue of strategic goals . 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 paradigm consisting of a set of design principles, that, when applied to the design of solution logic, results in service-oriented solution logic, which basic unit is the service, which is an independent software program with a functional context and a set of invocable capabilities, expressed in the form of a published service contract (API).Service Compositions: A service composition is a coordinated set of related services.Service Inventory: A service inventory is an independent collection of stan- dardized complementary services.2.3.2 Goals and Beneﬁts of Service-Oriented ComputingThe main goals and beneﬁts 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 Diversiﬁcation Options – Increased ROI – Reduced IT Burden2.3.3 Service-Oriented Computing in the Real WorldWeb Services: Nowadays, the technology platform most associated with SOA is Web services, which is deﬁned through a number of industry standards and provides a communications framework based on physically independent service contracts, which can be standardized independently from their par- ticular proprietary implementation details. There are two main generations of web services.1st-Generation Web Services Platform: Built upon the following core open technologies and speciﬁcations: – Web Services Description Language (WSDL) – XML Schema Deﬁnition Language (XSD) – SOAP (formerly the Simple Object Access Protocol) – UDDI (Universal Description, Discovery, and Integration) – WS-I Basic Proﬁle2nd-Generation Web Services Platform (WS-* extensions): Build upon the ﬁrst-generation messaging framework, and with the goal of solving some of 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 most important speciﬁcations 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 IntroductionIn , a Service-oriented architecture (SOA) is deﬁned as “a ﬂexible 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 , Sun Microsystems deﬁnes 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 deﬁnes SOA as “a paradigm fororganizing and utilizing distributed capabilities that may be under the controlof diﬀerent ownership domains” . SOA provides a way for consumers of services (web-based applications, etc.)to be aware of available services, deﬁning 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 deﬁne an API. Instead, it is based on the concept of endpoint(the entry point for a particular SOA implementation) being the interface deﬁnedin 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” . 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 ArchitectureArchitectures can operate independently of speciﬁc technologies. Designers canimplement SOA using a wide range of technologies, including SOAP, RPC,REST, CORBA, Web Services, DCOM, and WCF.Elements of SOAFigure 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 .Layer-1. Operational systems layer: Existing legacy systems (custom built applications), object-oriented systems and intelligence applications.Layer-2. Enterprise components layer: Enterprise components responsible for 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 PrinciplesSOA is based upon a number of speciﬁc principles, necessary for its develop-ment, maintenance, and usage.  enumerates the following eight principles asmandatory for any SOA implementation:Standardized Service Contract: Services adhere to a communications agree- ment, as deﬁned 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, services hide 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 eﬀectively discovered and interpreted.Service Composability: Services are eﬀective composition participants, re- gardless of the size and complexity of the composition.According to , 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 , SOA speciﬁcations in , SOA patterns in , WS andSOA in  and .3 e-SOA: SOA for Embedded Systems3.1 OverviewTraditionally, many devices were designed to work as isolated embedded sys-tems . As already commented in the introduction of this article, nowadaysthe trend is to connect and integrate daily-life devices into distributed embed-ded networks , as it is envisioned by the Internet of things (a.k.a. Internetof objects), which purpose is to interconnect all things . 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 . Connecting web services and embedded devices is essential, since the de-mand for systems capable for dealing with both worlds is rapidly increasing(, ), specially in the ﬁelds 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 diﬀerent from WS-based systems.Also, we will analyze diﬀerent existing approaches to save the gap between bothwords: the world of web services and the world of embedded services.
3.2 Embedded Networks RequirementsAccording to , 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 .Heterogeneity: Network nodes usually have a diversity of processing, storage, sensing, and acting capabilities, and are built upon hardware components from diﬀerent 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 placing the data consuming control logic nearby the data producing sensors.Reconﬁgurable Architecture: The network must be reconﬁgurable at run- time so that new nodes with previously unknown functionality can be con- nected at any time. Also, existing nodes must be reconﬁgurable by installing new applications on them. All of this requires a life cycle management mod- ule responsible for maintaining a repository of available devices as well as for 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 the execution of applications and the involved network protocols.Scalable Functionality: Small devices should be lightweighted so that they only perform the very essential task they were conceived to. More complex devices on their side, should be capable of adapting during run-time.Error Detection and Recovery: Wireless links and battery-powered devices are the focus of a number of issues on embedded networks, such as com- munication problems, which can be corrected by the network protocol, or even node failures, which can be solved by means of introducing redundant hardware.End-User Programming: In order to achieve the so-desired mass market for embedded networks, it is ﬁrst necessary to ease the entire process of instal- lation and conﬁguration of the devices, allowing the average non-expert ﬁnal user to buy, install, conﬁgure, re-conﬁgure, program, extend, monitor, or remove 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-based interfaces along with the introduction of semantic information (for the back- end systems to understand the data sent by the sensors) are needed.
3.3 eSOAEmbedded networks can take advantage of traditional SOA’s beneﬁts, 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 .Data-Driven Services: Unlike traditional SOAs which are based on a request- response message pattern, most of embedded applications are data-driven in a way that sensors acquire data on a periodic fashion and send it to connected services, which process it and produce new data that is sent to the next service in the so-called process chain.Service Life Cycle: Commonly, in traditional SOAs web services instances are not shared, so changes occurred in one instance are invisible to other ap- plications. As a contrast, in the world of embedded networks, services are frequently used simultaneously by multiple applications, thus, requiring the services states to be shared.Resource Constraints: Traditional SOAs normally rely on robust hardware infrastructures, supplying enough CPU cycles, memory, bandwidth, battery power, etc. so that web services run with few limitations. In contrast, embed- ded networks are typically characterized by relying on small devices, which are quite limited both in processing and storage capabilities. Because of this, the eﬃciency 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 classiﬁedinto 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 , which analysis and study isthe main objective of this article. , , , and , are all articles writtenby the same authors on the eSOA topic oﬀering a chronological evolution oftheir research activity on the ﬁeld. 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 ﬁeld of SOAs for embedded systems, so that the reader can get awider perspective on the current status of the ﬁeld.
3.4 eSOA Middleware Design PrinciplesAs explained by the authors themselves, the middleware proposed in  is basedon the 3-layers embedded networks hierarchy depicted in Figure 10. Each layercorresponds to a diﬀerent view. Next, let us comment on all of them in moredetailed.Abstract Infrastructure Layer: This layer provides a uniﬁed model of the underlying hardware components (nodes) and a serie of 1-hop network con- nections between nodes (links). Nodes can be classiﬁed into two types: pro- grammable nodes - those capable of executing arbitrary code - (gray boxes) and non-programmable nodes - those with limited conﬁguration 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 network protocols, include a number of properties modeling the transport medium and the communications characteristics.Service Layer: This layer provides a service-oriented view of the underlying sensors/actuators. Each sensor/actuator is mapped to a diﬀerent 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 (speciﬁed by the manufacturer and the 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/orientation of 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 ﬁelds depend heavily on speciﬁc applications, the proposed middleware makes no assumptions regarding the existence of such metadata. Instead, the middleware provides ﬁltering algorithms so that the ﬁnal user can extract, monitor, and conﬁgure a subset of nodes that ﬁt a speciﬁc criteria.Application Layer: This layer provides an overview of the installed applica- tions, the involved services instances, as well as of the information exchanged between instances. It is responsible for controlling and monitoring the appli- cations running within the system at any time. Moreover, it also provides an application patterns repository that facilitates the installation and conﬁgura- tion of applications. An application pattern is a description of an application as a composition of abstract services (slots) described in terms of metadata and the data connections between them. At run-time, the abstract services of an application pattern are matched against the available hardware services and logic services stored in the service repository, so that it can be deter- mined whether or not that speciﬁc application can be installed. There are three diﬀerent cases when installing a new application. First, the mapping of services to slots is unambiguous, allowing the automatic installation of the
application. Second, the mapping of services to slots is ambiguous, so that the user has to manually select the appropriate service candidate (among the diﬀerent options) for a speciﬁc slot. Third, not all slots in the pattern can be ﬁlled, case in which the user is provided with a “shopping list” that includes the necessary hardware devices for that speciﬁc application. Fig. 10. Embedded Networks Layers Architecture.The process of installing a new application consists of three steps: pattern ﬁlling,service placement and code generation.1. Pattern Filling: Consists of the selection of a pattern and the assignment of available and suitable services to all of the involved slots.2. Service Placement: The middleware optimizes the mapping of services to physical nodes, according to certain parameters of interest, such as an ho- mogeneous resource utilization on all nodes, or the minimization of network load.3. Code Generation: Includes the generation of platform-speciﬁc code for the targeted 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 eﬃcient service imple- mentation. Finally, the services are instantiated and conﬁgured according to the information available in the application pattern.
3.5 eSOA Middleware ImplementationIn this section we will analyze and study the implementation details of the pro-totypical eSOA middleware proposed in . As described in , “the resultof [the] code generation [...] is an optimized, tailored middleware with embed-ded and already conﬁgured services that implement the application logic. Themain task of the middleware is to connect the diﬀerent 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: eﬃcient 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 Eﬃcient Distributed Data ProcessingDue to strict CPU, memory, bandwidth, and battery limitations, it is essential forthe proposed middleware to eﬃciently collect, process, and distribute data. Thisis achieved by means of generating eﬃcient platform-speciﬁc code, together withan event-based data processing, as well as a distributed execution of applications.Eﬃcient Platform-Speciﬁc Code Generation: Thanks to the model-based code generation the middleware is capable of dealing with heterogeneous underlying 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 ﬂow at the application level. All the conﬁg- 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 reconﬁgured during run-time . The Network element, on its side, is in charge of the data routing as well as of handling with the physical communications. On the other hand, the Node Manager implements the service life cycle management, including the service announcements. The key idea here is that services are mapped into the speciﬁc platform by means of generating a service stub. Services are easily mapped into any other platform that provides the necessary compiler. Furthermore, the middleware functionality can be scaled down to only that strictly needed on a speciﬁc node.Event-Based Data Processing: When it comes to embedded networks, data is frequently acquired, transmitted, and processed at periodic intervals. In order to maximize the energetic eﬃciency of the system, a number of strate- gies, many of which are already contemplated by e-OSs (operating systems for embedded devices), can be applied, such as putting the CPU to sleep mode, or even turning oﬀ the sensor hardware during the inactivity periods in which the sensor is on idle state. The middleware under study supports this feature by providing an event-based processing model, in which the execution of application logic can be triggered in three diﬀerent ways: peri- odically, by incoming data, or due to environmental changes.Distributed Execution of Applications: In order to optimize the execution of applications, eSOA allows hardware-independent eServices, i.e. commonly all logic services, to be allocated at any programmable node. This approach improves aspects such as resource utilization, reliability, responsiveness, etc. Communications between eServices may include both simple or complex data types. The key idea at this point is that the proposed middleware intention- ally only provides data binding interfaces for XML-schema simple types  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. This strategy of storing the metadata descriptions of the speciﬁcation of both the representation and meaning of simple data types on the nodes them- selves, allows to reduce the transmitted data, to only the raw data payload if only simple types are involved, optimizing the bandwidth usage. The unique downside is that, obviously now, transmitted data is not self-descriptive any- more. There are two ways of dealing with this. The ﬁrst option is checking the compatibility between connected inputs and outputs during the process of service composition, which can be automated thanks to the metadata de- scriptions. The second option, not recommended for CPU-limited nodes, is inspecting the metadata description of the corresponding output so that the data type of the incoming data stream can be dynamically inferred.3.5.2 Metadata-Aided Service CompositionThe 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 of the suggested middleware, an intuitive end-user programming interface is provided. The average non-expert user will have a good understanding of the application domain, but little to no knowledge about implementation details, such as the installed hardware and software, and the used middle- ware. The proposed end-user programming interface allows the user to easily chose the most suitable application pattern from a repository of pre-existing pat- terns compatible with his/her hardware. Once a speciﬁc pattern has been chosen, the user can assign hardware services, among those available, to the slots deﬁned by the selected pattern on a drag-and-drop fashion. Finally, the user can also select the required logic services from a list of services with compatible metadata. The key idea is that all of the user’s selections are based uniquely on domain knowledge, which is represented in the metadata description. In the case of more experienced users with some basic understanding of the data types and services properties, it is possible to develop their own appli- cation patterns, which can be even published and shared in the internet with the 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 that application patterns should have only the strictly necessary requirements, so that they are compatible with as many speciﬁc services as possible, while ensuring the functionality of the entire application. Finally, in the case of a programmer, it is possible to develop logic services, just by ﬁlling a generated stub with some application-speciﬁc code. Simple
services, such as a temperature control service, may be composed of basic services – adders, comparators, etc. – so no manual programming is nec- essary at all. On the other hand, more complex services may require some programming. More on the diﬀerent types of users and roles can be found in .(Semi-) Automatic Service Composition: Some application ﬁelds 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, the process of (re-)conﬁguration of every single subnet can be quite tedious. It seems evident that some kind of automation would facilitate such a process. Application patterns allow certain level of automation due to the following reasons. First, changes done in a single installation are easily propagable to other installations, on condition that all of them are based on the same pat- tern. Second, since patterns can be easily inferred by simply inspecting the services available in a particular installation, it is possible to make sugges- tions based on those patterns for new installations. This can be achieved by a “copy & paste” functionality. If there are no ambiguities in the available metadata, the entire process is done automatically. Otherwise, the user has to solve the existing ambiguities.3.5.3 Run-Time AdaptabilityEmbedded networks are frequently dynamic: new nodes can be added at anytime, existing nodes can be reconﬁgured, 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-conﬁguration, 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, reconﬁguration, 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 andconﬁgured 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 ServicesAs 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 ﬁeldsof 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.188.8.131.52 Interaction SchemesThe 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 fourdiﬀerent types of communications:
Continuous Interaction with the Embedded Network: This case occurs when 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 the input of an eService to the output of a WS. Two main advantages are de- rived from the use of subscriptions: low communication overhead and support of non-periodic interactions. Subscriptions can be managed by technologies such as WS-Eventing. Let us now review WS-Eventing in more detail. As explained in , “Web services often want to receive messages when events occur in other services and applications. A mechanism for registering interest is needed because the set of Web services interested in receiving such messages is often unknown in advance or will change over time.” And continues: “This speciﬁcation [WS- Eventing] deﬁnes a protocol for one Web service (called a ”subscriber ”) to register interest (called a ”subscription”) with another Web service (called an ”event source”) in receiving messages about events (called ”notiﬁcations” or ”event messages”). The subscriber may manage the subscription by inter- acting with a Web service (called the ”subscription manager ”) designated by the event source.”Ad-hoc Interaction with the Embedded Network: Unlike in the previous case, in this scenario the interaction between services is not planned before- hand via subscriptions, but spontaneous. This type of communication is based on RPC-style WS invocations. As detailed in , “an RPC [Remote Procedure Call] is initiated by the client, which sends a request message to a known remote server to execute a speciﬁed procedure with supplied param- eters. The remote server sends a response to the client, and the application continues its process.”Continuous Interaction with the External Web Services: Characterized by the necessity of retrieving and/or sending data from/to an external WS on 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 not necessary, and thus not contemplated in the proposed middleware. Since eServices have no knowledge about the speciﬁc wiring, reconﬁgurations of applications are only triggered by either WS end-users or the middleware itself, but never by the eServices themselves.184.108.40.206 IP-compatible AddressingIn order to ensure a seamless integration between the WS and the embeddedworlds, and due to the worldwide extensive use of the Internet Protocol (IP), all the devices in the eSOA world have an IP address, even in those casesin which the underlying network uses a diﬀerent 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.220.127.116.11 Service BridgeAs already commented in section 18.104.22.168, the Service Bridge acts as an interfacebetween the WS world and that of embedded systems, converting incoming andoutgoing messages and providing WSDL  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 of making an eService accessible from the WS world, a WSDL generator creates a WSDL document which contains a description of the eService’s interfaces, including a Notiﬁcation type port for every output as well as a One-way port for every input. The correlation between these ports is conveniently stored in a mapping table. Finally, the newly created WSDL document is made available via a UDDI-based discovery interface, allowing the eService to be searchable by users from the WS world.Ad-hoc Interaction with the Embedded Network: In this scenario, the Service Brigde has to mediate between the WS pull-based request/response invocation scheme and the push-based communication scheme that governs embedded systems. In order to achieve this, the Service Brigde installs a caching 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 last incoming data, received from from the data input. Only in the event of an incoming message arriving to the trigger input, the caching service sends the stored data through the cache output. In conclusion, when a WS requires a measurement from the embedded world, this request arrives to the Service Brigde, which will trigger the necessary measurement at the target service
and send the reply back to the originating WS. The trigger input is thus just a synchronization mechanism.Continuous Interaction with the External Web Services: External WS can be accessed from the embedded world too. In order to achieve this, the WS is represented by a virtual eService, created by the Service Brigde, and which inputs and outputs are created according to the WSDL description of the target WS. An output is created for every Notiﬁcation type port, while an input is created for every One-way port. The correlation between these ports is conveniently stored in a mapping table. When an eService wants to send data to an external WS, it actually sends it to the input of the virtual service, which is running in the Service Brigde node. The Service Brigde intercepts the incoming message, converts it to a SOAP call, and forwards it to the destination WS, which is previously determined by consulting the mapping table. Analogously, incoming SOAP messages are captured by the Service Brigde, which converts them to the corresponding messages in the embedded world, and forwards them to the destination eService through the virtual service output.Ad-hoc Interaction with the External Web Services: As already seen in section 22.214.171.124, this scenario is not supported by the proposed middleware. However, in case it would be needed, it could be mimicked by means of installing 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 HomeOnce we have analyzed the eSOA middleware design principles and implemen-tation on detail, let us ﬁnish this section with a real example of implementationcalled Smart Home. As explained in , 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 oﬀ 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-)conﬁguration, 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-)conﬁguration, or management of thesystem.4 Related Work4.1 IntroductionAs explained in , , and , there are a number of standardized mid-dleware architectures oriented to concrete domains, such as AUTOSAR  forautomotive applications and KNX  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 itdiﬃcult to integrate them with external services. Regarding the ﬁeld of sensor networks, there are also certain middlewarescapable of monitoring them. Two salient examples to be mentioned are TinyDB and Cougar . 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 , RUNES  andMORE . 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 also based on SOA which adopt a diﬀerent approach based on DPWS (, )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 ﬁne 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 brieﬂy 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 AUTOSARAs deﬁned in , 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 GoalsThe main goals of AUTOSAR are: – Implementation and standardization of basic system functions as an OEM wide ”Standard Core” solution – Scalability to diﬀerent 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 oﬀ the shelf hardware” – Software updates and upgrades over vehicle lifetime4.2.2 Key FeaturesThe key features of AUTOSAR are: – Modularity and conﬁgurability – Standardized interfaces – Runtime environment4.2.3 Technical Goals – Modularity – Scalability – Transferability – Re-usability – Standardized interfaces
4.2.4 SoftwareFigure 17 shows the aspect of AUTOSAR software application. Fig. 17. AUTOSAR software application.4.2.5 ArchitectureFigure 18 shows the architecture of AUTOSAR, based upon the concept of onSW-Cs (software components) which encapsulate applications, and have well-deﬁned 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 Software4.3 KNXAs described in , 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 savings4.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 conﬁguration modes (system and easy mode) – Low operating costs resulting in considerable energy savings – Time saving – Flexibility and adaptability to future developments4.4 TinyDBAs deﬁned in  and , TinyDB is “a query processing system for extract-ing information from a network of TinyOS sensors.” The main diﬀerence 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, ﬁlters it, aggregates it together, and routes it out toa PC. TinyDB does this via power-eﬃcient in-network processing algorithms.4.4.1 Goals – Facilitating the programming (no need for low-level code) – Allowing quick development of data-driven applications4.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 display4.4.3 ArchitectureFigure 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 CougarAccording to , 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 oﬄine quering and analysis. The main downsides ofthis approach are the fact that the behaviors of the system cannot be modiﬁedduring 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 eﬃcient 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 network4.6 RUNESNowadays embedded systems constitute a major technological revolution foundin multiple ﬁelds such as smart buildings, industrial automation, power distribu-tion, etc. The resulting applications are more eﬃcient, accurate or cost eﬀective.In order to ensure interoperability of sensors between applications, a commonlanguage for all systems is necessary . As explained in , “the RUNES (Reconﬁgurable 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 market4.6.2 Key Features – Standardised architecture – Self-organisation to suit changeable environments – Adaptive middleware platform – Common language4.6.3 ArchitectureFigure 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-speciﬁc mechanisms, the middlewareAPI, cross-platform components, and hardware abstractions.
Fig. 20. RUNES architecture.4.7 MOREThe 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 diﬀerent wireless standards” .4.7.1 Goals – Provide a SOA-based middleware deployable on the device level – Eﬃcient interactions between humans and embedded systems – Customization to meet speciﬁc needs of diverse organizations – Alleviate heterogeneity of devices4.7.2 Key Features – Simpliﬁed 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 services4.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 SIRENAAs stated in , 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 SOCRADESAccording to , “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 on the Devices Proﬁle for Web Services (DPWS) – for encapsulating intelligence and sensing or actuating skills as services, as well as to specify associated frameworks for management and orchestration of device-level services. – Deﬁnition of a methodology for describing services with semantic mark-up that can be interpreted and processed by agents (Semantic Web Services), for the discovery, selection and composition of resources. – Speciﬁcation of a framework for service-enabled intelligent physical agents.
4.9.2 ArchitectureFigure 22 shows the architecture of SOCRADES. Fig. 22. SOCRADES architecture.4.10 Additional WorksThere are a number of related references that the reader may ﬁnd of interest,some of which are brieﬂy summarized here.  and  are studies about SOAon embedded systems.  gives an overview of the trends and roadmaps onSOA-based embedded networks for industrial automation, while  and  in-troduce SOA-based embedded systems development environments for industrialautomation.  illustrates a practical implementation of SOA for embeddedsystems in the context of harbours automatic management.  refers to theintegration of SOA-ready networked devices in enterprise systems via a cross-layered web service infraestructure, while , , and  introduce Web ServicesBusiness Process Execution Language (BPEL).  suggests a constraint-basedcomponent system for synthesizing scalable software systems, called BOTS. on it side, proposes SOA-toolkits for making embedded systems ready for webservices. On the other hand,  focuses on embedded software system testingbased on SOA for mobile service. Finally,  is a critique of ambient technologyand the all-seeing network of RFID.5 Future WorkOnce we have brieﬂy 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 ,  and  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 diﬀerentservice 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 ﬁeld-level devices and web services, as well as to ﬁnd out ifsuch requirements can be met with existing technologies such as UDDI registriesor query interfaces such as TinyDB.6 ConclusionsWhile 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 ﬁelds 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 oﬀers 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 reconﬁgurable 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 uniﬁed 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 ﬁlling, service placement, and code generation. The eSOA middleware implementation supports the following features: Ef-ﬁcient Distributed Data Processing , including Eﬃcient Platform-SpeciﬁcCode 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 the European Communities, 2009. 4. Autosar, 2010. http://www.autosar.org/. 5. Bpel: Business process execution language speciﬁcations, 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 proﬁles 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 proﬁle 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 ﬁeld: An approach for resource constrained sensor actor networks. In The Fourth Workshop on Service Oriented Architectures in Converging Networked Environments (SOCNE 2009), 2009.44. Gerosa M. Taisch M. Cannata, A. Trends and roadmaps on soa-based embedded networks for industrial automation systems: a review. 13th IFAC Symposium on Information 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 reconﬁgurable component-based approach to networked embedded systems. PIMRC, 2:806–810, 2005.48. T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Pearson Education, Inc, 2009.49. Jonischkat T. Helter, S. Soharbour: Soa for embedded systems. Duisburg Essen University.50. Baecker O. de Souza L. Karnouskos, S. Integration of soaready networked devices in enterprise systems via a crosslayered web service infraestructure. In 12th IEEE Conference on Emerging Technologies and Factory Automation, 2007.
51. Amudson I. Kushwaha, M. Oasis: A programming framework for service-oriented sensor networks. In COMSWARE, 2007.52. Cheol J. Jang O. Lee, M. Embedded software system testing based on soa for mobile 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 for sensor networks. ACM Transactional Database Systems, 30:122–173, 2005.54. E. Ort. Serviceoriented architecture and web services: Concepts, technologies and tools. Technical report, Sun Microsystems, 2005.55. Wu J. Pandey, R. Bots: A constraintbased component system for synthesizing scalable 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 architectures adapted for embedded networks. In Proceedings of the 7th International Conference on Industrial Informatics, 2009.58. Buckl C. Knoll A. Sommer, S. Applying the service oriented paradigm to develop sensor 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 web services and ﬁeld level devices. In International Workshop on the Future Internet of Things and Services Embedded Web Services for Pervasive Devices (at FITS 2009), 2009.60. Y. Sure. The internet of services: Systematic thought leadership for innovative business. Vienna, Austria. May 8th, 2008.61. Doukas G. Koumoutsos G. Thramboulidis, K.C. A soabased embedded systems development for industrial automation. EURASIP Journal on Embedded Systems, 1:., 2008.62. R. Van Kranenburg. The Internet of Things: A Critique of Ambient Technology and the AllSeeing Network of RFID. Institute of Network Cultures, Amsterdam, 2008.63. Gehrke J. Yao, Y. The cougar approach to innetwork query processing in sensor networks. SIGMOD Record, 31 (3):9–18, 2002.64. Bobek. A. Bohn H. Zeeb, E. Ws4d: Soatoolkits making embedded systems ready for web services. In Open Source Software and Productlines 2007 (OSSPL07), 2007.