interacting with the soa based internet of things discovery, query, selection, and on-demand...

IEEE TRANSACTIONS ON SERVICES COMPUTING – QUERY MODELS AND EFFICIENT SELECTION OF WEB SERVICES 1

Interacting with the SOA-based Internet ofThings: Discovery, Query, Selection, and

On-Demand Provisioning of Web ServicesDominique Guinard1,2, Stamatis Karnouskos1, Vlad Trifa1,2, Bettina Dober1, Patrik Spiess1, Domnic Savio1

SAP Research1 and Distributed Systems Group, ETH Zurich2.

Abstract—The increasing usage of smart embedded devices blurs the line between the virtual and real worlds. This creates newopportunities to build applications that better integrate state and events of the physical world and hence provide business servicesthat are more diverse, highly dynamic and efficient. Service-oriented Architecture approaches traditionally used to loosely couplefunctionality of heavyweight corporate IT systems, are becoming applicable to embedded real-world devices, i.e. objects of the physicalworld that feature embedded processing and communication. In such infrastructures, composed of a large number of networked,resource-limited devices, the discovery of services and on demand provisioning of missing functionality is a significant challenge. Thiswork proposes a process and a suitable system architecture that enables developers and business process designers to dynamicallydiscover, query, select, and use running instances of real-world services or even on-demand deploy new ones, all in the context ofcomposite, distributed business real-world applications.

Index Terms—Service-oriented Architecture (SOA), Web Services (WS), REST, Device Integration, Ubiquitous Business Processes,Device Integration, SOCRADES, Wireless Sensor (Actuator) Networks,On-Demand Deployment

F

1 INTRODUCTION

THE last years we have witnessed two major trendswith respect to the device world. Firstly, the hard-

ware is getting cheaper, smaller and more capable.According to the Internet of Things vision (IoT) [1],the majority of the devices will have communicationand computation capabilities, which they will use toconnect, interact, and cooperate with their surroundingenvironment. Secondly, the software industry is movingtowards service-oriented approaches and especially inthe business software domain new complex applicationsare based on the composition and collaboration of otherservices. The Internet of Services vision (IoS) [2] assumesthis on a large scale, where services reside in differentsystem layers e.g. enterprise, network, or even at thedevice level being realized by embedded software. Asboth of these trends are not domain specific and are com-mon to multiple industries, we are looking at a mega-trend in which service-based information will lead toblur the borders of real and business worlds, effectivelyproviding the ground for a new breed of highly sophis-ticated applications that are based on the cooperationof networked embedded devices among themselves andwith business systems [3]. In this SOA-based Internetof Things we expect that (dynamic) discovery, query,selection, and on-demand provisioning of web serviceswill be of crucial importance.

Contact Author: Dominique Guinard, SAP Research, Kreuzplatz 20, CH-8008 Zurich, Switzerland. Email: [email protected], Tel: +41 58871 7846, Fax: +41 58 871 7812

In the future service oriented Internet devices willbe offering their functionality over service-enabled in-terfaces, e.g. via SOAP-based Web Services or RESTfulAPIs, so that other components can dynamically inter-act with them. The functionality these devices will beoffering, e.g. the provisioning of on-line sensor data, isoften referred to as real-world services because they areprovided by embedded systems, in the sense that theyreside inside an object of the physical world. Unlikemost traditional enterprise services and applications,which are entirely virtual entities, real-world servicesprovide real-time (in the sense of relative low-latency,not assuming any hard time guarantees) data about thephysical world. Taking into consideration this data andevaluating it in a specific business context can have allowfor a significant increase of knowledge and insight whenbusiness decisions taken. Hence, web service enableddevices glue IoT and IoS, by providing their functionalityas a web service in an interoperable way that can be usedby other entities such as enterprise applications or evenother devices. No device drivers are needed any moreand a new level of dynamicity can be achieved as webservice clients can be generated dynamically at run-timefor programmatic consumption of the services.

Trends show that in the future, a much more di-versified infrastructure will emerge, and the way weinteract with it will change significantly. As depicted inFig. 1, mash-ups of services will be created, that can becombined and used across various system layers. We willexperience horizontal collaboration e.g. among devicesin the Internet of Things plane, as well as vertical one


Fig. 1. Vision of cross-layer service mashups

via complex interactions among devices, online services,people etc. in the Internet of Services plane. Enterpriseapplications will be able to connect directly if neededto devices, without the use of proprietary drivers, whilenon web service-enabled devices can still be attached,having their functionality wrapped by gateways or at themiddleware layer. Peer to peer communication amongthe devices will push SOA concepts down to the devicelayer and create new opportunities for functionalitydiscovery and collaboration. In order to foster this collab-orative approach and unleash the dynamicity we needdynamic discovery, query, selection, and on-demandprovisioning of web services within all system layers,i.e. from devices up to enterprise systems running in thecloud or grid.

2 MOTIVATION AND APPROACH PHILOSOPHY

According to OnWorld [4], the global market for Wire-less Sensor Network (WSN) systems and services isexpected to skyrocket to about $4.6 Bn in 2011, up fromapproximately $500 million in 2005. There will be aworldwide (conservative estimate) market of $5.3B forthe industrial control segment only, comprising 4.1 Mil-lion nodes by 2010. OnWorld’s most aggressive forecastfor all wireless sensor (& control) network segments is$8.2B by 2010, comprising 184 Million deployed nodes.It is important to note that OnWorld projections onlyaccount for the physical node hardware shipments - notthe physical gateway hardware, nor any independentsystem software components, enterprise software com-ponents, system integration services or other ancillaryservices. Hence, their forecast for WSNs does not captureall areas of revenue. Even so, it is obvious that the busi-ness opportunities for real-world services are promising.As mass market penetration of networked embeddeddevices seems to be soon a reality, and services takingadvantage of the unprecedented ease of consumption ofdevice functionality will give birth to new innovative

applications and provide both revenue generating andcost saving business advantages. From a technologicalpoint of view, the key challenge is how to discover,assess, and efficiently integrate the new data points intobusiness applications.

Several efforts have explored the integration of real-world and enterprise services e.g. [5, 6]. However, theprotocols used do not offer uniform interfaces acrossthe application space and are complicated to integratewith traditional enterprise applications. To ensure in-teroperability across all systems, recent work has fo-cused on applying the concept of Service-oriented Ar-chitecture (SOA), in particular Web Services standards(SOAP, WSDL, etc.) directly on devices (e.g. [7–9]). Im-plementing WS-* standards on devices presents sev-eral advantages in terms of end-to-end integration andprogrammability by reducing the needs for gatewaysand translation between the components. This enablesthe direct orchestration of services running on devices,with high-level enterprise services, e.g. offered by anEnterprise Resource Planning (ERP) applications. Forinstance, sensors physically attached to shipments canoffer via Web Services their info and be easily integratedin a process that updates the status (e.g. temperature)and location of the shipment directly in the involvedERP systems.

Embedding SOA concepts at device level initiallyseems a good idea, however we have to keep in mindthat SOA standards were designed primarily for con-necting few, complex, and rather static enterprise ser-vices. As a consequence, implementing WS-* standardsdirectly on devices is not always straightforward. Unlikeenterprise services, real-world services are deployed onresource constrained devices, e.g. with limited comput-ing, communication and storage capabilities. This re-quires significant simplification, optimization, and adap-tation of SOA tools and standards. Additionally, real-world services are found in highly dynamic environ-ments where devices and their underlying services con-stantly degrade, vanish, and possibly re-appear. As such,this infrastructure can not be considered static and long-lived, as traditional enterprise services. This implies theneed for automated, immediate discovery of devices andservices as well as their dynamic management.

