Service Integration in the Web of Things

Service Integration in the Web of Things 1|
Simon Mayer
http://people.inf.ethz.ch/mayersi
École d’Été Web Intelligence 2013 - Web des Objets
September 4th 2013, St. Germain au Mont d’Or
Simon Mayer, ETH Zurich
Service Integration in the Web of Things

Simon Mayer
Myself
Simon Mayer, PhD Student at ETH Zurich, WoT since 2009

Example: Sensor Platforms
Sensors: Temperature, Ambient Light, Accelerometer
Actuators: 8 LEDs, Analog Outputs (e.g., motor controller)

Example: Smart Cars
Sensors: Speed, GPS, Fuel Consumption, Total KM
Actuators: Unlock, Start, Accelerate, Brake

Simon Mayer
 Services measure or actuate values in the real, physical
world. They are provided by smart things
 Smart environments allow well-informed decisions
 Umbrella lights up if the forecast shows rain
 Smart environments can perform complex tasks
 Example: Music stream that follows the user
Service Integration and the Web of Things

Simon Mayer
 Smart Things can already do powerful tasks by themselves…
Service Integration and the Web of Things
http://koubachi.ch

 Open endpoints that are accessible by all authorized users
 Modeling according to the REST principles
However, the full potential is realized by
integrating functionality across services

The “Social Web of Things” (Ericsson, 2010)
Note the explicit communication between David and his smart
home…
“Leaving work”, “Sophia comes”, “No dinner”, “Order the usual”
…and the hidden communication between smart things
Oven, carpet vacuuming, smart umbrella, HiFi downloading playlist

Our Menu for Today.
45min.30min.15min.
Introduction/Overview WS-* Web Services
REST Service Integration Features
Service Integration via Structured Metadata
(WoT in the Wild)Semantic Service Integration
vous êtes ici

Introductory Stroll
WS-* Forest
REST Beacon of Hope
HATEOAS Cliffs
Structured
Data Lake
Crowded Village
Semantic Mountains
Unexplored State of Usability

Simon Mayer
Overview: WoT Concepts and Challenges
Saint Germain au Mont d’Or, France
saintgermainaumontdor.fr

Simon Mayer
 Definitions of the following concepts in a Web of Things
context
 Major challenges for service integration
Overview
Web of Things Concepts and Challenges
Smart Things
Services
Service
Integration
Service
Mashups
Arrive-and-
Operate
Mashup
Management
Automatic Service
Composition

Simon Mayer
 Cyber-physical functionality
 Sensing, Actuation (or both) of real, physical quantities
 Structured according to the REST principles
 Respect the HATEOAS property (application statelessness)
 Interfaces are “open”, but secure
 Fully described for people and machines
 Interacting Smart Things: Smart Environments
Smart Things in the Web of Things (WoT)

Simon Mayer
Smart Things in the Web of Things
Example: RESTful Sun SPOTs
http://vs3.inf.ethz.ch:8081/sunspots/Spot3
GET
<HTML>…
GET
{json}

Simon Mayer
 Generally: Services are Sub-Resources of Smart Things
 A Smart Thing itself (i.e., the top URL) can also be a service
Services in the Web of Things
M. Kovatsch, S. Mayer, and B. Ostermaier. Towards the Thin Server Architecture for the Internet of Things, 2012

Simon Mayer
Temperature Sensor:
http://vs3.inf.ethz.ch:8081/sunspots/Spot3/sensors/temperature
GET
28.5

Simon Mayer
PUT‘on’
OK
LED Switch: vs3.inf.ethz.ch:8081/sunspots/Spot3/actuators/leds/3/switch

Simon Mayer
 Prevalent Types
 Visual Data Rendering
 Cartographic / Geographic
 Data Converters, Aggregators (Feeds, News)
 Examples: programmableweb.com/mashups
 In the Web of Things, mashups also act on physical
quantities!
Service Mashups in the Web of Things
“A mashup (…) is a web application that
uses content from more than one source to
create a single new service.”

Simon Mayer
Mashups in the Web of Things
Example: Anti-Theft Mashup
 Shop management system + RFID reader + Web Cam
 All with Web servers on-board!
 Goal: Take a picture if a theft is detected
= if an item is read by the RFID reader but not marked as “sold”
 Send the picture to a mobile phone
D. Guinard, C. Floerkemeier, S. Sarma. Cloud Computing, REST and Mashups to Simplify RFID Application Development and Deployment, 2011

Simon Mayer
Mashups in the Web of Things
Example: Room Configuration

Simon Mayer
 Enabling people to talk to services
 Enabling services to talk to each other and form mashups
 Enabling people to talk to service mashups

Now, let’s talk about some
challenges in service
integration
Arrive-and-Operate: Service Discovery and Look-Up
Mashup Management: For Everyone
Automatic Service Composition

Simon Mayer
 Advertise services that are provided by devices within a
smart environment!
Arrive and Operate
Service Discovery
What’s the current
temperature?
I know that!
It’s 23°C
Thank you :-)

Simon Mayer
Arrive and Operate
Service Look-Up
 It’s not static text documents anymore!
 Possible to use Google for this?
 Which attributes? Keywords, Device Type, Reviews,..
 Search Engines for the WoT, e.g., Dyser, InfraWoT
B. Ostermaier, K. Römer, F. Mattern, M. Fahrmair, and W. Kellerer. A Real-Time Search Engine for the Web of Things, 2010
S. Mayer, D. Guinard, and V. Trifa. Searching in a Web-based Infrastructure for Smart Things, 2012

Simon Mayer
 Search for smart things that exhibit a given state at the
time of the query
 “Empty rooms that have a temperature of 23°C”
 Querying for real-time states is expensive!
 Dyser: Create statistical models for sensors. First query
sensors that likely satisfy the parameters
Arrive and Operate
Service Look-Up: Dyser

Simon Mayer
integration
Arrive-and-Operate: Service Discovery

Simon Mayer
Non-PhD-Nabaztag idea: Dom Guinard
Mashups for Everyone
I don’t have a PhD in computer
science...
Enable tech-savvy users to develop applications that
leverage functionality from sensors and actuators
[“programming the real world”]

Simon Mayer
Graphical Editors for Physical Mashups
 Facilitate the composition of RESTful services
 Clickscript (JavaScript-based visual programming language)
 https://github.com/lnaef/ClickScript
 Web of Things modules: Thermometer, fan, etc.

Simon Mayer
Graphical Editors for Physical Mashups
[Clickscript.ch]
D. Guinard, C. Floerkemeier, S. Sarma. Cloud Computing, REST and Mashups to Simplify RFID Application Development and Deployment, 2011

Simon Mayer
integration
Arrive-and-Operate: Service Discovery

Simon Mayer
 Embed information about what smart things can do!
 Syntactic level: Data type, units of measurement, etc.
 Semantic level: “What is the meaning of this data?”
 Is automatic mashup creation even possible? We’ll see… :-D
...and tell others!

Simon Mayer
Smart Service Composition
Possibilities

Simon Mayer
Possibilities

Simon Mayer
 Web of Things Concepts
 Smart Things and Smart Environments
 Services
 Service Integration
 Service Mashups
 Web of Things Challenges
 Arrive and Operate: Service Discovery and Look-Up
 Mashups: Enable tech-savvy users to program the real world
 Service Composition: Fully automatic?
Summary

Introductory Stroll
REST Beacon of Hope
HATEOAS Cliffs
Structured
Data Lake
Crowded Village
Semantic Mountains
Unexplored State of Usability
WS-* Forest

Simon Mayer
A History Primer: WS-* Web Services
Sonoma County, USA
ahmadladhani.wordpress.com

