Architecture Model
We were looking for a tool to exchange the representations of the architecture model in a editable way which in the best case also allows for change tracking. Github wiki and Gravizo in combination with PlantUML by means of the editor Planttext seem to do the job.
Note: Some times the code syntax contains chars (e.g., new lines) that the processor isn't able to sent to Gravizo properly, when this happen you can use a converter (http://www.gravizo.com/#converter). Use the result as url in your image tag.
![Architecture sketch](http://g.gravizo.com/g? @startuml; component [WoT Servient]; package "The classic Web" {; [Web Browser] -> [WoT Servient] ; [Web Server] <- [WoT Servient] ; }; [other \n WoT Servient] <-up-> [WoT Servient]; package "Mapping to Physical Device" {; [WoT Servient] <-down-> [WoT Servient \n for physical device]; [WoT Servient \n for physical device] - [Sensor/Actor Device]; }; note right of [WoT Servient]; WoT Servients run applications that expose or consume ; "Things" through an API and Protocol bindings ; end note; @enduml )
[DP] Feel free to comment on each sketch
![Virtual Instance](http://g.gravizo.com/g? @startuml; package "Virtual Instance" {; Servient -down- [Event Sources] ; Servient -down- [Recources] ; Servient -down- [Actions]; }; package "Real Thing" {; Mech_El_IF -down- [Sensors]; Mech_El_IF -down- [State]; Mech_El_IF -down- [Actors]; }; Sensors -up..> [Event Sources] : sensing; [Actions] ..> Actors; @enduml )
- Virtual Instance has actions, resources, and event sources.
- Actions, resources, and event sources contain APIs of a thing and code that how to actuate or sense a thing including protocol binding.
- A Virtual Instance ties to a real thing.
- More than one Virtual Instances can be allocated to a WoT Servient.
- Virtual Instance is instantiated by WoT Servient from script or code (i.e. Device Driver).
![RealBT](http://g.gravizo.com/g? @startuml; package "Virtual Lock Instance BT" {; LockServientBT -down- [Locking Event BT] ; LockServientBT -down- [Lock Position, Lock Usage BT] ; LockServientBT -down- [Lock Control BT]; }; package "BT GW" {; BT_V -up- [BT Adapter]; }; package "BTLock" {; LockIFM -down- [Lock Position Sensor BT]; LockIFM -down- [Lock State BT]; LockIFM -down- [Locking Motor BT]; BT_L - [LockController]; LockController -down- [Locking Motor BT]; LockController -down- [Lock Position Sensor BT]; }; BT_L -up..> BT_V; [Lock Control BT] ..> [BT Adapter]; [BT Adapter] ..> [Locking Event BT]; @enduml )
- WoT Servient gets a device profile on discovery.
- WoT Servient invokes a virtual instance and installs a Device Driver (Thing Description) that corresponds to the device profile.
- WoT Servient exposes APIs of the virtual instance.
- BT GW has a media conversion capability such as BLE or Bluetooth 2.1.
- BT GW accommodates an API such as GATT API, WebBluetooth, or HDP(Health Device Profile) in order to expose functions of a real thing.
- WoT Servient binds the real thing and the Virtual Instance through the BT GW.
![RealB](http://g.gravizo.com/g? @startuml; box "Virtual Instance A" %23LightBlue; entity EventSourceA1; entity ResourcesA; entity ActionA1; boundary ServientA; end box; box "Virtual Instance B" %23LightGreen; boundary ServientB; entity EventSourceB1; entity ResourcesB; entity ActionB1; end box; ServientB --> ServientA : Subscribe_EventA; EventSourceA1 --> ServientA : EventA; EventSourceA1 --> ResourcesA : EventA; ServientA --> ServientB : EventA; ServientB --> ActionB1 : TriggerB1; EventSourceB1 --> ResourcesB : SensedActionB1; @enduml )
Needs further work:
- All events, actions are mirrored as resource
- To support late binding use pub/sub
- Subscribe_EventA of B is not necessarily sent by B
- Also enables proxies due to resource constraints of servients
- Instance/logic binding events to actions
- Example: Mapping to conrete protocol
Please take a look at the code by editing the page.
![Alt text](http://g.gravizo.com/g? digraph Gdir { aize ="4,4"; main [shape=box]; main -> parse [weight=8]; parse -> execute; main -> init [style=dotted]; main -> cleanup; execute -> { make_string; printf} init -> make_string; edge [color=red]; main -> printf [style=bold,label="100 times"]; make_string [label="make a string"]; node [shape=box,style=filled,color=".7 .3 1.0"]; execute -> compare; } )
![Alt text](http://g.gravizo.com/g? @startuml; actor User; participant "First Class" as A; participant "Second Class" as B; participant "Last Class" as C; User -> A: DoWork; activate A; A -> B: Create Request; activate B; B -> C: DoWork; activate C; C --> B: WorkDone; destroy C; B --> A: Request Created; deactivate B; A --> User: Done; deactivate A; @enduml )
Things are virtual objects that act as proxies for physical and abstract entities. Each thing must have a model for its events, properties and actions (exposed to scripts as callbacks, object properties and methods). This is described using Linked Data and may be expressed in JSON-LD. The MIME type for the thing description language (TDL) implies a default JSON-LD context that defines the bindings to URIs for the vocabulary common to most things. This can be supplemented with domain specific vocabularies.
Each event must have a name and may have associated data conforming to the JSON data model, e.g. a number, boolean, string, array or object. Arrays and objects may have subsidiary data. Scripts can set event listeners.
Each property must have a name and a type. Some common types include number, boolean, string, array, object, stream or thing. Arrays and objects may have subsidiary properties.
Streams are a class of object that represent a data stream. Streams may have metadata indicating the sampling interval and the time window covered by the sample buffer. Streams may provide a means to query the value at a specific time, or to access samples spanning a given time interval. A stream may have multiple channels corresponding to related readings taken at the same time. These channels are numbered or named, and must have types, and may have additional metadata.
Properties may have additional metadata. One example is whether a property is writable. By default properties are readonly. A door, for instance, may have a sensor that detects whether it is open or closed, but no means for software to open or close it -- something that people have to do. Another example is where the value space for a property is constrained, e.g. to integers in the range 1 to 10.
Note that there may be a lag before a property update takes effect on the thing being proxied. One case is where a battery operated device spends most of its time asleep to prolong battery life, waking up periodically to listen for messages. The update has to wait until the device next wakes up. Things receive notifications when this has happened (the details depend on the protocol bindings). The notification is exposed as a property update event.
Question: should this update event be raised on the thing, or on the property? If the latter, then we need a means to listen for events on specific properties. This is probably platform specific.
Note that things may have additional metadata. Changes to this will be notified in essentially the same way as for properties. Examples include the location and owner of a sensor. A running meta datum is true when a thing has been started and reverts to false when it has been stopped.
Actions provide a means to invoke named methods exposed by things, e.g. to unlock a door. Actions may require data conforming to the JSON data model, e.g. a number, boolean, string, array or object. Arrays and objects may have subsidiary data. Actions are asynchronous and may return a result conforming to the JSON data model.