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.