SlideShare uma empresa Scribd logo
1 de 40
Baixar para ler offline
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), Service
Oriented Computing, Service Placement, Smart Home, SOAP, UDDI, WDSL,
Web Service (WS).


1   Introduction
When thinking of embedded sensor networks, one may think of independent
and isolated industrial systems responsible for the automatization of a number
of tasks. Unlike embedded networks from the past, most of current embedded
sensor networks are expected to interact with the world of web services and the
Internet. Indeed, the demand for this type of integration is increasing as new
business oportunities arise. In any case, the integration of both worlds is not
inmediate and cannot be taken for granted.
    In an attempt to reduce or eliminate this gap, researchers from all over the
world are searching for the best solutions that ensure the interoperability of
embedded sensor networks and traditional web services. One of these approaches
developed by the Computer Science Department at the Technical University
of 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 some
basic 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 as
a 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 some
fundamental 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 goal
of this article. We will first introduce the requirements of embedded networks.
Next, we will comment on the eSOA design principles and the implementation
details. 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, and
SOCRADES.
    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 be
accomplished.
    Finally, section-6 will draw the main conclusions derived from the study
and analysis of the eSOA middleware within the context of embedded sensor
networks.


1.1   The Internet of Things (IoT)

The concept Internet of things (a.k.a. Internet of objects) attributed to the
former Auto-ID Center, based at the MIT in 1999, year of its foundation, refers
to a “self-configuring wireless network of sensors which purpose would be to
interconnect all things” [13]. In order to achieve this, every single human-made
object in the world should be equipped with a unique identifying device (radio
tag) based for example on IPv6, which supports up to 2128 addresses. Because
of the enormous number of simultaneous events, time will no longer be used as
a common and linear dimension. Instead, it will depend on each entity, making
it necessary the management of massive parallel IT systems.
    Certain level of ambient intelligence would also be necessary so that objects
would be capable of, not only pursuing their own goals, but also shared objec-
tives by means of interacting with other objects, while considering the current
environment and circumstances (e.g. food products that record the temperature
along the supply chain, connected cars that would reduce traffic congestion, air
conditioning valves that react to the presence of people, connected trees that
would help reduce deforestation, etc. [3]).
    Regarding the complexity of IoT, three main points are highlighted by the
Commission 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 implemented
in 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 in
restricted networks (intranet of things) or in public ones (internet of things).
    The result would introduce many advantages such as real-time products
stock, location, and movement control, automatic identification and inventory,
etc. The Semantic Web, on its side, offers an alternative based on the idea of
making all things addressable by the existing naming protocols, for example by
means 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 radically
change the way we discover and invoke services“. A more extended definition can
be found in [60], according to which, the Internet of services could be considered
as a “worldwide, trusted service ecosystem of service providers, consumers, and
brokers, buying, selling, repurposing, and composing services for different needs
resulting 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, but
an extension which ultimate objective is removing the classical barriers and in-
efficiencies from service supply and access, so important in nowadays’ service
sector, 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 selling
services.
    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 expected
to include the research, development, design, production, marketing, sales, and
distribution of any specific service. All of these phases contribute to the final
value 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, with
different use policies, etc. All those handicaps have to be solved in a transparent
way for the final user of the “cloud” service. It is the underlying IT perspective,
the responsible for providing the necessary standards, architectures, applications,
and tools to support the business view.

1.3   Types of Services
There are three main types of services:

Business Service: A service, in its traditional sense, can be understood as the
   “non-material” equivalent of a good. In the business arena, a business service
refers to any “business activity provided by a service provider to a 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 Architecture


Web 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 Execution

Two 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 Service




1.5   Atomic Vs Composite Services
According to their complexity, services can be classified into two categories:

Atomic Service: Service that provides a basic functionality to the end user.
   It normally involves a one-on-one relationship between the service 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 the
exchanged data) are first described as abstract entities, and then bound to a
concrete network protocol and message format, making WDSL extensible while
allowing the reuse of these definitions [35].




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


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


1.7   SOAP (Simple Object Access Protocol)

The Simple Object Access Protocol (SOAP) is “a protocol specification
for exchanging structured information in the implementation of web services in
computer networks” [29]. An alternative definition is offered by the W3C when
describing it’s latest version: “SOAP Version 1.2 (SOAP) is a lightweight protocol
intended for exchanging structured information in a decentralized, distributed
environment.” [33]. SOAP forms the foundation layer of a web services protocol
stack, 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 message
negotiation and transmission, such as RPC and HTTP) upon which web services
can be built.
    SOAP can be divided into three main components: an envelope (including
a description of the content and instructions on how to process it), a set of
encoding rules (for expressing datatypes), and a convention (for specifying the
format of both procedure calls and responses).




                            Fig. 4. The SOAP Structure


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

The SOAP processing model: establishes the rules for SOAP messages 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   Overview

The Organization for the Advancement of Structured Information Standard (OA-
SIS ) defines SOA as “a paradigm for organizing and utilizing distributed capa-
bilities that may be under the control of different ownership domains.[...] It
provides a uniform means to offer, discover, interact with and use capabilities to
produce desired effects consistent with measurable preconditions and expecta-
tions.” [1]. In October 2009, the SOA Manifesto Working Group, a group of SOA
practitioners and vendors, published the “SOA Manifesto”, which gives prior-
ity to business value, strategic goals, flexibility, interoperability, shared services
and evolutionary refinement [24]. At present, it is supported by more than 700
signataries worldwide.
2.2   Fundamental Design Terms
Before we focus on SOA in more detail, we need first to cover some basic design
terms that establish a basic taxonomy used throughout this article. Figure 5
illustrates the main modules of a basic design framework, as well as the relation-
ships between them.




                        Fig. 5. Fundamental design terms



Design Characteristic: The term design characteristic refers to a specific at-
   tribute of a body of solution logic documented in a design specification 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 Computing

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

2.3.1 Elements of Service-Oriented Computing

Service-Oriented Architecture: A SOA is an architectural model with 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 Computing

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

 – Increased Intrinsic Interoperability
 – Increased Organizational Agility
 – Increased Business and Technology Alignment
Fig. 6. The individual description documents that can comprise a service contract for
a Web service.


 –   Increased Federation
 –   Increased Vendor Diversification Options
 –   Increased ROI
 –   Reduced IT Burden
2.3.3 Service-Oriented Computing in the Real World


Web Services: Nowadays, the technology platform most associated with 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 Profile
2nd-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 Introduction

