Comments (6)
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
from wot-architecture.
From WoT client point of view,
- WoT client gets Thing Description of target shadow device, that is, WoT server.
- 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 - 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. - 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
- Abstract interface between run time represented as "WoT-core" and each micro services
- 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.
from wot-architecture.
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").
from wot-architecture.
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.
from wot-architecture.
(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.
from wot-architecture.
OK, I agree that Mathias's document. Especially, TD does not go through protocol binding is correct.
from wot-architecture.
Related Issues (20)
- arch-security-consideration-avoid-direct unclear
- Siemens-Logilab implementation description HOT 2
- System and Discovery terms are currently unused
- Use Case due diligence HOT 2
- Requirements assessment HOT 1
- Remove section outline from abstract
- Update CR version with change log HOT 1
- TLS/DTLS Version Assertions Ambiguous HOT 7
- Evaluating At Risk Assertions HOT 1
- Cleanup Wiki pages HOT 1
- Removing redundant assertion csv files HOT 3
- Confusing Explanation for Figure 29 HOT 1
- Change "pre-shared keys" to "certificates" in arch-security-consideration-use-psk HOT 3
- Change "IoT ecosystem" to "IoT Platform" in arch-security-consideration-communication-platform
- Verify DTLS textual changes
- Improve normative text on "implicit acces control"
- Explain the term HAL
- Correct statement about "guest" networks
- Update Acknowledgements HOT 2
- Replace URLs in Document and IR with links HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wot-architecture.