[prog.c++] Любопытное про DDS и RxCpp

Посмотрел слайды презентации Reactive Stream Processing Rx4DDS с конференции CppCon 2015. Любопытно.

[prog] Свежая презентация "The Data Distribution Service Tutorial"

На SlideShare появилась свежая интересная презентация "The Data Distribution Service Tutorial":

Нужно сказать, что наличие такой штуки, как DDS -- это одна из причин, из-за которых в SO-5 сейчас нет штатного средства для создания распределенных приложений. ИМХО, гораздо перспективнее использовать для коммуникации уже существующие инструменты, вроде DDS, чем городить что-то свое.

Так же DDS -- это тема, к которой очень хочется пристегнуть SObjectizer. Только вот непонятно, в каком именно виде. Либо сделать на базе SObjectizer еще одну реализацию DDS (а ведь их немного). Либо же просто показать, как с помощью SObjectizer работать с DDS. Либо еще как-то (например, шлюз из DDS в какой-то другой протокол). В общем мне кажется интересным и перспективным это направление. Только вот ресурсов на это нужно прилично.

PS. Вот здесь можно найти подборку других материалов по DDS.

[prog.thoughts] Про использование модели publish/subscribe

В последнее время знакомился с разными инструментами, поддерживающими модель publish/subscribe (в первую очередь речь идет о MQTT и DDS). Подумалось, что в каких-то вещах начинает наблюдаться принцип "если у тебя в руках молоток, то все вокруг выглядит как гвозди". Т.е. модель pub/sub начинают использовать не совсем так, как это нужно.

Где-то pub/sub выглядит вполне естественно. Допустим, есть какой-то датчик температуры воздуха, который раз в 10 минут отсылает в сеть свое текущее значение. Тогда создается тема с именем, например, building-1/floor-2/temp-sensor-3, в которую датчик отсылает свои замеры. Тот, кто хочет читать значения именно этого датчика, тот подписывается именно на эту тему. Тот, кто хочет читать значения всех датчиков температуры с этого этажа, подписывается на несколько тем сразу, скажем, вот так: building-1/floor-2/temp-sensor-#. И таких подписчиков может быть несколько: один собирает информацию для управления климатом (например, когда температура выходит за заданные пределы, включается система кондиционирования), второй архивирует эту информацию для дальнейшей обработки (например, демонстрации графиков-трендов).

Совсем другое дело, когда pub/sub пытаются задействовать для организации взаимодействия друг с другом нескольких компонентов по принципу "запрос-ответ". Предположим, что есть состоящий из нескольких компонентов SMTP-сервер. Компонент-читатель получает очередной email и перед дальнейшей отправкой полученного письма хочет проверить, а не спам ли это. Для этого нужно сделать запрос к компоненту-анализатору-спама. Каким образом? Просто опубликовав запрос в теме spam-checking/request. Анализатор подписан на эту тему и, поэтому, рано или поздно получит этот запрос. Выполнив проверку компонент-анализатор опубликует ответ в теме spam-checking/response.

В принципе, мне уже здесь начинает казаться, что что-то идет не так. Подозрения усиливаются, если предположить, что для увеличения пропускной способности в нашем SMTP-сервере есть несколько компонентов-читателей, каждый из которых принимает email-ы и нуждается в их проверке. Вопрос в том, каким образом компонентам-читателям определяет, кому из них предназначался ответ в spam-checking/response?

Тут напрашивается сразу несколько решений:

• при публикации сообщения в теме spam-checking/response можно снабдить это сообщение каким-то мета-атрибутом, позволяющим однозначно определить получателя. По этому мета-атрибуту каждый из компонентов-читателей настраивает фильтры для темы spam-checking/response и, благодаря фильтрам, получает только свой трафик. Этот подход требует, чтобы pub/sub-система поддерживала мета-атрибуты (а разработчики знали про этот механизм и могли его использовать);
• для ответов создается не одна тема, а несколько, по одной на каждый компонент-читатель. Например, spam-checking/response-1, spam-checking/response-2 и т.д. Отсылая запрос компонент-читатель сообщает свой номер и ответ публикуется в той теме, которая создана персонально для этого читателя;
• каждый компонент-читатель создает свою собственную тему, например, receiver-1/spam-checking-result, receiver-2/spam-checking-result и т.д. Компонент-анализатор должен публиковать свои ответы в соответствующей теме.

По сути, все эти способы -- это все одни и те же яйца, только в профиль. Причем все способы требуют передачи вместе с запросом какого-то эквивалента обратного адреса. Т.е. все это, на самом-то деле, реализация peer-to-peer взаимодействия, только посредством того инструмента, который есть в наличии (отсюда и ощущение про молоток и гвозди).

