Re: New web of things server projects

> On 27 Jun 2015, at 13:38, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:
> 
> Dear Dave
>  
> For CoAP I would like to take advantage of the pub-sub mechanism that the IETF is working on, as a basis for the thing server to send notifications to other servers with proxies for the things that the CoAP server hosts.  I am chatting with some MQTT experts to ensure that we hit the ground running with the MQTT bindings.   A further challenge is the choice of binary encodings for messages.  Carsten Bormann of CoAP fame advocates CBOR, but other people are keen on EXI, which can offer superior compression based upon the data model.
>  
> I am getting more and more confused about what “Web” stands for in the W3C WoT activity. CoAP is a RESTful protocol that is built for transferring state of resources encoded as standard Internet Media Types. And it comes with a native support for asynchronous push notifications from the server. In what sense do we need a “binding” here?

The Web of Things defines an abstraction layer above the transport layer. It is about extending the Web from a Web of pages to a Web of Things, based upon the fundamental principle of URIs for addressing, protocols for accessing resources, and declarative formats as a basis for discovery and interoperability.

CoAP is great for its intended niche, namely an efficient RESTful client-server protocol for communicating with resource constrained devices.  In other contexts other protocols may be more appropriate. By defining an abstraction for things in terms of metadata, events, properties and actions we can create interoperability across Web servers of widely varying scales of devices and across different protocols, different data formats and different encodings.

>  Furthermore, why should we first constrain CoAP to the pub/sub pattern (which is very useful, IFF you want to explicitly build a pub/sub application, for instance to minimize the complexity for normally-off or mobile nodes) to then construct a binding on top to have RESTful interactions?

I agree, why indeed!   GET is appropriate for requesting the state of a thing (its properties), PUT to update all its properties, PATCH for a updating a subset of properties, and POST for invoking an action.  The observe design pattern for CoAP is good for asynchronous notifications of events and property updates.  Michael Koster’s proposal for supporting brokers with CoAP also looks interesting. I am looking forward to exploring all of this with a C based Web of Things server for either the Arduino or the ESP8266. The latter looks particularly appealing given its very low cost and much better spec.

>  In my understanding, a binding for MQTT would be a REST gateway that uses the layered-system constraint to provide a REST interface on the one side and connect it to whatever system on the other side. Since MQTT does not have the notion of URIs and Content-Types, I agree that we need a binding here. However, in my understanding, these things then are MQTT things behind a gateway and not Web of Things servers.

The Web of Things is at a higher level of abstraction, and that there is a place for HTTP, Web Sockets, CoAP, MQTT and XMPP according to the context.  When a Web of Things server wants to proxy a thing on another such server, the server metadata provides the basis for choosing an interoperable messaging path for events, property updates, invoking actions and responses. We are looking for efficient bindings for all of these protocols.  The data model for the Web of Things is founded on Linked Data, 

>  The main problem I see with this development is that we say “hey, let’s build something easy with JSON,” but at the moment ignore a lot of complexity that will hit us once we reach critical mass. Then we will need to extend our simply world view and will eventually end up with CORBA/WS-* 2.0… The nice lesson about REST was that there are already a lot of mechanisms built into the protocol(s) to deal with this critical mass complexity of distributed systems; and we should use these mechanisms.

Client-server and pub-sub are both appropriate in different contexts. I fully agree with the benefits of REST, and the need to choose data formats and encodings appropriate to the context.  We definitely want to scale from microcontrollers to very high throughput cloud based server farms. This is why the communication metadata is so important since no one solution will be a good fit in all contexts.

Coming back down to nuts and bolts, I would like to get your thoughts on encodings and binary formats for resource constrained devices.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>