# First video --- Mocked runtime In this demo, we show how a third-party developer can test their application in a mocked environment. That is, the developer does not need the complete SIFIS-Home framework to be up and running in order to test their application's functionalities. The SIFIS-Home developer APIs invoked within the application's code are processed by the mocked runtime component, which replies according to its configuration. ![](https://hackmd.io/_uploads/Hyg-HE-WT.png) # sifis-api showcase The sifis-api is made so third-party developers can write applications for the SIFIS-Home framework. The system assumes that the applications act as a client that is bound to a runtime server via a unix socket. ### Video sentences - This diagram shows the full interaction among the SIFIS-Home framework components - With the mocked runtime, everything after it, is simulated - The mocked runtime can be configured to expose some simulated devices, so that the application can interact with them - - The runtime shown in this demo is configured to expose two simulated lamps - The third-party application 'lamp' is started - This toy application: - looks for lamps, - prints their current state, and - attempts to turn them on - When a second run is performed, we notice that the status of both the lamps is 'on', due to the first run - The mock runtime logs the the lamps' internal state change, and the applications that connect to it ### Local development To simplify the development we provide a configurable mock server that does not need a full deployment of all the SIFIS-Home components. Here we have the simplest setup, the server running and an example application that tries to enumerate the lights available and turn them on. ![](https://hackmd.io/_uploads/B1iKQ4-Za.png) ----------------------------------------------------- ## Full Local deployment ![](https://hackmd.io/_uploads/BkInXP-bp.png) The sifis-api is split in an application side and a runtime side. The application side is a least-priviledge API designed to be used by untrusted application. The runtime side is designed to be trusted, provide information to a third party usage-control and interact with devices leveraging consumers. We provide a reference implementation of the SIFIS-Home runtime that leverages the DHT to communicate with the Usage Control engine and a reference consumer able to control WoT http devices, in our case Lamps. ![](https://hackmd.io/_uploads/SJtCNN-W6.png) ![](https://hackmd.io/_uploads/SyEQEEZZp.png) In order to deploy the full system you need the Usage Control service, a websocket-to-dht broker, the runtime server, a consumer with some WoT servients, applications. This demo uses: - the DoMO Broker and the sifis-runtime, configured to use the same DHT key - the Usage Control configured to connect to the local broker. - the sifis-consumer configured to use the same DHT key, it spawns two lamps. - The runtime registers itself with the Usage Control - The consumer is configured to spawn locally simulated devices - one of the lamps is with deployed policies and the other one without. - The third-party application 'lamp' is started - This toy application: - looks for lamps, - prints their current state, and - attempts to turn them on - Since the usage-control allows only one of the lamps this time the application output shows its behaviour on inacessible devices. - When the usage-control allows the action the runtime forwards the requests to the consumer that then controls a device exposed as WoT Thing. In this demo, we show the flow depicted in this diagram, which is triggered by the invocation of a SIFIS-Home Developer API 'App'(or 'third-party application'): the third-party application invoking the SIFIS-Home Developer APIs 'Runtime': the component intercepting the requests from the third-party application, and communicating both with the usage control engine and the consumer through the DHT 'broker': persistence and multi-protocol message dispatching node, used by the usage control engine to interact with the DHT 'UCON' (or 'usage control'): the usage control engine, which takes access control decisions according to the installed access policies 'consumer': the component that has direct control over a device, called Thing 'thing': the representation of a real device // using its description called Thing Description. // a device, as described using the Web of Things paradigm.