AW: [WoT IG] to converge on WoT architecture

Hi Vlad,



I do agree that it is a valid point to demand: everything (or rather every “Thing”) has to have a URI and follow a well-defined resource architecture including the media types and interfaces.

But I do think the value point is not that this has to be HTTP/JSON only. The true value is that everything that is adhering to this agreed resource model and is connected on OSI layer 4+ is then interoperable.



Following your example from the PDF: it’s nice and valid that you can connect them on the “Cream layer”, i.e. have some application somewhere on the web that gets notified from the cloud API of my light-switch vendor so that it can send a request to the cloud of my lamp vendor to switch it on.



But I think it is aiming too short. What if the startup that runs the service gets out of business? Or changes TOS?

We need Thing-to-Thing. I want my lightswitch to talk with my lamp. And it’s a fact that you cannot run HTTP on a low-footprint device. Running e.g. CoAP should not exclude it from adhering to the same model.



Even if one of them speaks natively HTTP and the other  a non-HTTP protocol (let’s call it “Foo”), I know that it is adhering to the resource model (or the URI points to an entity representing the physical thing that does) and all I need is a dumb adapter Foo-to-HTTP (which needs to to nothing more than protocol translation) and  I can interoperate them. Same adaptor can enable my browser/smartphone/… to talk with it.



So no problem with defining/designing for HTTP/JSON, but I would not restrict it to just that.

IMO the key value is, as you mentioned, to have a consistent developer experience. This is not based in using HTTP, but in having a commonly used resource model. For that we have to show this essential model and how to map this very same resource model including media types (=data structures) and interactions also to other protocols.



--Johannes



Von: Vlad Trifa [mailto:vlad@evrythng.com]
Gesendet: Donnerstag, 21. Mai 2015 23:45
An: Lynn, James (Fortify on Demand)
Cc: Dave Raggett; Heuer, Joerg; public-wot-ig@w3.org
Betreff: Re: [WoT IG] to converge on WoT architecture



