Two separate layers for the Protocol Binding mechanism

[ashimura]

As I mentioned during the TD call on June 2 and the WoT main call on June 7, I think it would be clearer to have the two separate layers for Protocol Binding:

• L1: TD World (=Device-independent abstract layer)
• L2: Device World (=Device-dependent layer)

"Protocol Binding" could be the combination of (1) getting/extracting device properties based on the each device's features and (2) packing the extracted properties into TD for interoperable connection. Probably each device vendor should provide concrete micro server implementation for the "propery extraction" part and we W3C WoT group could provide "how to pack the property into TD" as the "Binding Template".

Please see also the diagram below:

Note that the "Servient Internal Data Transfer" within the above diagram should be the standard WoT mechanism, e.g., TD and REST.

I'd suggest we update the WoT Architecture document, e.g., its section "4.3 Binding Templates" with the above idea.

[Tomoaki-Mizushima]

I update Mr.Ashimura's diagram. Please see the diagram blew:

I add "WoT Servient World" and "non WoT Servient World".

"WoT Servient World" is used to connect other WoT Servient and WoT Client Device. WoT Client Device is devices and sensors that Implements simple WoT Servient functions. I think micro server for WoT Client and WoT Servient does not need to transfer to WoT Servient Internal Data. I think they send JSON messages packed the property of TD.

"non WoT Servient World" is used to connect Echonet, BACnet, OCF, oneM2M, etc.

Thanks

[Kazuo-Kajimoto]

From WoT client point of view,

1. WoT client gets Thing Description of target shadow device, that is, WoT server.
2. WoT Client analyses the TD of WoT server and finds out
   2-1) What kind of APIs, WoT server exposes
   2-2) What kind of protocols, WoT server accepts
3. WoT client call scripting API such as
   　setProperty("http://xxx/wot-device/ledlamp/1/power-on-off", true)
   This syntax expects write "power-on-off" API as true(1) through HTTP.
4. Protocol binding maps scripting API to HTTP header and body as follows
   [Header]
   PUT http://xxx/wot-device/ledlamp/1/power-on-off HTTP/1.1
   ....
   Content-Length: 4
   ....
   Authorization: Bearer eyJhb...NiJ9.eyJhdW...zBjODIxIn0.TOM...Mn5w
   Content-Type: application/json;charset=UTF-8
   ....
   Accept-Language: ja,en;q=0.8,en-US;q=0.6
   Cookie: PHPSESSID=blbu7iqp3v2amo3m33ere6ti13

[Body]
true

In the architecture document, I assume this interaction process and draw "run time with scripting API" and "protocol binding" between WoT servients as building blocks according to IG discussion.
And "protocol binding" block as communication part is drawn in right side.

On the other hand, Echonet lite, OCF, oneM2M and other IoT standards have their own protocol binding policy, mapping methodology and syntax.
So the step of 4) is described legacy communication block in left side.

Both of Kaz-san and Mizushima-san's building block is just same as current architecture document's building block logically.

Kaz-san's building block has multiple legacy communication blocks parallel according to each IoT standards as micro service.

Mizushima-san's building block treats protocol binding in between WoT servients as one of legacy communication blocks.

Then current architecture has covered both of proposals logically, so we can move to discuss

1. Abstract interface between run time represented as "WoT-core" and each micro services
2. How to map TD to above abstract interface through Scripting API

This discussion is directly linked under "Protocol Binding" thread led by Michael Koster-san.
I propose to continue discussion under protocol binding thread.

[mkovatsc]

The figure is pretty close to the actual architecture of node-wot. I have a few comments:

A main issue to clear up is this "WoT Servient world". It came to be experienced just because we neglected the vocabulary in the link or binding to describe the method. We must be Web-compatible, ney, Web! :)

So please consider it as HTTP binding (microserver for HTTP + client for HTTP; ... for CoAP). With application/json as media type, it is identical to the Scripting API data model, so no transformation is required in the binding. For application/cbor the schema information is still identical, only the encoding has the be changed -- can easily behandled in a CBOR-parser-serializer ("CBOR handler").

[takuki]

In current architecture document, "connector" is responsible for the actual communication with other servients. (see Functional Architecture of WoT Servient) I think the "microserver for WoT" in Mizushima-san's diagram is similar to the "connector". Then, I think, "connector" should also be present for other protocols such as Echonet because as Kas mentioned the runtime and Echonet microserver, for example, is based on TD and WoT.

[mkovatsc]

(We overall have a challenge with quite diverse terminology and often adapt to reach the majority.)

Yes, connector and microserver are equivalent. In discussions also the term driver came up, which is probably closest to the view of "legacy communication". This driver approach is also how we implemented Modbus for node-wot. Since we usually want to convert the "legacy devices" (often the are up-to-date devices just from an for us exotic domain) to our TD and interactions model, I prefer the figure here (including the positioning of Echonet) over (the quite old) "Functional Architecture of WoT Servient".

We also changed "Resource Model" to "Interaction Model" since there are some platforms that are not resource-oriented -- the WoT interactions with the initial patterns Property, Action, and Event will still hold in such a case.

[Kazuo-Kajimoto]

OK, I agree that Mathias's document. Especially, TD does not go through protocol binding is correct.