a restful architecture for integrating decomposable delayed services within the web of things
DESCRIPTION
My Presentation in the IoT workshop held at ICPADS 2011 in Tainan, TaiwanTRANSCRIPT
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.