data destribution service omg standart

Технология Data Destribution Service 2.0 OMG standard – создание распределённых информационных систем реального времени

Вопросы

• Общие положения– Стандарты – Общие особенности–Области применения• Архитектура –Основные подходы–Особенности архитектуры (Data Centric Pub/Sub)–Базовые понятия: топик, тип данных

ОБЩИЕ ПОЛОЖЕНИЯ

• Стандарты• Общие особенности• Области применения

Источники и составные части

• The Data Distribution Service for Real-Time Systems (DDS) – стандарт OMG для middleware

• Доступные стандарты: –Data Distribution Service for Real-time Systems (DDS). 2007 Version 1.2 –The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDSI). Version 2.1 –DDS for Lightweight CCM –DDS-Java: Java 5 Language PSM for DDS

• PSM – Platform specific mapping –DDS-PSM-Cxx: ISO/IEC C++ 2003 Language DDS PSM, включает

• API • QoS –Extensible and Dynamic Topic Types for DDS (DDS-XTypes) –UML Profile for Data Distribution

Особенности• Декларируемые

–Масштабируемость –Работа в реальном масштабе времени–Надежность

–Высокая производительность• Существенные и практически значимые– Интероперабельность

• На уровне разных платформ (ОС + «железо»)• Разные языки программирования• Единый транспортный протокол у разных производителей DDS

–Поддержка парадигмы «подписка-публикация»

Области применения• Приложения Big data: –financial trading –Управление воздушным движением –smart grid management • Приложения на мобильных устройствах –Военные приложения • Приложения на встроенных устройствах: • –Транспортные системы и транспорт • –Медицина • DDS предполагается использовать как базовую технологию

для реализации IoT и IIoT

Военные приложения

Мирные приложения

АРХИТЕКТУРА

• Основные подходы• Особенности архитектуры ( Data-Centric

Pub/Sub)• Базовые понятия: топик, тип данных, QoS

Основные подходы

• Поддержка парадигмы «pub/sub»• Концепция «Глобальное пространство

данных» - циркулирующие данные хранятся в Общем информационном пространстве

• Дублирование источников данных

Особенности архитектуры

• Размещение компонентов– Автоматическое обнаружение обеспечивает независимость от топологии сети• Избыточность–Можно ввести дублирующих поставщиков и потребителей данных с указанием приоритетов и «передачей эстафеты»• Время–Прием данных не обязательно синхронен с передачей. Есть возможность получения данных, относящихся ко времени, когда подписчик еще даже не был включен в сеть•Платформа–Представление данных автоматически платформо-независимо («железо», ОС, язык программирования)•Реализация–Сетевой протокол является стандартом

Модели обмена данными в распределённых системах

• Point-to-point - каждый компонент «знает» кому нужны его данные и отправляет (или адресует их непосредственно)

• Client-server – клиент обращается к серверу за нужными ему данными

• Publish-subscribe - компонент, публикующий данные, сообщает об этом middleware (публикует данные), затем отправляет их в middleware не заботясь о наличии и расположении компонентов-подписчиков, нуждающихся в данных; - компонент-подписчик, нуждающийся в данных, сообщает об этом middleware (подписывается на данные). При наличии публикатора данные данного типа начинают поступать подписчику

Message-centric architecture • Используется модель Publish-subscribe • Middleware

–Позволяет обмениваться сообщениями –Передает данные как наборы байт, не заботясь о содержимом –Не хранит состояние системы и/или данные

• Контроль синтаксической и семантической целостности сообщений возлагается на разработчика приложения

• Наиболее известные реализации подхода: –JMS API –AMPQ –HLA RTI

Data-centric architecture • Используется модель Publish-subscribe • Middleware

–Позволяет обмениваться сообщениями –Хранит состояние системы и данные –Передаваемые данные проверяются на синтаксическую [и семантическую?] целостность