Simon Mayer
A History Primer: WS-* Web Services
Bliss, Microsoft
ahmadladhani.files.wordpress.com

Simon Mayer
 Here, endpoints are service calls, not resources
 Resource: www.myserver.org/thermometer/temperature
 Service: www.myserver.org/getTemperature
 Main Technologies:
 Service Access SOAP
 Service Description WSDL
 Service Discovery UDDI
The Service-Oriented Architecture

Simon Mayer
 Challenge (1995):
How to make heterogeneous services on the
Internet discoverable and usable for clients?
 Internet too heterogeneous for a single RPC technology
 Goal: Language-independent standards for Web Services
Main Technologies

Simon Mayer
 SOAP: Service Access (1998)
 “Simple Object Access Protocol”, today just “SOAP”
 Dave Winder (also RSS!), together with MS engineers
 Transport usually via HTTP, but also possible via, e.g., SMTP
Main Technologies: SOAP

Simon Mayer
 WSDL: Service Description (2000)
 Web Services Description Language
 IBM, MS, Ariba
 UDDI: Service Discovery (2000)
 Universal Description Discovery and Integration (part of WS-I)
 MS, IBM, Ariba
 SOAP, WSDL, and UDDI are part of the WS-* stack
Main Technologies: WSDL and UDDI

Simon Mayer
Main Technologies
XML Documens
Client Server
Registry-Service
UDDI
WSDLWSDL
SOAP
register
look up
request / reply
Material adapted from: F. Mattern, Distributed Systems Lecture, ETH Zurich, 2012

Simon Mayer
Main Technologies
Client Server
Lookup-Service
UDDI
WSDLWSDL
SOAP
register
look up
request / reply
SOAP envelope
Header (optional)
Body
WSDL description
types, messages
portType
binding
service

Simon Mayer
Main Technologies: SOAP
SOAP envelope
Header (optional)
Body
Envelope
SOAP Definition and Encoding Style
Optional Header
Transaction Context: Authentication and Billing
Body

Simon Mayer
Types: What does the exchanged data look like?
WSDL description
types, messages
portType
binding
service
Messages: What are messages composed of?
PortType: What do the operations look like?
Binding: Which protocol to use?
Service: Structure/Bundling of operations
Main Technologies: WSDL

Simon Mayer
Types: Define Serialization Objects
<xs:element name="myName" type="myObject"/>
<xs:complexType name="myObject">
<xs:sequence>
<xs:element name="i" type="xs:int"/>
<xs:element name="j" type="xs:float"/>
</xs:sequence>
</xs:complexType>
“complexType”: Composite Objects!
WSDL description
types, messages
portType
binding
service

Simon Mayer
Messages
<message name="myRequest">
<part name="parameters"
element="tns:myName"/>
<part name="optionalParameters"
element="tns:myOpt"/>
</message>
<message name="myResponse">
<part name="result" element="tns:myRet"/>
</message>
WSDL description
types, messages
portType
binding
service
“tns”: target namespace
myObject

Simon Mayer
PortType: Define Operations
<portType name="groupOfServices">
<operation name="myService">
<input message="tns:myRequest"/>
<output message="tns:myResponse"/>
<fault message="tns:someFault"/>
</operation>
</portType>
WSDL description
types, messages
portType
binding
service
There can also be multiple operations

Simon Mayer
Transport Binding
<binding name="myBinding“
type="tns:allMyServices">
<soap:binding
transport="http://schemas.xml-
soap.org/soap/http"
style="document"/>
</binding>
WSDL description
types, messages
portType
binding
service

Simon Mayer
Service: Packaging the Service
<service name="SimpleService">
<port binding="tns:myBinding">
<soap:address location=“
http://simpleService.org"/>
</port>
</service>
WSDL description
types, messages
portType
binding
service

Simon Mayer
 Stubs handle communication
issues such as message packing
and unpacking (“marshalling”)
 Server stub is also responsible for
publishing the WSDL file
WS-* in Practice
Application-Server
Server Logic
Server Stub
Client
Client Stub
Client Logic

Simon Mayer
 The “server stub”
 Handle SOAP marshalling
 Publish WSDL
 Two possibilities to create the server stub
1. Bottom-Up / Code-First: Stub from implementation
Example on next slide (JAX-WS)
2. Top-Down / Contract-First: Stub from Interface WSDL
WS-* in Practice: WS-* Servers
Application-Server
Server Logic
Server Stub

Simon Mayer
Java API for XML Web Services (JAX-WS)
Java Annotations to create Web
Services from simple Java code

Simon Mayer
 Stubs handle communication issues
such as message packing and
unpacking (“marshalling”)
 Server stub is also responsible for
publishing the WSDL file
WS-* in Practice
Application-Server
Server Logic
Server Stub
Client
Client Stub
Client Logic

Simon Mayer
 The “client stub” handles SOAP marshalling
 Two options:
1. Bottom-Up / Code-First: Stub from implementation
2. Contract-First: Stubs from WSDL
Highly appealing for enterprises!
WS-* in Practice: WS-* Clients
Client
Client Stub
Client Logic

Simon Mayer
Discussion of WS-*
 Immensely powerful and lots of available tools!
 Huge complexity - hard to learn
 WSDL: Enormous documents for simple functionality!
 SOAP: Only POST (for http-binding)
 Therefore no http-based caching possible!
 UDDI: No role-based access, no service life-cycle
management, limited look-up capabilities (IBM, 2007)

Simon Mayer
It is that it has features that encourage the
compiling of clients against it, and that
such clients are not flexible enough to
adapt to changing interfaces
(creation of client stubs from WSDL)
One of the biggest problems of WSDL (and WADL, see later) isn’t technical…

Introductory Stroll
WS-* Forest
HATEOAS Cliffs
Structured
Data Lake
Crowded Village
Semantic Mountains
REST Beacon of Hope

Web-based Interaction with Smart Environments 72|
Simon Mayer
(Back) to the Future: REST
CERN, Switzerland/France
home.web.cern.ch

Simon Mayer
REST and WS-*
Google Trends, 2004-2013
LHC
Image: Compact Muon Solenoid Experiment
[one of the main particle detectors at CERN]

Simon Mayer
 Introduction to REST by Michaël and Lionel (yesterday)
 Comparison of REST and WS-*
 Google Trends
 Performance of REST vs. WS-*
 Ease of use of REST and WS-*
 A different approach to understanding REST
 The main REST feature for service integration: HATEOAS
Overview: REST, WS-*, and HATEOAS

Simon Mayer
REST and WS-*
SOAP
Makes no sense to look this up… ;-)

Simon Mayer
REST and WS-*
“SOAP Java”

Simon Mayer
REST and WS-*
WSDL

Simon Mayer
REST and WS-*
UDDI

Simon Mayer
REST and WS-*
REST
Makes little sense to look this up either… ;-)

Simon Mayer
REST and WS-*
RESTful

Simon Mayer
REST and WS-*
UDDI
RESTful
“SOAP Java”

Simon Mayer
 REST outperforms WS-*
 Some data in a minute…
 REST is a better fit to the “Do-It-Yourself” Web
 Often frontend creation, i.e., quick data access
 “Web Developers” vs. “Programmers”
 WS-* suite is a complex standard, now
 Makes it hard to use for novices
 Some data in a minute…
REST and WS-*
The Downside of WS-* Web Services…

Simon Mayer
 REST and SOAP on devices with limited resources
REST and WS-*
Performance
Power Consumption [mW] Completion Time [s]
D. Yazar and A. Dunkels: Efficient Application Integration in IP-based Sensor Networks, 2009

Simon Mayer
REST and WS-*
Better Fit for Do-It-Yourself Web
 RESTful vs. “Big” Web Services
 REST for tactical, ad hoc integration over the Web
