Connecting Smart Things through Web services Orchestrations

Antonio Pintus - [email protected] TouchTheWeb’10 - Vienna, 6th July 2010

Connecting Smart Things through Web services

Orchestrations

Antonio Pintus, Davide Carboni, Andrea Piras, Alessandro Giordano*

CRS4

* Università di Cagliari

1

giovedì 8 luglio 2010

mailto:[email protected]


Antonio Pintus TouchTheWeb’10 - Vienna, 6th July 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



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)

5

BUT

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

?



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

9

Pipe := source ----> sink

Unix example: ls -l | less

snapshot displayImage



Hyperpipes

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

10

snapshot displayImage

• How to describe hyperpipes?

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



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

14

Synchronous Pipe Asynchronous Pipe



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



A Scenario

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

• We want to compose a pipe that• takes a snapshot from the IPWebcam• makes a color-to-grayscale processing on the image• displays the image in the screen

16

and generates a pipe (either multiple or simple depending on the number of processors inserted in cascade). The webcam is embedded in a NetBook exposing the webcam's WSDL. It defines two different actions: a synchronous snapshot, and an asynchronous image event fired when a movement is detected in the scene (moveDetected). The TV screen is a monitor connected to a PC not showed in the figure. Inside the piping are inserted two different processors that perform respectively a color-to-gray conversion with synchronous invocation, and a supersampling with asynchronous invocation. The different combinations that have been tested are:

• pipe(snapshot,TVsink)

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

• pipe(pipe(snapshot,supersampling),TVsink)

• 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 synchronous source snapshot with the asynchronous one moveDetected.

Fig. 2. Simple scenario with multimedia and processing components

8 The Prototype

In SOA applications one of the main issues are related to service publication and service discovery, often faced using registries and directory mechanisms (i.e. UDDI [23]). We adopt a “zero discovery” approach in which the services are real things in an environment and it is the user with the point-click-and-compose paradigm to choose which things she wants to connect. For this aim the user is assisted by an Android [2]-based smartphone application described later in this section.



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

18

Hyperpipes server

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

2. User sends collected WSDL URLs to server3. Server analyzes WSDLs and sends back potential pipes between things matching the datatypes of discovered operations4. User selects a particular match and

requests the start of the pipe5. 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



System Architecture

19

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

Executes Pipes defined as WS-BPEL Processes



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, [email protected]

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

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

24




http://geoweb.crs4.it

http://geoweb.crs4.it

http://geoweb.crs4.it/doku.php?id=Hyperpipes

http://geoweb.crs4.it/doku.php?id=Hyperpipes


Thank you for your attention

Any questions?

25
