Towards the Web of Things: Web Mashups for Embedded Devices @ MEM 2009

Dominique Guinard and Vlad Trifa, Towards the Web of Things: Web Mashups for Embedded Devices

Dominique Guinard presents this paper. (You might wonder how I manage to both present it and blog about it, well this is thanks to Ghislain Fourny who wrote a summary of my talk).
After introducing a couple of smart objects and noticing that the audience is uncool as nobody has a Poken, Dominique asks how we are going to deal with the 1000+ smart objects each person is going to have within the next 5 to 10 years. Communicating with these objects could be made easier with Mash-ups.

The agenda will consist of a discussion of the Web of Things, the introduction of a Web-oriented architecture of the real world, the demonstration of two prototypes one of which is going to crash, and finally real-world Mash-ups.

Architecture:
1. Resource design: each resource is accessed through a URL, e.g., http://webofthings.com/spots/2/sensors/light
2. Representation design: XHTML would be the default, JSON would be better for parsing and XML would be ideal for integration
3. Uniform interface: the HTTP protocol does the job with GET, PUT, DELETE, POST. HTTP headers tell what data is being sent, and HTTP bodies contain the data.

The integration could be done through a smart gateway which discovers the devices, understands their API and exposes them as a RESTful API. Dominique mentions that Nokia is going to introduce a home control center, which will, so he says, fortunately for his work be proprietary. As opposed to the integration with the smart gateway, a direct integration would consist of smart objects having all a RESTful API.

Dominique attempts a demonstration. He turns on a sensor which gets an IP address. Two LEDs indicate that it is on the web. With an AJAX website developed with the Google Web Toolkit, Dominique selects the sensor URL and explores its services, described using JSON.

The goal of the next example is to integrate smart plugs (Ploggs) thanks to the smart gateway. Dominique plugs one of them to his smart phone, the other one to his computer and starts the gateway. Using three rounds of bluetooth, the gateway identifies all phones, well, plugs (as of course everybody in the room kindly turned off their phones upon Dominique’s request). Then Dominique navigates to the gateway URL and notices with surprise that his computer consumes 80W.

In order to compose real-world Mash-ups using these devices and this architecture, it is possible to use Yahoo pipes, Microsoft Popfly, etc. For the example, he uses his own program showing diagrams of the consumption of his devices. After 20 seconds, the data are plotted and Dominique notices that his smart phone only consumes a cool 4W.

Eventually, he introduces a physical Mash-up with an ambient energy meter, which is a Mash-up made of Ploggs, Sun Spots and gateways.

Dominique concludes by considering REST as a suitable approach for small embedded applications, although it would be nice to have asynchronous mechanisms so that they are investigating protocols like XMPP. Mash-up editors would also be nice to have.

The video of the prototype in this presentation is available on: http://www.youtube.com/watch?v=1H49H1pPSBI
The presentation is available below:

Bibtex:

@inproceedings{dguinard:wotMashups:2009,
author = {Dominique Guinard and Vlad Trifa},
title = {Towards the Web of Things: Web Mashups for Embedded Devices},
year = {2009},
month = apr,
booktitle = {Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), in proceedings of WWW (International World Wide Web Conferences)},
address = {Madrid, Spain}
}

