4. Fundamentals

In terms of Softnet, a person or organization registered with Softnet MS is called an owner, which means device owner or project owner. An owner can be in one of three possible roles. An owner in the Provider role can deploy IoT projects and share devices with other persons or organizations. An owner in the Consumer role can only consume devices deployed by Providers. A Consumer is not allowed to deploy their own devices. The third role that Softnet MS supports is Administrator. An owner in this role is called an administrator and manages the entire management system.

Softnet employs the concept of a domain for managing an IoT project. In a domain, autonomous devices and clients are represented as services and clients, respectively. A domain also contains a list of users. The owner assigns access rights to users for the services deployed in the domain. Some services may employ role-based access control (RBAC) to implement various levels of access to the service (or device features). In this case, the owner can distribute roles defined by the services among domain users.

Along with a list of users, each domain contains a list of sites. Site is a virtual host on which you set up a service and its clients. Site can be single-service or multi-service. You create a single-service site if client applications that you are intended to set up on the site are designed to interact with one and only one remote service. Otherwise, you can create a multi-service site. In this case, one client application can interact with multiple remote services (i.e., autonomous devices). However, all services on the site must be of the same type. An IoT application developer can provide guidance on what type of site can be created to deploy a given autonomous device.

Each service implements a specific interface that exposes the device functionality to clients. In Softnet, a service interface is denoted by a combination of the service type name and the name of the contract author. These names are used to make it impossible for clients that are not designed to consume this type of service to make requests to it. This is achieved by the fact that when connecting to the site each client provides the site with the names of service type and contract author of the service for which it is designed. And if they do not match the names that the site expects, the client is assigned the status “service type conflict” and halted. The second purpose of using these names – it makes impossible for a service to get online if it has these names different from those that the site expects. In this case, the service is also assigned the status “service type conflict” and halted. If you’re wondering why Softnet uses a combination of these names instead of just a service type name, it’s because sometimes a service type name can be a fairly short string. Therefore, to avoid naming collisions, the service type is extended by the contract author, the person or organization that developed the service interface. Thus, two services have the same service type only if they have identical contract author. Softnet MS displays these names as follows: <service type> (<contract author>), i.e., the name of the service type followed by the contract author’s name in parentheses. This allows you to see in the management panel what type of services are deployed in a given domain and who their developers are. For example, the service type can be the device’s model name plus generation number, and the contract author can be the manufacturer’s name as follows: T-800 (Cyberdyne Systems). In case of DIY project, the service type can be the project name, and the contract author can be the person’s name who developed the project as follows: Smart Home (John Doe).

A service application that connects to the site for the first time provides the site with a structure called Site Structure. It is specific for each service interface, which is, as you know, denoted by the service type and contract author. The Site Structure contains elements and declarations used to build the site with the structure needed for the service interface. It is obvious that if the site is built for a given service interface, and then you connect a device with a different service interface to the site, you will get a conflict. There are two possible types of conflicts. If your service and site differ in service type, then the service status will be “service type conflict” as it is described in the previous paragraph. However, if they are identical but the service and site differ in Site Structure, then the service status will be “site structure mismatch”. From all this it follows that all devices you set up on the site must be identical, otherwise you will receive a “service type conflict” or “site structure mismatch” error for those devices that have a service type or Site Structure that differs from what the site expects.

In the beginning, it was said that the owner assigns access rights to users for the services deployed in a domain. However, it is not users who interact with services, but clients. In Softnet, the concept of a user differs from a classical one. It is simply an entity to which the owner assigns access rights for various services in the domain. By doing this with all users in the domain, the owner creates a user authority scheme for the entire IoT project. As a result, each site contains a list of domain users authorized on this site. Each client on the site is associated with one of those users, from which the client derives the access rights. Users themselves do not directly interact with services. Instead, clients interact with services on behalf of the users. One user can have multiple associated clients on different sites of the domain. On the site management panel, you can add or delete clients as well as change their parameters. If you need to change a client device or you lost it, you can simply delete the client and create a new one. Thus, we have a single user list for all autonomous devices in the project, and manipulations with clients are separated from managing their permissions. This makes the administration tasks convenient. However, the real power of this approach reveals when some of the domain users are associated with your partners.

The term social network is usually associated with Facebook or other similar networks where users can share articles, videos and other resources. But devices can also be thought of as resources that owners may need to share with partners over IP networks. Softnet implements the concept of contacts, which allows you to establish partnerships with individuals and organizations registered on the same Softnet server as you. In a domain, you can have users called Contact users that are associated with your contacts. When you create a new user, you simply specify which contact it is associated with. Then you assign it the necessary permissions on sites. That’s all. Your partners can see what services you share with them and with what permissions. They themselves can create and manage client entities on the sites. And, of course, your partners can also share services with you.