Описание структуры системы

Архитектура сервера приложения

Состав компонентов системы

• БД (База Данных) системы интеграции (хранит данные по объектам — датчики, события, архив).
• БД планеты (ГИС, хренение данных о 3Д моделях и их размещении)
• Сервер приложения (FireFly) — обеспечивает взаимодействия подсистем с БД
• MSS – сервер работы с оборудованием
• Сервер задач – обеспечивает работу логики системы
• ЦА (Центр Авторизации) – обеспечивает авторизацию пользователей
• Клиент — клиент Интегра Планеты Земля
• Веб клиент — тонкий клиент Интегра Планета Земля

Клиент получает тикет с ЦА. Далее подключается к серверу приложения, передав тикет. Сервер приложения авторизует пользователя по тикету через ЦА, при этом получая разграничения прав для данного пользователя. Клиент Интеграции так же напрямую работает с БД планеты IPE. Веб клиент работает со всеми БД по средствам сервера приложения.

Архитектура серверов системы Интегра

Обобщенная схема для 2х разных центров авторизации которые автономны

На данной схеме убраны некоторые компоненты системы, приведен пример подключения клиентов к объектам с разными независимыми центрами авторизации (без доверительной связи). В данном случае на обоих центрах должны быть заведены пользователи клиентов (возможно с разными правами)

Схема с 1 ЦА и кеш серверами

Схема с разными центрами авторизации (доверительный канал между ними)

На данной схеме все клиенты авторизуются через ЦА1. И при транзите сообщения необходимо добавлять метаинформацию о ЦА на котором авторизован пользователь и в случае несовпадения адресов центра авторизаций необходимо проверить тикет через доверительный канал.

Алгоритм работы сервера приложения

Все данные по объекту хранятся в локальной БД. Осуществляется запись в БД по средствам хранимых функций и только через сервер приложения (при записи в БД помимо сервера приложения будет осуществляться контроль версий транзакций).

Для поддержания актуальной модели на сервере приложения необходимо периодически сверять версию транзакции. При расхождении версий сервер будет добирать разницу изменений и рассылать их в подписках.

При запросе данных по локальным и удаленным объектам данные будут раздаваться с модели. (только перед раздачей будет дополнительная проверка на актуализацию данных).

Алгоритм работы с ЦА

При запуске клиент получает тикет от ЦА(центра авторизации), в случае успешной авторизации и передает полученный тикет на сервер приложения.

Сервер приложение проверяет валидность тикета пользователя на ЦА и получает текущие настройки разграничения прав (а так же периодически обновляет данные по тикету — активность пользователя). В случае неактивности пользователя тикет будет удален (данная функция еще не реализована). А так же сервер приложения периодически опрашивает ЦА на событие изменения прав пользователя. При изменении прав пользователя сервер сообщает об этом клиенту (клиент сам определяет переподключаться или нет), но права на сервере применяются сразу.

Запись архива

Запись архива осуществляется в локальную базу объекта, пишется вся информация и любые изменения параметров (события).

На кешируемых узлах должна писаться информация по объекту (архив) — полный архив по объекту в случае включения данной настройки (архив пишется по правам пользователя синхронизации).

Получение данных по архиву клиентом может осуществляться как с конечного узла так и с кеша (по умолчанию если включена запись архива на кеш то данные раздаются с кеша, для запроса напрямую с объекта необходимо в функции передать доп параметр)

Подписки

Это механизм селекторных подписок который описывает логику запроса (получения) данных.

Описание взаимодействия 2х роутеров.

По умолчанию при открытии соединения работает 1 подписка между серверами (3 составляющие подписки). Первая часть подписки — это мониторинг комплексных состояний , вторая — это подписка онлайн событий, которая открывается при подключении хотя бы 1 пользователя (а точнее создание к конечному серверу хотя бы 1 подписки) а так же пинг подписка для контроля соединения с сервером. Разграничение прав по подпискам применяется на вышестоящем узле (который организовал подписку).

Программные компоненты сервера приложения

Сервер приложения кроссплатформенное решение, на данный момент поддерживается работа системы на операционных системах компании Microsoft начиная с Windows XP на процессорах архитектуры x86-64 и ОС семейства Linux таких как Debian, Ubuntu, RedHat/CentOS, OC Заря на процессорах архитектуры x86-64.

Для корректной работы приложения ставятся следующие компоненты и модули:

1. python-2.7.9

2. Модули python

six-1.9.0-py2.py3-none-any

autobahn-0.9.3-3

zope.interface-4.1.1

Twisted-13.2.0-cp27

zope.event-4.0.3

psycopg2-2.5.5-cp27

pywin32-219

polib-1.0.6-py2.py3-none-any

