eclipse-thingweb / website

Homepage for Eclipse Thingweb, thingweb.io
https://thingweb.io
Other
5 stars 11 forks source link

[Redesign] Possible Thingweb Component Combinations #77

Open egekorkan opened 5 months ago

egekorkan commented 5 months ago

As discussed in today's call, we can think of useful Thingweb component combinations in different scopes. I will write some below but everyone can write some other ones. We do not need to limit to Thingweb components but no need to promote other stuff more than our components. Most WoT applications have a subset of the following parts, for which we have some components already:

  1. Thing Program: HW interfacing, protocol stack, logic
    • node-wot
    • Node-RED blocks (built with node-wot)
    • dart_wot (soon)
    • Online Things (not a component though)
    • Any WoT device
  2. Consumer Program: Logic, UI, Protocol stack
    • node-wot
    • Node-RED blocks (built with node-wot)
    • dart_wot
  3. TD-based tooling (validation, TD transformation etc.)
    • td-tools
    • playground
  4. TD Directory
    • Domus TDD

Basically, anything from categories 1 and 2 can be combined. They can be enhanced by tools from td-tools or Domus TDD. With tools from td-tools, we can integrate into or from other ecosystems such as AAS, OpenAPI or AsyncAPI.

Concrete combinations are coming soon as edits to this comment.

egekorkan commented 4 months ago

Simple Consumer-only workflow

  1. I get a device from a manufacturer without TD/TM. I write a TD/TM (or is given by the manufacturer). I validate it with Playground. I write the Consumer application with node-wot. Highlight: It can run on the browser.
  2. Same as above but the Consumer application is in dart_wot. Highlight: It can run on mobile
  3. Same as above but the Consumer application is with Node RED components of node-wot. Highlight: Easy to program with visual building blocks.

Simple and homogenous workflows

  1. node-wot Thing, node-wot Consumer: I write node-wot code and deploy it on a RPi, attach some sensors and interface to them. It generates the TD and I know exactly where it is (no need for discovery) and it is valid (no need for playground). I write the Consumer application.
  2. Node-RED Thing, Node-RED Consumer: Same as above.
  3. dart_wot Thing, dart_wot Consumer: Same as above.

Professional workflow

  1. Multiple people are building Things or have built them. Each has used another framework, programming language and protocol. They also have their TDs
  2. They validate their TDs on Playground.
  3. They submit their TDs to an instance of Domus TDD (of their organization)
  4. Other people search and find the relevant TDs. They start writing Consumer applications (any of the above components)

Maybe as a generic message, starting somewhere (others' device or your own DIY device) but scaling thanks to Thingweb is a nice idea.