(“Mashups”)
 WS-* in professional enterprise application integration
scenarios with a longer lifespan and advanced QoS
requirements
 Today, REST is being more and more adopted for this use case!
C. Pautasso, O. Zimmermann, and F. Leymann: RESTful Web Services vs. “Big” Web Services. Making the Right Architectural Decision, 2008

Simon Mayer
REST and WS-*
Complexity & Approachability
 Also consider the perceived ease of use as a key to the
adoption of an IT system
 Increasing reliance on external developers to build
innovative services (App Store, Google Play, etc.)
F. D. Davis. Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, 1989
D. Gefen and M. Keil. The Impact of Developer Responsiveness on Perceptions of Usefulness and Ease of Use, 1998
An easy to learn and easy to use API is key
to foster a broad community of developers!

Simon Mayer
REST and WS-*
Developers’ Perspective
 Study to evaluate the developers’ experience when
learning and implementing Web Service applications
 Perceived advantages & disadvantages of REST and WS-*
 Ease and speed of learning
 Perceived suitability of REST and WS-* for different scenarios
 Participants
 Computer science students (n = 69)
 Third or fourth year of Bachelor studies
D. Guinard, I. Ion, S. Mayer: REST or WS-*? A Developers’ Perspective, 2011

Simon Mayer
REST and WS-*
Developers’ Perspective: Study Setup
 Data Sources (quantitative and qualitative feedback)
1. Implementation Task Teams (n = 25)
2. Structured Questionnaire Individual (n = 69)
3. Feedback Form Anonymous (n = 37)
 Implementation Task: Mobile Phone Applications (n = 25)
 Access temperature measurements on wireless sensor nodes
a. RESTful API
b. WS-* (WSDL + SOAP) API
 Standard libraries: Apache HTTPClient for REST, kSoap2 for WS-*
All course material is available online: tinyurl.com/vs-material

Simon Mayer
REST and WS-*

Simon Mayer
REST and WS-*
2. Structured Questionnaire (n = 69)
 Advantages and disadvantages of REST and WS-*
 Suitability of WS-* and REST in different domains
 Completed after finishing implementation
3. Anonymous Feedback Form (n = 37)
 WS-* / REST ease and speed of learning
 Suitability of WS-* / REST in different domains
 Completed after finishing implementation

Simon Mayer
REST and WS-*
Developers’ Perspective: Results
 Perceived advantages of each technology
 Ease and speed of learning
 Perceived suitability for use cases
 Embedded devices
 Mobile phone client applications
 Business applications

Simon Mayer
REST and WS-*
Developers’ Perspective: Perceived Advantages
 REST
 Very easy to understand, learn, and implement (36 participants)
 More lightweight (27)
 More scalable (21)
 WS-*
 WSDL enables service contracts (31)
 Better security features (19)
 Better level of abstraction (11)
Qualitative Results, n = 69

Simon Mayer
REST and WS-*
Developers’ Perspective: Ease of Learning
 “Easy” or “Very easy” to learn
 REST: 70%
 WS-*: 11%
 REST M = 3.85, SD = 1.09
 WS-* M = 2.50, SD = 1.10
 REST significantly easier to learn (p < 0.001, Wilcoxon signed rank test)
Not easy at all Not easy Average Easy Very easy
0
2
4
6
8
10
12
14
16
18
REST
WS-*
5 point Likert scale [1 = Not easy at all, ..., 5 = Very easy], n = 37

Simon Mayer
REST and WS-*
Developers’ Perspective: Speed of Learning
 “Fast” or “Very fast” to learn
 REST: 65%
 WS-*: 0%
 REST: M = 3.43, SD = 1.09
 WS-*: M = 2.21, SD = 0.80
 REST significantly faster to learn (p < 0.009, Wilcoxon signed rank test)
Not fast at all Not fast Average Fast Very fast
0
2
4
6
8
10
12
14
REST
WS-*
5 point Likert scale [1 = Not fast at all, ..., 5 = Very fast], n = 37

Simon Mayer
 REST easier to learn because RESTful Web Services are based on
familiar technologies such as HTTP (9)
 REST made it easier to understand what services the sensor nodes
offer (25). This is because of the HTML interface (8)
 WSDL and SOAP are more complex to use (8)
 Good that WSDL is “standard” (7)
REST and WS-*
Developers’ Perspective: Summary
“REST is easy and WS-* is
just a complicated mess.”
“Everybody who is using a browser
already knows a little about [REST]”
Qualitative Results, n = 69

[http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%202007-02.pdf]
WS-* Standards Overview

Simon Mayer
REST and WS-*
Developers’ Perspective: Use Cases
Would you use REST or WS-* for…
… Embedded Devices?
… Mobile Phone Clients?
… Business Applications?

Simon Mayer
5 point Likert scale [1 = WS-*, ..., 5 = REST], n = 37
REST and WS-*

Simon Mayer
REST and WS-*
 Embedded Devices
 REST (66%), WS-* (8%)
 Reasons: REST better in heterogeneous environments, more
lightweight
 Smart Home Sensor Network (students’ private homes)
 REST (89%), WS-* (7%)
 Reasons: Simplicity of deployment and use (24)
(avg. footprint 17.46 kB for REST, 83.27 kB for WS-* application)
5 point Likert scale [1 = WS-*, ..., 5 = REST], n = 37 + qualitative data

Simon Mayer
REST and WS-*
 Mobile Phones
 REST (53%), WS-* (16%), 32% undecided
 Reasons: REST causes less traffic (7)
 Undecided reasons: Mobile phones getting very powerful

Simon Mayer
REST and WS-*
 Business Applications
 WS-* (52%), REST (24%)
 WS-* Reasons: Security needs (21), better service contracts (18)
 REST Reasons: Simplicity (10), Scalability (10)

Simon Mayer
REST and WS-*
Developers’ Perspective: Summary
 REST: Intuitive, flexible, lightweight
 WS-*: Advanced security, standardization, contracts
 Learning Ease and Speed: REST Preference (significant)
 Embedded and Mobile Apps: REST Preference (significant)
 Business Applications: WS-* Preference (not significant)
 Study done among novice developers

Simon Mayer
REST and WS-*
REST Advantages: Summary
 Great for open, interoperable APIs
 Greatly facilitates creation of mashups
 Web features for free
 Bookmark your devices and their functionality
 Caching for scalability, security mechanisms
 People are used to exploring the Web using a browser
 Seems to facilitate application development

Simon Mayer
REST and WS-*
REST Advantages: Summary
 REST and SOAP on devices with limited resources
 UDDI discontinued by IBM, Microsoft, SAP in 2006
 Functionality removed from Windows Server in 2010
 WS-* APIs discontinued by Google in 2011
Power Consumption [mW] Completion Time [s]
[derekskeba.com]

Try to avoid repeating the same mistakes for service
integration in the Web of Things
Do not create service descriptions
that encourage the compiling of
clients against them

Introductory Stroll
WS-* Forest
REST Beacon of Hope
HATEOAS Cliffs
Structured
Data Lake
Crowded Village
Semantic Mountains

Now for the cool stuff: HATEOAS
[or, Hypermedia as the Engine of Application State]
[or, the server guides clients using hyperlinks]

Did you ever experience that the “back”
button broke a hypermedia application?
e-banking, e-commerce, flights booking, etc.
Why is that?

“The Hypertext Transfer Protocol (HTTP)
is a networking protocol for distributed,
collaborative, hypermedia information
systems. HTTP is the foundation of data
communication for the World Wide Web.”
“Prominent members
include the Hypertext
Transfer Protocol.”
http://en.wikipedia.org/wiki/HTTP
http://en.wikipedia.org/wiki/Networking_protocol
http://en.wikipedia.org/wiki/WWW
http://en.wikipedia.org/wiki/URI
http://en.wikipedia.org/wiki/Hyperlink
HATEOAS: Simple Example
Known URL!