A crucial challenge for SOA developers and processdesigners is to find adequate services for solving a par-ticular task [10], which for enterprise services implies amanual query of a number of registries, typically Univer-sal Description and Discovery and Integration (UDDI)registries. The results depend largely on the quality ofthe data within the registry, which is entered manuallytherefore is prone to error. While this de facto approach isadequate for a rarely changing set of large-scale services,the same does not hold for the requirements of thedynamic real-world services. Registering a service withone or more UDDIs is rather complex, and does notcomply with the minimization of usage of the devices’limited resources. Furthermore extensive description in-


formation is necessary [11], while the device can onlyreport basic information about itself and the services ithosts. Trying to reduce the complexity of registration andservice discovery, different research directions have beenfollowed in order to provide alternatives or extensionsof the UDDI standard [10, 12, 13]. However these donot take into account the particular requirements of real-world services.

Based on our experience within SAP for developingreal-world services for the enterprises we introduce herea set of requirements to facilitate the querying and userdiscovery of real-world services from within enterpriseapplications:

1) R1: Minimal Service Overhead. As most real-world services are offered by embedded deviceswith (very) limited computing capabilities there isa need for a lightweight service-oriented paradigmwhich does not generate too much overhead com-pared to using functionality through the propri-etary (in best case also device-specific optimized)APIs.

2) R2: Minimal Registration Effort. A device shouldbe able to advertise its services to an open registryusing network-level discovery. The process shouldbe “plug and play”, without requiring human in-tervention. A device should also be expected toprovide only a small amount of information whenregistering.

3) R3: Support for Dynamic and Contextual Search.It should be possible to also use external sourcesof information to better formulate the queries. Fur-thermore, queries should go beyond simple key-word search and take into account user-qualityparameters such as context (e.g. location, Qualityof Service (QoS), application context). Support forcontext is essential as the functionality of mostdevices is task-specific within well-defined places(e.g. a building, a manufacturing plant, etc.).

4) R4: Support for On-Demand Provisioning. Ser-vices on embedded devices offer rather atomic op-erations, such as obtaining data from sensors. Thus,while the WSN platforms are rather heterogeneous,the services that the sensor nodes can offer sharesignificant similarities and could be (re)deployedon-demand per user request.

The key contribution of the work presented here isa service discovery process for real-world serviceswe initially introduced in [14], shown on Figure 2 anddescribed in detail in section 5. The goal of this process,called Real-World Service Discovery and ProvisioningProcess (RSDPP), is to assist the developers in thediscovery of real-world services to be included in com-posite applications. This innovative process fulfills therequirements of real-world services we described (R1 toR4) above as follows:

In order to ensure a minimal overhead (R1) for pro-viding the functionality of embedded devices as service

we propose two approaches. In the first one we use theDevice Profile for Web Services (DPWS) [7, 15] and itsdynamic discovery mechanism. DPWS defines a limitedset of WS-* standards which are implementable on rel-atively resource-constrained devices. We will describeDPWS in section 4.1.

As an alternative to fulfill requirement R1 we alsointroduce the design of Resource Oriented real-world de-vices, that is embedded devices providing their function-ality through a RESTful API [16–18]. REST (Representa-tional State Transfer) [19] is the architectural principlethat lies at the heart of the Web and shares a similargoal with DPWS, which is to increase interoperabilityfor a looser coupling between the parts of distributedapplications. We further describe the concept of resource-oriented real-world devices in section 4.2.

The minimal registration effort (R2) requirement is metby using the DPWS [7, 15] and its discovery mechanism.In section 4.2 we also describe how Resource Orienteddevices can also fulfill this requirement.

We further ensure the minimal registration (R2) effortand support for dynamic search (R3) by extending userprovided keywords with vocabularies of related termsalso known as “lightweight ontologies” [20]. We gener-ate these terms dynamically, by using semi-structuredweb resources like Wikipedia and Yahoo! Web Search.This part of the process called Query Augmentation, isdescribed in section 5.1.

The dynamic search requirement (R3) is also fulfilledby taking into account the user context and matchingit with the extracted context of real-world services. Thisuser quality information is then used for adequate ser-vice selection when retrieving and ranking services asexplained in section 5.2.

The requirement for on-demand dynamic provisioning(R4) is fulfilled by a software architecture that enablesthe developer to automatically deploy services on de-vices when no requirement-satisfying service was foundin the environment [21]. This architecture is described insection 5.3.

Finally, we present our implementation within anenterprise application (based on Java Enterprise Editionand SAP NetWeaver) as well as its deployment andvalidation of our results in section 6.

Before describing the process itself we start with anoverview of the framework in which the RSDPP wasdeveloped and how devices can register themselves andadvertise their services in an automated manner.

3 THE SOCRADES INTEGRATION ARCHI-TECTURE

The process described in this article has been developedand implemented as part of the SOCRADES IntegrationArchitecture (SIA) [8, 22, 23], which is depicted in figure3. The role of SIA is to enable the ubiquitous integrationof real-world services running on embedded deviceswith enterprise-level applications. Web Service standards


Fig. 2. Overview of the Real-World Service Discovery andProvisioning Process (RSDPP).

constitute the de facto communication method used bythe components of enterprise-level applications, and forthis reason SIA is fully based on them. In this manner,business applications can access near real-time data froma wide range of networked devices using a high-level,abstract interface based on Web Services. This enablesany networked device that is connected to the SIA todirectly participate in business processes while neitherrequiring the process modeler, nor the process executionengine to know about the exact details of the underlyinghardware.

The SIA has been described in [23], and here we onlydescribe a few particular components of the whole ar-chitecture. SIA is basically split into two parts: A “local”part which features also a Local Discovery Unit (LDU)and is running at the local network that contains thedevices to be integrated and a central system (anywhereon the network or even Internet) that hosts enterprise-level applications. Although the quantitative relationbetween both subsystems is m:n, in a typical single-purpose set-up there will be only one central system andone or more on-premise systems. In a multi-Enterprisecollaborative landscape however, we would witness sev-eral “central” systems collaborating and possibly various“local” systems reporting to more than one “central”ones.

In the local subsystem at Devices Layer there aredifferent embedded devices that are running differentservices. SIA is able to interact with devices using sev-eral communication protocols, such as DPWS, OPC-UA,REST, etc. In this article, however, we focus solely ondevices that are connected to SIA using web services andfor our experiments we have used DPWS. Nevertheless,since DPWS-enabled devices support Web Services, theyalso can bypass SIA for a direct connection to EnterpriseApplications, which is desirable in some use cases, butnot for the majority of foreseen ones. Furthermore, SIAallows applications to subscribe to any events sent bythe devices, offering a publish/subscribe componentby providing a WS-Notification compliant Notification

Local / On Premise Set-Up

Shop-floor and other Devices

Local Discovery Unit

Device Service Proxy

DPWSplug-in (DSP)

Restplug-in

other /3rd party

DPWS-EnabledDevices

Rest-BasedDevices Legacy Devices

Gateway / Mediator

Back-end Connector

Enterprise ServiceProxy Factory

Device ServiceInjector

DPWSplug-in (ESPF)

Central / Remote / Cloud System (Java EE)

Eventing(WS BrokeredNotification)

R

SubscriptionPool

MiddlewareArchiver

DeviceMonitor

ServiceMonitor

ServiceImplementation

Repository

SIRManagement

R

R

DRManagement

DeviceRepository

DataArchive

Administrator / Operator

Administrative GUI

ApplicationServiceCatalog

R