In [20], a Service-oriented architecture (SOA) is defined as “a flexible set of
design principles used during the phases of systems development and integration
in computing. A system based on a SOA architecture will package functionality
as a suite of interoperable services that can be used within multiple separate
systems from several business domains.” In [54], Sun Microsystems defines SOA
as “an information technology approach or strategy in which applications make
use of (perhaps more accurately, rely on) services available in a network such
as the World Wide Web.” OASIS on its side defines SOA as “a paradigm for
organizing and utilizing distributed capabilities that may be under the control
of 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 applications
using multiple implementation platforms. A service is a software resource with
an externalized description available for searching, binding, and invocation by a
service 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 defined
in terms of protocols and functionality. The way the client of a service (which
can be another service) communicates with the service does not depend on the
implementation of the service. This is usually referred to as loose coupling. A
service can provide both a single discrete function or a set of related functions.
Also, services can be combined into aggregated or composite services that satisfy
more complex requirements. To sum up, a SOA is “an approach to connecting
applications (exposed as services) so that they can communicate with (and take
advantage 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: the
more complex the services, the less interfaces needed but the less reusable, and
viceverse.

2.4.2 Architecture

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

Elements of SOA

Figure 7 shows the tree-based relationship schema between SOA, services, im-
plementations, interfaces, and data.
SOA Meta Model
Fig. 7. Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama.


Figure 8 presents the SOA meta-model which is an abstraction of a SOA struc-
tured into a number of layers. A more detailed model, shown in Figure 9 is
available 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 Principles

SOA is based upon a number of specific principles, necessary for its develop-
ment, maintenance, and usage. [27] enumerates the following eight principles as
mandatory 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 in
literature:

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 and
SOA in [38] and [46].


3     e-SOA: SOA for Embedded Systems
3.1   Overview
Traditionally, many devices were designed to work as isolated embedded sys-
tems [43]. As already commented in the introduction of this article, nowadays
the 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. Internet
of objects), which purpose is to interconnect all things [13]. The service-oriented
paradigm, based upon the Service-Oriented Architecture (SOA), explained in the
previous section, is the most extended and widely adopted strategy for imple-
menting complex, heterogeneous, and large IT systems worldwide, mostly based
on 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 for
network-enabled hardware devices. In this section we will introduce the main
characteristics that make embedded systems different from WS-based systems.
Also, we will analyze different existing approaches to save the gap between both
words: the world of web services and the world of embedded services.
3.2   Embedded Networks Requirements
According to [10], an embedded system is “a computer system designed to per-
form one or a few dedicated functions often with real-time computing constraints
[. . . ] embedded as part of a complete device often including hardware and me-
chanical parts.” An embedded network is a network composed of embedded
systems, which can be very diverse both in hard- and software components.
Throughout this article, when we talk about embedded networks we will refer to
embedded sensor-actor networks, this is, those used in control and automation
tasks. Following, there is a list of requirements for embedded networks, available
in [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   eSOA
Embedded networks can take advantage of traditional SOA’s benefits, discussed
in section 2.4.3 in order to meet some of the requirements commented in section
3.2. However, and as we already mentioned, traditional SOA (based on web
services) cannot be applied directly to the world of embedded networks, but
some 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 classified
into sensor-eServices (producing data), logic-eServices (processing data), and
actuator-eServices (consuming data). The communication model used by e-
Services is based on the concept of data stream, which is a sequence of data
packets 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 programmable
control devices, are independent of the concrete hardware implementation.
    Once we have seen an overview of eSOA, let us now focus on a particular
implementation, to be concrete, that covered in [57], which analysis and study is
the main objective of this article. [58], [43], [57], and [59], are all articles written
by the same authors on the eSOA topic offering a chronological evolution of
their research activity on the field. In the next two sections we will analyze
the authors’ proposal: an eSOA middleware. Section 3.4 explains the design
principles of such a middleware, while section 3.5 focuses on its implementation.
Additionally, we will comment on other proposals and projects by other research
groups in the field of SOAs for embedded systems, so that the reader can get a
wider perspective on the current status of the field.
3.4   eSOA Middleware Design Principles

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

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 Implementation
In this section we will analyze and study the implementation details of the pro-
totypical eSOA middleware proposed in [57]. As described in [58], “the result
of [the] code generation [...] is an optimized, tailored middleware with embed-
ded and already configured services that implement the application logic. The
main 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 the
middleware 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, metadata
aided service composition, run-time adaptability, and integration with external
services. Let us now review all of these aspects.




                          Fig. 11. Network Architecture.


3.5.1 Efficient Distributed Data Processing

Due to strict CPU, memory, bandwidth, and battery limitations, it is essential for
the proposed middleware to efficiently collect, process, and distribute data. This
is achieved by means of generating efficient platform-specific code, together with
an 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 Composition

The metadata-based description of services, commented above, introduces two
additional 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 Adaptability

Embedded networks are frequently dynamic: new nodes can be added at any
time, existing nodes can be reconfigured, become temporarily unavailable, or
even removed, mobile nodes can enter and leave the network, etc. The proposed
middleware provides a discovery mechanism based on the (semi-)automatic ser-
vice composition, which is capable of integrating the hardware on the newly
discovered node with the running applications.
    Regarding the failures of nodes, there are two ways in which they can be
managed: locally or globally. Local recovery is possible only when redundant
eServices and/or communication channels are available to replace those with
failure. 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 failed
node. 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 new
eServices 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 operating
system. 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 be
instantiated and started. In any case, the new service instance is started and
configured as required by the application itself. In the event of an application
removal, all those services used only by that application are conveniently shut
down and de-installed, facilitating the maintenance of the services repository.

3.5.4 Integration with External Services

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




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



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

3.5.4.1 Interaction Schemes

The mediation between both worlds is performed by a Service Bridge (gateway),
responsible for converting incoming and outgoing messages, as well as for pro-
viding WSDL interfaces for eServices. The Service Bridge must support four
different 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 Addressing

In order to ensure a seamless integration between the WS and the embedded
worlds, 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 cases
in which the underlying network uses a different addressing scheme. The Service
Bridge is responsible for monitoring all incoming messages at the Network Layer.
When an incoming message is targeted at a certain eService, it is conveniently
translated into the suitable packet format and forwarded to the corresponding
eService. An illustrative example is depicted in Figure 14. The incoming WS
message is translated into the ZigBee protocol by means of analyzing the WSDL
description.




                             Fig. 14. Service Bridge.


3.5.4.3 Service Bridge

As already commented in section 3.5.4.1, the Service Bridge acts as an interface
between the WS world and that of embedded systems, converting incoming and
outgoing messages and providing WSDL [41] interfaces for eServices. Let us now
analyze in more detail the translation process realized by the Service Bridge for
all 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 that
it is independent of services, so that no changes are needed when new services
are added to the system.

3.6 eSOA Middleware Example: Smart Home

Once we have analyzed the eSOA middleware design principles and implemen-
tation on detail, let us finish this section with a real example of implementation
called Smart Home. As explained in [43], one of the most salient and demanded
applications of embedded networks is building automation. While in the in-
dustrial and business arena there is an notorious and increasing demand for
systems that automate part of the common activities, building automation has
not 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 Home
is reducing installation costs, by facilitating the installation process so that end
users themselves can setup their own automated systems at home.
    A Smart Home demonstrator is depicted in Figure 15. The system consists
of a power supply, a battery, two lights, a refrigerator, and a phone. All of these
elements are thought of as they would exist in a future home. Another advantage
of Smart Home is the fact that it is designed to save energy. It is assumed that
future 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 the
battery, the system can switch from one to the other as pleased. It is well known
that 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 when
price is high, so that the householders save money in their monthly bills. When
the prices are low again, the system automatically switches again to the power
supply. Of course, it is taken for granted that the energy would be obtained from
the 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 temperature
threshold 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 from
the 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 to
facilitate 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 with
some graphical tools. For instance, the electricity prices can be retrieved from
the 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 the
system.


4     Related Work
4.1   Introduction
As explained in [43], [57], and [59], there are a number of standardized mid-
dleware architectures oriented to concrete domains, such as AUTOSAR [4] for
automotive 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 processing
paradigm is not compatible with that of service-oriented systems, making it
difficult to integrate them with external services.
    Regarding the field of sensor networks, there are also certain middlewares
capable of monitoring them. Two salient examples to be mentioned are TinyDB
[53] and Cougar [63]. The main disadvantage of these systems are the potential
bottlenecks and the single points of failure for those control-oriented applications
consisting of multiple sensors and actuators. This is due to their hierarchical
network structure, since the amount of necessary data increases as we ascend
from level to level within the hierarchy.
    In relation to SOA, there are other projects, apart from the middleware
proposed in this article, which also take advantage of this approach for embedded
networks. Some of the most representative are OASIS [51], RUNES [47] and
MORE [16]. The main drawback of these projects is that they do not support
neither the generation of tailored code nor the optimization of the placement of
services. As a direct consequence, unlike the suggested eSOA middleware, they
do 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 accessible
from the WS world. The main weakness of such approach is the fact that, even
when 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 overhead
introduced by the WS technologies and protocols.
    Once we have briefly commented on the most relevant projects related to the
eSOA-based middleware object of this article, let us now study in more detail
each of them. Since an extensive analysis of these projects is out of the scope
of this work, we will make only a brief introduction to each of them so that it
serves as a general overview.

4.2     AUTOSAR
As defined in [4], AUTOSAR (AUTomotive Open System ARchitecture) is “an
open and standardized automotive software architecture, jointly developed by
automobile manufacturers, suppliers and tool developers.” AUTOSAR supports
all vehicle domains and will serve as a platform standard upon which future
vehicle applications will be implemented, minimizing current barriers between
functional domains.

4.2.1 Goals

The 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 lifetime

4.2.2 Key Features

The key features of AUTOSAR are:

 – Modularity and configurability
 – Standardized interfaces
 – Runtime environment

4.2.3 Technical Goals

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

Figure 17 shows the aspect of AUTOSAR software application.




                     Fig. 17. AUTOSAR software application.



4.2.5 Architecture

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

The AUTOSAR architecture consists of the following elements:

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


4.3    KNX

As described in [15], KXN is the “worldwide standard for all applications in
home 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 existing
home and buildings.”

4.3.1 Goals

 – Convenience
 – Safety
 – Energy savings

4.3.2 Key Features

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

4.4    TinyDB
As defined in [53] and [32], TinyDB is “a query processing system for extract-
ing information from a network of TinyOS sensors.” The main difference be-
tween TinyDB and other solutions for data processing in TinyOS is the fact
that TinyDB does not require the programmer to write embedded C code for
sensors but it provides a simple SQL-like interface to specify the data to be
extracted, along with additional parameters. TinyDB collects that data from
motes in the environment, filters it, aggregates it together, and routes it out to
a PC. TinyDB does this via power-efficient in-network processing algorithms.

4.4.1 Goals

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

4.4.2 Key Features

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

4.4.3 Architecture

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




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

4.5.1 Key Features
 – Query optimizer: generates an efficient query plan for in-network query pro-
   cessing
 – Reduction of resources usage
 – Extended life of sensors
 – Queries expressed in declarative language
 – Independence from the underlying physical network

4.6     RUNES
Nowadays embedded systems constitute a major technological revolution found
in 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 common
language 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, widely
distributed, heterogeneous networked embedded systems that interoperate and
adapt to their environments.”

4.6.1 Goals
 –    Simplify the programming
 –    Simplify the application creation process
 –    Cut the costs of new applications development
 –    Fasten the time to market
4.6.2 Key Features
 –    Standardised architecture
 –    Self-organisation to suit changeable environments
 –    Adaptive middleware platform
 –    Common language
4.6.3 Architecture

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


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

4.7.1 Goals

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

4.7.2 Key Features

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

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




                          Fig. 21. MORE architecture.




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

4.9   SOCRADES
According to [31], “the SOCRADES project is a European research and advanced
development project. Its primary objective is to develop a design, execution and
management platform for next-generation industrial automation systems, ex-
ploiting the Service Oriented Architecture paradigm both at the device and at
the 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 Architecture

Figure 22 shows the architecture of SOCRADES.




                        Fig. 22. SOCRADES architecture.




4.10   Additional Works

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


5   Future Work

Once we have briefly introduced the main projects related to the eSOA middle-
ware focus of this article, let us now comment on the eSOA authors’ ongoing
work. As discussed in [57], [43] and [59] there are a number of possible improve-
ments to the proposed platform.
    Fist, the application execution can be improved by applying data stream
management technologies. Second, there is the need for evaluating different
service placement strategies. Third, it may be interesting researching ways to
achieve the automatic learning of service patterns based on a repository of ex-
isting applications. Forth, the development of application level connectivity at
the routing layer is necessary for routing optimization with low overhaead for
protocols and routing tables. Fifth, the enrichment of the semantic descriptions
of services would allow obtaining metrics that may allow to select the most
suitable service out of a service repository. Sixth, further research has to be ac-
complished regarding the requirements of an intuitive interface for the discovery
and integration of field-level devices and web services, as well as to find out if
such requirements can be met with existing technologies such as UDDI registries
or query interfaces such as TinyDB.


6   Conclusions

While traditionally many devices were designed to work as isolated embedded
systems, nowadays the trend is to connect and integrate daily-life devices into
distributed 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 for
systems capable for dealing with both worlds is rapidly increasing, specially in
the fields of automotive, factory automation, and building management, in part,
as a consequence of the ongoing decline in prices for network-enabled hardware
devices.
    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, mostly
based on web services. The SOA paradigm offers numerous advantages such
as 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, and
bridging - traditional SOA cannot be applied directly to them.
    There are several research projects which attempt to integrate the worlds
of embeddded sensor networks and that of web services. One of these projects,
developed by the Computer Science Department at the Technical University of
Munich, and focus of this article, proposes a SOA-based middleware for em-
bedded networks called eSOA, which architecture consists of three layers. The
Abstract Infrastructure Layer provides a unified model of the underlying
hardware 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 of
the installed applications, the involved services instances, as well as of the infor-
mation exchanged between instances. The process of installing a new application
consists 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-Specific
Code Generation, Event-Based Data Processing, and Distributed Execution of
Applications, Metadata-Aided Service Composition, including End-user
Programming and (Semi-) Automatic Service Composition, Run-Time Adapt-
ability , as well as Integration with External Services, including support for
continuous/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, further
research 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.

Mais conteúdo relacionado

Mais procurados

Hardware/Software Interoperability and Single Point Vulnerability Problems of...
Hardware/Software Interoperability and Single Point Vulnerability Problems of...Hardware/Software Interoperability and Single Point Vulnerability Problems of...
Hardware/Software Interoperability and Single Point Vulnerability Problems of...BRNSS Publication Hub
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMijwmn
 
Security Aspects of the Information Centric Networks Model
Security Aspects of the Information Centric Networks ModelSecurity Aspects of the Information Centric Networks Model
Security Aspects of the Information Centric Networks ModelCSCJournals
 
Study and analysis of mobility, security, and caching issues in CCN
Study and analysis of mobility, security,  and caching issues in CCN Study and analysis of mobility, security,  and caching issues in CCN
Study and analysis of mobility, security, and caching issues in CCN IJECEIAES
 
March 2021: Top 10 Read Articles in Network Security and Its Applications
March 2021: Top 10 Read Articles in Network Security and Its ApplicationsMarch 2021: Top 10 Read Articles in Network Security and Its Applications
March 2021: Top 10 Read Articles in Network Security and Its ApplicationsIJNSA Journal
 
Does the Convergence of the Blockchain, the Internet of Things and Artificial...
Does the Convergence of the Blockchain, the Internet of Things and Artificial...Does the Convergence of the Blockchain, the Internet of Things and Artificial...
Does the Convergence of the Blockchain, the Internet of Things and Artificial...eraser Juan José Calderón
 
Security and privacy issues and solutions of Mobile Cloud Computing
Security and privacy issues and solutions of Mobile Cloud ComputingSecurity and privacy issues and solutions of Mobile Cloud Computing
Security and privacy issues and solutions of Mobile Cloud ComputingTahmin Aysha Murshed
 
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...Cisco Service Provider Mobility
 
Open Source Platforms Integration for the Development of an Architecture of C...
Open Source Platforms Integration for the Development of an Architecture of C...Open Source Platforms Integration for the Development of an Architecture of C...
Open Source Platforms Integration for the Development of an Architecture of C...Eswar Publications
 
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...Rida Qayyum
 
An Event-based Middleware for Syntactical Interoperability in Internet of Th...
An Event-based Middleware for Syntactical Interoperability  in Internet of Th...An Event-based Middleware for Syntactical Interoperability  in Internet of Th...
An Event-based Middleware for Syntactical Interoperability in Internet of Th...IJECEIAES
 
Toward social internet of vehicles concept architecture, and applications
Toward social internet of vehicles  concept architecture, and applicationsToward social internet of vehicles  concept architecture, and applications
Toward social internet of vehicles concept architecture, and applicationsredpel dot com
 
Lightweight IoT middleware for rapid application development
Lightweight IoT middleware for rapid application developmentLightweight IoT middleware for rapid application development
Lightweight IoT middleware for rapid application developmentTELKOMNIKA JOURNAL
 
May 2021: Top 10 Read Articles in Network Security and Its Applications
May 2021: Top 10 Read Articles in Network Security and Its ApplicationsMay 2021: Top 10 Read Articles in Network Security and Its Applications
May 2021: Top 10 Read Articles in Network Security and Its ApplicationsIJNSA Journal
 
IRJET - Cloud Computing and IoT Convergence
IRJET -  	  Cloud Computing and IoT ConvergenceIRJET -  	  Cloud Computing and IoT Convergence
IRJET - Cloud Computing and IoT ConvergenceIRJET Journal
 
June 2021 - Top 10 Read Articles in Network Security and Its Applications
June 2021 - Top 10 Read Articles in Network Security and Its ApplicationsJune 2021 - Top 10 Read Articles in Network Security and Its Applications
June 2021 - Top 10 Read Articles in Network Security and Its ApplicationsIJNSA Journal
 
Truzzt box 3.2-en
Truzzt box 3.2-enTruzzt box 3.2-en
Truzzt box 3.2-enh-bauer2014
 
Security aspects-of-mobile-cloud-computing
Security aspects-of-mobile-cloud-computingSecurity aspects-of-mobile-cloud-computing
Security aspects-of-mobile-cloud-computingSHREYASSRINATH94
 
The Weakest Point of Security in IoT
The Weakest Point of Security in IoTThe Weakest Point of Security in IoT
The Weakest Point of Security in IoTnsangary
 
Opportunistic cyberphysical services: A novel paradigm for the future Interne...
Opportunistic cyberphysical services: A novel paradigm for the future Interne...Opportunistic cyberphysical services: A novel paradigm for the future Interne...
Opportunistic cyberphysical services: A novel paradigm for the future Interne...Universita della Calabria,
 

Mais procurados (20)

Hardware/Software Interoperability and Single Point Vulnerability Problems of...
Hardware/Software Interoperability and Single Point Vulnerability Problems of...Hardware/Software Interoperability and Single Point Vulnerability Problems of...
Hardware/Software Interoperability and Single Point Vulnerability Problems of...
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
 
Security Aspects of the Information Centric Networks Model
Security Aspects of the Information Centric Networks ModelSecurity Aspects of the Information Centric Networks Model
Security Aspects of the Information Centric Networks Model
 
Study and analysis of mobility, security, and caching issues in CCN
Study and analysis of mobility, security,  and caching issues in CCN Study and analysis of mobility, security,  and caching issues in CCN
Study and analysis of mobility, security, and caching issues in CCN
 
March 2021: Top 10 Read Articles in Network Security and Its Applications
March 2021: Top 10 Read Articles in Network Security and Its ApplicationsMarch 2021: Top 10 Read Articles in Network Security and Its Applications
March 2021: Top 10 Read Articles in Network Security and Its Applications
 
Does the Convergence of the Blockchain, the Internet of Things and Artificial...
Does the Convergence of the Blockchain, the Internet of Things and Artificial...Does the Convergence of the Blockchain, the Internet of Things and Artificial...
Does the Convergence of the Blockchain, the Internet of Things and Artificial...
 
Security and privacy issues and solutions of Mobile Cloud Computing
Security and privacy issues and solutions of Mobile Cloud ComputingSecurity and privacy issues and solutions of Mobile Cloud Computing
Security and privacy issues and solutions of Mobile Cloud Computing
 
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...
MTC: When Machines Communicate (A New Hot Topic Taking Over the Industry) - a...
 
Open Source Platforms Integration for the Development of an Architecture of C...
Open Source Platforms Integration for the Development of an Architecture of C...Open Source Platforms Integration for the Development of an Architecture of C...
Open Source Platforms Integration for the Development of an Architecture of C...
 
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...
A Critical Survey on Privacy Prevailing in Mobile Cloud Computing: Challenges...
 
An Event-based Middleware for Syntactical Interoperability in Internet of Th...
An Event-based Middleware for Syntactical Interoperability  in Internet of Th...An Event-based Middleware for Syntactical Interoperability  in Internet of Th...
An Event-based Middleware for Syntactical Interoperability in Internet of Th...
 
Toward social internet of vehicles concept architecture, and applications
Toward social internet of vehicles  concept architecture, and applicationsToward social internet of vehicles  concept architecture, and applications
Toward social internet of vehicles concept architecture, and applications
 
Lightweight IoT middleware for rapid application development
Lightweight IoT middleware for rapid application developmentLightweight IoT middleware for rapid application development
Lightweight IoT middleware for rapid application development
 
May 2021: Top 10 Read Articles in Network Security and Its Applications
May 2021: Top 10 Read Articles in Network Security and Its ApplicationsMay 2021: Top 10 Read Articles in Network Security and Its Applications
May 2021: Top 10 Read Articles in Network Security and Its Applications
 
IRJET - Cloud Computing and IoT Convergence
IRJET -  	  Cloud Computing and IoT ConvergenceIRJET -  	  Cloud Computing and IoT Convergence
IRJET - Cloud Computing and IoT Convergence
 
June 2021 - Top 10 Read Articles in Network Security and Its Applications
June 2021 - Top 10 Read Articles in Network Security and Its ApplicationsJune 2021 - Top 10 Read Articles in Network Security and Its Applications
June 2021 - Top 10 Read Articles in Network Security and Its Applications
 
Truzzt box 3.2-en
Truzzt box 3.2-enTruzzt box 3.2-en
Truzzt box 3.2-en
 
Security aspects-of-mobile-cloud-computing
Security aspects-of-mobile-cloud-computingSecurity aspects-of-mobile-cloud-computing
Security aspects-of-mobile-cloud-computing
 
The Weakest Point of Security in IoT
The Weakest Point of Security in IoTThe Weakest Point of Security in IoT
The Weakest Point of Security in IoT
 
Opportunistic cyberphysical services: A novel paradigm for the future Interne...
Opportunistic cyberphysical services: A novel paradigm for the future Interne...Opportunistic cyberphysical services: A novel paradigm for the future Interne...
Opportunistic cyberphysical services: A novel paradigm for the future Interne...
 

Destaque

Web Services Composition Optimizer (WSCOv1.0)
Web Services Composition Optimizer (WSCOv1.0)Web Services Composition Optimizer (WSCOv1.0)
Web Services Composition Optimizer (WSCOv1.0)Juan Antonio Martin Checa
 
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's Interface
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's InterfaceWeb Sites UI Taxonomy & Design: An Analysis on Web Sites User's Interface
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's InterfaceJuan Antonio Martin Checa
 
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...Juan Antonio Martin Checa
 
awSOA: Agents-based SOA for Wireless Sensor & Actor Networks
awSOA: Agents-based SOA for Wireless Sensor & Actor NetworksawSOA: Agents-based SOA for Wireless Sensor & Actor Networks
awSOA: Agents-based SOA for Wireless Sensor & Actor NetworksJuan Antonio Martin Checa
 
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...Juan Antonio Martin Checa
 

Destaque (11)

smartSpeed: online meeting tools
smartSpeed: online meeting toolssmartSpeed: online meeting tools
smartSpeed: online meeting tools
 
Web Services Composition Optimizer (WSCOv1.0)
Web Services Composition Optimizer (WSCOv1.0)Web Services Composition Optimizer (WSCOv1.0)
Web Services Composition Optimizer (WSCOv1.0)
 
HMSSC - User\'s Manual
HMSSC - User\'s ManualHMSSC - User\'s Manual
HMSSC - User\'s Manual
 
Tactile Interfaces: Past, Present & Future
Tactile Interfaces: Past, Present & FutureTactile Interfaces: Past, Present & Future
Tactile Interfaces: Past, Present & Future
 
Weaving Variability into Domain Metamodels
 Weaving Variability into Domain Metamodels Weaving Variability into Domain Metamodels
Weaving Variability into Domain Metamodels
 
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's Interface
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's InterfaceWeb Sites UI Taxonomy & Design: An Analysis on Web Sites User's Interface
Web Sites UI Taxonomy & Design: An Analysis on Web Sites User's Interface
 
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...
The Sokoban Challenge: An Analysis on Past, Present, and Trends in Algorithms...
 
Model-Driven Software Verification
Model-Driven Software VerificationModel-Driven Software Verification
Model-Driven Software Verification
 
awSOA: Agents-based SOA for Wireless Sensor & Actor Networks
awSOA: Agents-based SOA for Wireless Sensor & Actor NetworksawSOA: Agents-based SOA for Wireless Sensor & Actor Networks
awSOA: Agents-based SOA for Wireless Sensor & Actor Networks
 
HMSSC
HMSSCHMSSC
HMSSC
 
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...
eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Ne...
 

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

Standardization Of The Itu Telecommunications...
Standardization Of The Itu Telecommunications...Standardization Of The Itu Telecommunications...
Standardization Of The Itu Telecommunications...Brenda Torres
 
Toward a real time framework in cloudlet-based architecture
Toward a real time framework in cloudlet-based architectureToward a real time framework in cloudlet-based architecture
Toward a real time framework in cloudlet-based architectureredpel dot com
 
Фреймворк промышленного интернета
Фреймворк промышленного интернетаФреймворк промышленного интернета
Фреймворк промышленного интернетаSergey Zhdanov
 
Understanding Architecture of Internet of Things
Understanding Architecture of Internet of ThingsUnderstanding Architecture of Internet of Things
Understanding Architecture of Internet of ThingsIJSRED
 
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdfA_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf12rno
 
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...Universita della Calabria,
 
What Is Openstack And Its Importance
What Is Openstack And Its ImportanceWhat Is Openstack And Its Importance
What Is Openstack And Its ImportanceLorie Harris
 
internet architecture.pdf
internet architecture.pdfinternet architecture.pdf
internet architecture.pdfqhawengcongo
 
Seminar on Intelligent Personal Assistant based on Internet of Things approach
Seminar on Intelligent Personal Assistant based on Internet of Things approachSeminar on Intelligent Personal Assistant based on Internet of Things approach
Seminar on Intelligent Personal Assistant based on Internet of Things approachKarthic C M
 
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...IJCNCJournal
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMijwmn
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMijwmn
 
Middleware Framework For Streaming Data Essay
Middleware Framework For Streaming Data EssayMiddleware Framework For Streaming Data Essay
Middleware Framework For Streaming Data EssayLissette Hartman
 
IoT Challenges: Technological, Business and Social aspects
IoT Challenges: Technological, Business and Social aspectsIoT Challenges: Technological, Business and Social aspects
IoT Challenges: Technological, Business and Social aspectsRoberto Minerva
 
May 2022: Most Download Articles in Web & Semantic Technology
May 2022: Most Download Articles in Web & Semantic TechnologyMay 2022: Most Download Articles in Web & Semantic Technology
May 2022: Most Download Articles in Web & Semantic Technologydannyijwest
 
Mobile Wireless Network Essay
Mobile Wireless Network EssayMobile Wireless Network Essay
Mobile Wireless Network EssaySusan Myers
 
Semantic Technologies for the Internet of Things: Challenges and Opportunities
Semantic Technologies for the Internet of Things: Challenges and Opportunities Semantic Technologies for the Internet of Things: Challenges and Opportunities
Semantic Technologies for the Internet of Things: Challenges and Opportunities PayamBarnaghi
 
A survey of fog computing concepts applications and issues
A survey of fog computing concepts  applications and issuesA survey of fog computing concepts  applications and issues
A survey of fog computing concepts applications and issuesRezgar Mohammad
 

Semelhante a eSOA: A Contextual Analysis on Service Oriented Architecture for Embeddded Networks (20)

Standardization Of The Itu Telecommunications...
Standardization Of The Itu Telecommunications...Standardization Of The Itu Telecommunications...
Standardization Of The Itu Telecommunications...
 
Toward a real time framework in cloudlet-based architecture
Toward a real time framework in cloudlet-based architectureToward a real time framework in cloudlet-based architecture
Toward a real time framework in cloudlet-based architecture
 
Фреймворк промышленного интернета
Фреймворк промышленного интернетаФреймворк промышленного интернета
Фреймворк промышленного интернета
 
Understanding Architecture of Internet of Things
Understanding Architecture of Internet of ThingsUnderstanding Architecture of Internet of Things
Understanding Architecture of Internet of Things
 
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdfA_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
 
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...
Towards Interoperable, Cognitive and Autonomic IoT Systems: an Agent-based Ap...
 
What Is Openstack And Its Importance
What Is Openstack And Its ImportanceWhat Is Openstack And Its Importance
What Is Openstack And Its Importance
 
IoT.pdf
IoT.pdfIoT.pdf
IoT.pdf
 
internet architecture.pdf
internet architecture.pdfinternet architecture.pdf
internet architecture.pdf
 
Seminar on Intelligent Personal Assistant based on Internet of Things approach
Seminar on Intelligent Personal Assistant based on Internet of Things approachSeminar on Intelligent Personal Assistant based on Internet of Things approach
Seminar on Intelligent Personal Assistant based on Internet of Things approach
 
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...
Context Information Aggregation Mechanism Based on Bloom Filters (CIA-BF) for...
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
 
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
 
Middleware Framework For Streaming Data Essay
Middleware Framework For Streaming Data EssayMiddleware Framework For Streaming Data Essay
Middleware Framework For Streaming Data Essay
 
IoT Challenges: Technological, Business and Social aspects
IoT Challenges: Technological, Business and Social aspectsIoT Challenges: Technological, Business and Social aspects
IoT Challenges: Technological, Business and Social aspects
 
1570272924-3
1570272924-31570272924-3
1570272924-3
 
May 2022: Most Download Articles in Web & Semantic Technology
May 2022: Most Download Articles in Web & Semantic TechnologyMay 2022: Most Download Articles in Web & Semantic Technology
May 2022: Most Download Articles in Web & Semantic Technology
 
Mobile Wireless Network Essay
Mobile Wireless Network EssayMobile Wireless Network Essay
Mobile Wireless Network Essay
 
Semantic Technologies for the Internet of Things: Challenges and Opportunities
Semantic Technologies for the Internet of Things: Challenges and Opportunities Semantic Technologies for the Internet of Things: Challenges and Opportunities
Semantic Technologies for the Internet of Things: Challenges and Opportunities
 
A survey of fog computing concepts applications and issues
A survey of fog computing concepts  applications and issuesA survey of fog computing concepts  applications and issues
A survey of fog computing concepts applications and issues
 

Último

UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncObject Automation
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataSafe Software
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?SANGHEE SHIN
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfAnna Loughnan Colquhoun
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIUdaiappa Ramachandran
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 

Último (20)

UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation Inc
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdf
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AI
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 

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

  • 1. 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), Service Oriented Computing, Service Placement, Smart Home, SOAP, UDDI, WDSL, Web Service (WS). 1 Introduction When thinking of embedded sensor networks, one may think of independent and isolated industrial systems responsible for the automatization of a number of tasks. Unlike embedded networks from the past, most of current embedded sensor networks are expected to interact with the world of web services and the Internet. Indeed, the demand for this type of integration is increasing as new business oportunities arise. In any case, the integration of both worlds is not inmediate and cannot be taken for granted. In an attempt to reduce or eliminate this gap, researchers from all over the world are searching for the best solutions that ensure the interoperability of embedded sensor networks and traditional web services. One of these approaches developed by the Computer Science Department at the Technical University of Munich, consists of a SOA-based middleware for embedded networks called
  • 2. 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 some basic 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 as a 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 some fundamental 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 goal of this article. We will first introduce the requirements of embedded networks. Next, we will comment on the eSOA design principles and the implementation details. 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, and SOCRADES. 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 be accomplished. Finally, section-6 will draw the main conclusions derived from the study and analysis of the eSOA middleware within the context of embedded sensor networks. 1.1 The Internet of Things (IoT) The concept Internet of things (a.k.a. Internet of objects) attributed to the former Auto-ID Center, based at the MIT in 1999, year of its foundation, refers to a “self-configuring wireless network of sensors which purpose would be to interconnect all things” [13]. In order to achieve this, every single human-made object in the world should be equipped with a unique identifying device (radio tag) based for example on IPv6, which supports up to 2128 addresses. Because of the enormous number of simultaneous events, time will no longer be used as a common and linear dimension. Instead, it will depend on each entity, making it necessary the management of massive parallel IT systems. Certain level of ambient intelligence would also be necessary so that objects would be capable of, not only pursuing their own goals, but also shared objec- tives by means of interacting with other objects, while considering the current environment and circumstances (e.g. food products that record the temperature along the supply chain, connected cars that would reduce traffic congestion, air conditioning valves that react to the presence of people, connected trees that would help reduce deforestation, etc. [3]). Regarding the complexity of IoT, three main points are highlighted by the Commission of the European Communities. First, IoT should be seen as a set of
  • 3. new independent autonomous systems with their own infrastructures that par- tially rely on those existing in the Internet. Second, IoT should be implemented in 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 in restricted networks (intranet of things) or in public ones (internet of things). The result would introduce many advantages such as real-time products stock, location, and movement control, automatic identification and inventory, etc. The Semantic Web, on its side, offers an alternative based on the idea of making all things addressable by the existing naming protocols, for example by means 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 radically change the way we discover and invoke services“. A more extended definition can be found in [60], according to which, the Internet of services could be considered as a “worldwide, trusted service ecosystem of service providers, consumers, and brokers, buying, selling, repurposing, and composing services for different needs resulting 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, but an extension which ultimate objective is removing the classical barriers and in- efficiencies from service supply and access, so important in nowadays’ service sector, 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 selling services. 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 expected to include the research, development, design, production, marketing, sales, and distribution of any specific service. All of these phases contribute to the final value 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, with different use policies, etc. All those handicaps have to be solved in a transparent way for the final user of the “cloud” service. It is the underlying IT perspective, the responsible for providing the necessary standards, architectures, applications, and tools to support the business view. 1.3 Types of Services There are three main types of services: Business Service: A service, in its traditional sense, can be understood as the “non-material” equivalent of a good. In the business arena, a business service
  • 4. 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 Architecture Web 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 Execution Two main phases can be identified along the lifecycle of services [45]:
  • 5. 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 Service 1.5 Atomic Vs Composite Services According to their complexity, services can be classified into two categories: Atomic Service: Service that provides a basic functionality to the end user. It normally involves a one-on-one relationship between the service 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
  • 6. 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 the exchanged data) are first described as abstract entities, and then bound to a concrete network protocol and message format, making WDSL extensible while allowing the reuse of these definitions [35]. Fig. 3. Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents When a client program connects to a web service offered by a server, it can read the WSDL file in order to determine what operations are supported by that particular server. Special datatypes, if any, are embedded in the WSDL file in the form of XML Schemas. Finally, the client can use SOAP to call the desired operation (one of those listed in the WSDL file). 1.7 SOAP (Simple Object Access Protocol) The Simple Object Access Protocol (SOAP) is “a protocol specification for exchanging structured information in the implementation of web services in computer networks” [29]. An alternative definition is offered by the W3C when describing it’s latest version: “SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment.” [33]. SOAP forms the foundation layer of a web services protocol stack, by means of providing a basic messaging framework (which relies on XML
  • 7. for the message format as well as on other application layer protocols for message negotiation and transmission, such as RPC and HTTP) upon which web services can be built. SOAP can be divided into three main components: an envelope (including a description of the content and instructions on how to process it), a set of encoding rules (for expressing datatypes), and a convention (for specifying the format of both procedure calls and responses). Fig. 4. The SOAP Structure Regarding the messaging framework, it consists of the following elements: The SOAP processing model: establishes the rules for SOAP messages 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 Overview The Organization for the Advancement of Structured Information Standard (OA- SIS ) defines SOA as “a paradigm for organizing and utilizing distributed capa- bilities that may be under the control of different ownership domains.[...] It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expecta- tions.” [1]. In October 2009, the SOA Manifesto Working Group, a group of SOA practitioners and vendors, published the “SOA Manifesto”, which gives prior- ity to business value, strategic goals, flexibility, interoperability, shared services and evolutionary refinement [24]. At present, it is supported by more than 700 signataries worldwide.
  • 8. 2.2 Fundamental Design Terms Before we focus on SOA in more detail, we need first to cover some basic design terms that establish a basic taxonomy used throughout this article. Figure 5 illustrates the main modules of a basic design framework, as well as the relation- ships between them. Fig. 5. Fundamental design terms Design Characteristic: The term design characteristic refers to a specific at- tribute of a body of solution logic documented in a design specification 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
  • 9. 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 Computing Service-oriented computing is a new generation distributed computing platform characterized by its distinct architectural model, design paradigm, and design principles, that includes design pattern catalogs, pattern languages, as well as related concepts, technologies, and frameworks. Let’s review briefly its main el- ements. 2.3.1 Elements of Service-Oriented Computing Service-Oriented Architecture: A SOA is an architectural model with 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 Computing The main goals and benefits derived from the use of Service-Oriented Computing are: – Increased Intrinsic Interoperability – Increased Organizational Agility – Increased Business and Technology Alignment
  • 10. Fig. 6. The individual description documents that can comprise a service contract for a Web service. – Increased Federation – Increased Vendor Diversification Options – Increased ROI – Reduced IT Burden 2.3.3 Service-Oriented Computing in the Real World Web Services: Nowadays, the technology platform most associated with 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 Profile 2nd-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
  • 11. 2.4 Service-Oriented Architecture (SOA) 2.4.1 Introduction In [20], a Service-oriented architecture (SOA) is defined as “a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a SOA architecture will package functionality as a suite of interoperable services that can be used within multiple separate systems from several business domains.” In [54], Sun Microsystems defines SOA as “an information technology approach or strategy in which applications make use of (perhaps more accurately, rely on) services available in a network such as the World Wide Web.” OASIS on its side defines SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of 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 applications using multiple implementation platforms. A service is a software resource with an externalized description available for searching, binding, and invocation by a service 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 defined in terms of protocols and functionality. The way the client of a service (which can be another service) communicates with the service does not depend on the implementation of the service. This is usually referred to as loose coupling. A service can provide both a single discrete function or a set of related functions. Also, services can be combined into aggregated or composite services that satisfy more complex requirements. To sum up, a SOA is “an approach to connecting applications (exposed as services) so that they can communicate with (and take advantage 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: the more complex the services, the less interfaces needed but the less reusable, and viceverse. 2.4.2 Architecture Architectures can operate independently of specific technologies. Designers can implement SOA using a wide range of technologies, including SOAP, RPC, REST, CORBA, Web Services, DCOM, and WCF. Elements of SOA Figure 7 shows the tree-based relationship schema between SOA, services, im- plementations, interfaces, and data. SOA Meta Model
  • 12. 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 is available 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 Principles SOA is based upon a number of specific principles, necessary for its develop- ment, maintenance, and usage. [27] enumerates the following eight principles as mandatory 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.
  • 13. Fig. 8. SOA meta-model, The Linthicum Group, 2007. Fig. 9. Layes of a SOA.
  • 14. 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 in literature: 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 and SOA in [38] and [46]. 3 e-SOA: SOA for Embedded Systems 3.1 Overview Traditionally, many devices were designed to work as isolated embedded sys- tems [43]. As already commented in the introduction of this article, nowadays the 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. Internet of objects), which purpose is to interconnect all things [13]. The service-oriented paradigm, based upon the Service-Oriented Architecture (SOA), explained in the previous section, is the most extended and widely adopted strategy for imple- menting complex, heterogeneous, and large IT systems worldwide, mostly based on 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 for network-enabled hardware devices. In this section we will introduce the main characteristics that make embedded systems different from WS-based systems. Also, we will analyze different existing approaches to save the gap between both words: the world of web services and the world of embedded services.
  • 15. 3.2 Embedded Networks Requirements According to [10], an embedded system is “a computer system designed to per- form one or a few dedicated functions often with real-time computing constraints [. . . ] embedded as part of a complete device often including hardware and me- chanical parts.” An embedded network is a network composed of embedded systems, which can be very diverse both in hard- and software components. Throughout this article, when we talk about embedded networks we will refer to embedded sensor-actor networks, this is, those used in control and automation tasks. Following, there is a list of requirements for embedded networks, available in [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.
  • 16. 3.3 eSOA Embedded networks can take advantage of traditional SOA’s benefits, discussed in section 2.4.3 in order to meet some of the requirements commented in section 3.2. However, and as we already mentioned, traditional SOA (based on web services) cannot be applied directly to the world of embedded networks, but some 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 classified into sensor-eServices (producing data), logic-eServices (processing data), and actuator-eServices (consuming data). The communication model used by e- Services is based on the concept of data stream, which is a sequence of data packets 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 programmable control devices, are independent of the concrete hardware implementation. Once we have seen an overview of eSOA, let us now focus on a particular implementation, to be concrete, that covered in [57], which analysis and study is the main objective of this article. [58], [43], [57], and [59], are all articles written by the same authors on the eSOA topic offering a chronological evolution of their research activity on the field. In the next two sections we will analyze the authors’ proposal: an eSOA middleware. Section 3.4 explains the design principles of such a middleware, while section 3.5 focuses on its implementation. Additionally, we will comment on other proposals and projects by other research groups in the field of SOAs for embedded systems, so that the reader can get a wider perspective on the current status of the field.
  • 17. 3.4 eSOA Middleware Design Principles As explained by the authors themselves, the middleware proposed in [57] is based on the 3-layers embedded networks hierarchy depicted in Figure 10. Each layer corresponds to a different view. Next, let us comment on all of them in more detailed. 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
  • 18. 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.
  • 19. 3.5 eSOA Middleware Implementation In this section we will analyze and study the implementation details of the pro- totypical eSOA middleware proposed in [57]. As described in [58], “the result of [the] code generation [...] is an optimized, tailored middleware with embed- ded and already configured services that implement the application logic. The main 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 the middleware 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, metadata aided service composition, run-time adaptability, and integration with external services. Let us now review all of these aspects. Fig. 11. Network Architecture. 3.5.1 Efficient Distributed Data Processing Due to strict CPU, memory, bandwidth, and battery limitations, it is essential for the proposed middleware to efficiently collect, process, and distribute data. This is achieved by means of generating efficient platform-specific code, together with an 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
  • 20. 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
  • 21. 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 Composition The metadata-based description of services, commented above, introduces two additional 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
  • 22. 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 Adaptability Embedded networks are frequently dynamic: new nodes can be added at any time, existing nodes can be reconfigured, become temporarily unavailable, or even removed, mobile nodes can enter and leave the network, etc. The proposed middleware provides a discovery mechanism based on the (semi-)automatic ser- vice composition, which is capable of integrating the hardware on the newly discovered node with the running applications. Regarding the failures of nodes, there are two ways in which they can be managed: locally or globally. Local recovery is possible only when redundant eServices and/or communication channels are available to replace those with failure. 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 failed node. 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 new eServices 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 operating system. 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 be instantiated and started. In any case, the new service instance is started and configured as required by the application itself. In the event of an application removal, all those services used only by that application are conveniently shut
  • 23. down and de-installed, facilitating the maintenance of the services repository. 3.5.4 Integration with External Services As explained in section 3.1, nowadays there is an increasing demand for inte- grating the world of web services and that of eServices, specially in the fields of manufacturing and logistics, in which a break in the information exchange between both worlds is not tolerable anymore. As illustrated in Figure 13, the integration has to be designed so that it ensures that users from any of both worlds are allowed to interact with services from the other world in the same way they interact with those services from their own world. In other worlds, users familiar with the WS world should be allowed to interact with eServices in the same way that they interact with WS. On the other hand, users from the embedded world should be allowed to interact with WS in the same manner as they interact with eServices. Fig. 13. Integration of Web Services and Embedded Worlds. Next, let us focus on three aspects of interest: the interaction schemes, the IP- compatible addressing, and the Service Bridge. 3.5.4.1 Interaction Schemes The mediation between both worlds is performed by a Service Bridge (gateway), responsible for converting incoming and outgoing messages, as well as for pro- viding WSDL interfaces for eServices. The Service Bridge must support four different types of communications:
  • 24. 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 Addressing In order to ensure a seamless integration between the WS and the embedded worlds, 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 cases in which the underlying network uses a different addressing scheme. The Service Bridge is responsible for monitoring all incoming messages at the Network Layer. When an incoming message is targeted at a certain eService, it is conveniently translated into the suitable packet format and forwarded to the corresponding
  • 25. eService. An illustrative example is depicted in Figure 14. The incoming WS message is translated into the ZigBee protocol by means of analyzing the WSDL description. Fig. 14. Service Bridge. 3.5.4.3 Service Bridge As already commented in section 3.5.4.1, the Service Bridge acts as an interface between the WS world and that of embedded systems, converting incoming and outgoing messages and providing WSDL [41] interfaces for eServices. Let us now analyze in more detail the translation process realized by the Service Bridge for all 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
  • 26. 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 that it is independent of services, so that no changes are needed when new services are added to the system. 3.6 eSOA Middleware Example: Smart Home Once we have analyzed the eSOA middleware design principles and implemen- tation on detail, let us finish this section with a real example of implementation called Smart Home. As explained in [43], one of the most salient and demanded applications of embedded networks is building automation. While in the in- dustrial and business arena there is an notorious and increasing demand for systems that automate part of the common activities, building automation has not 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 Home is reducing installation costs, by facilitating the installation process so that end users themselves can setup their own automated systems at home. A Smart Home demonstrator is depicted in Figure 15. The system consists of a power supply, a battery, two lights, a refrigerator, and a phone. All of these elements are thought of as they would exist in a future home. Another advantage of Smart Home is the fact that it is designed to save energy. It is assumed that future 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 the battery, the system can switch from one to the other as pleased. It is well known that energy cost varies throughout the day. The key idea is obtaining the energy
  • 27. from the power supply when the price is low, and switching to the battery when price is high, so that the householders save money in their monthly bills. When the prices are low again, the system automatically switches again to the power supply. Of course, it is taken for granted that the energy would be obtained from the 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 temperature threshold 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 from the 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 to facilitate 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 with some graphical tools. For instance, the electricity prices can be retrieved from the 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 the system. 4 Related Work 4.1 Introduction As explained in [43], [57], and [59], there are a number of standardized mid- dleware architectures oriented to concrete domains, such as AUTOSAR [4] for automotive applications and KNX [15] for building automation. The main down- sides of these approaches are derived from their very low abstraction level, which
  • 28. Fig. 16. GUI for Pattern Installation. does not allow end-user programmability. Furthermore, their data processing paradigm is not compatible with that of service-oriented systems, making it difficult to integrate them with external services. Regarding the field of sensor networks, there are also certain middlewares capable of monitoring them. Two salient examples to be mentioned are TinyDB [53] and Cougar [63]. The main disadvantage of these systems are the potential bottlenecks and the single points of failure for those control-oriented applications consisting of multiple sensors and actuators. This is due to their hierarchical network structure, since the amount of necessary data increases as we ascend from level to level within the hierarchy. In relation to SOA, there are other projects, apart from the middleware proposed in this article, which also take advantage of this approach for embedded networks. Some of the most representative are OASIS [51], RUNES [47] and MORE [16]. The main drawback of these projects is that they do not support neither the generation of tailored code nor the optimization of the placement of services. As a direct consequence, unlike the suggested eSOA middleware, they do 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 accessible from the WS world. The main weakness of such approach is the fact that, even when it may work fine with certain types of devices, it is not suitable for small
  • 29. lightweighted ones, since these are not capable of dealing with the overhead introduced by the WS technologies and protocols. Once we have briefly commented on the most relevant projects related to the eSOA-based middleware object of this article, let us now study in more detail each of them. Since an extensive analysis of these projects is out of the scope of this work, we will make only a brief introduction to each of them so that it serves as a general overview. 4.2 AUTOSAR As defined in [4], AUTOSAR (AUTomotive Open System ARchitecture) is “an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers.” AUTOSAR supports all vehicle domains and will serve as a platform standard upon which future vehicle applications will be implemented, minimizing current barriers between functional domains. 4.2.1 Goals The 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 lifetime 4.2.2 Key Features The key features of AUTOSAR are: – Modularity and configurability – Standardized interfaces – Runtime environment 4.2.3 Technical Goals – Modularity – Scalability – Transferability – Re-usability – Standardized interfaces
  • 30. 4.2.4 Software Figure 17 shows the aspect of AUTOSAR software application. Fig. 17. AUTOSAR software application. 4.2.5 Architecture Figure 18 shows the architecture of AUTOSAR, based upon the concept of on SW-Cs (software components) which encapsulate applications, and have well- defined standardized interfaces. The AUTOSAR architecture consists of the following elements: – Software Component (SW-C) – Software Component Description (SW-C description) – Virtual Functional Bus (VFB) – System Constraint Descriptions – ECU Descriptions – Mapping on ECUs – Runtime Environment (RTE) – Basic Software 4.3 KNX As described in [15], KXN is the “worldwide standard for all applications in home and building control, ranging from lighting and shutter control to various
  • 31. 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 existing home and buildings.” 4.3.1 Goals – Convenience – Safety – Energy savings 4.3.2 Key Features – A single, manufacturer independent design and commissioning tool (ETS) – A complete set of supported communication media (TP, PL, RF and IP) – A complete set of supported configuration modes (system and easy mode) – Low operating costs resulting in considerable energy savings – Time saving – Flexibility and adaptability to future developments 4.4 TinyDB As defined in [53] and [32], TinyDB is “a query processing system for extract- ing information from a network of TinyOS sensors.” The main difference be- tween TinyDB and other solutions for data processing in TinyOS is the fact
  • 32. that TinyDB does not require the programmer to write embedded C code for sensors but it provides a simple SQL-like interface to specify the data to be extracted, along with additional parameters. TinyDB collects that data from motes in the environment, filters it, aggregates it together, and routes it out to a PC. TinyDB does this via power-efficient in-network processing algorithms. 4.4.1 Goals – Facilitating the programming (no need for low-level code) – Allowing quick development of data-driven applications 4.4.2 Key Features – Metadata management – High level queries – Network topology – Multiple queries – Incremental deployment via query sharing – Java API for writing PC applications – Graphical query-builder and result display 4.4.3 Architecture Figure 19 shows the architecture of TinyDB in which the TinyDB query processor is installed in every single mote of the network. Fig. 19. TinyDB architecture.
  • 33. 4.5 Cougar According to [63], existing sensor networks are based upon an structure of pre- programmed sensors that send data to a central front-end where the data is aggregated and stored for offline quering and analysis. The main downsides of this approach are the fact that the behaviors of the system cannot be modified during runtime, as well as the lack of in-network programming. The Cougar ap- proach aims to solve these issues by means of using declarative queries. 4.5.1 Key Features – Query optimizer: generates an efficient query plan for in-network query pro- cessing – Reduction of resources usage – Extended life of sensors – Queries expressed in declarative language – Independence from the underlying physical network 4.6 RUNES Nowadays embedded systems constitute a major technological revolution found in 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 common language 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, widely distributed, heterogeneous networked embedded systems that interoperate and adapt to their environments.” 4.6.1 Goals – Simplify the programming – Simplify the application creation process – Cut the costs of new applications development – Fasten the time to market 4.6.2 Key Features – Standardised architecture – Self-organisation to suit changeable environments – Adaptive middleware platform – Common language 4.6.3 Architecture Figure 20 shows the architecture of RUNES, consisting of applications, a component- based middleware, and the hardware devices. The middleware itself is structured into four layers: services and application-specific mechanisms, the middleware API, cross-platform components, and hardware abstractions.
  • 34. Fig. 20. RUNES architecture. 4.7 MORE The MORE (Network-centric Middleware for GrOup communication & Resource Sharing across Heterogeneous Embedded Systems) project aims to “implement new technology to facilitate communication and distributed intelligence across groups of users using different wireless standards” [16]. 4.7.1 Goals – Provide a SOA-based middleware deployable on the device level – Efficient interactions between humans and embedded systems – Customization to meet specific needs of diverse organizations – Alleviate heterogeneity of devices 4.7.2 Key Features – Simplified APIs – Management mechanisms – Independence from the underlying physical network – Policy driven group communication – Resource sharing between devices/services – Security of communications for secure data exchanges – Enabling gateway services 4.7.3 Architecture
  • 35. Figure 21 shows the architecture of MORE, including the MORE middleware consisting of a Core Management Service (CMS) along with a number of En- abling Services. Fig. 21. MORE architecture. 4.8 SIRENA As stated in [22], the SIRENA project was “a European research and advanced development project, from 2003 to 2005, with the objective to develop a Ser- vice Infrastructure for Real time Embedded Networked Applications.” The main contribution of SIRENA was the application of the SOA paradigm to communi- cations and interworking between components at the device level. The SIRENA project served as the foundation for projects such as SODA and SOCRADES. 4.9 SOCRADES According to [31], “the SOCRADES project is a European research and advanced development project. Its primary objective is to develop a design, execution and management platform for next-generation industrial automation systems, ex- ploiting the Service Oriented Architecture paradigm both at the device and at the 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.
  • 36. 4.9.2 Architecture Figure 22 shows the architecture of SOCRADES. Fig. 22. SOCRADES architecture. 4.10 Additional Works There are a number of related references that the reader may find of interest, some of which are briefly summarized here. [25] and [9] are studies about SOA on embedded systems. [44] gives an overview of the trends and roadmaps on SOA-based embedded networks for industrial automation, while [61] and [23] in- troduce SOA-based embedded systems development environments for industrial automation. [49] illustrates a practical implementation of SOA for embedded systems in the context of harbours automatic management. [50] refers to the integration of SOA-ready networked devices in enterprise systems via a cross- layered web service infraestructure, while [6], [5], and [2] introduce Web Services Business Process Execution Language (BPEL). [55] suggests a constraint-based component system for synthesizing scalable software systems, called BOTS. [64] on it side, proposes SOA-toolkits for making embedded systems ready for web services. On the other hand, [52] focuses on embedded software system testing based on SOA for mobile service. Finally, [62] is a critique of ambient technology and the all-seeing network of RFID. 5 Future Work Once we have briefly introduced the main projects related to the eSOA middle- ware focus of this article, let us now comment on the eSOA authors’ ongoing
  • 37. 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 stream management technologies. Second, there is the need for evaluating different service placement strategies. Third, it may be interesting researching ways to achieve the automatic learning of service patterns based on a repository of ex- isting applications. Forth, the development of application level connectivity at the routing layer is necessary for routing optimization with low overhaead for protocols and routing tables. Fifth, the enrichment of the semantic descriptions of services would allow obtaining metrics that may allow to select the most suitable service out of a service repository. Sixth, further research has to be ac- complished regarding the requirements of an intuitive interface for the discovery and integration of field-level devices and web services, as well as to find out if such requirements can be met with existing technologies such as UDDI registries or query interfaces such as TinyDB. 6 Conclusions While traditionally many devices were designed to work as isolated embedded systems, nowadays the trend is to connect and integrate daily-life devices into distributed 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 for systems capable for dealing with both worlds is rapidly increasing, specially in the fields of automotive, factory automation, and building management, in part, as a consequence of the ongoing decline in prices for network-enabled hardware devices. 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, mostly based on web services. The SOA paradigm offers numerous advantages such as 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, and bridging - traditional SOA cannot be applied directly to them. There are several research projects which attempt to integrate the worlds of embeddded sensor networks and that of web services. One of these projects, developed by the Computer Science Department at the Technical University of Munich, and focus of this article, proposes a SOA-based middleware for em- bedded networks called eSOA, which architecture consists of three layers. The Abstract Infrastructure Layer provides a unified model of the underlying hardware components (nodes) and a serie of 1-hop network connections between
  • 38. nodes ( links). The Service Layer provides a service-oriented view of the un- derlying sensors/actuators. The Application Layer provides an overview of the installed applications, the involved services instances, as well as of the infor- mation exchanged between instances. The process of installing a new application consists 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-Specific Code Generation, Event-Based Data Processing, and Distributed Execution of Applications, Metadata-Aided Service Composition, including End-user Programming and (Semi-) Automatic Service Composition, Run-Time Adapt- ability , as well as Integration with External Services, including support for continuous/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, further research 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/.
  • 39. 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.
  • 40. 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.