Clients that click “back” break the HATEOAS “contract”!
The server didn’t want a “back” button to be available in the application. Else,
there would be a hypermedia control to enable the “back”-action

Simon Mayer
 All possible state transitions of an application are under
control of the server. To guide clients in applications, the
server provides hyperlinks that they may follow
 Clients only follow provided hyperlinks! “follow your nose”
 Take Care! What if a client wants to buy a book, but only
finds a link “Add to shopping cart”?
Representational State Transfer (REST)
HATEOAS [Hypermedia as the Engine of Application State]
No Problem!
What about
me??

Simon Mayer
Client context,
e.g.: Do I like
chocolate?
Page contents,
e.g.: ”Zurich”
advertisement
HATEOAS for Human Clients

Simon Mayer
 Important part of REST! Especially for service integration…
HATEOAS: Google Trends (2004-2013)
HATEOAS

http://bookstore.org/books/book1
HATEOAS: Book Store Example
Known URL!
“Recommended Books: Book1
Books in your cart: None.
Checkout not possible (no books).”
“This is Book1. It’s great!
Add book to cart”
GET books/book1

http://bookstore.org/carts/simon http://bookstore.org/books/book1
http://bookstore.org/checkout?customerID=simon
Known URL!
Add book to cart”
POST carts/simon?book=Book1
“Recommended Books: None
Books in your cart: Book1.
Go to checkout.”
“Select payment type:
Credit Card, Debit Card”

http://bookstore.org/carts/simon
Known URL!
http://bookstore.org/books/book1 http://bookstore.org/XYZ/book1
What if the bookstore renames the /books pages?

http://bookstore.org/XYZ/book1
Known URL!
Add book to cart”
GET XYZ/book1

http://bookstore.org/carts/simon
http://bookstore.org/XYZ/book1
Known URL!
Add book to cart”
GET XYZ/book1
“Recommended Books: None
Books in your cart: Book1.
Go to checkout.”

Simon Mayer
 HATEOAS is what adds flexibility to REST systems!
 Links are discovered by clients at runtime
 Clients will automatically adapt if links change!
 This is why browsers are general-purpose tools and not
specialized applications
 What if the book store API was described in WSDL?
 Risk that clients are compiled from the WSDL
 Not mandatory, but was common practice! Why?
 WSDLs are more complex to parse and perceived as being static
HATEOAS and Flexible Service Consumption

Simon Mayer
 We assume that a machine client can follow its nose
 Can they, really? What is required to “follow your nose”?
 How to combine services from different providers?
 They don’t know about each other!
 They cannot include links to each other!
 HATEOAS cannot accomplish such service integration
tasks alone!
HATEOAS for Machine Clients: Challenges

This is where HATEOAS breaks down for machine clients!
Options?
Create a new type of WSDL, for RESTful Web Services
(top-down, standardization, look at WADL in the next slides)
Offer Web developers ways of annotating their resources
(basically the same thing, but taking into account the developers’ perspective / bottom-up)

Simon Mayer
 Web Application Description Language
 Initial draft (2005) by Marc Hadley
 Sun Microsystems (today: Oracle)
Some words about WADL
WADL

Simon Mayer
WADL: Repeating WS-* Mistakes?
 WADL example to annotate a news search
 Alternative Option: OpenSearch
 WADL documents are verbose and
perceived as rather rigid
 “the REST answer to WSDL”
Risk of compiling against WADL!
http://www.w3.org/Submission/wadl/
http://www.opensearch.org/Specifications/OpenSearch/1.1

Simon Mayer
WoT Service Integration
Zurich, Switzerland
ethz.ch

Simon Mayer
Example Scenario

Simon Mayer
 User enters personal preferences into smartphone
(temperature, preferred song, etc.)
 Smartphone negotiates with devices in the surroundings
to set these preferences
 Constraints
 Must be flexible: Should work in the user’s home, office, hotels, etc.
 Interaction metadata must be discoverable on the fly!
 Discourage compiling against service descriptions!
Example Scenario

Simon Mayer
 Heterogeneous services from different providers should
be dynamically composable
 Services don’t know anything about how to interact with
other services when they are created (i.e., no “standards”)
 No HATEOAS: No hyperlinks between services!
 Links are known only between “local” services where URLs have
been intentionally linked by the service provider
The big picture…

Simon Mayer
 Make things smart enough to know what they can do…
 First level: Syntax
“What type does a service’s output data have?”
 REST offers a great mechanism to help with that: Content Negotiation
 Second level: Semantics
“Does it make sense to link these two services?”
Service Integration: Self-aware Things!
...and tell others!

Simon Mayer
...and tell others!

Simon Mayer
 A smart thermostat takes inputs as XML:
 The client’s desired temperature is in a JSON document:
Service Integration: “Self-aware” Things?
A Glimpse at Syntactic Service Integration
{
commonName:”clientX”,
desiredSong:”Yellow Submarine”,
desiredTemperature:”20”
}
Method: PUT
Endpoint: myserver.org/things/thermostat
Content: (…)<value>23.3</value>(…)

Simon Mayer
 Describe the service’s API in an Internet Media Type!
 Make this information public!
 Client can now create/render the input and use the service
 This is part of REST self-describing messages!
A Glimpse at Syntactic Service Integration
Method: PUT
Content-Type: application/xml+simon-thermostat

Simon Mayer
...and tell others!

How to infer that it’s about temperatures
and not about a GPS longitude?
Not possible! They look the same!
Yes, but their semantics are different.
?

True, the messages aren’t self-descriptive with respect to
this: “value” could be anything
Method: PUT
But we can fix that, by adding semantic metadata!
Not possible! They look the same!

Alright… from the beginning :-)
We’ll see four service integration techniques, an
example for each, and discuss their suitability for
our considered applications

Simon Mayer
 Simple Hypermedia Crawling
 Metadata: Microformats and Microdata
 Crowd-sourced Service Integration
 Web Linking: “Globalized” HATEOAS?
 Semantics-based Service Integration
 Web Linking + Metadata Embedding
 My current research…
Techniques for Semantic Service Integration
morefunctionality……morecomplexity

Simon Mayer
 My own current research…

Simon Mayer
 Crawling of hypermedia structures sometimes is already
sufficient as enabler for integration
 Mainly relies on: GET Well-known, right?
HEAD Who knows this?
OPTIONS And this one?
 Friends and Things: Sharing of physical and digital
artifacts via social networks
Hypermedia Crawling
D. Guinard, M. Fischer, V. Trifa. Sharing Using Social Networks in a Composable Web of Things, 2010

Simon Mayer
@home Sharing your energy consumption
Encouraging energy savings…
@work Laboratory automation
“You may monitor my mass spectrometer”
@business Sharing the trace of tagged products
RESTful EPCIS
Hypermedia Crawling
The Friends and Things Project

Simon Mayer
Hypermedia Crawling

Simon Mayer
 FaT must discover thing APIs to be shared first
 Entirely done via hypermedia crawling, no semantics whatsoever
 Then, things can be shared via the OpenSocial API
 …and used by others
Hypermedia Crawling

Simon Mayer
Hypermedia Crawling

Simon Mayer
 Only API discovery, nothing else!
 No information about how APIs can be used: Only
specialized applications can use them
 For crawling to work, links must already exist!
(the “local” hyperlinks problem, again…)
Hypermedia Crawling: Limitations