python-dateutil-1.4.1

python-gflags-2.0

pytz-2010l

google-apputils-0.4.0

protobuf-2.6.1

pyasn1-0.1.7

pycparser-2.12

cryptography-0.7.1-cp27

pyOpenSSL-0.14

cyclone-1.1

Shapely-1.5.12-cp27

3. PostgreSQL 9.6 и выше

Данные требования Так же актуальны и для установки центра авторизации.

Описание подписок на основе селекторов

Предпосылка

Усложнение критериев выборки интересующих подписчика событий, например в задачах трекинга необходима подписка по событиям внутри полигона.

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

Термины

Селектор - объект проверяющий сообщение и возможно его контекст на соответствие некоторому условию, которое и является сутью селектора. Простые селекторы могут проверять например равенство некоторого поля сообщения заданному значению, другие - составные, содержать другие селекторы и производить над ними операции AND, OR, NOT. То есть компоновать другие селекторы в дерево булевого выражения.

Сообщение - объект описывающий изменение параметра базы данных

Контекст - объект или свойство объекта не входящий в объект-сообщение но связанный с ним.

Текущие дата и время, пользователь отправивший изменения, объект сервера, связи объекта - всё это примеры контекстов.

Для эффективной работы с контекстами нужна модель в памяти firefly, другие более просты, например текущие дата и время.

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

Как это работает:

1. Обходим текущие темы сообщений;
2. Каждой теме соответствует единственный, возможно композитный селектор;
3. Каждое сообщение транзакции проходит проверку на соответствие критериями селектора текущей

очереди и в случае успеха добавляется в массив транзакции для текущей темы;

1. Когда транзакции для каждой темы сформированы производится отправка данных (publish);

Управление темами

• com.integra.open_topic(selector) где selector это сериализованный в JSON селектор.

Возвращает имя подписки соответствующей переданному селектору при успехе.

Имя содержит UUID что гарантирует её недоступность для других пользователей.

• com.integra.close_topic(topic_name) где topic_name это имя подписки которое вернулось при открытии темы.

Возвращает имя подписки при успехе. 

Закрыть подписку может только владелец.

Автоматическое закрытие тем

Если на тему никто не подписался то она закроется через минуту.

Если у подписки были подписчики, а потом все отписались то она закроется автоматически не позже чем через query_timout секунд.

Доступные селекторы

Наименование типа	Композитный	Параметры
PropertyEqualitySelector	нет	name - имя свойства value - значение свойства
AndCompositeSelector	да	массив вложенных селекторов
PositionInPolygonSelector	нет	polygon_text - текстовое представление полигона(как в PostgreSQL)
ValueInListSelector	нет	name - имя свойства-массива value - значение

Пример селектора

1 {
2         "$type": "AndCompositeSelector",
3         "selectors": [
4             {
5                 "$type": "PropertyEqualitySelector",
6                 "name": "name",
7                 "value": "ip" 
8             },
9             {
10                "$type": "PropertyEqualitySelector",
11                "name": "value",
12                "value": "127.0.0.1" 
13             },
14            {
15                "$type": "PositionInPolygonSelector",
16                "polygon_text": "POLYGON ((0 0, 0 1, 1 1, 1 0, 0 0))" 
17            },
18            {
19                "$type": "ValueInListSelector",
20                "name": "users",
21                "value": 5
22            }
23        ]
24    }

Пример транзакции из одного изменения проходящего проверку селектором из примера

1             [
2                 {
3                     "server": "76606d62-a514-11e4-8c37-a7064178f246",
4                     "txid": 843037,
5                     "version": 51425717,
6                     "id": "883c24e2-02cb-4988-8e07-3c8bd24654da",
7                     "position": "POINT (0.1 0.2)",
8                     "name": "ip",
9                     "value": "127.0.0.1",
10                    "datetime": "2015-09-02 06:24:06.844",
11                    "types": [
12                        "Item",
13                        "Computer",
14                        "Object",
15                        "DuoEthernetDevice",
16                        "EthernetDevice",
17                        "PowerConsumer",
18                        "MssControlable",
19                        "SpatialObject",
20                        "BaseObject" 
21                     ],
22                    "dict": { "a": "b" },
23                    "users": [
24                        null,
25                        13,
26                        5
27                    ]
28                }
29            ]

Пример работы с подписками на селекторах:

1. Подписались на изменения загрузки процессора:

1 firefly.WAMP.p_com_integra_open_topic({"$type": "PropertyEqualitySelector","name": "name","value": "cpu_usage"}).

2 then(function(res) { console.log(res); }, function(res) { console.log(res); });

2. Нам вернётся имя темы на которую надо подписаться:

1 firefly.session.subscribe('com.integra.selector_subscriptions.027004e8aed04834bf45bcda18ea2ccf', function(res) { console.log('test sub', res); } ).

2 then(function(res) { console.log(res); }, function(res) { console.log(res); })

3. Поменяем что нибудь подходящее в базе. Нужно помнить, что изменения из базы больше не вычитываются и для тестов надо использовать apply_changes:

1 firefly.WAMP.p_com_integra_apply_changes('76606d62-a514-11e4-8c37-a7064178f246', [{"id": "4b618576-ed74-413a-919d-a3e127cbe98f","name": "cpu_usage","value" : 77,"datetime": null,"dict": null}]).

2 then(function(r) { console.log(r); },function(e) { console.log(e); })

4. В консоли должен появиться вывод test sub и далее данные.

Описание структуры типов Интегра-Планета-4D

Формат описания типов элементов системы

Типы элементов системы Интегра-Планета-4Д описываются на языке XML версии 1.0 с использованием utf-8 кодировки.

В xml документе могут присутствовать в произвольном количестве следующие теги:

• enum - описание перечисляемого типа параметра.
• item - описание устройства(объекта).
• pin - описание разъема устройства(объекта).
• link - описание соединения между разъемами.
• event - описание события.

Корневой элемент файла описания может называться произвольно (например root).

Любой тег может содержать дополнительные атрибуты доступные в режиме исполнения.   Дополнительный атрибут может иметь любое имя не совпадающее с именами служебных атрибутов описанных ниже.

Имена дополнительных атрибутов так же не могут совпадать с именами тегов.

Описание Тегов

1. is

Теги enum, item, link, pin и event описывают конкретные элементы системы и их тела могут содержать произвольное количество тегов is, указывающих базовый тип элемента.

Тег is может содержать следующие атрибуты:

type - тип базового устройства. Обязательный атрибут.

Наследуемый тип получает все значения, параметры и разъемы базового.