InvocationHandler

ComposedServicesRuntime

SAP Applications(ERP, CRM,

SCM, SRM, …)

Configuration

ConfigurationPool

Security PolicyEnforcement

Point

Local OrchestrationEngine

Security PolicyStore

Fig. 3. The SOCRADES Integration Architecture (SIA)

Broker (hosted in the central part). It also offers bufferedinvocations of hosted services on devices that are onlyintermittently connected, by receiving notifications whenthe device becomes available again or having the systemcache the message and delivering it when the device isready to receive it. As such SIA is a vital componenthiding and managing the complexity of real-world land-scapes from the enterprise service developers, easingtheir tasks.

The key component that connects the local subsystemwith the central one is the local discovery unit (or LDU).The LDU scans the local network for DPWS devices andreports their connecting and disconnecting to the centralsystem. Some of the advanced features of the LDU are alightweight, local orchestration engine that allows for au-tonomous execution of local processes, a device serviceinjector that is able to change the embedded software inorder to (un)deploy or (re)configure embedded services,and an enterprise service proxy factory that can makeremote services from the central system available inthe local network (embedded ERP). All this is realizedby web service calls only from the LDU to the centralsystem, therefore allowing for firewall-friendly operationalso working through a http(s) proxy.


In the central subsystem, we have implementedhigher-level components to ease the management anduse of devices in a standardized and uniform way. TheDevice Repository holds all dynamically acquired butmostly static device information (metadata) of all on-lineand off-line devices (of all connected local subsystems),while the Device Monitor contains information aboutthe current state of each device. The Device Monitor actsas the single access point where enterprise applicationscan find all devices even when they have no direct accessto the shop floor network or such access is not wished(e.g. flooding of shop-floor with discovery messages).

At the same time, information about the differentservices hosted on the device (typically described usingWSDL) will be retrieved and forwarded using an eventto the Service Type Repository and Service Monitor asshown on Figure 2. The former only contains informationabout the service types without their respective end-point references, the latter contains information aboutthe available service instances hosted by the devices andtheir endpoint references, and also installable servicetypes. The Service Type Repository acts as a facade forquerying the underlying repositories and monitors forpointers to running service instances.

4 NETWORK DISCOVERY OF EMBEDDED DE-VICES

As the number of embedded devices appearing in shop-floor systems increases, so are also the incentives toconnect them to ERP systems. Along with increasinglydynamic infrastructures as mobile devices appear ordisappear from the network at operation time, there is astrong need for tools to simplify the management andinterconnection of networked devices. Discovery is acentral process in ubiquitous and distributed computingand many protocols have been proposed for differentpurposes: network discovery of devices, service dis-covery, search of information, and so so on. Many ofthose protocols focus on “service discovery”, such as theService Location Protocol (SLP), Universal Plug and Play(UPnP), Device Profile for Web Services, Sun’s Jini, orApple’s Bonjour.

A similar mechanism for zero-configuration networks,where devices can join the network and discover dynam-ically the services offered by other devices, is necessaryin future enterprise scenarios, therefore we propose inthis section two mechanisms we have used for networkdiscovery of devices to be integrated in our system.

As depicted in Figure 4, the process of finding out realworld services running on physical devices can be doneas follows:

1) this is the classic WS-Discovery (both active andpassive)

2) this is the RESTful active discovery, where a devicesignals its presence to the LDU

3) this is the passive REST discovery for devicesthat do not comply with SIA discovery, which is

LDU

DEVICES DPWSSIA compliant

RESTSIA compliant

RESTNOT SIA compliant

DPWSconnector

RESTconnector

2 31

WS-Discovery Active discovery Forced discovery

Fig. 4. Discovery process of real-world services onphysical devices

triggered by passing the URI of the device to beregistered in the system as a parameter of theforced discovery method call

4.1 Real-World DPWS Web ServicesDPWS defines a minimal set of implementationconstraints to enable (secure) Web Service messag-ing, discovery, description, and eventing on resource-constrained devices. Its objectives are similar to thoseof Universal Plug and Play (UPnP) but, in addition,DPWS is fully aligned with Web Services technologyand includes extension points, allowing for seamless in-tegration of device-provided services in enterprise-wideapplication scenarios. The DPWS specification defines anarchitecture in which devices run two types of services:a) hosting services and b) hosted services. Hosting servicesare directly associated to a device, and play an importantpart in the device discovery process. Hosted services aremostly functional and depend on their hosting devicefor discovery. Hosting services comprise of: discoveryservices used by a device connected to a network toadvertise itself and to discover other devices, metadataexchange services to provide information about a deviceand the hosted services on it, and asynchronous publishand subscribe eventing, allowing to subscribe to asyn-chronous event messages produced by a given hostedservice.

4.1.1 Network Discovery of DPWS DevicesAs real-world services run natively on embedded de-vices, we need a robust mechanism to dynamically finddevices as they connect to the network, and dynamicallyretrieve metadata about the device and the services ithosts. Furthermore, we want mechanism to fulfill therequirement for a minimal registration effort. To achievethis, we use DPWS which follows the WS-Discoveryspecification. When a new device joins the network, itwill multicast a HELLO message via the UDP protocol. Bylistening to this message, clients can detect new devices


and in a second step retrieve their metadata. This inturn triggers the sending of an appropriate message tothe SOCRADES Device Monitor, containing the device’sstatic metadata. The metadata information can be classi-fied into a certain set of metadata classes, and is requiredfor searching services according to more detailed criteria.This data about the device is stored by the higher unitsfor future usage.

Filter information is included in a Probe message sentto a multicast group; devices that match the probesend a ProbeMatch response directly to the client (inunicast mode). Similarly, to locate a device by name,a client sends a Resolve message to the same multicastgroup and the device that matches sends a ResolveMatchresponse directly to the client. After this network-levelscan, the result set can be further narrowed by matchingkeywords or textual information that describe both static(device type, available sensors on board) and dynamicproperties of devices (QoS, physical location, availablebattery life, network connectivity, available sensors).

The DPWS metadata of devices and services can beclassified in different categories, as follows:

• Scopes a set of attributes that may be used toorganize devices into logical or hierarchical groups,e.g. according to their location or access rights.

• Model and Device metadata provides informationabout the type of the device like manufacturer name,model name, model number, etc. as well as infor-mation on the device itself such as serial number,firmware version and friendly name.

• Types are a set of messages the device can sendand/or receive; these can be either functional WSDLport types (e.g. ’turn on’, ’turn off’) or abstract typesgrouping several port types and/or hosted services(e.g. ’printer’, ’lighting’, ’residential gateway’).

• Links to WSDL document (i.e. URLs), containingthe port types (operations and message structures)implemented and the endpoint of hosted services.

4.2 RESTful Services for the Real-World

The architectural principle that lies at the heart of theWeb, namely Representational State Transfer (REST) asdefined by Roy Fielding [19], shares a similar goal withmore well known integration techniques such as WS-*Web services (SOAP, WSDL, etc), which is to increaseinteroperability for a looser coupling between the partsof distributed applications. However, the goal of RESTis to achieve this in a more lightweight and simplermanner seamlessly integrated to the Web. In particular,REST uses the Web as an application platform and fullyleverages all the features inherent to HTTP such asauthentication, authorization, encryption, compression,and caching. This way, REST brings services “into thebrowser”: resources can be linked and bookmarked andthe results are visible with any Web browser, with noneed to generate complex source code out of WSDL filesto be able to interact with the service. Indeed, requests

