1/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

A RESTful architecture for integratingdecomposable delayed services within the

Web of Things

Andreas Ruppen, Jacques Pasquier, Tony Hürlimann{firstname.lastname}@unifr.ch

University of FribourgDepartment of Informatics

Software Engineering Group

December, 2011

2/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

1 Introduction

2 Generic Architecture

3 RESTifying a Service

4 Validation

5 Conclusion

3/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Web of ThingsOur Vision

Internet Of Thingssmart Thing

SunSPOT

Arduino

4/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Web of ThingsOur Vision

Internet Of Thingssmart Thing

SunSPOT

Arduino

RESTful Services

REST

HTTP

HATEOAS

statelessnes

addressable

5/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Web of ThingsOur Vision

Internet Of Thingssmart Thing

SunSPOT

Arduino

RESTful Services

REST

HTTP

HATEOAS

statelessnes

addressable

Web Of Things

6/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Web of ThingsOur Vision

Internet Of Thingssmart Thing

SunSPOT

Arduino

RESTful Services

REST

HTTP

HATEOAS

statelessnes

addressable

Web Of Things

Services

7/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Motivating ExampleThe parcel delivery center

A parcel delivery center deals each day with a big numberof parcels.Parcels are arriving during the day.Parcels received the day before are distributed tocustomers.The central has a fixed number of trucks.Over night an optimal route to deliver the parcels has to befound.This routing takes into consideration:

the number of available trucks andthe priority of each parcel.

8/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Preliminary considerationsLessons learned from the motivating example

Resources that appear and disappear are very much in thespirit 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.

9/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

WoT ServicesTaxonomy

Services can roughly be classified into four categories:Short-living services.Real-time services.Delayed services.Complex-delayed services.

10/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Preliminary considerationsArchitectural starting point

The approach proposed by Richardson et al. for simpledelayed services is a good starting point.The only resources bound to the service are the tasks andthe task queue.As stated by Richardson these tasks are not a state whichis transferred to the server but a new resource available onthe server.The service is invoked by creating a new task or byconsulting an existing task.

11/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

ArchitectureRelation 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 URIscheme:

http://example.com/tasks/⇒ List of taskshttp://example.com/tasks/1/⇒ Details of task 1http://example.com/tasks/1/5⇒ Details of sub-task 5. . .

12/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

ArchitectureThe Task Model

All such services have in common that the ongoing task isrepresented by a Task object. We can define a set of minimalproperties composing a Task:

A unique idA user idThe resultThe inputThe statusThe start- and end-timeA short log messagesA list of sub-tasks

13/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

ArchitectureSemantics

According to the specification of RESTful services, standardCRUD methods are implemented. However in the case ofdecomposable delayed services, it is important to note that:

POST creates a new Task. The server should immediatelyrespond 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 areaborted and second that the delete is cascading.GET should allow to filter for most of the fields of a Task.

14/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

RESTifying a Service

Services can bere-used.Even not RESTful ones.They can be restified.

15/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

RESTifying a Services

16/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleThe parcel delivery center

Given a big parcel delivery center which has to deliverparcel to its customers.Each parcel has an assigned priority representing anadditional constraint on the delivery time.All parcels received during the day, will be distributed thenext day respecting the priorities.Upon arriving at the parcel delivery center, each parcel isscanned and added to the distribution list.This is a well know problem in operations-research: TheVehicle Routing Problem with Time Window (VRP-TW)which consists of finding an optimal set of routesperformed by a fleet of vehicles respecting the deliverytime constraints.

17/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleVehicle Routing Problem with Time Window (VRP-TW)

Definition (VRP-TW)Given n locations numbered from 1 to n, we want to delivergood to each customer in a given time-window using kvehicles, all starting at the central (location 1) and return to thecentral 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-windowsfor each subgroup.

18/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleVehicle Routing Problem with Time Window (VRP-TW) — Solution

19/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleVehicle Routing Problem with Time Window (VRP-TW) — Solution

20/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleVehicle Routing Problem with Time Window (VRP-TW) — Solution

21/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Validating ExampleVehicle Routing Problem with Time Window (VRP-TW) — Solution

Suppose the central has to deliver 199 customer in a givenregion during a given day.Starting in the morning at 5h00, each of the four postmenvisits 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 laterthan 9h25, “normal” no later than 11h05 and “slow” till16h00.The partitioning takes 10min.Each of the 4 routings takes 20min.

22/22

Outline Introduction Generic Architecture RESTifying a Service Validation Conclusion

Conclusion

We identified the challenging problem of integratingdecomposable delayed service into the WoT.We propose a reference architecture for such services.We showed how existing services can made be availableto the Web of Things.Finally we validated our findings with a prototypalimplementation.