Думаю так же, что если мы отходим от pub/sub в сторону простых очередей сообщений, то результат, на мой взгляд, получается более логичным. Т.е., если мы строим SMTP-сервер из компонентов на основе message queues, то у каждого компонента появляется своя очередь входящих сообщений. Например, receiver-1-queue, receiver-2-queue, spam-analyzer-queue и т.д. Нужно отправить запрос на анализ очередного письма? Просто пишем его в spam-analyzer-queue, а в качестве обратного адреса указываем имя очереди, в которую нужно отослать ответ (например, receiver-2-queue).

Однако, если у нас появляется такое peer-to-peer взаимодействие, то манипуляции с очередями начинают казаться чем-то низкоуровневым. Ну действительно, зачем нам знать про какие-то очереди? Нам нужно знать идентификатор/адрес получателя. А уже способ доставки сообщения до него -- пусть определяет промежуточный слой.

Т.е. приходим к чему-то вроде "шины данных" (пишу "вроде", т.к. термин этот может быть слишком перегружен): есть какая-то магистраль, по которой туда-сюда снуют сообщения. Компоненты подключаются к этой магистрали, для чего им нужны уникальные идентификаторы или адреса. После чего общение компонентов друг с другом осуществляется путем отсылки сообщения на адрес получателя. Все остальное определяется реализацией самой шины: будут ли это очереди на стороне отправителя или же получателя, или же это будет какое-то централизованное хранилище на главном брокере (или совокупность таких хранилищ), и т.д, и т.п.

Имхо, такая модель peer-to-peer взаимодействия компонентов через шину данных хорошо подходит для многостадийной обработки информации. Например, в сложных Web-приложениях, при обработке SMTP- или SMPP-трафика, при обслуживании платежных транзакций и т.д. Гораздо лучше, чем использование publish/subscribe моделей и инструментов. Хотя, у меня сложилось впечатление, что вендоры DDS-решений так не думают :)

PS. В принципе, для peer-to-peer взаимодействия можно использовать и простой синхронный RPC. Но это, на мой взгляд, и масштабируется хуже, и, со временем, могут всплыть вопросы с версионностью данных (расширять сообщения, как показывает практика, проще, чем синхронные интерфейсы, базирующиеся на чем-то вроде CORBA).

PPS. А еще мне кажется, что для задач, с которыми приходилось сталкиваться, нужно иметь промежуточное ПО, которое поддерживает сразу два способа взаимодействия -- и peer-to-peer через шину данных, и publish/subscribe. А местами и data-flow :)

[prog.flame] Слайд для любителей использовать XML/JSON/YAML

Найден в презентации OMG DDS Tutorial Part II:

Т.е. по сравнению с бинарным представлением CDR (используемым в CORBA) текстовые форматы могут давать увеличение объема до 10 раз и снижение производительности до 20 раз.

Данные, которые отображены на этом слайде, взяты из этой презентации, в которой описываются результаты экспериментов с несколькими форматами данных. Эксперименты эти проводились из-за необходимости поддерживать версионность данных (т.е. когда в последующих версиях структура данных может изменяться, как правило, расширяться новыми полями).

Как я понимаю, CORBA и DDS не поддерживают версионности, поэтому решили попробовать что-то еще. Только вот не понятно, почему не попробовали хотя бы ASN.1 с его extension point-ами. К сожалению, я не помню, был ли Google Protobuf в 2008-м, но мы у себя в 2008-м уже года четыре как использовали собственную ObjESSty, которая, как и ASN.1 BER/PER, сериализовала данные в двоичное представление, да еще и поддерживала версионность данных. Т.е. в очередной раз убеждаюсь, что многие вещи мы на интуитивном уровне делали правильно, но вот выбраться из своего маленького гаражика со своими идеями не смогли :) Кстати говоря, в библиотеке MBAPI, которая добавляет возможность строить распределенные приложения на основе SObjectizer-а, для сериализации используется именно ObjESSty, так что в MBAPI нет проблем с расширением сообщений новыми полями, в отличии от DDS...

PS. Еще одна заметка на счет эффективности XML из моего блога.

[prog] Пара ссылок на PDF-ки на тему DDS

Заглянул краем глаза в такую большую область как DDS (Data Distribution Service for Real-Time Systems). В процессе поиска чего-нибудь полезного нашел два небольших документа, которые позволяют понять, что это такое не закапываясь в огромные толмуды спецификаций:

Messaging Technologies for the Industrial Internet and the Internet of Things Whitepaper (A Comparison Between DDS, AMQP, MQTT, JMS, REST and CoAP). Не очень большой документ, который делает краткий обзор нескольких протоколов/технологий и очерчивает области их применения. Смотреть нужно с некоторой долей скепсиса, т.к. в нем явно чувствуется маркетинговая цель доказать, что DDS круче всех.

The Data Distribution Service Tutorial (ссылка на SlideShare, но оттуда можно скачать и сам PDF-документ). Небольшое введение в использование DDS (примеры на C++, но для Java разработчиков вряд ли будут сложности).

Еще одна похожая презентация от того же автора, но уже от 2015-ого года: The Data Distribution Service Tutorial.

Еще два больших PDF-а с толковыми презентациями (от 2009-го года, но все равно крайне полезными): OMG DDS Tutorial Part I (на 162 слайда) и OMG DDS Tutorial Part II (на 94 слайда).

Очень толковая презентация о применимости и полезности DDS в реальном мире: Why is DDS the Right Technology for the Industrial Internet?

Хорошая презентация о DDS и его применимости вообще, а так же конкретно об OpenSplice: DDS in SCADA, Utilities, Smart Grid and Smart Cities (носит в большей степени технических характер). Плюс еще одна очень большая презентация об OpenSplice на 200 слайдов, по сути, "все-в-одном": и рассказ о DDS и различных его аспектах, и некоторые детали реализации OpenSplice, и пример использования OpenSplice в контроле за авиационным трафиком (последние 10 слайдов): Introducing the OMG DDS to the Aerospace Valley (второе название "OMG DDS: The Data Distribution Service for Real-Time Systems).

Так же могу отметить презентации на SlideShare от Angelo Corsaro, ну и разделы Tutorials и Presentations на официальном портале DDS.

Не совсем про DDS, но зато про M2M (machine-2-machine) и IoT (internet-of-things), т.е. про области, в которых DDS находит широкое применение:

• Smart City: Many Applications and Devices -- интересная презентация о том, какой спектр инструментов может предложить клиенту компания Eurotech и как эти инструменты используются в решении реальных проблем клиента. Вообще на SlideShare канал этой компании является источником интересных материалов на тему M2M и IoT: SlideShare Eurochannel;
• Internet Of Things Basics -- интересная презентация на тему IoT и M2M, которая затрагивает очень широкий спектр вопросов -- от бизнес-проблем до особенностей использования разных версий Java на мелких устройствах;
• Internet of Things -- where OMG's DDS stands -- совсем короткая презентация, коротко рассказывающая об IoT и показывающая роль и место стандарта DDS внутри IoT. Так же на последнем слайде есть список ссылок, которые могут быть полезны интересующимся этой темой;
• Real-World Applications of OMG Technology in Medicine -- довольно большая презентация, рассказывающая о том, как DDS может применяться в медицине (носит явно маркетинговый характер, т.к. подготовлена вендором DDS-платформы, но представление об одной из областей применения дает).

Для меня, как C++ника, интересной оказалась презентация Standardizing the Data Distribution Service (DDS) API for Modern C++.

PS. Насколько я понял, в области DDS сейчас всего три живых и развивающихся продукта: Connext DDS от RTI, OpenSlice от Prismtech и OpenDDS от Object Computing (OpenDDS полностью OpenSource, построен на основе ACE и TAO теми же людьми). Upd. Есть еще вполне себе живая CoreDX DDS от Twin Oaks Computing.

[prog] Вот уж где не ожидал увидеть UML...

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

Вот уж, действительно, о сколько нам открытий чудных... :)

PS. Это фрагмент спецификации протокола RTPS.

[prog] Две интересные обзорные статьи на тему протоколов для Internet of Things

Статьи на английском, но читаются легко. Полагаю, что довольно поверхностные и, возможно, местами спорные. Но в качестве отправной точки для дальнейшего погружения в дебри вполне приличные. Их автор -- основатель компании RTI, которая является поставщиком одной из реализаций стандарта DDS, так что человек может не знать каких-то технических деталей, но представление о том, о чем говорит имеет хорошее.

Understanding The Protocols Behind The Internet Of Things. Очень кратко по поводу MQTT, XMPP, DDS и AMQP.

What’s The Difference Between DDS And AMQP? Более подробно на тему того, что такое DDS и что такое AMQP, назначение, различия между ними и, как следствие, предпочтительные области применения.

PS. К теме DDS я пока только слегка прикоснулся. Но, после того маразма, который в "корпоративных приложениях" выстраивают вокруг HTTP, все это воспринимается как глоток свежего воздуха :)