for services (i.e. verbs on resources) are formulated usinga standard URI. For instance, typing a URI such ashttp://.../spot1/sensors/temperature in a browser, canbe used to request the resource “temperature” of theresource “sensor” of “spot1” with the verb GET.

Traditionally, REST has been used to integrate web-sites together. However, the lightweight aspect of RESTmakes it an ideal candidate for resource-constrained em-bedded devices to offer services to the world [16–18, 24].Since many such devices usually offer rather simpleand atomic functionalities (for example reading sensorvalues), modeling them using REST is often straightfor-ward. Still, it is important to note that REST servicesalso have certain limitations and do not always solveproblems in a straightforward manner. For instance, theinherent simplicity of REST paradoxically complicatesthe creation of highly complex services. While RESTservices are well adapted for rather services, which coverthe a great part of services available on embedded andreal-world device, their limitations become evident whenit comes to modeling services which require complexinput and/or deliver complex outputs. Based on ourown experience and the experience of others [25] inmore traditional integration patterns such as WS-* WebServices, we suggest that WS-* services are to be pre-ferred for highly complex real-world integration andrather static use-cases, such as those involving compli-cated business processes or requiring high reliability,for example composing a manufacturing process onseveral machines. However, for smaller and more user-oriented applications, the RESTful approach offers manyadvantages such as light and simple use, browsability ofservices, and a much looser coupling. Thus, our decisionto support both DPWS and REST enabled devices.

4.2.1 Network Discovery of Resource Oriented DevicesHTTP has been designed as a high-level applicationprotocol, therefore the notion of discovery is not partof HTTP specifications. In the modern Web, resourcesare discovered by simply following links from otherresources, but this model requires to know beforehandresources identifiers to link to them, therefore is notsuited for discovering new devices that appear on thenetwork. To counter that, mRDP [26] was proposedas a simple HTTP-based semantic resource discoverymechanism. In our approach, we focus apart from theWS-Discovery based one also on a RESTful discoverymechanism. In the passive discovery, each device mustannounce itself using a HELLO mechanism (exactly asin the DPWS discovery case), however, upon recep-tion of the acknowledgment from the LDU, the devicewill generate a PUT request on the LDU REST server,and register itself into the LDU using a predefined (orpreagreed but dynamically resolved) device registrationprocedure.

However, one cannot generally expect general-purpose RESTful devices to be compliant with SIA dis-covery mechanism, but only to possess a RESTful API.


In this case, one needs to force the discovery (active)upon the device, by issuing a GET request on the devicepage. The LDU will parse the page contained at thisURL and retrieve the necessary information from thedevice. The device page a machine-readable RESTfulAPI is described using metadata contained in a spe-cific microformat (see www.microformats.org) we havedeveloped. The metadata contained in the microformatis the same as the metadata as used in the discoveryprocess of DPWS devices, so that the same informationis contained in the service repositories of the architecture.

5 REAL-WORLD SERVICE DISCOVERY ANDPROVISIONING PROCESS (RSDPP)After describing the way devices and their services areadvertised, this section describes the RSDPP and itsunderlying steps. As illustrated in Figure 2 step 1, theprocess begins with a Types Query after the network dis-covery of devices has been executed. In this sub-processthe developer uses keywords to search for services, ashe would search for documents on any search engine.This query is then extended with related keywordsfetched from different websites, and used to retrievetypes of services that describe the functionality, but notyet the real-world device it runs on. This is the taskof the Candidate Search where the running instancesof the service type are retrieved and ranked accordingto context parameters provided by the developer (Fig2, step 2). In case no service instance has been foundthe process goes on with Provisioning. It begins with aforced network discovery of devices, where the devicesknown to provide the service type the developer islooking for are asked to acknowledge their presence(step 3). If no suitable device is discovered, a serviceinjection can be requested. In this last step the systemtries to find suitable devices that could run the requestedservice, and installs it remotely (step 4).

5.1 Types Query

In the first part of the discovery process (step 1 on Figure2), the developer or process designer enters keywordsdescribing the type of service s/he wants to find (step1 on Figure 5). A Service Type is a generic WSDL filedescribing the abstract functionalities of a real-worldservice, but not bound to any particular end-point ofa concrete real-world device. The entered keywords willbe sent to the Query Augmentation module which isgoing to extend the query with additional keywords. Theoutput of this module is then used to retrieve and ranktypes of services according to user-quality parameterssuch as the current user context.

5.1.1 Query Augmentation and AssistantIn conventional service discovery applications, the key-words entered by the user would be sent to a ServiceRepository to find types of services corresponding to

Fig. 5. Looking for a Service Type.

the keywords. The problem with this simple keywordmatching mechanism is that it lacks flexibility. For in-stance, a developer that wants to find services offeredby a “smart meter”, a term often used to describe anext generation device that can measure the energyconsumption of other devices and possibly control themdepending on built-in logic. Typing “smart meter” only,will likely not lead into finding all the corresponding ser-vices, because services dealing with energy consumptionmonitoring might not be tagged with the “smart meter”keyword but simply with “electronic meter” etc. Wewant to avoid the construction of domain ontologies, andto minimize the amount of data that embedded devicesneed to provide upon network discovery of device andservice registration. Thus, we propose a system that usesservices on the web to extend queries without involvingcommunication with the embedded devices or requiringcomplex service descriptions from them. This is thequery augmentation shown on step 2 of Figure 5.

The idea is to use existing knowledge repositoriessuch as web encyclopedias (e.g. Wikipedia) and searchengines (e.g. Google, Yahoo! Web Search), in order toextract “lightweight ontologies” [20] or vocabularies ofterms from their semi-structured results. The basic con-cept of the query augmentation (step 2 on Figure 5) is tocall 1..n web search engines or encyclopedias with thesearch terms provided by the user, for instance “smartmeter”. The XHTML result page from each web resourceis then automatically downloaded and analyzed. Theresult is a list of keywords, which frequently appearedon pages related to “smart meter”. A number of the re-sulting keywords are thus related to the initial keywords“smart meter” and therefore can be used when searchingfor types of services corresponding to the initial input.

An invocable web-resource together with several fil-ters and analysis applied to the results is called a QueryStrategy and their structure is based on the StrategyPattern [27], which enables us to encapsulate algorithms


into entirely independent and interchangeable classes.This eases the implementation of new strategies based onweb resources containing relevant terms for a particulardomain. This is depicted on Figure 6, a simplified classdiagram of the Query Strategy framework. Any QueryStrategy has to implement the AbstractStrategy classwhich provides the general definition of the algorithm.As an example the YahooStrategy is a concrete imple-mentation of this algorithm using the Yahoo! Search ser-vice. Furthermore, strategies can have extensions addingsome functionality to a concrete instance of a QueryStrategy. As an example the WikipediaStrategy can beextended with the WikipediaBacklinks class. This partic-ular extension is using the backlinks operation offeredby Wikipedia in order to know what pages are linkingto the currently analyzed page similarly to what thewell-known PageRank uses to rank websites [28]. Thisinformation is then used by the WikipediaStrategy tobrowse to related pages and gather relevant keywords.

Furthermore, Query Strategies can be combined in or-der to get a final result that reflects the successive resultsof calling a number of web-resources. The resulting listof related keywords is then returned to the developer inthe Query Assistant, where s/he can (optionally) removekeywords that are not relevant (step 3 of Figure 5).

The implementation of the Query Strategy architecturemakes it easy to test combination of several strategiestogether with their extension. We implemented a numberof these and their evaluation is presented in section 6.2.

Fig. 6. Architectural overview of the Query Strategiesbased on the Strategy and Template software designpatterns.