Simon Mayer
Hypermedia Crawling
Discussion
Rating Comments
Interface
Discovery
Partial Requires APIs to be connected via hyperlinks
Automatic
Service Usage
No
Can be used to discover APIs that are then used
by tailored applications (like Friends and Things
does!)
Level of
Semantic
Integration
None No semantic integration whatsoever
Simplicity Very Easy No specific annotations required

Simon Mayer

Simon Mayer
 Easy: Find a common way of embedding “useful” metadata
 Standardized “structured Data” can be successful… ;-)
 vCard supporters:
Android, Symbian, Apple Mac OS X, combit Relationship Manager, Egroupware, Kontact,
Lotus Notes, Lotus Organizer, Gmail, Microsoft Outlook, Mozilla Thunderbird, Novell
Evolution, Novell GroupWise, Roundcube, SOGo, Palm Desktop, The Bat, Trillian, Turba,
WebWeaver Suite, etc.
Metadata Embedding
Anybody know the vCard format?

Simon Mayer
 Easy: Find a common way of embedding “useful” metadata
 Standardized “structured Data” can be successful… ;-)
 Wikipedia “Infoboxes”
 Wikidata
Metadata Embedding
http://fr.wikipedia.org/wiki/Lyon
http://www.wikidata.org/wiki/Q456

Simon Mayer
 Microformats
 Specifically hRESTS for service integration
 Standardized formats for describing contact info, products, etc.
 Example application: Service lookup infrastructure
 Microdata
 Driven by the “big players”, often linked to ontologies
 Example application: UI descriptions
Metadata Embedding
both: HTML!

Simon Mayer
 Microformats
 Microdata
Metadata Embedding

Simon Mayer
 Standardized HTML-embeddable structured data profiles
Metadata Embedding
Microformats
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
hCard format
For API descriptions! Next slide!
hRESTS format

Simon Mayer
Does this really help machine clients?
Microformats
The hRESTS Format for API Descriptions
<div class="service">
This <span class="label">thermostat</span> enables users to
<div class="operation”>
<span class="label">configure the current temperature</span>
. It is invoked using a
<span class="method">PUT</span>
request at
<span class="address">http://myserver.org/thermostat?t={temp}</span>
with
<span class="input">the desired temperature</span>
replacing the
<code>temp</code>
parameter.
</div>
</div>
Demonstration!

Simon Mayer
 A management infrastructure for smart things
 Enables searching for devices in smart environments
 Parameters:
 UUID, Name, Keywords
 Type/Category of device
 Location
 Reviews
 Type of REST API
Microformats
Embedded Microformats Example: InfraWoT
S. Mayer, D. Guinard, and V. Trifa. Searching in a Web-based Infrastructure for Smart Things, 2012
Find a Thermostat at the
location Living Room that
takes a temperature as input

Simon Mayer
 Hierarchies of management nodes, nodes only aware of
direct neighbors
highly scalable! (tested with 100k devices…)
Microformats
The InfraWoT Project

Simon Mayer
 Management infrastructure for smart things
 Service Discovery and Look-up
Microformats
Trifa, V., Guinard, D., Mayer, S. Leveraging the Web for a Distributed Location-aware Infrastructure for the Real World, 2010
Things register
first…

Simon Mayer
 Management infrastructure for smart things
 Service Discovery and Look-up
Microformats
…and can be
found by clients!
Things register
first… Find a Thermostat at the
location Living Room that
takes a temperature as input

Simon Mayer
Microformats
The InfraWoT Project: Registration

Simon Mayer
Microformats
The InfraWoT Project: Metadata
Parameters Microformat
Identification Name, UUID
None. Information
derived from URL
Product Info Device Type, Brand, Price, etc. hProduct
User Reviews Ratings, Description hReview
Context Location (GPS + Indoor Location)
GEO for GPS, proprietary
format for indoor
API Description
Label, URL Template, Input,
Output
hRESTS

Simon Mayer
Microformats
The InfraWoT Project: Service Look-Up
Find a Thermostat at the location
Living Room that takes a
temperature as input
www.myserver.org/things/thermostat
Method: HTTP PUT
Rating: 4.3 (0..5)
hProduct Category
GEO
hRESTS Input

Simon Mayer
 Information is not machine-interpretable
 hRESTS service label can only be “understood” by humans!
 Only allows to annotate text/html representations
 Clumsy embedding via HTML overloading of “class”
 Declining interest…
Microformats
Discussion
Microformats

Simon Mayer
Microformats
Discussion
Rating Comments
Interface
Discovery
None Requires to fall back on crawling or indexing
Automatic
Service Usage
Partial
hRESTS allows definition of API, but no format to
describe it for machine clients
Level of
Semantic
Integration
Partial
Microformats define the semantics of objects, but
are only partially linked to ontologies
Simplicity Medium
Cumbersome annotation of HTML
representations required

Simon Mayer
 Microformats
 Microdata
Metadata Embedding

Simon Mayer
 Also based on structured data and HTML embedding
 New attributes instead of overloading
 Part of HTML5
 “More semantics”: Linking to ontologies possible via fixed
vocabularies like www.schema.org or data-vocabulary.org
 Maintainers: Google, MS, etc.
schema.org
Metadata Embedding
Microdata

Simon Mayer
 Smarter embedding via special HTML attributes
<… itemprop=“propertyName”> to annotate specific items
<… itemscope itemprop=“scopeName”> for scoping
 Usually added to <span> or <div> tags
 Demonstration (navigate to colored LED)
Metadata Embedding
Microdata
<html>…<span itemscope itemprop=“vCard”>This page is
about <span itemprop=“firstName”>Maximilian</span>
<span itemprop=“lastName”>Muster</span> who lives in
<span itemprop=“locality”>Zurich</span></span>…</html>

Simon Mayer
 Goal: Automatic UI generation for smart things
 Intuitive interfaces for multiple modalities (GUI, speech, haptics, etc.)
 Metadata should be easy to embed for developers
 UI Information embedded as Microdata
Microdata
Embedded Microdata Example: InterWoTions

Simon Mayer
InterWoTions
Human- and machine-readable volume controller interaction markup.
Microdata
The InterWoTions Project

GUI / Touch Screen
Haptic / Gyro
Example: Interaction with a Web-enabled LED

Speech
Haptic / Accelerometer
Example: Interaction with a Web-enabled Power Plug

Haptic / Gyroscope
Example: Interaction with a Web-enabled Toy Robot

GUI / Gyroscope
Composite UI
set intensity,
switch, get data,
goto, move
Example: Interaction with iTunes
Faster than the iPhone-App!

Simon Mayer
 Yields useful interfaces
 Covers lots of use cases: Home automation, A/V, lecture
controls, car controls, etc.
 Markup is easily producible for tech-savvy users
Microdata
Embedded Interaction Information: InterWoTions

Simon Mayer
Microdata
Discussion
Rating Comments
Interface
Discovery
None Requires to fall back on crawling or indexing
Automatic
Service Usage
No No standard format to annotate Web APIs
Level of
Semantic
Integration
Partial
Allows to define an object’s class/type, if
ontologies like schema.org are used
Simplicity Easy
Annotation of HTML representations required.
Better usability than Microformats

Simon Mayer
 We never actually tried that! Rather, we moved on to explore “full”,
functional semantic integration…
 Works only for HTML representations (like Microformats)
 W3C working on Microdata-RDF Transformation
Microdata
Discussion
Allows to define an object’s class/type, if
ontologies like schema.org are used

 Goal: Extract interesting information about a device
regardless of the annotation format
 Approach: Discovery based on a runtime-dynamic set of
strategies (Microformats-Strategy, Microdata-Strategy, proprietary
strategies, etc.)
Brief Outtake!
How to merge different embedded
Metadata Descriptions
S. Mayer, D. Guinard. An Extensible Discovery Service for Smart Things, 2011

