Connecting Smart Things through Web services Orchestrations

Connecting Smart Things
through Web services
Orchestrations
Antonio Pintus, Davide Carboni, Andrea Piras, Alessandro Giordano*
CRS4

* Università di Cagliari

Antonio Pintus - pintux@crs4.it TouchTheWeb’10 - Vienna, 6th July 2010 1

giovedì 8 luglio 2010

Outline

• Who, where...
• Introduction
• Things as Web services (WS)
• Pipes
• Connecting Things: Pipes as WS Orchestrations
• Scenario & prototype
• Limitation and future works
• Technologies
• Conclusions

2
Antonio Pintus TouchTheWeb’10 - Vienna, 6th July 2010

Who, where...
• Antonio Pintus
• ICT Group @ CRS4, an interdisciplinary applied research center based in
Pula (Cagliari), SARDINIA, Italy

3

Introduction

• In the Web of Things (WoT) vision, things are connected to a pervasive wireless/wired
network and can communicate with other objects and services using HTTP-based
protocols
– Everyday surrounding objects (phones, domestic appliances, advertisement
billboards, musical instruments,... ) become nodes of the WoT

• De ning simple mechanisms to connect things can foster a huge number of
unpredictable applications:
– users, objects and networks are the ingredients to build a WoT in which users are
also the programmers

• The Web is a real platform for Service-Oriented Computing (SOC) and Service-Oriented
Architecture (SOA) paradigms
– nowadays the Web Services (WSs) and related standards are the enabling
technologies for SOC and SOA

4

Things as Web services?

• ...and what if we imagine each thing as a (Web) service?
– we could:
– have a formal description for functional interfaces (WSDL)
– have well-de ned data types (XML Schema)
– have a messaging format (SOAP)
?

BUT

• what about “nature of things “ and connection and
communication capabilities?

5

Assumptions on Things

• things must be able to connect to the network and to
run a WS stack. Basically in two ways:
• the object itself is powerful enough
• or, it have to be connected and “driven” by a proxy computer
which satis es the requirements

• Virtual Things: Web sites, social networks, ...
• HTTP-enabled Smart Appliances: smartphones, printers, screens
(proxied?)
• Internet-enabled Things: TCP/IP, UDP/IP, proxied
• Network-enabled Things: No IP protocol: X10, Bluetooth, ZigBee, proxied.
• Things not digitally enabled: must have a digital peer, i.e.: a book
6

Things as Web services!

• “Proxied” or not, each Thing is represented by a Web
service:
• WSDL describes things capabilities as WS operations using XML
Schema datatypes
• things functionalities can be activated using SOAP messages

7

Connecting Things

• Ok, we have WS representing Things...

• The most interesting part is in

–connecting them to build brand new applications!
–Let users play with connections

8

Pipes

• Concept inspired by pipes in Unix world
• A pipe is a simple logical connection between two things implemented as a
process that retrieves data from one source, (adapts) and sends to a

Pipe := source ----> sink

Unix example: ls -l | less

snapshot displayImage

9

Hyperpipes

• Basic concept: using a pipe to connect two Things
functionalities

snapshot displayImage

• How to describe hyperpipes?

• Things are WS ------> use WS-BPEL to describe and execute
pipes

10

Hyperpipes, de nitions

• We de ne:
• src: a generic thing functionality (WS operation) which
represents a functional capability of the thing returning a value
due to its invocation

• snk: a generic thing functionality (WS operation) which
represents a functional capability of the thing able to accept a
value as input

• adapter: a generic WS able to provide data transformation or
data adaptation functionalities exposed as service operations

11

Hyperpipes: patterns and...

• synchronous: on an thing x is invoked an operation src, (the result is
adapted) and then passed as an input to an operation snk exposed by a
thing y

• asynchronous: the pipe registers itself as a listener for an event produced
by an exposed operation src on thing x. When the event is red, the data
attached to the event is (adapted and then) sent to the snk operation
exposed by the thing y

• streaming: a thing y receives from a thing x a stream of data. A suitable real
time media transmission protocol should be used after a negotiation and
handshaking phase between things. The pipe represents and enables the
handshaking step

12

...control pattern