5.1.2 Service Type LookupThe augmented query is used to determine any matchingservice types in the Service Type Repository (step 4 andstep 5 on Figure 5). All service types that match anyof the keywords supplied are found, both those manu-ally entered and those determined automatically by theaugmentation step. The query keywords are matchedagainst all metadata of a service type, which was sent tothe Service Monitor upon network discovery or extended

by manual entry. This includes human readable descrip-tions, contact information, legal terms, explicit keywordsand interface descriptions (WSDL). Additionally, struc-tured technical metadata is considered, e.g. dependencyinformation between service types, and requirements ofthe service type on underlying hardware. The result ofthe Service Type Lookup is a list of service types thatpotentially support the functionality the developer islooking for.

5.2 Candidate Search

Fig. 7. Ranking and optionally Provisioning Service In-stances.

Real-world devices are volatile e.g. connect and dis-connect thus we need to decouple the discovery ofservice types from the discovery of actual instances ofservices. The Candidate Search (step 2 on Figure 2)models the discovery of running service instances. Thefirst step in this sub-process is for the developer to selectthe suitable types of services by browsing their details(step 1 on Figure 7). Alternatively s/he can select all thetypes retrieved in the Types Query part of the process.

5.2.1 Context ExtractorOne of the main differences between real-world serviceand virtual services is that real-world services are di-rectly linked to the physical world. As a consequence,the context in which a service exists as well as the contextin which the user initiates the discovery of a service ishighly relevant. Context is information that qualifies thephysical world, and it can help in both reducing thenumber of services returned to the developer, as well asin finding the most appropriate services for the currentenvironment [29].

To satisfy the requirements of real-world service dis-covery, we propose modeling the context by two distinctparts inspired from [30]: the digital environment, which


we define as everything that is related to the virtualworld the developer is using, and the physical environ-ment, which refers to properties of the physical situationthe developer currently is located in or wants to discoverservices about.

The digital environment is composed of ApplicationContext and Quality of Service. The Application Contextdescribes the business application the developer useswhen trying to discover services, e.g. the type of ap-plication s/he is currently developing or the languagecurrently set as default. Such information co-determinesthe services a developer is looking for and can reduce thescope of the discovery. The QoS Information reflects theexpectation of the developer (or of the application s/heis currently using) in terms of how the discovered serviceis expected to perform. Our current implementation sup-ports service health and network latency, i.e. the currentstatus of the service and the network transmission delayusually measured when calling it.

The physical environment is mainly composed of in-formation about location. Developers are likely to belooking for real-world services located at a particularplace, unlike when searching most virtual services. Wedecompose the location into two sub-parts following theLocation API for Mobile Devices (as defined in JavaSpecification Request JSR-179). The Address encapsu-lates the virtual description of the current location, withinformation such as building name, building floor, street,country, etc. and the Coordinates are GPS coordinates.In our implementation the location can either be au-tomatically extracted e.g. if the developer looks for areal-world service close to her location, or it can beexplicitly specified if s/he wants a service located closeto a particular location e.g. in a form of radius.

In the RSDPP Context, extraction on the developerside is done at step 2 of Figure 7. It is worth noting thatthe context on the developer side is meant to reflect theexpectations or requirements with regard to the servicesthat are going to be returned. As an example, during thisphase the developer can express the wish for a service tobe physically close to his/her current location. Or s/hecan quantify the importance of context parameters suchas Quality of Service.

This user-quality information is then going to becompared to the service and device side context by theService Instance Ranking component (see section 5.2.3)in order to select and rank the most relevant serviceinstances.

5.2.2 Service Instance SearchIn step 3 of Figure 7, the identifiers of the selected servicetypes and the context object extracted on the user-sideare sent to the Service Monitor. This component is thelink between service types and running instances ofthese services. Thanks to the dynamic network discoveryof devices (explained in section 4.1) the Service Monitorand the Device Monitor know what devices are currentlyproviding what service types. In steps 4 and 5 of Figure

7, the Service Monitor queries the Device Monitor forthe context of the selected service instances. The digitalenvironment context parameters such as the Quality ofService is derived from polling the devices from time totime as well as by monitoring the invocations of servicesand calculating their execution time.

Getting the context parameters related to the physicalenvironment of service instance is slightly more com-plicated. Indeed, as an example it can not be expectedfrom each real-world device to know its location. Thus,we suggest taking a best effort strategy where eachactor of the discovery process is trying to further fillthe context object. As an example consider a mobilesensor node without a coordinate-resolving module (e.g.a GPS). When discovered by the Local Discovery Unit(see section 4.1 and Figure 3), the sensor node does notknow its location and thus can not fill the Address andCoordinates fields of the context object. The LDU how-ever, is a static component of the network infrastructureand thus can be setup in order for it to know its locationand current address. As a consequence the LDU can fillthe Address and Coordinate fields of the sensor nodewith its own location (within a specific radius). Whilenot entirely accurate in regards to the sensor’s exactlocation this information will already provide a hintwhich can be valuable for the developer. In the futuremore sophisticated methods can be taken at device orLDU level (especially if any of these is mobile) e.g. [31] inorder to acquire accurate-enough location info. Similarly,since we can not expect every LDU to provide a fullcontextual profile, the Service Monitor has its own de-fault context component which can again used to extendthe information the device and LDU provided. The finalcontext information is packed into a context object foreach device running the selected Service Instances.

5.2.3 Service Instance RankingThe Service Instance Ranking component is responsiblefor sorting the instances according to their compliancewith the context specified by the developer or extractedfrom his machine. As shown in step 6 of Figure 7 theService Instance Ranking component receives a numberof service instances alongside with their context object. Itthen uses a Ranking Strategy to sort the list of instancesfound. For example, a Ranking Strategy could use thenetwork latency so that the services will be listed sortedaccording to their network latency, another could rankinstances according to their compliance with the currentlocation of a user or the target location s/he provided.The design of the component is open enough and couldbe extended to accommodate emerging research e.g. [32–34] on matching and ranking that needs however tobe adapted to consider the specifics of the real-worldservices.

As for Query Strategies (see section 5.1.1), Rankingstrategies can well be modeled using the Strategy pat-tern. This way new strategies can be easily implementedand integrated. Furthermore, we extend the pattern


to support chained ranking strategies in order for theresulting ranking to reflect a multi-criteria evaluation.Furthermore, each ranking criterion can use both thecontext information of the instances gathered duringthe Service Instance Search and the context informationextracted on the developer side in step 2 of Figure 7.Thus, instances can be ranked against each other or/andagainst the context of the developer (e.g. her location).The output of the ranking process is an ordered listof running service instances corresponding both to theextended keywords and to the requirements in terms ofcontext expressed by the user.

5.3 On-Demand Service Provisioning

In case no running service instance has been found, On-Demand Service Provisioning will be carried on. Thiswill first dynamically discover devices on the networkthat offer services matching the requirements of thedevelopers. In the last instance, installation of serviceson suitable devices will be carried out.

5.3.1 Forced Network Discovery of Devices

As discussed in section 4.1, passive discovery can beunreliable depending on the mechanism used. This isdue to the fact that UDP is used, which provides anunreliable service where datagrams may arrive out oforder, appear duplicated, or simply get lost withoutnotification. Furthermore, this mechanism might take along time to propagate across the whole system (espe-cially when we have thousands of on-device servicese.g. [35]), as UDP packets are multicasted only in localnetworks. When up-to-date information is needed, theforced discovery mechanism (also called active discovery)shall be used, particularly within dynamic environmentswhere devices with unknown capabilities continuouslyconnect to or disconnect from the network. This dynamicprocess can use different types of filters to specify thedevice type of the scope in which the device resides, andother additional semantic information. This is useful torestrict the result set when looking for new devices, asonly devices matching the specified criteria will respond.

