JSON конфигурирование

Помимо управления получением данных через HTTP RESTful API, конфигурирование встраиваемого программного обеспечения — одна из важных характеристик, на которую обращают внимание разработчики интегрирующего приложения.

Конфигурация для Viinex представляет собой текстовый документ JSON, который не зависит от языка реализации приложений и позволяет использовать JSON для обмена данными между различными приложениями, а формат конфигурационного документа Viinex разработан так, чтобы конфигурация Viinex была простой при ее генерации интегрирующим приложением.

Формат конфигурационного документа Viinex разработан так, чтобы конфигурация Viinex была простой в написании и обслуживании. В JSON конфигурации Viinex есть два основных ключа: Objects и Links. Objects в Viinex представляет собой массив JSON для элементарных функциональных блоков («объектов» или модулей функциональности), запускаемых при запуске Viinex, а Links содержит массив JSON, каждый из которых описывает одно или несколько функциональных соединений, которые должны быть установлены между модулями Viinex во время выполнения.

Контроль целостности и непротиворечивости

Между удаленными компонентами, работающими на разных экземплярах Viinex, никогда не устанавливается неявных соединений, что гарантирует, что сконфигурированный экземпляр Viinex может работать автономно. Все связи между компонентами Viinex и ссылки на компоненты, фигурирующие в конфигурации, интерпретируются как локальные (в пределах того же экземпляра Viinex). Как следствие, между компонентами на разных экземплярах Viinex, работающих в одной распределенной системе, не может возникнуть конфликта имен. В то же время, на одном экземпляре Viineх достаточно просто развернуть несколько предопределенных конфигураций — путем объединения этих конфигураций в один конфигурационный документ или в одну конфигурационную директорию. Это позволяет запускать несколько предопределнных агрегатов из компонентов Viinex, сохраняя связи между компонентами внутри каждого агрегата, — на одном экземпляре Viineх, или на разных экземплярах, — по усмотрению приложения, использующего Viinex. Тем самым Viinex поддерживает миграцию связанных друг с другом компонентов, для обеспечения масштабируемости вашего приложения.

Изменение конфигурации Viinex осуществляется интегрирующим приложением «атомарно», то есть так, чтобы все изменения, связанные с объектами, которые должны работать совместно, применялись одновременно. Такой подход при использовании встраиваемых систем обладает существенным преимуществом: при нем все объекты, которые полагаются друг на друга для корректного функционирования, — могут безопасно предполагать, что их зависимости во время работы Viinex не исчезнут из-за изменения настроек.

Непротиворечивость конфигурации может быть проверена единожды, при старте экземпляра Viinex, и эта целостность гарантируется на всем протяжении работы экземпляра, что особенно актуально, когда к конфигурации программной системы применяются изменения, и система сама состоит из нескольких логических объектов, взаимодействующих друг с другом и зависящих друг от друга.

Кластеры и динамическое добавление объектов

Viinex содержит средства для создания и удаления групп объектов прямо во время работы. То есть, если встраивающему приложению нужно динамически создать или удалить, например, источники видео, Viinex предоставляет для этого HTTP API, позволяющий программно создавать и удалять группы объектов. Такие группы в Viinex названы кластерами. Важно, что кластеры могут быть созданы и удалены во время работы экземпляра Viinex, — конфигурация каждого кластера, как и ранее, остается неизменяемой (с точки зрения объектов в соответствующем кластере — они не могут наблюдать изменения конфигурации кластера). Для того чтобы изменить конфигурацию кластера, его нужно полностью удалить и затем создать заново, уже с новой конфигурацией.

Еще одним следствием принципа неизменности конфигурации кластеров является то, что объекты внутри кластера могут быть связаны только друг с другом, но не с объектами в других кластерах. Это объясняется тем, что связи между объектами являются частью конфигурации, которая неизменна для каждого отдельного кластера.
Это ограничение практически может быть преодолено за счет, например, установки сетевых соединений между объектами в различных кластерах. Сетевое соединение по своей сути может быть нестабильным, поэтому реализации объектов в Viinex изначально готовы обрабатывать разрывы сетевых соединений из-за удаления кластеров, содержащих объекты, с которыми установлены такие соединения. Это будет нормальным, ожидаемым поведением для второй стороны соединения, потому что сетевое соединение может разорваться из-за внешних причин – в отличие от связей между объектами Viinex в одном кластере или в главной конфигурации.

Мы считаем, что вышеописанный подход к конфигурации является более прямолинейным, чем попытки обработать не вполне состоятельную конфигурацию, возникающую при последовательном, «частичном» изменении настроек и их применении «на лету». Например, если требуется добавить камеру в систему, получать от нее события, настроить правила для реагирования на какой-то из детекторов, и записывать по этому правилу видео от данной камеры в архив, — если соответствующие изменения в конфигурацию начать делать «на лету» последовательно, по цепочке, одно за другим, — то конфигурация системы в целом окажется несостоятельной до тех пор, пока не будет выполнено самое последнее изменение в цепочке.