A RESTful architecture for integrating decomposable delayed services within the Web of Things
1 like575 views
The document outlines a RESTful architecture for integrating delayed services within the Web of Things. It proposes representing ongoing tasks as resources with a uniform Task model. A task resource can have sub-task resources in a hierarchical structure, and standard CRUD methods are adapted to the semantics of creating, reading, updating, aborting, and deleting tasks and sub-tasks. The architecture provides a generic way of exposing delayed services as RESTful APIs.
A RESTful architecture for integrating decomposable delayed services within the Web of Things
- 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