5.3.2 On-Demand Service Injection on Devices

In case that even after forced network discovery ofdevices, no service instances that match the query havebeen identified, the system tries to generate appropriateinstances by injecting (i.e. remotely installing) the iden-tified service types. This involves finding devices thatare capable of hosting the service, and actually installingit in a platform-dependent way. This is possible if thedescriptions of the service types identified in previoussteps include installation instructions and executablesoftware artifacts.

In the Service Repository, for each service type, weprovide data structures for deployable artifacts, includ-ing (dynamic and static) hardware requirements and

dependency relations between services. These require-ments are compared with the capabilities and states ofthe currently available devices. An efficient service todevice mapping is calculated and platform-specific in-jection actions are taken to change the system accordingto the mapping. Once the injection finished successfully,control is handed back to Service Instance Ranking,which will use the Service Monitor again to discover thenewly installed Service Instances.

In a concrete example, the service description of afire detection service could include both DPWS bundlefor installation on an DPWS-enabled sensor platformand a rule set for a rule-based sensing system. Metainformation makes sure that the bundle and the rule setare only applied to the appropriate platforms. Furtherinformation for deployment can be included, like thedesired coverage (e.g. 80 % of all nodes), dependency onother services, e.g. a temperature measurement serviceand a fire shutter control service. If the service to bedeployed is annotated to depend on other services, thosecan be deployed as well. Further metadata may includethe flash or RAM memory required to install the newservice. Our efforts on service mapping and injection aredescribed in detail in [21].

6 PROCESS EVALUATION

Fig. 8. Search User Interface, looking for instances ofservices in the Application Service Catalogue

A prototype of the described process was imple-mented and integrated to the SOCRADES IntegrationArchitecture. The prototype implementation was devel-oped in Java and deployed on a Java Enterprise Appli-cation Server (SAP NetWeaver) at two distinct locations.The evaluation of the prototype was split in three partsfollowing the sub-parts of the Real-World Service Dis-covery Process.

The first step in evaluating the implementation of theprocess was to get a number of DPWS-enabled devicesoffering services to search for. Unfortunately since DPWSis still a rather new standard its adoption on industrialdevices is ongoing thus, we decided to simulate a larger


number of devices that one could expect finding infuture industrial environments. Since developers usuallywrite the description of Web Services [10], we selectedseventeen experienced developers and asked them towrite the description of a selected device and of at leasttwo services it could offer. The developers were giventhe documentation of a concrete device according to theirown skills and business. Based on these descriptions wegenerated thirty types of services (described in WSDLcontaining DPWS metadata) for sixteen different smartdevices ranging from RFID readers to robots and sensorboards. Out of these, one thousand service instanceswere simulated at the two deployed locations.

This work further extended the simulation by imple-menting them on a prototyped shop floor in a labo-ratory and industrial setup in two different scenariosbriefed in sections 6.4. The locations were spannedacross cities and countries using Internet as the com-munication backbone for these services and inter op-erations. Common shop floor devices like temperatureand vibration sensors were identified. SunSPOT sensors(www.sunspotworld.com), gantry robots, PLC devicescontrolling conveyor belts and proximity sensors fromleading industrial vendors were wrapped with (DPWS)web services or directly deployed service instances onthe devices themselves.

The prototype of the SOCRADES Integration Archi-tecture was used in the back end to monitor, searchand compose services offered by these devices. The localdiscovery unit of the SOCRADES Integration Architec-ture was used at different locations in the field trialsto dynamically discover devices on the prototyped shopfloor.

6.1 Search User Interface

A search (or discovery) Web user interface (UI) wasdeveloped (shown on Figure 8) on the top of the JavaEnterprise implementation of the RSDDP. This UI offersseveral interaction zones corresponding to the steps ofthe process and allows the developer to feed his feedbackinto the discovery loop at every step of the process.

In the first zone (1. Search Form) the developer isasked to enter 1..n keywords. These keywords are thenextended with related words by the Query Augmenta-tion and Assistant module (see section 5.1.1 and step 1on Figure 2), as shown in the second zone (2. QueryAugmentation). In this zone the user can also choose toremove extend words before performing a Service TypeLookup (second part of step 1 and section 5.1.2). Theresult of this latter is shown in the third zone (3. SearchResult - Types of Services) is a list of all the types ofservices corresponding to the extended keywords. Thedeveloper then selects the types he is actually interestedin. To help him identifying these a table provides adescription of each type as well as all its currentlyassociated tags. Additionally, the developer can tag theservice types with new keywords if she thinks relevant

Fig. 9. Results for the Query Augmentation with Yahoo!and Wikipedia

tags are still missing. Once the service types selected theCandidate Search is performed (step 2 on Figure 2 andsection 5.2. The result of this execution (zone 5. Result- Service Instances) is a list of running instances forall the selected types. As mentioned before, to facilitatethe final selection of a service, the instances are rankedaccording to the context parameters extracted on thedeveloper side. As an example the service instanceson Figure 8 are sorted according to three combinedparameters: network latency, service health and location(with respective relevance levels of 10%, 30% and 50%).

Before taking the final decision on what service toselect the instances can be tested. In the case of a(DP)WS service a click on a instance results in openingits complete WSDL file, a further click on a link opensthe Web Service Navigator of SAP Netweaver to allowtesting the service. In the case of a REST service a clickon an instance directly retrieves the identifier of theservice (i.e. a URL) and allows for direct testing withinthe browser.

Finally, if no running instances were found for any ofthe selected types, the developer can choose to force thediscovery of instances (step 3 on Figure 2 and section5.3) or to perform an injection of the selected types onappropriate embedded devices and sensor nodes (zone4. Actions on Types of Service).

6.2 Evaluation of Types Query and CandidateSearchIn the evaluation of the Query Augmentation modulewe wanted to know whether:

1) Augmenting user input with related keywordscould help in finding more real-world web services

2) What type of combination of query strategies is themost suitable.

Two types strategies were used. In the first strategywe used a human generated index (Wikipedia), and inthe second a robot generated index (Yahoo! Web Search).


The input keywords were selected by seven volunteers,all working in IT. They provided seventy-one searchterms (composed of one to two words) that they couldimagine using when searching for services provided bythe seventeen devices. These terms where entered oneby one and all the results were logged.

