TOWARDS SERVICE ORIENTATION ON RESOURCE

CONSTRAINED DEVICES

Nils Glombitza, Dennis Pﬁsterer, Stefan Fischer

Institute of Telematics, University of L

ubeck, Ratzeburger Allee 160, L

ubeck, Germany

Carsten Buschmann

coalesenses Ltd., R

ontgenstraße 28, L

ubeck, Germany

Horst Pahl

Travem

under Datenverbund Ltd., Seelandstraße 3, L

ubeck, Germany

Keywords:

e-Business, Service oriented architecture, Business process execution language, Web service, Wireless sensor

network, Logistics, L2D2.

Abstract:

For the ﬂexible integration of enterprise applications and business processes, the Service Oriented Architecture

(SOA) concept and the web service technology are the state of the art today. Especially for powerful hardware,

a lot of web service and related technologies were developed during the last years. But with the development

of Future Internet technologies, there is a demand for integrating all kinds of devices into a SOA. This includes

especially devices with extremely limited resources, such as wireless sensor nodes, which are not capable of

running today’s web service technologies. In this paper we disclose the need for research action on different

layers of the web service technology stack. We discuss promising solutions for running standard compliant

web services in sensor networks and integrating sensor network and enterprise IT web services as well as

BPEL business processes seamlessly. We introduce the L2D2 project in which our concept will be realized

and proven.

1 INTRODUCTION

In the international computer science researching

community, a lot of groups are working on the devel-

opment of technologies to build up the Future Internet

(European Union, 2008). The scope of topics which

are related to the Future Internet is widely spread.

It includes the development of internet test beds

such as WISEBED (Fischer et al., 2008) as well as

computing grids and especially the Internet of Things

(Erl, 2007; Fleisch and Mattern, 2005). In our point

of view, the integration of a plethora of devices into

the Internet is one of the most important changes that

will be seen in the next years. This targets not only

classical mobile devices like notebooks, PDAs or cell

phones, but includes connecting all kinds of everyday

devices like refrigerators, toasters or cars on the one

hand as well as machines, production equipment and

wireless sensor networks on the other. These devices

are often based upon simple microcontrollers instead

of powerful processors, resulting in severe resource

constraints.

From this perspective, the Future Internet is a

seamless and efﬁcient platform to connect all kinds

of objects. A plurality of new services will arise

based upon this standard communication platform. In

addition, developers will increasingly create applica-

tions by simply rearranging existing services to new

demands instead of programming every functionality

completely from scratch. To realize these new soft-

ware development paradigms, adequate software ar-

chitectures for distributed systems and applications

are needed (Dunkel et al., 2008).

Closely coupled client server architectures or web

applications which are developed for a very speciﬁc

purpose do not fulﬁll the technical and economic re-

quirements of today’s application environments. Con-

sequently, the approach of Service Oriented Architec-

Glombitza N., Pﬁsterer D., Fischer S., Buschmann C. and Pahl H.

TOWARDS SERVICE ORIENTATION ON RESOURCE CONSTRAINED DEVICES.

DOI: 10.5220/0002151900720077

In Proceedings of the Fifth International Conference on Web Information Systems and Technologies (WEBIST 2009), page

ISBN: 978-989-8111-81-4

L2D2

Application

(e.g.:

Management

Dangerous

Goods)

Database

Workstation

Service

Web 2.0 Application

L2D2 Platform

Client Layer

Application Layer Data Layer

Sensor

Network

Database

Figure 1: Architecture of the overall L2D2 system.

tures (SOAs) has been developed to meet the require-

ments of today’s applications development. How-

ever, SOA based applications can so far nearly only

be found in the enterprise IT environment, there are

still only a few approaches published which describe

the ﬂexible integration of resource constrained de-

vices such as sensor networks into Service Oriented

Architectures.

We strongly believe that only the integration of

such devices will unleash the true power of the Future

Internet, as machine to machine communication will

be one of its most important communication patterns.

Hence, in this paper we present an Internet based ap-

plication example integrating different classes of de-

