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

Hi Dave, 

Thanks for the quick comments!

Here is an updated slide deck you can view on github:

https://github.com/connectIOT/iotivity-servient/blob/master/docs/OCF-Servient.pdf <https://github.com/connectIOT/iotivity-servient/blob/master/docs/OCF-Servient.pdf>

Comments below...

Best regards,

Michael

> On May 29, 2017, at 9:11 AM, Dave Raggett <dsr@w3.org> wrote:
> 
> 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?
> 
By "WoT Network", I mean the nework over which WoT Things are exposed via the exposed thing interface, using the REST mapping specified in the default http protocol binding.

> 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.

I call that a forward proxy protocol binding, shown in orange on the left side of slide 4. I expect to use the iotivity-node client API to layer this on top of, and adapt to the (Scripting) Consumed Thing API.
> 
> 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 didn't at first consider the case where you can use the WoT Exposed ThIng scripting API to create an OCF device. I didn't think it would be useful, but now I am beginning to think TD might be a good OCF device definition language, at least for virtual devices. I will add it to the use cases.
> 
> 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. 

I see it as mapping the OCF interaction model to the WoT model in such a way that the client would not need to know it was accessing an OCF device vs. any other TD-based device at the scripting API level. The TD metadata I propose in the example TD at: https://github.com/connectIOT/iotivity-servient/blob/master/td/td-ocf-protocol-binding.json <https://github.com/connectIOT/iotivity-servient/blob/master/td/td-ocf-protocol-binding.json> is exactly intended to be the metadata the OCF driver needs. Likewise for re-exposing the OCF device as a WoT Exposed Thing.
> 
> 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.

Yes, I think we can demonstrate quite a bit of this by November if we stay with it.
> 
> 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.
> 
The last slide in the deck illustrates my approach to this. I propose to use an OCF Link BInding to invoke an external network function (perhaps in a Node-RED instance) that can be a simulated or physical device. Physical devices can be off the shelf things like Philips Hue, IKEA Tradfri, etc. that have simple LAN-accessable REST APIs. This can all be easily wired in with Link Bindings and Node-RED.
> 
> 
>> On 29 May 2017, at 16:38, Michael Koster <michael.koster@smartthings.com <mailto: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 <mailto:dsr@w3.org>> http://www.w3.org/People/Raggett <http://www.w3.org/People/Raggett>
> W3C champion for the Web of things
> 
> 
> 
>