• A pipe is controlled using a VCR-like interface:
start/pause, stop

• VCR-like interface is exposed by a Pipe
Controller

13

Pipes as WS-BPEL processes

Synchronous Pipe Asynchronous Pipe
14

Pipes composition: User Interaction

• Pipes are composed by users through a simple interaction
pattern, using “everyday” objects, where:

– Things are “augmented” with a QR Visual Tag (containing the WSDL URL of the
related WS)

– Users, using an ad hoc smartphone application, are able to:

– Point the desired objects (which will be connected) with the
smartphone cam
– Click to import them in the hyperpipes system
– Compose pipes connecting Things functionalities

15

• pipe(pipe(snapshot,color-to-gray),TVsink)
• pipe(pipe(snapshot,supersampling),TVsink)

A Scenario
•
•
pipe(pipe(pipe(snapshot,color-to-gray),supersampling),TVsink)
pipe(pipe(pipe(snapshot,supersampling),color-to-gray),TVsink)
The same combinations have been tested replacing the synchrono
snapshot with the asynchronous one moveDetected.

• Three Things:
1. IPWebcam
2. image processing service
3. display/screen

• We want to compose a2.pipescenario with multimedia and processing components
Fig. Simple that

• takes a snapshot from the IPWebcam
• makes a color-to-grayscale processing on the image
8 The Prototype
• displays the image in the screen
In SOA applications one of the main issues are related to service publi
service discovery, often faced using registries and directory mechanisms
[23]). We adopt a “zero discovery” approach in which the services are rea
16
an environment and it is the user with the point-click-and-compose pa

Prototype
• Mainly the prototype is composed of two modules
• a smartphone app for the user

• a “server” module able to accept incoming “requests” from the
smartphone app, compose and execute the pipes

17

Steps

Hyperpipes server

1. User collects Things and smartphone app decodes
QR (WSDL URLs)

2. User sends collected WSDL URLs to server
3. Server analyzes WSDLs and sends back
potential pipes between things matching the
datatypes of discovered operations
4. User selects a particular match and
requests the start of the pipe
5. The server composes the WS-BPEL
following the pipe pattern and orchestrating the
involved WSs

6. User can control the pipe execution using a
VCR-like UI: start/pause, stop

18

System Architecture

Executes Pipes defined as WS-BPEL
Processes

analyzes WSDLs, proposes pipes, composes
WS-BPEL for pipes, deploys them and accepts
commands from mobile application

19

Limitations & future work (1)

• Automatic matching of possible pipes given the WSDLs:
– next versions will add a complete user responsibility in composing pipes
using discovered things

• Operations matching relies on shared XML Schemas
– For simplicity, XML Schemas are shared and things operations use them
to expose datatypes

20

Limitations & future work (2)

• We are investigating for a good compromise between datatypes
generality and datatypes matching in our context (semantics?)

• Streaming pipes not implemented, yet

• We are working for the inclusion of other types of services for
representing objects: REST services, RSS/ATOM feeds, ...

• WSDL wrappers?
• WS-BPEL extensions?

21

Technology

• Architecture written in Java

• Apache ODE as WS-BPEL engine

• MTOM (SOAP Message Transmission Optimization
Mechanism) for optimization of binary data transmission
with SOAP

• Android platform for mobile application

22

Conclusions
• Representing things as WS implies interesting research topics about a
SOA application in the eld of Web of Things, we’ve developed a
simple mechanism based on the concept of pipe

• Things composition using broad adopted standards (WS-BPEL) --->
inclusion of things in business processes

• Main role of users in discovering and composing things

• several issues related to “nature” of things emerge: connection,
capabilities, proxies, ...

• datatypes de nition and matching, messaging, binary data, ...

23

Contact

• Antonio Pintus, pintux@crs4.it

• My group @ CRS4: http://geoweb.crs4.it/

• Hyper-pipes: http://geoweb.crs4.it/doku.php?id=Hyperpipes

24

Thank you for your attention

Any questions?

25

Connecting Smart Things through Web services Orchestrations

More Related Content

Viewers also liked

Similar to Connecting Smart Things through Web services Orchestrations

More from Antonio Pintus

Recently uploaded

Connecting Smart Things through Web services Orchestrations