My Presentation in the IoT workshop held at ICPADS 2011 in Tainan, Taiwan

1. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
A RESTful architecture for integrating
decomposable delayed services within the
Web of Things
Andreas Ruppen, Jacques Pasquier, Tony Hürlimann
{firstname.lastname}@unifr.ch
University of Fribourg
Department of Informatics
Software Engineering Group
December, 2011
1/22

2. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
1 Introduction
2 Generic Architecture
3 RESTifying a Service
4 Validation
5 Conclusion
2/22

3. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Web of Things
Our Vision
SunSPOT
Internet Of Things
smart
Thing
Arduino
3/22

4. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Web of Things
Our Vision
RESTful Services
SunSPOT
REST
statelessnes
Internet Of Things HTTP
smart
Thing HATEOAS
Arduino
addressable
4/22

5. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Web of Things
Our Vision
RESTful Services
SunSPOT
REST
statelessnes
Internet Of Things HTTP
smart
Thing HATEOAS
Arduino
addressable
Web Of Things
5/22

6. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Web of Things
Our Vision
RESTful Services
SunSPOT
REST
statelessnes
Internet Of Things HTTP
smart
Thing HATEOAS
Arduino Services
addressable
Web Of Things
6/22

7. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Motivating Example
The parcel delivery center
A parcel delivery center deals each day with a big number
of parcels.
Parcels are arriving during the day.
Parcels received the day before are distributed to
customers.
The central has a fixed number of trucks.
Over night an optimal route to deliver the parcels has to be
found.
This routing takes into consideration:
the number of available trucks and
the priority of each parcel.
7/22

8. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Preliminary considerations
Lessons learned from the motivating example
Resources that appear and disappear are very much in the
spirit of the WoT.
We want a RESTful solution.
The service has no physical representation.
The service is asynchronous.
The solution decomposes itself in sub-solutions.
8/22

9. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
WoT Services
Taxonomy
Services can roughly be classified into four categories:
Short-living services.
Real-time services.
Delayed services.
Complex-delayed services.
9/22

10. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Preliminary considerations
Architectural starting point
The approach proposed by Richardson et al. for simple
delayed services is a good starting point.
The only resources bound to the service are the tasks and
the task queue.
As stated by Richardson these tasks are not a state which
is transferred to the server but a new resource available on
the server.
The service is invoked by creating a new task or by
consulting an existing task.
10/22

11. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Architecture
Relation between Tasks
A sub-task always relates to a parent-taks.
A parent-task can have zero or more sub-tasks.
This observation motivates the choice of the following URI
scheme:
http://example.com/tasks/ ⇒ List of tasks
http://example.com/tasks/1/ ⇒ Details of task 1
http://example.com/tasks/1/5 ⇒ Details of sub-task 5
...
11/22

12. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Architecture
The Task Model
All such services have in common that the ongoing task is
represented by a Task object. We can define a set of minimal
properties composing a Task:
A unique id
A user id
The result
The input
The status
The start- and end-time
A short log messages
A list of sub-tasks
12/22

13. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Architecture
Semantics
According to the specification of RESTful services, standard
CRUD methods are implemented. However in the case of
decomposable delayed services, it is important to note that:
POST creates a new Task. The server should immediately
respond with a 202 Accepted.
PUT is used to abort a task (and its eventually sub-tasks).
DELETE has to make sure that first all sub-tasks are
aborted and second that the delete is cascading.
GET should allow to filter for most of the fields of a Task.
13/22

14. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
RESTifying a Service
Services can be
re-used.
Even not RESTful ones.
They can be restified.
14/22

15. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
RESTifying a Services
15/22

16. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
The parcel delivery center
Given a big parcel delivery center which has to deliver
parcel to its customers.
Each parcel has an assigned priority representing an
additional constraint on the delivery time.
All parcels received during the day, will be distributed the
next day respecting the priorities.
Upon arriving at the parcel delivery center, each parcel is
scanned and added to the distribution list.
This is a well know problem in operations-research: The
Vehicle Routing Problem with Time Window (VRP-TW)
which consists of finding an optimal set of routes
performed by a fleet of vehicles respecting the delivery
time constraints.
16/22

17. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
Vehicle Routing Problem with Time Window (VRP-TW)
Definition (VRP-TW)
Given n locations numbered from 1 to n, we want to deliver
good to each customer in a given time-window using k
vehicles, all starting at the central (location 1) and return to the
central using the shortest distances possible.
The problem is solved in two steps:
Partitioning all the customer 2 to n into k subgroups.
Finding the shortest path with respect to the time-windows
for each subgroup.
17/22

18. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
Vehicle Routing Problem with Time Window (VRP-TW) — Solution
18/22

19. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
Vehicle Routing Problem with Time Window (VRP-TW) — Solution
19/22

20. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
Vehicle Routing Problem with Time Window (VRP-TW) — Solution
20/22

21. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Validating Example
Vehicle Routing Problem with Time Window (VRP-TW) — Solution
Suppose the central has to deliver 199 customer in a given
region during a given day.
Starting in the morning at 5h00, each of the four postmen
visits a subset of all customers.
Suppose furthermore, that each customer is in a group of
“express”, “normal” or “slow” delivery.
“express” means that the item has to be delivered no later
than 9h25, “normal” no later than 11h05 and “slow” till
16h00.
The partitioning takes 10min.
Each of the 4 routings takes 20min.
21/22

22. Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion
Conclusion
We identified the challenging problem of integrating
decomposable delayed service into the WoT.
We propose a reference architecture for such services.
We showed how existing services can made be available
to the Web of Things.
Finally we validated our findings with a prototypal
implementation.
22/22