The trend extracted from these experiments is shownon Figure 9. Two results can be extracted. First the QueryAugmentation process does help in finding more real-world services. Without augmentation 75% of the servicetypes were found using the query augmentation up toa 100%. However, Query Augmentation does generatea number of false positives (i.e. service types that arereturned even if they are not related to the providedkeywords). Thus the need to restrict the number of key-words added to the intitial ones. The observed optimumis between 5 and 10 added keywords, leading to out95% of types of services found for less than 20% falsepositives. Secondly it can be seen on Figure 9 that usingYahoo! performs slightly better than Wikipedia. This re-sult actually needs to be constrasted. Indeded, about 50%of the keywords used against Wikipedia did not lead toany page because they do not have dedicated articlesyet this even if Wikipedia grows at a rate of about 1500articles per day (source: http://en.wikipedia.org/wiki/Wikipedia:Size of Wikipedia). However, when resultswhere extracted from Wikipedia pages they were actu-ally more relevant for the searched real-world services.Thus, a good solution would be to chain the strategies sothat first human generated indexes are called and thenrobot generated ones in case the first part did not leadto results.

The Candidate Search was evaluated based on a proofof concept evaluation. We tested two chained rankingstrategies for the generated services, one comparingservice health and given weight of 30 out of 100 as wellas one comparing network latency and given a weightof 50. They performed as expected, sorting the listsof retrieved service instances according to the rankingstrategies which, we believe helps developers findingtheir way across the results but would need to be testedwith neutral volunteers. We implemented the sortingusing the merge sort algorithm which has a complexityof O(n log n), since the strategies can be chained we havean overhead for the ranking of O(mn log n) where m isthe number of strategies and n the number of ServiceInstances.

6.3 Evaluation of On-Demand Service Provisioning

A key result of our contribution includes the on-demandprovisioning of real-world services. This can be the resultof not being able to find a suitable running service, oreven because the possible existence of such a service ona specific device would result in better satisfying therequirements e.g. better performance. Our implementa-tion of the on-demand provisioning part was done usingadaptations of well-known algorithms, which resulted

Fig. 10. Trial of the SIA in an multi-location, cross-networkreal-world scenario

to NP-hard approaches for service to device mapping[21]. Both probabilistic / efficient (O(nk)) and complete/ inefficient (O(nk)) algorithms have been implemented.Some evaluation was done using test scenarios, in whichthe probabilistic algorithms produced results close tothe optimum, with respect to a given objective function.A proof of concept implementation demonstrated theservice mapping and deployment both on simulated andreal devices (PDA-scale). Flexibility is achieved by usingexchangeable strategies for each step of the mappingprocess that can be exchanged at run-time through con-figuration. This approach is also scalable, since most ofthe components can be easily replicated and distributedacross different locations. A detailed evaluation and dis-cussion of the on-demand service provisioning is givenin [21].

6.4 Demonstrator and Field Trial

In the recent years we have witnessed the SOA conceptsstarting to be successfully applied to the shop floors offuture factories. Especially with devices being able tooffer their functionality as a service, SOA platforms caneasily integrate them. The key motivation for evaluatingthe prototype was to identify the feasibility of SOA basedcross-location infrastructure in real-world situations. Inthe demonstrated scenario multiple heterogeneous phys-ical devices on the shop floor were discovered, theservices to be composed were identified and used basedon the RSDPP. In particular, DPWS and RESTful webservices were deployed with the aim to evaluate part ofthe aforementioned concepts on real data and events.

In the trial, a manufacturer operates in two distinctgeographical locations (marked as “Location A” and“Location B” in Figure 10), that also belong to differentnetworks and are behind firewall/proxy without di-rect connections between the shop-floors. At company’sheadquarters a running ERP system governs the overall


operations with respect to the two locations. A pro-duction order is issued from the head quarters to itsproduction facilities at location A. During the course ofproduction, a severe unpredictable failure of machinescauses the production to be stopped at location A. Sucha scenario occurs often in production plants where thestop per hour could run to a loss of thousands of dollars.

In this scenario the ERP system at the headquartersis immediately alerted about the current loss and anestimated delay in completing the production order.Subsequently the ERP evaluates alternative scenariosin order to satisfy the customer’s order and decidesto relocate the remaining of the production order tolocation B. It also arranges for the already producedparts of location A are to be transfered to a storageroom where the parts from location B will also arrivein order to complete the shipment to the customer. TheERP evaluates location B and its resources, continuesthe rest of the production and redeems the waiting timefor the customer. The entire operation is split in two -design and run time phases. During the design time,the services hosted on the devices at these facilities arediscovered. They are composed to an service mashup byusing the RWSPP. In the second phase - run time phase,the actual scenario is being executed.

Design time: The SOCRADES Integration Architectureidentifies the services hosted by the SAP ERP system. Italso discovers the services hosted at the two productionfacilities at location A and B using the Local DiscoveryUnits (LDUs). These services along with their QoS andcontextual information are stored in the service typerepository, and are later available for service type basedquery and candidate search process steps. A sequentialprocess oriented composite application is created by thedeveloper by searching for instances of services usingthe RSDPP and the search user interface in order tocomplete a production sequence. This composite appli-cation is then also available as a web service. Two suchapplications were developed for place A and B for thisscenario.

Runtime: During runtime the production order is re-leased by the ERP system. The composite application,started executing the order at location A. This appli-cation was also getting events about the health of theDPWS based PLC devices. Events like temperature,vibration, sensor status, completion of process stagesexposed as web service events were monitored by thecomposite application. The availability of these devicesand their services were monitored by the device and ser-vice monitor respectively. Upon the failure of devices atplace A, the composite application was able to gather thecurrent production data, estimate the cost of productionhalt and initiated the continuation of the production tobe carried out by using services at place B.

The ERP system, gathers information from both lo-cations on a continuous basis to keep them in syncfor the distributed process that is running with depen-dencies. During the design time, the services hosted

on the devices at these facilities are discovered. Theyare composed to an application using the SOCRADESIntegration Architecture. In the second phase - run timephase, the actual scenario is being executed. Function-ality envisioned at design time that does not exist, ison-demand deployed during runtime.

7 CONCLUSION

The future Internet will be highly populated by net-worked embedded devices that will further blur theborders of real and business world, empowering us withnew capabilities in creating sophisticated applications.For this to happen, it is of high importance to be ableto finding real-world services that can be dynamicallyincluded in enterprise applications - a task that is quitechallenging considering the application requirements,technologies and heterogeneity of devices. In that line ofthought, we have presented here an approach that wouldfacilitate this task for developers, allowing them not onlyto search efficiently for services running on embeddeddevices, but also to deploy missing functionalities whenneeded.

The comprehensive process demonstrated in this arti-cle shows that we can extend the reach of enterprise com-puting to the real world (and vice versa). To achieve this,we suggest to use Web Services standards (DPWS) andWeb oriented patterns (REST) to easily integrate physicaldevices into existing enterprise information systems.Web services on devices can be used to dynamicallyregister devices and the service(s) they provide. We havesuggested to use queries to search services metadata thathas been gathered by the network discovery of devices.Furthermore, we have designed and evaluated automaticaugmentation of the search queries with strategies thatextend queries with related keywords found on knowl-edge repositories available on the network e.g. thirdparty web sites. With this extension we have shownthat significantly more services can be identified withoutoverloading devices with description data. We also showhow context is important for real-world services andexplain its use within the service discovery process.Finally, we presented how missing functionality can beinjected on devices upon developer’s request.

REFERENCES[1] E. Fleisch and F. Mattern, Das Internet der Dinge: Ubiquitous

Computing und RFID in der Praxis:Visionen, Technologien,Anwendungen, Handlungsanleitungen. Secaucus, NJ, USA:Springer-Verlag New York, Inc., 2005.

[2] D. Lizcano, M. Jimenez, J. Soriano, J. M. Cantera,M. Reyes, J. J. Hierro, F. Garijo, and N. Tsouroulas,“Leveraging the upcoming internet of services through anopen user-service front-end framework,” in ServiceWave’08: Proceedings of the 1st European Conference on Towards aService-Based Internet. Berlin, Heidelberg: Springer-Verlag,2008, pp. 147–158.

[3] P. J. Marron, S. Karnouskos, D. Minder, and the CONETconsortium, Research Roadmap on Cooperating Objects. Eu-ropean Commission, Office for Official Publications of the


European Communities, July 2009, no. ISBN: 978-92-79-12046-6.

[4] M. Hatler, D. Gurganious, C. Chi, and M. Ritter, “WSNfor Smart Industries,” OnWorld Study, 2007. [Online].Available: www.onworld.com

[5] M. Marin-Perianu, N. Meratnia, P. Havinga, L. de Souza,J. Muller, P. Spiess, S. Haller, T. Riedel, C. Decker, andG. Stromberg, “Decentralized enterprise systems: a mul-tiplatform wireless sensor network approach,” WirelessCommunications, IEEE, 2007.

[6] W. K. Edwards, “Discovery systems in ubiquitous com-puting,” IEEE Pervasive Computing, vol. 5, no. 2, p. 7077,2006.

[7] F. Jammes and H. Smit, “Service-oriented paradigms inindustrial automation,” IEEE Transactions on Industrial In-formatics, vol. 1, no. 1, pp. 62–70, Feb. 2005.

[8] L. M. S. de Souza, P. Spiess, D. Guinard, M. Koehler,S. Karnouskos, and D. Savio, “Socrades: A web servicebased shop floor integration infrastructure,” in Proc. of theInternet of Things (IOT 2008). Springer, 2008.

[9] N. B. Priyantha, A. Kansal, M. Goraczko, and F. Zhao,“Tiny web services: design and implementation of inter-operable and evolvable sensor networks,” in Proc. of the6th ACM conference on Embedded Network Sensor Systems.Raleigh, NC, USA: ACM, 2008, pp. 253–266.

[10] M. Crasso, A. Zunino, and M. Campo, “Easy web ser-vice discovery: A query-by-example approach,” Science ofComputer Programming, vol. 71, no. 2, pp. 144–164, Apr.2008.

[11] R. Monson-Haefel, J2EE Web Services: XML SOAP WSDLUDDI WS-I JAX-RPC JAXR SAAJ JAXP. Addison-WesleyProfessional, Oct. 2003.

[12] H. Song, D. Cheng, A. Messer, and S. Kalasapur, “Webservice discovery using General-Purpose search engines,”in Web Services, 2007. ICWS 2007. IEEE International Con-ference on, 2007, pp. 265–271.

[13] C. Atkinson, P. Bostan, O. Hummel, and D. Stoll, “A prac-tical approach to web service discovery and retrieval,” inProc of the International Conferent on Web Services (ICWS2007), 2007, pp. 241–248.

[14] D. Guinard, V. Trifa, P. Spiess, B. Dober, andS. Karnouskos, “Discovery and on-demand provisionningof real-world web services,” in Proceedings of ICWS 2009(IEEE International Conference on Web Services), LosAngeles, California, USA, July 2009.

[15] H. Bohn, A. Bobek, and F. Golatowski, “SIRENA - serviceinfrastructure for real-time embedded networked devices:A service oriented framework for different domains,” inProc. of the International Conference on Networking, Systems,Mobile Communications and Learning Technologies. IEEEComputer Society, 2006, p. 43.

[16] D. Guinard and V. Trifa, “Towards the web of things: Webmashups for embedded devices,” in Workshop on Mashups,Enterprise Mashups and Lightweight Composition on the Web(MEM 2009), in proceedings of WWW (International WorldWide Web Conferences), Madrid, Spain, April 2009.

[17] E. Wilde, “Putting things to REST,” School of Information,UC Berkeley, Tech. Rep. UCB iSchool Report 2007-015,November 2007.

[18] D. Guinard, V. Trifa, T. Pham, and O. Liechti, “Towardsphysical mashups in the web of things,” in Proceedings ofINSS 2009 (IEEE Sixth International Conference on NetworkedSensing Systems), Pittsburgh, USA, June 2009.

[19] R. T. Fielding and R. N. Taylor, “Principled design ofthe modern web architecture,” ACM Trans. Internet Techn.,vol. 2, no. 2, pp. 115–150, 2002.

[20] M. Hepp, K. Siorpaes, and D. Bachlechner, “Harvestingwiki consensus: Using wikipedia entries as vocabularyfor knowledge management,” Internet Computing, IEEE,

vol. 11, no. 5, pp. 54–65, 2007.[21] T. Frenken, P. Spiess, and J. Anke, A Flexible and Extensible

Architecture for Device-Level Service Deployment, ser. LNCS.Springer, December 2008, vol. 5377, pp. 230–241.

[22] S. Karnouskos, O. Baecker, L. M. S. de Souza, andP. Spiess, “Integration of soa-ready networked embeddeddevices in enterprise systems via a cross-layered webservice infrastructure,” in Proc. ETFA Emerging Technologies& Factory Automation IEEE Conference on, 25–28 Sept. 2007,pp. 293–300.

[23] P. Spiess, S. Karnouskos, D. Guinard, D. Savio, O. Baecker,L. M. S. de Souza, and V. Trifa, “SOA-based integration ofthe internet of things in enterprise services,” in Proceed-ings of ICWS 2009 (IEEE International Conference on WebServices), Los Angeles, California, USA, July 2009.

[24] T. Luckenbach, P. Gober, S. Arbanowski, A. Kotsopoulos,and K. Kim, “Tinyrest - a protocol for integrating sensornetworks into the internet,” Stockholm, Sweden, 2005.

[25] C. Pautasso, O. Zimmermann, and F. Leymann, “RESTfulWeb services vs. ”big” Web services: making the rightarchitectural decision,” in WWW ’08: Proceeding of the 17thinternational conference on World Wide Web. ACM, 2008.

[26] J. I. Vazquez and D. L. de Ipina, “mRDP: An HTTP-based lightweight semantic discovery protocol,” ComputerNetworks Journal - Special Issue on Innovations in Web Com-munications Infrastructure, vol. 51, no. 16, 2007.

[27] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides, De-sign Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, Nov. 1994.

[28] S. Brin and L. Page, “The anatomy of a large-scale hyper-textual web search engine,” in Proceedings of the seventhinternational conference on World Wide Web 7. Brisbane,Australia: Elsevier Science Publishers B. V., 1998, pp. 107–117.

[29] W. Balke and M. Wagner, “Through different eyes: assess-ing multiple conceptual views for querying web services,”in Proceedings of the 13th international World Wide Webconference on Alternate track papers \& posters. NewYork, NY, USA: ACM, 2004, pp. 196–205.

[30] A. Schmidt, M. Beigl, and H. Gellersen, “There is more tocontext than location,” in Proc. of the International Workshopon Interactive Applications of Mobile Computing (IMC98),vol. 23, Nov. 1998, pp. 893–901.

[31] R. Weizheng, “A rapid acquisition algorithm of wsn-aidedgps location,” in Proc. Second International Symposium onIntelligent Information Technology and Security InformaticsIITSI ’09, 23–25 Jan. 2009, pp. 42–46.

[32] A. Segev and E. Toch, “Context-based matching and rank-ing of web services for composition,” IEEE Transactions onServices Computing, vol. 99, no. 1, June 2009.

[33] H. Chan, T. Chieu, and T. Kwok, “Autonomic ranking andselection of web services by using single value decompo-sition technique,” in Proc. IEEE International Conference onWeb Services ICWS ’08, 23–26 Sept. 2008, pp. 661–666.

[34] V. X. Tran and H. Tsuji, “Qos based ranking for webservices: Fuzzy approaches,” in Proc. 4th International Con-ference on Next Generation Web Services Practices NWESP’08, 20–22 Oct. 2008, pp. 77–82.

[35] S. Karnouskos and A. Izmaylova, “Simulation of webservice enabled smart meters in an event-based infrastruc-ture.” 7th IEEE International Conference on IndustrialInformatics (INDIN 2009), Cardiff, Wales, UK, 24-26thJune 2009.

interacting with the soa based internet of things discovery, query, selection, and on-demand...

Education

business services

discovery of services

web services ws

business systems

business worlds

realworld devices

embedded software

soabased internet of