Forecast: Rain
Temperature: 24˚C Please configure
forecast data source
Your fridge currently
consumes 45W
I’m located in Zurich!
Human-readable and understandable
Lots of smart things…

...and multiple semantic annotation formats...
{“data”:[{“weather-
forecast”:”Rain”}],
“name”:”MyNabaztag”}
…<div itemscope><div
itemprop=“tag=“>Illumination</div><div
itemprop=“value”>150</div></div>…
...
<div class="geo">GEO: <span
class="latitude">8.549902</span>,
<span class="longitude">-
47.378088</span></span></div>
{“consumption”:”45”,
“unit”:”Watts”,
“appliance”:”fridge”}

...and multiple semantic annotation formats...
{“data”:[{“weather-
forecast”:”Rain”}],
…<div itemscope><div
itemprop=“tag=“>Illumination</div><div
itemprop=“value”>150</div></div>…
...
<div class="geo">GEO: <span
class="latitude">8.549902</span>,
<span class="longitude">-
47.378088</span></span></div>
Content type:
application/json
Content type: text/html
Annotations: Microdata
Content type: text/html
Annotations: Microformats
Machine-readable
{“consumption”:”45”,
“unit”:”Watts”,
“appliance”:”fridge”}
Content type:
application/json

Does every smart device have to be
capable of parsing every single
format...?

Simon Mayer
And it gets worse...
{“data”:[{“weather-forecast”:”Rain”}],
Imagine we agreed on everybody using application/json...
Content type:
application/json
{“data”:{“weather-forecast”:”Rain”},
{“data-item”:[{“weather-forecast”:”Rain”}],

Simon Mayer
A single, agreed upon,
standard format
Options for annotating smart things
Or multiple (but few!) formats
Syntax problem remains
Probably not feasible...

Simon Mayer
Different Syntax: OK!
A method to understand
multiple different formats
Future formats?

Simon Mayer
Different Syntax: OK!
An extensible method to
understand multiple
different formats
Future formats: OK!

Simon Mayer
 Uses multiple strategies to extract metadata
 More strategies can be loaded at runtime
 Can handle protected resources and resources behind firewalls
 Great help for decoupling service providers and consumers
The DiscoWoT Project
GET /analyze?http://thing.org
Information about thing.org
S. Mayer, D. Guinard. An Extensible Discovery Service for Smart Things, 2011

Computer vision techniques + Embedded UI Information
=
Intuitive Interfaces!
Outtake! Embedded Metadata to Interact
with Smart Things!
S. Mayer, M. Schalch, M. George, G. Sörös: Device Recognition for Intuitive Interaction with the Web of Things, 2013

Simon Mayer
Object Recognition + Embedded UI Metadata
Object
Categorization
Object
Tracking Rendered UI
(InterWoTions)

Simon Mayer
Example: Web-enabled Toy Robot
GUI / Gyroscope

Simon Mayer
Example: Volume Controller
GUI / Gyroscope

Simon Mayer
Soon for cars?

Simon Mayer
Current status…

Simon Mayer
 Microdata-based metadata is absolutely suitable for this!
 Lots of potential, if data access is ensured!
Embedded UI information + Object Recognition
Conclusion
S. Mayer, C. Beckel, B. Scheidegger, C. Barthels, G. Sörös: Uncovering Device Whispers in Smart Homes, 2012
S. Mayer, M. Schalch, M. George, G. Sörös: Device Recognition for Intuitive Interaction with the Web of Things, 2013

Simon Mayer
 Simple crawling for interface discovery
 Requires hyperlinks to be present!
 Application: Access right management
 Structured Data (Microformats and Microdata) for simple embedding of
metadata in resources
 Application: Web of Things search engine
 Application: Embedding of interaction information
Take-home Points

Simon Mayer

However…
These are constrained to
operating within hypermedia
applications!
They require HATEOAS-style hypermedia controls to be already present!
[example coming right up…]

 All possible state transitions of an application are under
control of the server. To guide clients in applications, the
server provides hyperlinks that they may follow
 Clients only follow provided hyperlinks! “follow your nose”
 Take Care! What if a client wants to buy a book, but
only finds a link “Add to shopping cart”?
HATEOAS [Hypermedia as the Engine of Application State]
I can do
that! What about
me??
Still remember this?

http://bookstore.org/carts/simon http://bookstore.org/books/book1
Example from REST Introduction
Known URL!
Add book to cart”
GET books/book1

Example from REST Introduction
/book/cart
/checkout

What about multiple stores?
Not possible! No Link!
/book/cart
/checkout
/book/cart
/checkout
Store A
Store BI found this great book at store
A. It also exists in store B.
I’d like to buy it there!
I can
do that!
…

Simon’s Office
- Contains 2 services
More seriously: Think about a smart environment…
I have a song title,
“Yellow Submarine”.
I’d like to play that song.
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL
Output: Plays song
Not possible! No Link!
I can do
that, too! Will you stop
now !

It’s the “follow your nose”-Problem again!
What if a client wants to “buy” a book, but only finds a link “Add to shopping cart”?
Hm, you
know. I can…
YES! I got it.
Our goal is to enable it for this guy!

Simon Mayer
 Special-purpose link lists that can be queried by users
 Various implementations: Web Linking metadata
Link repositories
 Multiple ways of constructing these
 Crowd-sourced Linkbases
 Semantics-based Linkbases
Globalization of HATEOAS: Linkbases
vs.

Simon Mayer

Simon Mayer
 Rely on developers or users to publish links
Globalization of HATEOAS
Crowd-sourced Linkbases
Simon’s Office
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL
Output: Will play music
I know that you can
connect these services!
Let me show you!

Simon Mayer
S. Mayer, D. Karam. A Computational Marketplace for the Web of Things, 2012
 Mashup developers find links manually, but publish their
mashups in a “WoT Marketplace”
 Clients can ask the marketplace for linking information
 These links make sense, because they are used in a mashup!
 Clients only need to choose which link to follow
 Yay! That sounds like we can use HATEOAS again!

Simon Mayer
Marketplace
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL

Simon Mayer
Marketplace
Node A
Node B
Node C
Node D
Node F
Marketplace exposes linking metadata about nodes!
Node X: www.wot_marketplace.org/nodes/X

GET wot_marketplace.org/nodes/A
{
“service” : “www.songsearch.org”
“forward_paths” : {
# None
}
}

Simon Mayer
Marketplace
Node A
Node B
Node C
Node D
Node F
I know that you can
connect the services at
A and F!

POST wot_marketplace.org/nodes/A?link=nodes/F&name=play_song
202 Created

Marketplace
Node A
Node B
Node C
Node D
Node F
Now, others can use
that information!
play_song

{
“play_song” : “nodes/F”
}
}

{
}
}
I can do that
now, too!

Simon Mayer
 Clients need to be able to find services on the
marketplace and select appropriate services to achieve
their goal
 The marketplace should provide meta-information about
services and thus help to optimize traversal
 Mechanisms are required for security and billing

Simon Mayer
their goal

Simon Mayer
 Marketplace API exposes paths
 “Graph Crawler” keeps all paths up-to-date
 Basically an ordinary search machine…
Crowd-sourced Linkbases: Interface Discovery
{
}
}

Simon Mayer
their goal

Simon Mayer
Crowd-sourced Linkbases: Service Traversal
The following use case is about
arrhythmia detection
We have a heartbeat feed and an
arrhythmia detector.
We want to decide whether to follow the
“ambulance” link

Simon Mayer

Simon Mayer
Yes, this is hard!
But at least we have links again and can “outsource” the logic to
the client…
Here, clients are not “compiled” against the links anymore,
but against the link names!
This is a bit less bad…

Task: Implement a client such that it follows
the emergency link when the probability for
arrhythmia is higher than 50%

Simon Mayer

Simon Mayer
their goal

Simon Mayer
{
“service” : “www.arrhythmia_detect.net”
“play_song” : {
“node” : “nodes/F”,
“cost”:”0.02$”,
“delay”:”1sec”
}
}
}