Dominique Guinard

  • Pingback: CollaBlog » Blog Archive » Primera dia a WWW 2009

  • Pingback: Pervasive web or Pervasive computing ? | cOOlOs

  • http://www.vladounet.com Vlad Trifa

    Awesome talk dude! congrats, too bad I missed that!

  • Pingback: R.Seiji » links for 2009-04-22

  • Cedric

    Hi Dominique,

    Interesting concept (and I’m not saying this because I’m at SAP Research ;) ). Marek pointed me to your site, let’s hope your approach will prove successfull. You may want to have a look at http://www.quadraspace.org/ which works on similar concepts of RESTifying access to sensors.
    Of course, you may also have a look at our concept of Web Object Orientation and Internet of Objects which we shortly describe on SDN: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13491 and https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14012

    Regards,

    Cedric

  • http://www.guinard.org Dominique Guinard

    Hi Cedric!

    Yeah quite like quadraspace in some points they lack respecting all the REST blueprints but their approach is definitely good and similar to the approach we are taking.

    I also quite enjoyed reading your blog entry. The idea of a Web Oriented programming is rather interesting. However, I’m not sure the example you’re taking in the case of the robot is the best. What would justify to use a WSDL to move the robot? Where do you see an advantage in doing that rather than a POST to the robot position resource? Don’t you think having two systems an a very thin line separating them is going to be rather confusing?

    Now, I’m not saying WS-* are evil (unlike some of my colleagues I won’t cite ;-)) but I would rather see them used for more complex integration scenarios than the ones involving real-world, limited devices.
    I would point you to these papers on that matter (the first one is from Pautasso and Wilde, two very active and smart REST guys :-)):
    http://www.jopera.org/docs/publications/2009/coupling
    http://www.jopera.org/docs/publications/2008/restws

    Hope to be able to meet you within SAP one of these days and don’t forget to reference your posts on your blog here!

  • http://www.vladounet.com Vlad Trifa

    Honestly, I’m not so convinced by the idea of using REST for sensory motor coordination in robots, nor for anything that requires real-time for that matter.

    There are many optimized protocols for controlling machines. so I wouldn’t use REST for such tasks (although tcp/ip might be just fine for that…). I think REST would make sense for interacting with the robot, which wouldn’t suffer from a few seconds of delay (such as “hey robot, play this song by my favorite band”).

  • http://www.guinard.org Dominique Guinard

    That’s not really what I wanted to focus on. Obviously if you’re talking about real-time, industrial robots REST is not really interesting. However if you think of something more “home oriented” such as the iRobot then you could send it, via REST a command to move from A to B.

    But my point wasn’t so much about the real-time matter I was more interested in what does moving the robot from point A to B is different from getting its position. Why do you think REST is not suitable for the first case but is for the latter. Does this particular difference justifies the use of a different system? If yes then why. That was more my point….

  • http://www.vladounet.com Vlad Trifa

    well, I think the difference between retrieving the position of something, and telling him to go somewhere is two different things. I agree that using the same “vehicle” for these two operations is a good thing – as long as we’re talking about the high level “send a command to a black box” aspect, but certainly not the way the command is actually implemented (especially if you also want an ack).

  • Cedric Ulmer

    Hi guys,

    sorry I never noticed you had answered my comment :P
    First of all, we used the robot as a proof of concept rather than as a valid use case. What we propose is more a mix between REST and webservices, where REST is usefull for simple actions, and webservices for more complex ones.
    Yet if you want to have a clean concept (which you can still break when implementing ;) ), it is cleaner to state that REST is there for object identification and CRUD manipulations, and webservices for the operations. That clearly separates the usages.

    When you say that using WSDL for moving a robot is more complex than using REST, I agree with you. But still, you’re then more referring to a RESTful service rather than to a pure resource oriented REST CRUD manipulation. So it’s not “clean” enough (altough it definitly works).
    To be as clean as possible, one would then create a subresource called robotxyz/nextlocation, and do a POST do assign the next location.

    As for realtime problematics, we of course leave it up to realtime controllers to handle these issues. But nothing prevents on the command side to have a mapper allowing to use “RESTlike” commands that are converted into realtime controls. This gives a unity of REST flavor for at least the command side.

    I’m open to further discussions of course ;),

    Regards,

    Cedric

  • http://blogs.grommit.com/poorna Poornaprajna Udupi

    Dominique,

    The tag “SunSPOT” gets mixed results. All documents and videos about the SunSPOTs platform on the web are being tagged with “spaughts” tag for easy search.

    Cheers
    Poorna

  • http://www.guinard.org Dominique Guinard

    Thanks for that Poorna, I added the tag to the posts.