JSON Configuration

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

The Viinex configuration is a JSON text document that is independent of the application language and enables the use of JSON for data exchange between various applications.

There are two main keys in Viinex’s JSON configuration: Objects and Links. An Object in Viinex is a JSON array for basic functional blocks, or functional modules, which are started when Viinex starts. A Link contains a JSON array that describes 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 can always run autonomously. All links between Viinex components and references within one configuration are treated as local, so 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 and deployed in a single Viinex instance by merging them into one configuration document or directory. This makes it possible to run several predefined aggregates of Viinex components, preserving the links within such aggregates, in a single Viinex instance or on multiple instances as required by the application that uses Viinex.

The integrating application makes changes to the Viinex configuration in an atomic way, meaning that changes related to objects that need to 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 due to a change in settings.

Configuration consistency can be checked once at Viinex instance start and guaranteed throughout the instance’s operation. 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.

The Middleware Supports Clusters and the Dynamic Object Addition

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

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

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

We consider the above approach to configuration more straightforward than attempting to process a not-quite-consistent configuration resulting from gradual, partial changes to the settings and their application on the fly. For example, if there is a need to add a camera to the system, receive events from it, set up 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 the configuration are made on the fly, the whole system configuration will remain inconsistent until the last change in line is applied.