[tl;dr] I guess my previous mail could be summarised as follows ;)











   On 21 May 2015, at 22:28, Vlad Trifa <vlad@evrythng.com<mailto:vlad@evrythng.com>> wrote:



   Fair point Jim.



   I think the idea of "making them part of the Web of Things" is that somewhere between an app I write and the thing itself, there's a server that exposes data/services about that product in HTTP and thus makes it part of the Web of Things. It Web-enables that thing. A bottle of wine on its own isn't part of the Web of Things, unless it has an identifier on it, which you can use to query a Web server and read/write data about that bottle. But this server needs to do more than "just expose an HTML page about that thing"!!! Otherwise I could argue that Amazon is the biggest Web of Things server ever made! Indeed, there are pages about every thing there, from golf clubs to cars, and more - real things!! That obviously has nothing to do with the Web of Things, it's just the Web.



   Using this analogy, a Web cam with an IP address and a very limited HTML user interface (but no API I can use programmatically) isn't part of the Web of Things to me, it's just part of the Web. So the question really is this: do we consider the Web of Things as nothing more than the Web? Or is the WoT a little layer of cream on top of the Web that makes it more programmer friendly, or at least more physical-object-friendly??



   If I have an IP camera in my LAN so it has an IP address, but I need to install a vintage application that runs only on Windows to access that camera (because it speaks a horrible protocol from the 80's), can we really consider it part of the Web of Things? Definitely not to me. But if it does have a socket open on port 80 though... and a server listening there? Still not. And if it has a horrible HTTP API that I need 3 days to understand because it's everything but restful? Maybe... ?



   Putting an HTTP API server on the camera, on the router of my LAN, somewhere in the cloud, or even as a plugin in my chrome browser that translates my HTTP request my app is sending to "whatever the device speaks" is all we need to make it part of the Web of Things. That is what I meant by a "layer of cream", something that other machines could easily read, and something that a developer could easily use, which HTTP alone won't do.



   It feels that this definition is broad enough so that any thing can be part of the Web as long as there's something somewhere I can send HTTP requests to. But if I need to write an app that uses non-Web requests to it, and I - as a developer - need to learn and write that specific protocol in the app I'm writing for a particular device (e.g. bluetooth), then it feels that we're missing the point of the Web of Things. Without this line in the sand, I feel we're back to the place where I need to learn several non-web protocols to talk to several devices (and that place is the Internet of Things, ie. the world of today).



   My definition of the WoT is that as long as there's a Web URL somewhere I can send a JSON/HTTP request from a javascript app I'm writing (regardless of where that URL is hosted - all I need to know is that its a URL and I can talk HTTP to it), is a necessary (but not sufficient!) condition to be part of the Web of Things. And I believe without this strong requirement in place, then we're simply patching the status quo in the IoT world and "try to pull" various protocols in the same direction, as opposed to create a simple, universal, and truly Web-based ecosystem and do a great work to integrate other protocols into it (as we'll always need them).





   Would love to hear how you all think think/feel about these ideas! Agree, or definitely not?





      On 21 May 2015, at 19:58, Lynn, James (Fortify on Demand) <james.lynn@hp.com<mailto:james.lynn@hp.com>> wrote:



      Vlad



      I think there a lot of things that will not be servers but will be considered part of the WoT. I think many of these fall into the category of sensors or other data feeds that will be clients to a server. I believe some webcams may be an example a thing which is not a server and certain components of a home automation system may be client-only and yet have a presence on the web including an IP address and/or a URI.



      Regards,

      Jim



      From: Vlad Trifa [mailto:vlad@evrythng.com]
      Sent: Tuesday, May 19, 2015 8:44 AM
      To: Dave Raggett
      Cc: Heuer, Joerg; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
      Subject: Re: [WoT IG] to converge on WoT architecture



      Thanks!



      How about simply "Web Thing"? Because the Web of Things is made of Things - Web Things. It seems simple enough to be useful & reusable.



      A Web Thing should automatically imply that it's a server, otherwise it's not accessible over the Web.



      What might be a useful term though is "Web Thing Client" or "Web of Things Client", which means it can access, read, and control other Web Things, but doesn't expose its services on the Web.



      This is what we've proposed in our proposal here: bit.ly/wot-label<http://bit.ly/wot-label> --> feedback very welcome!



      Thoughts?



      Vlad





      --

      vlad trifa, phd ////

      co-founder, head of r&d + innovation

      m +44 750 888 2051 // w evrythng.com<http://evrythng.net/>

      t @vladounet /////// w vladtrifa.com<http://vladtrifa.com/>



         On 19 May 2015, at 11:52, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote:





            On 18 May 2015, at 19:42, Heuer, Joerg <Joerg.Heuer@siemens.com<mailto:Joerg.Heuer@siemens.com>> wrote:



            So I did the exercise to draft some architecture aspects from my view point and share



            a)      the attached slides showing those aspects (I assume they are not self explanatory yet, but for sure you have some associations ;-) and

            b)      the plantUML source code, so you can edit or augment the figures e.g. with an online editor e.g. [PlantText]



            In the webconf tomorrow I can give a brief introduction to the slides, but even more important we need to discuss if we can agree to take plantUML for joint editing of these views and understanding. It is my understanding that in parallel Johannes is conducting some experiments to integrate plantUML figure generation into github so we not have to share two documents as done for illustration above but can work on a single one.



            So please share your ideas on this.



         Thanks for sharing this with us.  Any particular reason why the term “wot servient” has been introduced here? For me, Web of Things Server is clearer — it is a web server that hosts things.



         My implementation work, and my look at microcontrollers suggests that a critical part of the architecture will be the metadata and the need to cleanly separate descriptions of things, security and communications related aspects.  One example is to cover the possibility that some servers will batch data and even multiplex data from different sensors.



         Best regards,



         —

            Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>