JSON Configuration

Besides data receiving control via HTTP RESTful API, there is another important feature that developers of the integrating application pay heed to, namely configuration of integrated software. Viinex configuration document format is designed to be simple and manageable.

Configuration for Viinex is a JSON text document, which is independent from application language and allows to use JSON for data exchange between various applications, while the format of this JSON configuration document is developed in a way that makes configuration of Viinex easy when generated by integrating application.

There are two main keys in Viinex JSON configuration: Objects and Links. Object in Viinex is a JSON array for basic functional blocks (“objects” or functional modules), which are started at Viinex start, and Link contains JSON array, each describing one or several functional links that should be established between Viinex modules at the time of performance.

Integrity and consistency control

There are no implicit interconnections between Viinex remote components, which ensures that a configured system always can be ran autonomously. All the links between Viinex components and references within one configuration are treated as local. That’s why a namespace clash can never occur for components running in a single Viinex instance. At the same time, several predefined configurations can be easily combined to deploy them in a single Viinex instance, by simply merging that configurations into one configuration document or into one configuration directory. This makes it possible to run several predefined aggregates of Viinex components, preseving the links within such aggregates, – in a single Viinex instance, or on multiple Viinex instances, when required by application which uses Viinex.

The integrating application makes changes in Viinex configuration in atomic way, i.e. the changes related to the objects that should work together are made simultaneously. This approach to the use of integrated systems has a significant advantage, since all objects that rely on each other to operate correctly can safely assume that their dependency in Viinex operations will not disappear because of change of the settings.

Configuration consistency can be checked once at Viinex instance start and be guaranteed throughout the time of instance work. This is particularly important when changes are applied to a software system configuration, and the system itself consists of several interoperating and interdependent logical objects.

Clusters and dynamic addition of objects

Viinex contains tools for creating and deleting groups of objects on the run. That is to say, if integrating application needs to dynamically create or delete, for example, a video source, Viinex provides for these purposes an HTTP API which allows for programmed creation and deletion of groups of objects. In Viinex these groups are named clusters. It is important that clusters can be created and deleted in Viinex instance operation – and each cluster’s configuration remains unchanged (from the perspective of the objects in a respective cluster – they cannot see changes in cluster configuration). To change the cluster configuration, it has to be deleted and then created again, this time with new configuration.

Another effect of cluster configuration stability principle is that objects within a cluster can be linked only to each other, but not with objects in other clusters. The reason for this is that links between objects are a part of configuration, which is unchangeable for every single cluster.

This restriction can be overcome by, for instance, establishing network connections between objects in different clusters. Network connection can be unstable by its nature, that’s why the realizations of objects in Viinex are inherently ready to process connection breaks because of deletion of clusters containing the objects these connections were established with. It would be a normal, expected action from the perspective of the other side of the connection, since network connection can be broken due to external reasons – unlike the links between Viinex objects in one cluster or main configuration.

We consider the above approach to configuration more straightforward than attempts to process a not quite consistent configuration that results from gradual, partial change of the settings and its appliance on the run. Say, if there’s a need to add a camera to the system, receive events from it, setup the rules for reaction to some detector and record video according to this rule from this camera to a video archive – if all respective changes to configuration are done on the go, in turns down the line – the whole system configuration will remain inconsistent until the last change in line is applied.