2. enum Тег enum содержит следующие атрибуты: type - тип перечисления. Обязательный атрибут. assembly - имя сборки в которой определен данный тип (пространство имен должно быть строго acuario2.types). По умолчанию создает новый тип. Тело тега enum содержит один или несколько тегов value, являющихся описанием конкретного значения перечисления. Тело тега value содержит текстовое представление значения с которым связан данный элемент перечисления. Так же тег value может содержать дополнительные атрибуты, например, в случае описания состояния устройства, следующие: color - цвет состояния (в html формате). image - плоское изображение состояния. model - 3D модель состояния. sound - звуковое обозначение состояния. hint - подсказка пользователю (может содержать URL HTML документа с подробным описанием действий оператора в случае наступления данного события). Тег enum должен содержать один тег value не имеющий тела, который может содержать дополнительные атрибуты по умолчанию для всех значений не описанных в перечислении. 3. param Теги item, link, pin и event описывают конкретные элементы системы и их тела могут содержать произвольное количество тегов param, описывающих параметры данного элемента. Тег param может содержать следующие атрибуты: type - тип параметра. Обязательный атрибут. ref - ссылка на другой элемент (uuid); bool - булево значение (bool); char - символ (char(1)); int - целое знаковое число (int8); real - число с плавающей точкой (float8); guid - глобальный уникальный идентификатор (uuid); time - дата/время (timestamp); span - интервал времени (interval); bits - битовая строка (varbit); text - строка (text); ltree - ветка иерархического дерева (ltree); list - список строк (text[]); vector - список чисел с плавающей точкой (float8[]); blob - бинарные данные (bytea); hstore - словарь ключ/значение (hstore); json - документ типа json (json); xml - документ типа xml (xml); point - точка в пространстве (point); multipoint - множество точек (multipoint); polygon - полигон (polygon); multipolygon - множество полигонов (multipolygon); args - если связано с перечисляемым типом при помощи атрибута enum, то список уникальных значений этого перечисления, иначе просто список строк (text[]); name - имя параметра. Обязательный атрибут. enum - тип перечисления связанного с данным параметром. public - булево значение, помечающее параметр как доступный для внешних систем. См. тег item. По умолчанию считается равным false. editor - тип редактора для параметра (например acuario2.client.EgsCodeEditor,acuario2.editor). По умолчанию выбирается автоматически в соответствии с типом параметра. converter - тип конвертера для параметра (например acuario2.utils.UnixTimeConverter,acuario2.utils). По умолчанию выбирается автоматически в соответствии с типом параметра. unit - единица измерения (например second). typedef - имя параметра внутри данного типа содержащего описание json документа хранящегося в данном параметре. См. Dynamic TypeDef в конце документа. Если тип параметра не указан то считается что это текстовый параметр. Тело тега param может содержать текстовое представление значения поля по умолчанию. Экземпляр элемента системы может содержать только одну копию одного и того же параметра. Для совместимости с предыдущей версией параметр помеченный атрибутом many со значением true считается параметром типа list. Имена параметров input и output являются частично зарезервированными и не должны использоваться при описании типов соединений. Имена параметров state и stateargs, так же является частично зарезервированными, но должны быть описаны для каждого типа устройства. Состояние элемента определяется тремя параметрами: state - визуальное состояние элемента. Всегда имеет тип ltree. Должно быть связано с перечисляемым типом при помощи атрибута enum. stateargs - дополнительные состояния элемента. Всегда имеет тип args. Должно быть связано с перечисляемым типом при помощи атрибута enum. 4. pin Тег pin может содержать следующие атрибуты: type - тип разъема. Обязательный атрибут. abstract - булево значение, помечающее тип как абстрактный. Т.е. запрещающий создание экземпляров такого типа. По умолчанию считается равным false. many - булево значение указывающее что из данного разъема может выходить несколько соединений. По умолчанию считается равным false. must - булево значение указывающее что данный разъем обязательно должен быть соединен. По умолчанию считается равным false. base - базовый тип элемента. По умолчанию Pin. 5. link Тег link может содержать следующие атрибуты: type - тип соединения. Обязательный атрибут. abstract - булево значение, помечающее тип как абстрактный. Т.е. запрещающий создание экземпляров такого типа. По умолчанию считается равным false. in - тип входного разъема. Обязательный атрибут. out - тип выходного разъема. Обязательный атрибут. base - базовый тип элемента. По умолчанию Link. 6. item Тег item может содержать следующие атрибуты: type - тип устройства. Обязательный атрибут. abstract - булево значение, помечающее тип как абстрактный. Т.е. запрещающий создание экземпляров такого типа. По умолчанию считается равным false. public - булево значение, помечающее тип как доступный для внешних систем. Т.е. указывает, что компилятор должен создать специальные типы в пространстве имен @public для использования их в качестве параметров soap веб-сервиса. По умолчанию считается равным false. base - базовый тип элемента. По умолчанию Item. Тело тега item может содержать произвольное количество следующих тегов: pin - указывает тип разъема. Тег pin может содержать следующие атрибуты: type - тип разъема. Обязательный атрибут. name - уникальное для устройства имя разъема. Используется для связывания с графическим отображением устройства. . Если для разъема не указано имя, то его имя совпадает с его типом. many - булево значение указывающее что из данного разъема может выходить несколько соединений. По умолчанию берется значение атрибута из базового класса. must - булево значение указывающее что данный разъем обязательно должен быть соединен. По умолчанию берется значение атрибута из базового класса. repeat - строковое значение задающее диапазон номеров имен дубликатов разъемов вида 1..8. Вместо такого разъема создаются его копии с добавлением к имени индекса из дипазона. Внутренний для устройства разъем не может содержать дополнительных параметров. 7. event Тег event может содержать следующие атрибуты: type - тип события. Обязательный атрибут. abstract - булево значение, помечающее тип как абстрактный. Т.е. запрещающий создание экземпляров такого типа. По умолчанию считается равным false. base - базовый тип элемента. По умолчанию Event.

Замечания В процессе парсинга первая буква всех имен типов переводится в верхний регистр, а первая буква всех имен параметров и разъемов в нижний. Dynamic TypeDef Динамическое описание типа позволяет во время исполнения программы строить визуальные формы для редактирование некоторого набора параметров содержащихся в плоском json документе, который в свою очередь полностью содержится в одном обычном параметре. Т.е. для Dynamic TypeDef необходимо два параметра внутри одного типа. Например: <item type="TestItem">

   <param name="settings" type="json" typedef="typedef" />
   <param name="typedef" type="xml"/>

</item>

Тип TestItem содержит параметр settings типа json описание к которому содержится в параметре typedef типа xml. Dynamic TypeDef представляет собой подмножество основного языка TypeDef, в котором произвольный корневой элемент может содержать один или несколько тегов param со всеми описанными выше атрибутами, и таким образом описывает параметры плоского json документа. Например если параметр typedef содержит: <root>

   <param name="enabled" type="bool" />
   <param name="list" type="list" />
   <param name="timeout" type="int" unit="second">500</param>

</root> Тогда параметр settings будет содержать json документ вида: {

   enabled: false,
   list: null,
   timeout: 500

} Отметим что данную технологию не следует использовать для расширения типа объектов динамическими параметрами, т.к. само описание динамического типа хранится так же в параметре конкретного (а не любого) экземпляра типа. Поэтому Dynamic TypeDef следует использовать только для расширения конкретного экземпляра типа, как например внутри триггеров EGS.