---
# System prepended metadata

title: sifis-api

---

# 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.