Описание структуры системы — различия между версиями
Wikiadmin (обсуждение | вклад) (→Запись архива) |
Wikiadmin (обсуждение | вклад) (→Подписки) |
||
| Строка 61: | Строка 61: | ||
Получение данных по архиву клиентом может осуществляться как с конечного узла так и с кеша (по умолчанию если включена запись архива на кеш то данные раздаются с кеша, для запроса напрямую с объекта необходимо в функции передать доп параметр) | Получение данных по архиву клиентом может осуществляться как с конечного узла так и с кеша (по умолчанию если включена запись архива на кеш то данные раздаются с кеша, для запроса напрямую с объекта необходимо в функции передать доп параметр) | ||
| − | ==Подписки== | + | ===Подписки=== |
Это механизм селекторных подписок который описывает логику запроса (получения) данных. | Это механизм селекторных подписок который описывает логику запроса (получения) данных. | ||
Версия 08:02, 10 октября 2017
Содержание
Архитектура сервера приложения
Состав компонентов системы
- БД (База Данных) системы интеграции (хранит данные по объектам — датчики, события, архив).
- БД планеты (ГИС, хренение данных о 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. Каждое сообщение транзакции проходит проверку на соответствие критериями селектора текущей очереди и в случае успеха добавляется в массив транзакции для текущей темы; 4. Когда транзакции для каждой темы сформированы производится отправка данных (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 ]
- 6
Обновлено Илья Травкин больше 1 года назад Пример работы с подписками на селекторах: 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 и далее данные.