Simon Mayer
 Optimize traversal according to application needs
 Multi-dimensional cost metrics: time, money, quality,...
 Marketplace offers this information, but does not decide
on routes → Generic path deciders
Crowd-sourced Linkbases: Path Optimization

Simon Mayer
Marketplace
Node A
Node D
Node B
Node C Node E
This is for arrhythmia
detection, again!
Node A: Heartbeat feed
Nodes B, C, D: Arrhythmia Detectors. The marketplace provides delay metadata
Node E: Emergency-Link, “Call Ambulance” Service

This is the actual thing! (we use gephi.org/ to create these)
S. Mayer, D. Karam. A Computational Marketplace for the Web of Things, 2012

Task: Implement a client that
always uses the arrhythmia
detector with the lowest delay

Simon Mayer
 Generic service traversal (lowest time cost path)
Crowd-sourced Linkbases: Path Optimization

Result: Automatic load balancing!
That’s why we call it “marketplace”

Simon Mayer
their goal

Simon Mayer
 Authentication, authorization, and billing schemes to
restrict access to computational resources
 Don’t create a centralized repository for login data
 Trust problems, security problems, scaling problems...
 Instead use third-party schemes (like OAuth 2.0) and
inline this functionality as a linked computational node!
Crowd-sourced Linkbases: Security and Billing

Simon Mayer
Marketplace
Node A
Node B
Node C
Node D
Node F
The OAuth node controls
access to the media player!

Simon Mayer
Discussion
Rating Comments
Interface
Discovery
Yes Requires developers or users to publish links
Automatic
Service Usage
Partial Only on syntactic level (data types and formats)
Level of
Semantic
Integration
None No annotations
Simplicity Tricky
Relies on enough participants! And on them
being reliable enough!

Again, this didn’t enable automatic service usage!

Simon Mayer
Can we automate the publishing of links?
Simon’s Office
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL

Simon Mayer

Simon Mayer
Use semantic metadata to find potential links!
Semantics-based Linkbases
Simon’s Office
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL
R.Verborgh et al. RESTdesc - A Functionality-Centered Approach to Semantic Service Description and Composition, 2012
S. Mayer and G. Basler. Embedded Semantic Metadata to Support Device Interaction in Smart Environments, 2013

Simon Mayer
Simon’s Office
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL
Based on what I know
about these services, there
could be a link here!

Simon Mayer
 We’ve already seen limited metadata embedding…
 This time, we mean it!
Functional semantic service descriptions
 Semantic reasoner to process these descriptions
How?
Connect that information to its API
What?
Describe what a service does

Simon Mayer
 Usability as one major constraint
 It should not be too hard to create service descriptions
 It should be easy to create user goals
 Pragmatism as another
 Make use of previous research in semantic technologies
 Use existing ontologies. Avoid creating new ones!
 Format: Notation3 (user-friendly RDF with inference rules)

The title of the resource people.org/person1/, is “Person 1”, and it knows
another resource, people.org/person2/
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc=http://purl.org/dc/elements/1.1/ xmlns:foaf="http://xmlns.com/foaf/0.1/">
<rdf:Description rdf:about=“people.org/person1/">
<dc:title>Person 1</dc:title>
<foaf:knows>people.org/person2/</foaf:knows>
</rdf:Description>
</rdf:RDF>
StandardRDF/XML
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
<people.org/person1>
dc:title "Person 1";
foaf:knows "people.org/person2/".
Notation3
Brief N3 Primer: Statements
Remember Catherine’s talk?
Turtle Syntax

Brief N3 Primer: Rules
𝑹𝒖𝒍𝒆: 𝑃𝑟𝑒𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 → 𝑃𝑜𝑠𝑡𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛
“people.org/person1/ knows people.org/person2/ ”
implies
“people.org/person2/ knows people.org/person1/ ”
If one person knows another person, this second person also knows the first.
(“foaf:knows is symmetric”)

Notation3
{
Precondition.
}
=>
{
Postcondition.
}
is shorthand for=> log:implies

Notation3
{
?x a foaf:Person;
foaf:knows ?y.
}
=>
{
?y foaf:knows ?x.
}
is shorthand for=> log:implies
Superb tutorial at n3.restdesc.org (by Ruben Verborgh)

Simon Mayer
Now: Semantic metadata for the Songs Search Machine
Simon’s Office
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL
Media Player
Method: PUT
Input: MP3 URL
Semantics-based Linkbases: Metadata

Simon Mayer
Precondition: Facts that are required for a meaningful execution of the service
-> Knowledge of a Song Title
Postcondition: Additional facts that hold after an execution of the service?”
-> Knowledge of a URL of a song with that title
Songs Search
Machine
Method: GET
Input: Song Title
Output: MP3 URL

Notation3
The Songs Search Machine
{
Precondition.
}
=>
{
Postcondition.
}
If we know a song title, we also know the URL of a song with that title.

If we know a song title, we also know the URL of a song with that title.
Notation3
{
?songTitle a dc:title.
}
=>
{
?songURL a dc:Song;
myOnt:hasTitle ?songTitle.
}
Store this as ssm_rule.n3

Simon Mayer
Now, we only need to link that to the service!
Multiple ways to do that…
We use HTTP OPTIONS for that
“This method allows the client to determine the options and/or requirements
associated with a resource, or the capabilities of a server, without implying a
resource action or initiating a resource retrieval.” (RFC 2616)
OPTIONS www.ssm.org
Link: <ssm_rule.n3>; rel=“describedBy“
We use the Link Header (RFC 5988) to return the description
Demonstration!
Songs Search
Machine
ssm_rule.n3

Why is that?
After reading ssm_rule.n3, I know
that I can get a song URL.
But I don’t know how!

How to include the request? Basically two options…
𝑹𝒖𝒍𝒆: 𝑃𝑟𝑒𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 ∧ 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 → 𝑃𝑜𝑠𝑡𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛
𝑹𝒖𝒍𝒆: 𝑃𝑟𝑒𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 → 𝑃𝑜𝑠𝑡𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 ∧ 𝑅𝑒𝑞𝑢𝑒𝑠𝑡
This works, but is impractical (knowledge about all requests required from the start…)
It also messes up the quantification!
“Given the Preconditions, all GET requests give the Postcondition”
This works too, and it is sound!
“Given the Preconditions, there exists a GET request that gives the Postcondition”
R.Verborgh et al. RESTdesc - A Functionality-Centered Approach to Semantic Service Description and Composition, 2012
The second option
sounds better to me!

Notation3
{
}
=>
{
?songURL a dc:Song;
Request.
}
If we know a song title, we also know the URL of a song with that title. Plus, we
know about an HTTP request.

Notation3
@prefix http: <http://www.w3.org/2011/http#>.
{
}
=>
{
?songURL a dc:Song;
_:request http:methodName “GET”;
http:requestURI (<www.ssm.org?title=>?songTitle);
http:resp [ http:body ?songURL ].
}
Store this as ssm_rule.n3
We’ll refer to it as a “RESTdesc” description
If we know a song title, we also know the URL of a song with that title. Plus, we
know about an HTTP request.

“Yellow Submarine” a dc:title.
“Yellow Submarine” a dc:Title.
?songURL a dc:Song;
myOnt:hasTitle “Yellow Submarine”.
_:request http:methodName “GET”;
http:requestURI (<www.ssm.org?title=>?songTitle);
http:resp [ http:body ?songURL ].
[+ proof]
ssm_rule.n3

