Re: protocol binding use cases for iotivity-node integration with node-wot

On slide 4, I am unsure what exactly is meant by “WoT Network” given that the Web of Things is an abstraction layer above IoT standards, protocols, data formats and communication patterns. In other words we will use whatever IoT standards are appropriate, or are you suggesting that W3C define another IoT standard?

I expect to use an OCF driver module that sits between the WoT Scripting API and the underlying protocol drivers.  This could be layered on top of iotivity-node and iotivity, or it could be layered directly on top of HTTP and CoAP modules, replacing iotivity altogether.  A basic OCF driver could be quite simple and developed to interoperate with an iotivity based server.

On slide 3, you might want to note the case where an OCF client seeks access to a non OCF device that is exposed to OCF as if it were an OCF device.  This could arise when a Web of things server application exposes a thing and wants to make it accessible as an OCF device.  Given than OCF requires conformance to a fixed set of devices, this requires some kind of translation layer.

I envisage the application using an interaction model that mirrors an OCF device (see my work on mapping  OCF devices to thing descriptions). You would then just need to add the metadata for the OCF driver. I see this as something we should aim to demonstrate at a future plugfest. 

Unfortunately, I am rushed off my feet at the moment with the AI Expo and IoT TechExpo this week in Berlin, the IoT Week in Geneva (next week), and preparing some EU project deliverables due by the end of June. I there would like to set such a demonstration as a target for this year’s TPAC.

p.s. I am particularly interested in support for simulated devices as a means to explore interoperability experiments without the need for physical devices.  The approach I outline above would make that relatively easy.

Best regards,
     Dave


> On 29 May 2017, at 16:38, Michael Koster <michael.koster@smartthings.com> wrote:
> 
> Hi,
> 
> I revised my previous diagrams showing the two integration patterns based on using CoAP only for the OCF device network, slide 4.
> 
> Note that the same protocol binding template can be used to adapt the WoT Consumed ThIng API to the iotivity-node client (forward proxy), as well as adapt the WoT Exposed Thing API to iotivity-node (reverse proxy) to re-expose OCF things as WoT things on a network.
> 
> In the forward proxy case, the protocol binding adapts a WoT client to an OCF client, and lives on the client.
> 
> In the reverse proxy case, the protocol binding lives on the server, and the client sees a standard WoT thing on the network.
> 
> Do these 2 cases make sense? Are there other arrangements we need to look at?
> 
> I don't seem to be on the scripting mailing list, if there is one. Forwarding to the public list; please excuse the interruption if you aren't interested.
> 
> Best regards,
> 
> Michael
> 
> <OCF-Servient.pptx>

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things