vices using Web Services, and discuss the challenges

that are posed when extending service orientation to

extremely resource constrained devices such as wire-

less sensors.

2 USE CASE: LOGISTICS

PLATFORM L

UBECK

Logistics is a business domain where intra- and in-

tercompany business processes are highly integrated.

Next to the producers and buyers of goods, more and

more organizations of the supply chain (e.g.: air-

lines, shipping lines, port operators, railway com-

panies, conveyances, and authorities) are getting in-

volved in the automated treatment of ﬂows of goods.

The Logistics Platform L

ubeck (L2D2)

is a re-

searching project which will be realized by the Uni-

versity of L

ubeck, the Travem

under Datenverbund

Ltd., and coalesenses Ltd. to build up a Service Ori-

ented Architecture based platform on which all kinds

of research concepts related to service orientation can

be evaluated under realistic conditions. Additionally,

various organizations of a logistics supply chain can

offer services to partner companies. The platform will

be open to partner companies to ﬂexibly add further

services at any time.

Figure 1 shows the architecture of the overall

L2D2 system. Basically the system consists of three

layers. Several partners provide data. The L2D2 plat-

form offers service interfaces for all these data re-

spectively software components based on these data.

Additional to the services of L2D2, it is possible to

integrate services from providers of other platforms.

Next to the basic services, the L2D2 platform pro-

vides complex composed services. Finally, the L2D2

services as well as additional services will be com-

posed with Web 2.0 technologies to different applica-

tions.

An example application which will be developed

The shortcut L2D2 is derived from the German title of

the project: ”L

ubecker Logistik Datendrehscheibe”.

TOWARDS SERVICE ORIENTATION ON RESOURCE CONSTRAINED DEVICES

Table 1: Services of the L2D2 platform.

Service Type Used Technology Frequency of Redesign Perspective

Basic Service Java/C++ Web Service constant technical

Composed Service Java/C++ Web Service constant/low technical

Business Process BPEL constantly changing business

on top of the L2D2 platform will be an application for

the management of dangerous goods (MoDG). MoDG

will be built up in two phases. First, we will imple-

ment services and business processes which integrate

the data and services of the currently existing isolated

applications of the organizations which are involved

in the transportation of dangerous goods in L

ubeck.

Furthermore, based on these basic services, we will

implement complex composite services and business

processes.

In a second step, we will integrate mobile ser-

vices on resource constrained devices into MoDG and

the L2D2 platform. The ”smart truck” can improve

the safety of the transport and handling of dangerous

goods. The idea is that every truck carries wireless

sensor nodes which are communicating data about the

goods wirelessly to other trucks and to further com-

ponents of the enterprise IT. The communicated data

is not limited to static information about the loaded

goods, e.g., an electronic waybill. Furthermore, real

time information of the sensed data, such as the tem-

perature or the position of the goods, can be commu-

nicated. For example, if two trucks, carrying goods

that must have a minimum distance to each other, are

located to close together, an alarm will be given.

3 SERVICE ORIENTED

ARCHITECTURE ON

RESOURCE CONSTRAINED

DEVICES

In a SOA, applications do not longer consist of mono-

lithic and closely coupled software systems. Appli-

cations will be ﬂexibly composed by using existing

services on demand (Papazoglou, 2008).

Table 1 shows the different types of services of

a SOA based application system. First, there are so

called basic services. They are widely stable, i.e. they

will only rarely be changed. Second, the so called

composed services use basic services to offer more

sophisticated functionality. Both services are devel-

oped by technical IT staff. They offer functional-

ity on a technical level, e.g., a temperature measure-

ment service. While a basic service, such as the tem-

perature measurement service, offers very elementary

Figure 2: iSense wireless sensor.

functionality, a composed service is built on top of ba-

sic as well as other composed services and provides

functionality on a higher level. As these two service

types are building blocks of the application system,

they will be implemented in an object oriented pro-

gramming language such as Java or C++.

On top of the basic and composed services, busi-

ness process services implement the business logic.