• Разработчики создают ПО, которое читает и обновляет данные в глобальном виртуальном пространстве

• Наиболее известные реализации подхода: –DDS API –Протокол RTPS (DDSI)

«Эволюция middleware»

Message-Centric Pub/Sub против Data-Centric Pub/Sub

MCPS сравнение с DCPS

• MCPS •Middleware не «понимает» ваши данные •Разработчику приходится реализовывать проверку синтаксической правильности и формировать/разбирать сообщения •Можно выиграть на времени передачи

• DCPS •Middleware «понимает» ваши данные•Разработчик «экономит» на проверке синтаксической правильности и формировании/разборе сообщений •Постоянный контроль в отлаженных приложениях избыточен и поглощает ресурсы

Основные понятия

Типы данных

• Тип данных, на который ссылается топик DDS, описывается структурой IDL, содержащей произвольное число полей. Типами данных поля могут быть: –Примитивные типы IDL. Например: octet, short, long, float, string (bound/unbound), и т.д. –Перечислимый тип (enumeration) –Объединение (union) –Последовательность (sequence – bounded or unbounded) –Массив –Структура (вложенная)

Типы данных

Типы данных: ключи

• Каждый тип данных (для топика DDS) дополнительно описывается ключом (key-set) – набором полей

• На количество полей, входящих в ключ, ограничений не накладывается ( например, набор полей может быть пуст)

• В ключ могут входить атрибуты верхнего уровня и атрибуты из вложенных структур


• Ключи используются для идентификации «экземпляров»

• Если провести параллель с ООП, то: –Типы данных без ключа – синглетоны (экземпляр строго единственный) –Типы данных с ключом аналогичны «обычным» классам с экземплярами, идентифицируемыми значением ключевых полей –Можно считать, что новое значение ключа порождает новый «объект» в распределённой системе DDS

Имена топиков и регистрация

• Регистрация топика идемпотентна (sic!), т.е. может быть выполнена повторная регистрация топика и это не приведёт к ошибке в приложении( приложениях).

• Попытка зарегистрировать топик, отличающийся только типом приведет к ошибке

Имена топиков и регистрация

РАЗГРАНИЧЕНИЕ ДАННЫХ

• Домены• Области

Домены и области

• Домен – под доменом понимается экземпляр глобального пространства данных (DDS Global Data Space). Приложения DDS (и более низкие элементы) всегда относятся только к одному домену

• Область (partition) - это механизм, позволяющий выделять подмножества взаимодействующих компонентов DDS (в том числе приложений)

• Приложения DDS (и более низкие элементы) могут относиться сразу к нескольким доменам

Домены и области

Области

• Каждая область идентифицируется строкой. Например, «sensor-data», «log-data» и т.д.

• Доступ к области по чтению/записи обеспечивается через компоненты DDS Publisher/Subscribers

• Каждому такому компоненту (Publisher или Subscriber) можно передать список имен областей. Каждое имя может включать групповые символы (wildcards) или регулярное выражение, например «*-data»

Области

• Хотя иерархичность областей не поддерживается в DDS напрямую, её легко организовать при разработке РИС, используя «точечную» нотацию

• Например, для здания, в котором размещаются датчики температуры, можно использовать нотацию «здание.этаж.номер-комнаты»–building.floor-2.room-10–building.floor-3.room-15

• Тогда, для получения данных по этажу используется маска названия области «building.floor-2.*», а для всего здания маска «building.*»

Области

ПОЛУЧЕНИЕ И ОТПРАВКА ДАННЫХ

• Отправка данных• Чтение данных

Отправка данных

• Отправка данных производится в два шага:–Создается компонент DataWriter с помощью нужного конструктора (выбор завит от требующейся функциональности – отличной от стандартной)–Потом данные передаются в произвольный момент с использованием этого компонента

