eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks
Upcoming SlideShare
Loading in...5
×
 

eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks

on

  • 1,241 views

eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks

eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks

Statistics

Views

Total Views
1,241
Views on SlideShare
1,241
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks Document Transcript

  • 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 jamcheca@telefonica.net 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 field, 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 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 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” [45].e-Service: Rowley (2006) [56] defines e-services as: “. . . deeds, efforts 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”, definition that reflects three main components: service provider, service receiver, and the channels of service delivery [8].Web Service: The W3C defines 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 (specifically 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.” [36]. More on web services in [37]. Fig. 1. Web Service ArchitectureWeb services are classified by the W3C [34] 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 identified along the lifecycle of services [45]:
  • 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 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 provider and the customer.Composite Service: Service consisting of two or more atomic or composite services, offering a superior functionality to the end user. It is normally provided by an aggregator, entity responsible for contracting basic services from different 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 (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 documentsWhen 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 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: 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 OverviewThe 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 TermsBefore 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 termsDesign Characteristic: The term design characteristic refers to a specific at- tribute of a body of solution logic documented in a design specification which is expected to be implemented. In the field of service-orientation the usual objective is the creation of design characteristics that are common, very specific, 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 designing solution logic, usually consisting of a set of complementary principles that define 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 defined 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 briefly 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, efficiency, 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 [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 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 Benefits of Service-Oriented ComputingThe 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 Burden2.3.3 Service-Oriented Computing in the Real WorldWeb Services: Nowadays, the technology platform most associated with SOA is Web services, which is defined 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 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 Profile2nd-Generation Web Services Platform (WS-* extensions): Build upon the first-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 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 IntroductionIn [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 ArchitectureArchitectures 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 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 [21].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 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, 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 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 Systems3.1 OverviewTraditionally, 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 RequirementsAccording 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 components from 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 placing the 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 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 first necessary to ease the entire process of instal- lation and configuration of the devices, allowing the average non-expert final user to buy, install, configure, re-configure, 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 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-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 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 PrinciplesAs 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 the underlying 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 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 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 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 fields depend heavily on specific applications, the proposed middleware makes no assumptions regarding the existence of such metadata. Instead, the middleware provides filtering algorithms so that the final user can extract, monitor, and configure a subset of nodes that fit a specific 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 configura- 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 specific application can be installed. There are three different 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 different options) for a specific slot. Third, not all slots in the pattern can be filled, case in which the user is provided with a “shopping list” that includes 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 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-specific 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 efficient service imple- mentation. Finally, the services are instantiated and configured 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 [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 ProcessingDue 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-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 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 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 specific 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 specific 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 efficiency 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 off 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 different 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 [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. This strategy of storing the metadata descriptions of the specification 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 first 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 specific pattern has been chosen, the user can assign hardware services, among those available, to the slots defined 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 specific 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 filling a generated stub with some application-specific 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 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, the process of (re-)configuration 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 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 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 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 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 fourdifferent 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 [39], “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 specification [WS- Eventing] defines 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 ”notifications” 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 [18], “an RPC [Remote Procedure Call] is initiated by the client, which sends a request message to a known remote server to execute a specified 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 specific wiring, reconfigurations of applications are only triggered by either WS end-users or the middleware itself, but never by the eServices themselves.3.5.4.2 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)[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 BridgeAs 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 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 Notification 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 Notification 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 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 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 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 Work4.1 IntroductionAs 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 AUTOSARAs 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 GoalsThe main goals of AUTOSAR are: – Implementation and standardization of basic system functions as an OEM wide ”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 lifetime4.2.2 Key FeaturesThe key features of AUTOSAR are: – Modularity and configurability – 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-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 Software4.3 KNXAs 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 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 configuration modes (system and easy mode) – Low operating costs resulting in considerable energy savings – Time saving – Flexibility and adaptability to future developments4.4 TinyDBAs 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 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 [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 network4.6 RUNESNowadays 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 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-specific 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 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 devices4.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 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 [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 SOCRADESAccording 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 on the Devices Profile 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. – Definition 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. – Specification 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 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 WorkOnce 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 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 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 the European 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 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 reconfigurable 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 field 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.