These processes are constantly changing. To be able

to adapt these services to changing requirements as

well as to let business staff modify them, the Business

Process Execution Language (BPEL) (OASIS WS-

BPEL Technical Committee, 2005) will be used to

develop this service type.

In the enterprise IT context, there are a lot of well

developed technologies for the implementation of a

web service based SOA (including BPEL). Our main

researching focus is on the integration of mobile and

wireless sensor networks into our platform with web

service technologies for sensor networks. The goal is

to be able to implement all service types deﬁned in

Table 1 on all kinds of resource constrained devices.

For a seamless integration of sensor network and en-

terprise IT services it is necessary to extend today’s

SOA technologies rather than developing new solu-

tions.

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

Figure 2 shows a typical example of the resource

constrained hardware we are targeting. The depicted

iSense wireless sensor network platform (Buschmann

and Pﬁsterer, 2007) consists of a number of hard-

ware modules that can be combined to wireless sensor

nodes.

The main module (back of the node in the ﬁg-

ure) comprises a 32-bit RISC controller running at

16 MHz including 96 kBytes of memory for both

program code and data, an IEEE 802.15.4 compli-

ant wireless communication interface which provides

a data rate of 250kBit/s as well as a universal system

connector. The connector can be used to attach other

modules, providing sensors (center), batteries (front),

GPS positioning, a PC interface et cetera.

To be independently mobile, sensor nodes are

commonly battery powered. As the wireless commu-

nication interface is the main energy consumer, it will

have to be turned off most of the time to prolong the

battery lifetime. As a result, the networking proto-

cols must be able to deal with this kind of temporary

disconnection.

3.1 Related Work

A ﬁrst step to integrate sensor network applications

respectively services offered by sensor nodes into

business processes is the GWELS (Graphical Work-

ﬂow Execution Language for Sensor Networks) lan-

guage and toolkit (Glombitza et al., 2009). The big

advantage of GWELS is that sensor network services

can be easily composed to business processes by peo-

ple with no special IT expertise. But other than work-

ﬂow execution languages such as BPEL or ebXML

(Clark et al., 2001) which can be used to compose

web services to business processes, GWELS can be

used in the context of sensor networks with its ex-

tremely limited hardware. But even though GWELS

can be integrated via a web service interface into a

web service based SOA, a direct integration of sensor

network services and enterprise IT services is not pos-

sible. The developers always need to use the GWELS

web service connector. Furthermore, GWELS is based

on proprietary communication technologies which are

not compatible to any other SOA technology.

Spiess et al (Spiess et al., 2006) describe how to

use BPEL for the integration of sensor networks and

business processes. The work is part of the CoBIs

project (European Union, 2007) which uses a wireless

sensor network to monitor chemicals. Unfortunately,

these publications do not describe which parts of the

sensor network application itself are described using

BPEL.

Piryantha et al (Piryantha et al., 2008) describe

HTTP, JMS, SMTP

XML

SOAP

WSDL

UDDI

WSNTB

Fabric XML

Compression

Management

Context

Coordination

Transaction

WS-SecurityWS-Reliability

Transport

Message

Description

Discovery

Quality of

Service

Business

Processes

BPEL for WSN

Orchestration – BPEL

Figure 3: Extended web service stack of the L2D2 project.

how to realize tiny web services in a TCP/IP based

sensor network. The approach is not applicable for

our scenario. First, Piryantha et al use a much more

powerful category of sensor network devices. The

hardware capabilities of the sensor nodes which we

will use are to low to deal with the TCP/IP overhead.

Second, we have to deal with very inconstant commu-

nication links which make it impossible to use TCP.

3.2 Challenges

When extending Service Oriented Architectures to

extremely resource constrained devices, a number of

adaptations are required:

1. XML serialization: as bandwidth is limited and

communication is energy-consuming, the serial-

ized message representation must be as compact

as possible.

2. XML processing: established XML processing is

not possible due to memory constraints.

3. Transport protocol: the networking protocols em-

ployed in the classical internet are too resource