But how do I say that
I want a song URL?

Goal: ?song a dc:Song; hasTitle “Yellow Submarine”.
A proof that is parsed to an internal HTTP request description format
Send a GET request to www.ssm.org?title={songTitle} and substitute “songTitle” with
“Yellow Submarine”. Then, unpack the response. Its body contains the song.
GET ?title=YellowSubmarine
www.songs.org/yellowsub.mp3
ssm_rule.n3
Songs Search
Machine
ssm_rule.n3

Why does this solve the
missing links Problem?

Simon Mayer
First: Add semantic metadata to the Media Player!
Simon’s Office
Songs Search
Machine
ssm_rule.n3
Media Player
Method: PUT
Input: MP3 URL

Simon Mayer
Parfait!
Simon’s Office
Songs Search
Machine
ssm_rule.n3
Media Player
mp_rule.n3

I want to play “Yellow
Submarine” now!!
Then formulate your goal.
But be precise!
?state a st:State;
log:includes {
:SimonsOffice musicPlaying [ myOnt:hasTitle “Yellow Submarine” ]
}
I want Simon’s office to be in a state
where “Yellow Submarine” is playing.

Client Goal
A proof that can be parsed to an internal HTTP request description format
Send a GET request to www.ssm.org?title={songTitle} and substitute “songTitle”
with “Yellow Submarine”. Then, unpack the response. Its body contains the
songURL. Take this variable and send a PUT to www.mp.org?song={songURL}
Execute the requests to play the song!
ssm_rule.n3
mp_rule.n3

Send a GET request to www.ssm.org?title={songTitle} and substitute “songTitle” with
“Yellow Submarine”. Then, unpack the response. Its body contains the songURL. Take this
variable and send a PUT to www.mp.org?song={songURL}
Media Player
mp_rule.n3
GET ?title=YellowSubmarine
Songs Search
Machine
ssm_rule.n3
PUT ?song=www.songs.org/yellowsub.mp3
Now, yellowsub.mp3 is playing in Simon’s office!

Sounds complicated. Could you
summarize what I have to do?
1. Formulate your goal
2. Search for a reasoner (e.g., using InfraWoT)
3. Ask the reasoner how to reach the goal
4. Parse the proof to extract the requests
5. Execute the requests

I don’t believe this!
Let’s see it!

http://192.168.8.102:8000/proof?q=http://people.inf.ethz.ch/
mayersi/n3goals/user-goal-
music.n3&r=http://people.inf.ethz.ch/mayersi/n3goals/user-
input.n3
+ reasoner has access to ssm_rule.n3, mp_rule.n3, and a states ontology.
Do Proof!
(the two n3 files aren’t online anymore)

Isn’t it too hard to create the
goal, for a client like me?
That’s tricky. But we’re working on it!
One idea is to integrate the goal creation with Clickscript.
And you know how to use that, right?

Simon Mayer
 A standard semantic reasoner
 Lots of research done into this, optimized
 Can handle lots of inference rules, will not be the
bottleneck, at least for home automation scenarios
 Infer what a smart environment can do for us!
 And how to trigger that functionality!
Semantics-based Linkbases: Discussion

Simon Mayer
 Set favorite song on your mobile
phone to create a music stream
that follows you!
 Indoor localization service
 Stream server/transmitter
 Stream players/receivers in all
rooms
Semantics-based Linkbases: Prototype
S. Mayer and G. Basler. Semantic Metadata to Support Device Interaction in Smart Environments, 2013

Simon Mayer
 A music stream that “follows” the user

Simon Mayer
 Implementation (version 1)
 Passive reasoner: Only active when queried by the client
 Implementation (version 2)
 Reasoner actively searching for services using the InfraWoT
discovery infrastructure

Simon Mayer
 Too many requests! 10s to change the song!
Semantics-based Linkbases: Prototype v1

Simon Mayer
 Working on this… stay tuned!
 Scalability testing looks good
 InfraWoT strategy: Growing scopes
Semantics-based Linkbases: Prototype v2

Hm. So I should
just state my goals.
And I can find and
use services, too!

Discussion
Rating Comments
Interface
Discovery
Yes Only requires service entry endpoints
Automatic
Service Usage
Yes Contains API annotations for automatic usage
Level of
Semantic
Integration
Partial
Uses reasoner to deduce paths for reaching the
user’s goal. Does not make use of big ontologies
(but could/should…)
Simplicity ?
Requires annotation of devices and definition of
goals. Good progress, but not out of the
woods yet

Simon Mayer
Semantics-based Linkbases: Possibilities

Simon Mayer

Semantic Service Integration Technologies: Overview
Crawling Microformats Microdata Crowd
Linkbases
Semantic
Linkbases
Interface
Discovery
Partial None None Yes Yes
Automatic
Service Usage
No Partial No Partial Yes
Level of
Semantic
Integration
None Partial Partial None Partial
Simplicity Very Easy Medium Easy Tricky ?

Simon Mayer
Conclusion
Carinthia, Austria
presse.kaernten.at

Study techniques and technologies that
enable machines to discover smart
devices, to select appropriate services,
and to use them automatically!
Goal

Expose services as REST resources. Make
them discoverable via repositories or search
machines. Annotate them to expose their APIs
and make them automatically usable!
Approach

However, REST by itself is not enough for
automatic service usage
REST offers very interesting features for smart
environments and allows to embed API
descriptions and other metadata

We’ve seen multiple approaches to
facilitate the creation of mashups, and the
usage by machine clients
Embedding functional semantic service
descriptions could be a viable alternative to
“top-down” standardization

Simon Mayer
 Beginnings in Europe, now intercontinental!
 Web of Things Workshop Series: webofthings.org/wot
 WoT 2010 @ PerCom, Mannheim
 WoT 2011 @ Pervasive, San Francisco
 WoT 2012 @ Pervasive, Newcastle
 WoT 2013 @ UbiComp, Zurich
 Community blog: webofthings.org
The Web of Things Community

Simon Mayer
 Ruben Verborgh, David Karam
 Nadine Inhelder, Gianin Basler
 Markus Schalch, Andreas Tschofen
 Dominique Guinard, Vlad Trifa
 Matthias Kovatsch, Leyna Sadamori, Gábor Sörös
 Erik Wilhelm, Josh Siegel, Sanjay Sarma
 Special Thanks to Ruben, Nadine, and David for your input on these slides!
Credits

THANK YOU for this invitation !
Jean-Paul Jamont
Cécile Favre
Lionel Médini
Michaël Mrissa
Tous les participants de l’école d’été Web Intelligence 2013!

 http://andrewbleakley.com
 http://www.webmarchand.com
 http://www.patentspostgrant.com/
 http://www.orkin.com
 http://sweetclipart.com
 http://la-matrice.org
 http://learn.randolph.k12.ma.us
 http://theparisreview.org
 http://bestclipartblog.com
 http://freepik.com
 http://http://www.rugdots.com
 http://www.productdose.com
 http://westwoodblinds.co.uk
 http://www.ambientdevices.com
 http://www.pats.ua.ac.be
 http://www.vesternet.com
 http://www.rovingnetworks.com
 http://www.qualitymechanicalservices.com
 http://chantalteakettle.org
 http://blog.eeye.com
 http://cartographersguild.com
 http://haverford.edu
 http://clker.com
 http://stickers-addict.fr
 http://en.wikipedia.org
Image Sources

Service Integration in the Web of Things

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Service Integration in the Web of Things

Similaire à Service Integration in the Web of Things (20)

Dernier

Dernier (20)

Service Integration in the Web of Things