Отправка данныхtemplate <typename T> class dds::pub::DataWriter : public dds::core:: Entity{ public: DataWriter(); DataWriter(Topic<T> topic) DataWriter(Topic<T> topic, const DataWriterQos& qos) DataWriter(Topic<T> topic, const DataWriterQos& qos, Publisher pub); // ... };

Получение данных

• Операция чтения (read) «проходит» по всем доступным семплам (sample) экземпляра

• Семплы не удаляются из локального кеша DDS в результате операции чтения (read)

• Прочтенные могут быть прочтены из локального кеша DDS снова при указании специальных параметров операции чтения

Получение данных

Состояния при чтении• Кроме содержащих непосредственно данные семплов DataReaders

предоставляют информацию о состоянии переданных данных и источниках данных (DataWriters)

• Состояние семпла:{READ|NOT_READ}. Определяет, был ли данный семпл уже хотя бы раз прочитан (read)

• Состояние экземпляра: {ALIVE | NOT_ALIVE| DISPOSED}. Определяет:–Существует ли хоть один писатель для данного конкретного экземпляра ?–Нет ни одного писателя для экземпляра–Экземпляр был сброшен (disposed)• Состояние view: {NEW | NOT_NEW}. Определяет, первый ли это

семпл для нового (или повторно появившегося – re-born) экземпляра

Состояния при чтении

Получение данных от DDS Доступны три способа взаимодействия (обмена данными между) DDS и приложением:–Опрос (polling) – приложение (по своей инициативе, обычно, периодически) запрашивает DDS для получения новых данных или информирования о смене состояния. Интервал опроса может зависеть от приложения и/или от данных и их значений–Списки ожидания (WaitSets) – приложение регистрирует в DDS списки ожидания и ждет (например, в режиме suspended) до тех пор, пока одно из переданных событий не произойдет –«Слушатели» (listeners) – приложение регистрирует в DDS (в классах, где события могут произойти) специальные классы-слушатели, которые будут информированы при наступлении этих событий

Получение данных от DDS

Обработка полученных данных

• Основанная на жизненном цикле (lifecycle):–Чтение данных только по «живым» экземплярам –Чтение данных только по новым экземплярам –Чтение только не прочитанных ранее семплов • SQL фильтрация:• –Фильтрация ?по ?значениям ?атрибутов ?• –Агрегация ?экземпляров ?по ?ключу ?• –Условия ?могут ?быть ?изменены ?во ?время ?

работы ?

Обработка полученных данных

QoS (КАЧЕСТВО ОБСЛУЖИВАНИЯ)

• Типы QoS в DDS• Особенности обеспечения

Внутренние события

Возможные типы QoS

Гарантированность доставки

• QoS гарантированности доставки (RELIABILITY QoS) задает «уровень гарантированности» доставки данных от публикатора подписчикам. Возможны два уровня:–Reliable – в установившемся режиме middleware гарантирует, что все семплы из истории DataWriter будут в конечном итоге доставлены всем DataReader–Best Effort – означает, что допустимо не повторять неудачную пересылку семплов

Reliability QoS

Хранение истории

• Хранение истории (history QoS) назначает количество семплов экземпляра, которые хранятся в middleware для DataReader. Возможные значения:–Хранить последние K – в этом случае хранятся последние К семплов. По умолчанию K = 1 –Хранить все – в этом случае сохраняются все семплы, отправленные DataWriter, до тех пор, пока:

•Они не «взяты» (taken) или •Не достигнуто ограничение на использование ресурсов

Состояние

• Объекты в РИС могут быть: –С внутренним состоянием (stateful)

•Атрибуты в определении интерфейса – достаточное, но не необходимое условие •Внутренние переменные экземпляра

–Без внутреннего состояния (stateless) • Варианты хранения:

–Долговечными (persistent) – продолжающие существовать и после завершения процесса –Временными (transient)

Состояние: примеры

• Служба именования –Stateful –Persistent

• Положение моделируемого самолета –Stateful –Persistent (?)

• Команда –Stateless –Transient

Долговременное хранение

• Долговременное хранение – способность объекта переживать процесс, в котором он находится

–Состояние должно запоминаться на промежуток деактивации и активации • В качестве хранилища может использоваться:

– Файловая система – СУБД ( любого вида: реляционная, объектная)–Постоянная оперативная память

Долговременное хранение• За долговременное хранение в РИС может отвечать:– middleware– Каждое приложение самостоятельно– Выделенное приложение• Например, в ?HLA за реализацию долговременного

хранения отвечает:– Состояние middleware и выполняющейся распределенной модели в целом: сам HLA RTI–Состояние внутренних переменных моделей сохраняются самими приложениями


Пример долговременного хранения в CORBA


• Хранилище данных (datastorage) – общая область хранения всех данных – например: БД

• Область хранения (storage home) – отдельный контейнер с долговременные представлениями хранимых объектов – например: таблица

• Объект хранения (storage object) – представление одного хранимого объекта – например: запись в таблице РБД

• Тип хранения (storage type) – определяет интерфейс объекта хранения

Долговременное хранение• Воплощение объекта хранения (storage object

incarnation) – представление объекта хранения в памяти средствами языка программирования

• Воплощение области хранения (storage home incarnation) – представление экземпляра области хранения на языке программирования

• Ключ – атрибут, однозначно идентифицирующий объект хранения в пределах области хранения

• Сессия – логическая связь между хранилищем данных и процессом, в котором выполняется объект-сервер

DDS: Durability QoS

• В DDS имеется QoS описывающий варианты хранения истории изменений: –Volatile (непостоянный) – История не хранится–Transient_local – История хранится локально в памяти отправителя–Transient – История хранится в сервисе TRANSIENT (в оперативной памяти)–Persistent – История хранится в постоянной памяти

DDS: Durability QoS

Вопросы

• «Более хитрые» QoS в DDS:– Состояние компонентов (liveliness)– Состояние экземпляров (deadline)– Максимальное время доставки (latency budget)– Приоритет (priority)– Владение (ownership, ownership strength)– Фильтрация по времени (Time-based filtering)–Фильтрация по значению (Content-Based filtering)

•«Лучшие практики»

Состояние компонентов DDS

• QoS отслеживания состояния компонентов системы (Liveliness QoS) позволяет отслеживать существование, статус и активность компонентов DDS (для Participant, Reader, Writer)

• Упрощенно можно сказать, что отвечает на вопрос «является ли отсутствие новостей хорошей новостью?»

• Для определения состояния используются специальные Liveliness Packets (аналог heartbeats)


• Возможные уровни использования, определяют, кто отвечает за генерацию пакетов – AUTOMATIC – пакеты генерируются инфраструктурой автоматически– MANUAL_BY_PARTICIPANT –MANUAL_BY_TOPIC – Генерация пакетов переложена на приложения


• QoS используется совместно с исключительным владением экземплярами: –Writer считается владельцем только если он «жив» –Как только DDS обнаруживает факт пропуска прихода сообщений liveliness, она «отбирает» у писателя все его экземпляры и назначает владельцем следующего (с учетом их приоритетности)


• Не следует использовать термин deadline, чтобы не спутать с QoS Deadline

• Периоды посылки сообщений liveliness конфигурируемы

• При использовании уровня MANUAL_* приложение должно посылать сообщения liveliness:–В явном виде с помощью вызова метода assert_liveliness–В неявном виде с помощью посылки семпла

Состояние компонентов DDS (liveliness)

• MANUAL_BY_PARTICIPANT определяет состояние на уровне DomainParticipant

• MANUAL_BY_TOPIC определяет состояние на уровне DataWriter

• Соглашение о настройках QoS происходит с учетом предлагаемых:–Уровня (можно сдвинуть выше):– AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC –Времени задержки (можно сделать меньше):– Предложенное время < установленного времени

Состояние экземпляров

• QoS отслеживания состояния экземпляров (Deadline QoS) позволяет отслеживать статус и активность экземпляров

• Если данные по экземпляру не обновляются как установлено, то приложение получает сигнал об этом

Состояние экземпляров

Время на доставку

• Максимальное время доставки (Latency_budget) определяет максимально допустимое время задержки данных между их отправкой (операция write) и получением (записью в очередь чтения подписчика)

• Значение по умолчанию – нулевое, что означает, что время доставки должно быть минимизировано

• Данная QoS является «подсказкой» для DDS. Время доставки не мониторится и не может быть явно установлено

Время на доставку

Приоритет

• Приоритет (Transport_priority) является подсказкой транспорту, устанавливающей «преимущества» в доставке семплов того или иного топика

Владение

• Владение (Ownership) устанавливается на уровне экземпляра ( или топика, если для типа данных не установлен ключ). Возможно установить следующие варианты владения:–SHARED: Совместное владение, когда любой участник, опубликовавший топик, может обновлять экземпляр. По действию такой режим эквивалентен отключению использования данной QoS–EXCLUSIVE: Исключительное владение, когда только один источник (writer) может обновлять данные по экземпляру

Владение: Shared

Владение: Exclusive

Владение• Приоритет владения (Ownership Strength) устанавливается

для источника (writer) и применяется к его экземплярам (или топикам, если для типа данных не установлен ключ)

• Только один источник (writer), имеющий максимальный приоритет, может обновлять данные по экземпляру

• Владение автоматически передается:• –При появлении более приоритетного источника,• –Или следующему по приоритету, если:

Источник «умер» (согласно QoS liveliness) Пропустил отправку данных (согласно QoS Deadline) Перестал публиковать топик или экземпляр

Владение: Приоритет

Фильтрация по времени

• Фильтрация по времени (Time_based_filter) позволяет подписчикам указывать, что они не желают получать данные слишком часто. Это позволяет сократить количество получаемых семплов и сэкономить время на их обработку

• DataReader указывает, что: –Ему не обязательно получать все семплы –Однако он хочет получать не меньше одного семпла в каждый период (minimum_separation)

Фильтрация по времени

Фильтрация по значению

• Фильтрация по значению (Content-based filtering) позволяет подписчикам указывать, семплы с какими значениями полей они хотят получать. Это позволяет: –Исключить из видимости некоторые экземпляры ?–Сократить количество получаемых семплов и сэкономить время на их обработку –Получать только «особенные» семплы (индикация событий)

Фильтрация по значению


• Хранение истории (history QoS) назначает количество семплов экземпляра, которые хранятся в middleware для DataReader. Возможные значения: –Хранить последние K – в этом случае хранятся последние K семплов. По умолчанию K = 1 –Хранить все – в этом случае сохраняются все семплы, отправленные DataWriter, до тех пор, пока: •Они не «взяты» (taken) или •Не достигнуто ограничение на использование ресурсов

DDS: Durability QoS

• В DDS имеется QoS описывающий варианты хранения истории изменений:

–Volatile (непостоянный, изменчивый) - История не хранится –Transient_local - История хранится локально в памяти отправителя –Transient – История хранится в сервисе TRANSIENT (в оперативной памяти) –Persistent – История хранится в постоянной памяти

DDS: Durability QoS

Лучшие практики

• Начните с описания модели данных, затем отразите её на домены DDS, типы данных и топики

• Полностью и явно опишите типы данных: не используйте произвольные инкапсуляции

• Распределите подсистемы по доменам DDS • Используйте типы данных с ключами

Лучшие практики

• Опишите используемые QoS и их настройки. Лучше не использовать изменения настроек QoS в процессе функционирования, в больших системах (группах разработчиков) должны использоваться настройки QoS по умолчанию

data destribution service omg standart

Technology