demanding and not well adapted to wireless com-

munication and disconnection periods.

4. Integrating sensor network services into business

processes: run-time interpretation of BPEL is not

possible due to resource constraints.

5. Self description of services: memory constraints

require compact WSDL representations.

Figure 3 shows the required extensions of the stan-

dard web service stack to implement the above men-

tioned adaptations for a web service based integra-

tion of sensor networks and enterprise web services as

well as business processes (elements with white text

on dark background).

It is not possible to handle plain SOAP XML mes-

sages in sensor networks. With the small bandwidth

TOWARDS SERVICE ORIENTATION ON RESOURCE CONSTRAINED DEVICES

in sensor networks, it is hardly possible to exchange

and process SOAP messages serialized to the verbose

XML text representation. To reduce the problem of

message sizes, the very simple approach would be

to use GZIP (Deutsch, 1996) to compress the SOAP

messages. But with this approach, it is still needed to

decompress the message on the sensor node to a large

XML message and process this message on the very

restricted hardware. For our approach we use XML

compression as described in (Werner et al., 2006) or

(Pﬁsterer et al., 2007) to reduce the message size.

The big advantage especially of Fabric/Microﬁbre ap-

proach of Pﬁsterer et al is that the compressed mes-

sages are directly decompressed respectively deseri-

alized to programming language data structures rather

than to a large SOAP XML message. Thus, on the

sensor node, the deserialized SOAP message is very

small and can be used right away without the need

of an XML processing which requires more hardware

resources than our sensor network platform can offer.

For the transfer of the compacted SOAP messages,

a web service transport binding which is optimized

for the requirements of communication in sensor net-

works is required. This Web Service Transport Bind-

ing for Sensor Networks (WSNTB) hides the com-

plexity of the integration of TCP/IP and sensor net-

work based communication from the application or

web service developer. There is no difference be-

tween the addressing of services in the sensor network

or in the TCP/IP network. The transport binding of-

fers a seamless integration of both ”worlds”. While

WSNTB will use TCP/IP for the communication out-

side the sensor network, it is highly ﬂexible consid-

ering which transport or routing protocol to use in-

side the sensor network. WSNTB can be used with ev-

ery routing protocol which is available for the iSense

sensor network platform. For the convenient devel-

opment and access of web services, an integration of

WSNTB into a web services engine like Apache Axis2

is desirable.

To integrate web services provided by sensor

nodes into the business processes of organizations,

the sensor network services must be accessible by the

BPEL runtime hosted on an enterprise IT server. To

reach this goal it is required to extend a BPEL runtime

(such as the Apache ODE BPEL runtime (Apache

Software Foundation, 2009)) with the XML compres-

sion capabilities and web service transport binding

WSNTB described above.

However, to deploy BPEL web services not only

on enterprise servers but also on sensor nodes, fur-

ther adaptations are required. The sensor nodes’ re-

source constraints inhibit the interpretation of BPEL

process descriptions on the node at run-time. Instead,

the BPEL description has to be compiled on a PC at

design-time to optimized machine code for the target

platform and can then be transferred to the destina-

tion node. For the communication between the BPEL

process and other services, WSNTB can be used as

well. As sensor network web services, these BPEL

processes will also be able to call web services pro-

vided by other sensor nodes as well as by enterprise

servers. The representation of the XML data and mes-

sage types for the communication with the BPEL pro-

cess as well as the data representation of the BPEL

process itself will be realized by using programming

language data structures automatically generated by

the Fabric/Microﬁbre toolkit.

The ﬁnal issue to address is the service descrip-

tion. For the sake of compatibility, the description

of web services should be done using WSDL. As

web services usually describe themselves, the WSDL

description consequently has to be stored on the re-

source constraint device itself. The required ex-

tremely compact representation of the description can

be achieved by applying Fabric/Microﬁbre.

4 CONCLUSIONS

Two major but so far unfortunately separate trends of

the Future Internet are the integration of all kinds of

resource constrained devices and a consequent service

orientation. To integrate these two, we pinpointed the

need for research action on different layers of the web

service technology stack and discussed promising so-

lutions. We proposed WSNTB to address the need for

a compact XML serialization, low processing over-

head and a seamless transport protocol integration. In

addition, we outlined how BPEL can be applied to re-

source constrained devices and the resulting services

can describe themselves efﬁciently.

REFERENCES

Apache Software Foundation (2009). Apache ODE. Tech-

nical report, WWW: http://ode.apache.org/.

Buschmann, C. and Pﬁsterer, D. (2007). iSense: A modu-

lar hardware and software platform for wireless sensor

networks. Technical report, 6. Fachgespr

ach Draht-

lose Sensornetze der GI/ITG-Fachgruppe Kommu-

nikation und Verteilte Systeme.

Clark, J., Casanave, C., Kanaskie, K., B.Harvey, Smith, N.,

Yunker, J., and Riemer, K. (2001). ebXML Business

Process Speciﬁcation Schema Version 1.01. Technical

report, UN/CEFACT & OASIS.

Deutsch, P. (1996). GZIP ﬁle format speciﬁcation

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

version 4.3. RFC 1952 (Informational). WWW:

http://www.ietf.org/rfc/rfc1952.txt.

Dunkel, J., Eberhart, A., Fischer, S., Kleiner, C., and

Koschel, A. (2008). Systemarchitekturen f

ur Verteilte

Anwendungen. Hanser-Verlag.

Erl, T. (2007). SOA Principles of Service Design. Prentice

Hall.

European Union (2007). Collaborative Business Items, EU

project website. WWW: http://www.cobis-online.de/.

European Union (2008). Future Internet. WWW:

http://www.future-internet.eu.

Fischer, S., Pﬁsterer, D., Fekete, S. P., and Kroeller, A.

(2008). Wisebed - pan-european wireless sensor

network testbeds. In Fachgespraech der GI/ITG-

Fachgruppe Kommunikation und Verteilte Systeme.

Fleisch, E. and Mattern, F. (2005). Das Internet der Dinge.

Springer.

Glombitza, N., Lipphardt, M., Werner, C., and Fischer, S.

(2009). Using Graphical Process Modeling for Re-

alizing SOA Programming Paradigms in Sensor Net-

works. In Sixth Annual Conference on Wireless On de-

mand Network Systems and Services, Snowbird, Utah,

USA.

OASIS WS-BPEL Technical Committee (2005). Webser-

vices – Business Process Execution Language Ver-

sion 2.0. Technical report, WWW: http://www.oasis-

open.org/committees/wsbpel.

Papazoglou, M. P. (2008). Web Services – Principles and

Technology. Pearson.

Pﬁsterer, D., Wegner, M., Hellbr

uck, H., Werner, C., and

Fischer, S. (2007). Energy-optimized Data Seri-

alization For Heterogeneous WSNs Using Middle-

ware Synthesis. In Proceedings of The Sixth Annual

Mediterranean Ad Hoc Networking Workshop (Med-

Hoc-Net 2007).

Piryantha, N. B., Kansal, A., Goraczko, M., and Zhao, F.

(2008). Tiny Web Services – Design and Implementa-

tion of Interoperable and Evolvable Sensor Networks.

In Proceedings of the 6th ACM Conference on Embed-

ded Networked Sensor Systems.

Spiess, P., Vogt, H., and J

utting, H. (2006). Integrat-

ing Sensor Networks with Business Processes. In

The 4th ACM International Conference on Mobile

Systems, Applications, and Services (ACM MobiSys

2006), Real-World Sensor Networks Workshop, Upp-

sala, Sweden.

Werner, C., Buschmann, C., Brandt, Y., and Fischer, S.

(2006). Compressing SOAP Messages by using Push-

down Automata. In ICWS ’06: Proceedings of

the IEEE International Conference on Web Services,

pages 19–28, Washington, DC, USA. IEEE Computer

Society.

TOWARDS SERVICE ORIENTATION ON RESOURCE CONSTRAINED DEVICES