Паттерн Pub/Sub для самых маленьких

Разбираем паттерн "на пальцах"

При обмене данными между разными информационными системами мы сталкиваемся с определенными трудностями:

Как отправить сообщение из одной информационной системы нескольким, не зная об их количестве.
Как нам отправлять сообщения, не дожидаясь ответа.
Как отправить одно и то же сообщение информационным системам, требующим на вход разные типы сообщений (xml, json и т.д.).

Паттерн Publisher/Subscriber, также известный как Observer, позволяет сделать возможным такое взаимодействие, добавляя прослойку между отправителем и получателем в виде сервера. Благодаря серверу мы можем подняться на один уровень абстракций выше обмена и добавить сущность для промежуточного хранения файлов, а также сущность для преобразования файлов.

Реализуем данный паттерн текстом.

Без шины (принцип вытягивания).

Жил-был магазин животных, в него приходили покупатели и покупали домашних животных. Но в один момент магазин стал слишком большим для просто закупок, и они стали продавать животных через биржу магазинам поменьше. Но они столкнулись с проблемой, некоторые магазины брали только кошек, некоторые только собак, некоторые только собак комнатного размера.

С простейшей шиной (толкай — тяни)

Тогда магазин (pub) нанял мужичка (server), которому они отдавали животных по мере появления. Мужичок бережливо распределял их по разным комнатам, кошек в одну, собак в другую. А магазины (sub) поменьше стали приходить только в нужные им комнаты и брать живность. Но покупателей становилось всё больше, и сами они становились всё специфичнее. Одни требовали сделать прическу собакам, другие научить их командам, а третьи расстраивались, когда, придя в комнату, не находили там животных, из-за того, что их уже кто-то забрал.

С полноценной шиной.

Тогда хитрый мужичок построил аппарат для клонирования, и каждому приходящему в комнату отдавал нужное животное (message), но с необходимым набором навыков (xml, json, char[]… whatever).

Домашнее задание.

Реализовать вариант «с простейшей шиной» на языке 1С. 1 pub, 2 subа. В качестве хранилища использовать каталоги системы. Обмен в формате xml, через стандартную сериализацию. Порядок обмена следующий:

1.1 Pub кладет в каталог pub файлик со строкой.

1.2 Шина его забирает.

1.3 Преобразует файл ( input: MessageNumber.xml, output: base1_ MessageNumber.xml, base2_ MessageNumber.xml).

1.4 Кладет полученные файлы в каталог sub.

1.5 Удаляет файл из каталога pub.

1.6 Откуда их забирают (слушая наличие файлов) subы, записывают значения в справочник. И удаляют файлик.

2. Усложним задачу: одна из баз будет принимать xml, а вторая json. Сведения о том, какая база какой тип принимает, должны храниться в шине в виде справочника.

Как проверяется задание:

В Publishere пишем строку, нажимаем “Разослать», проверяем наличие записи в базах-приемниках.

39 Comments

CheBurator 12.02.2016 at 16:28

ничего непонятно.

не понял, почему в домашнем задании нельзя

1.1 Pub кладет в каталог sub

???

Reply ↓
premierex 12.02.2016 at 16:51

(1) CheBurator, потому что шина в данном примере выступает координатором транспорта сообщений и является, по сути, независимой системой.

(0) Интересный пример.

Reply ↓
CheBurator 12.02.2016 at 16:58

(2) Ничего не понял*2

для чего необходио вводить промежуточную систему.

почему Pub не может сразу положить в Sub

Шина, являясь промежуточным звеном, является в свою очередь ОТПРАВИТЕЛЕМ.

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

Reply ↓
Armando 12.02.2016 at 20:05

Какой-то sap pi/xi

Reply ↓
FilatovRA 12.02.2016 at 21:35

(4) Armando, всё верно и IBM ESB и Microsoft Biztalk всё о том же 🙂

Reply ↓
FilatovRA 12.02.2016 at 21:44

(3) CheBurator, Система(Отправитель1) хранит в себе некоторые данные и реализует определенную (бизнес, технологическую) логику. Шина же в свою очередь(Отправитель2) имеет своей единственной целью доставить сообщение. Поэтому, если бы мы развивали наш пример до масштабов реальной ШПД, то у нас бы выросли резервные каналы, проверки контрольных сумм и даже дубль-системы основной шины, отправляющие данные в резервное хранилище на всякий случай. И это не считая правил преобразования форматов, контроля очередности сообщений и информирования администраторов о неполадках.

Reply ↓
CheBurator 12.02.2016 at 22:32

(6) Специализация системы понятна.

остался вопрос:

Шина, являясь промежуточным звеном, является в свою очередь ОТПРАВИТЕЛЕМ.

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

Reply ↓
minimajack 12.02.2016 at 23:59

(7) CheBurator, потому что шина обычно одна, а отправителей-получателей может быть много….

Reply ↓
CheBurator 13.02.2016 at 03:13

(8) ответ вообще ни о чем

Исходный отправитель на строне отправителя тоже один

Шина как отправитель — тоже одна

При этом исходному отправителю присущи некоторые проблемы

А шине- отправителю эти проблемы внезапно не присущи

Непонятно

ВОПРОС ОСТАЛСЯ

Reply ↓
CheBurator 13.02.2016 at 03:15

Попутный вопрос чайниколамера

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

Reply ↓
FilatovRA 13.02.2016 at 10:35

(3) CheBurator, перечитал пост, о какой именно проблеме присущей отправителю, описанной в тексте, идет речь?

Reply ↓
premierex 13.02.2016 at 10:48

(9) CheBurator, прочитайте вот эту статью, может быть что-то для себя проясните. ESB — довольно распространенный стандарт обмена данными между различными информационными системами.

А пример приведён «для самых маленьких», т. е. простейший пример использования шины для обмена сообщениями (что и указано в заголовке публикации).

Reply ↓
Armando 13.02.2016 at 11:08

(10) CheBurator, информационных систем может быть туева хуча и все они должны между собой обмениваться, при этом они все могут находиться в разных зонах безопасности. Каждая инф система поддерживает ограниченное количество технологий обмена данными, и имеет свои особенности работы с этими технологиями. Задача источника гарантированно передать на шину пакет данных в своем формате. Задача шины преобразовать входящие данные в формат понятный получателю и обеспечить гарантированную доставку. То есть источника не волнуют особенности целевого получателя, которых много. Это головная боль шины, которая одна и всё умеет. Если шины не будет, то на стороне источников придется учитывать особенности всех получателей и обеспечивать доступ к ним. Если тебе эти проблемы не знакомы, то шина не нужна.

Reply ↓
FilatovRA 13.02.2016 at 16:04

(10) CheBurator, шина в данной статье использована лишь для демонстрации паттерна, но если цглубиться в тему, то с помощью шины мы можем обеспечить асинхронность обмена, например: есть СверхсекретнаяСистемаКакого-тоНИИСверхзакрытаяИз-заСтарыхНачальников-маразматиковИТакПовелосьИНеСокращатьЖеПервыйОтделУМеняТамТещаРаботает, написана индусами на коболе и может отдавать важную цифру файликом только 1 числа каждого месяца и обязательно требует подтверждение доставки, иначе новый не даст. И есть вторая система НеМенееСекретногоНИИКотороеНаходитсяВЮрисдикцииТогоЖеВедомстваНоОтЭтогоКакОбычноНеЛегче, которая может принимать этот файлик только по средам при прлной луне, причем во вторник файлика быть не должно ни в коем случае, иначе система встанет. Вот тут на помощь и приходит шина 😊

Reply ↓
CheBurator 13.02.2016 at 16:46

(13) Спасибо за внятный ответ. По сути: проблем при обмене много. Это не значит в общем случае что эти проблемы нельзя решить на стороне отправителя. Но вопросы взаимодействия отправителя и получателя являются специфическими и их ПРОСТО УДОБНЕЕ ВЫДЕЛЯТЬ В ОТДЕЛЬНУЮ НЕЗАВИСИМУЮ СПЕЦИАЛИЗИРОВАННУЮ СИСТЕМУ(ШИНУ) ОБМЕНА.

Все. Вот так я понял те «сопли», которые были развешаны в публикации (спасибо комментам).

Reply ↓
CheBurator 13.02.2016 at 16:54

Но, получается, шину все равно не сделать достаточно независимой.

например, отправитель умеет отдавать в xml

получатель читает только csv

вопрос: на основании чего шина преобразует одно в другое? человек, работающий на шине — идет к отправителю, выспрашивает, идет к получателю, выспрашивает, думает, пишет коннектор-преобразователь. если это все в рамках одного предприятия/холдинга — концы еще можно склеить. Если отправители и получатели — разные конторы — превращается — даже на простых вещах — в приличную (_._) — так и живем (zркий пример — EDI)

Reply ↓
TODD22 13.02.2016 at 17:04

(16) CheBurator,

Но, получается, шину все равно не сделать достаточно независимой.

например, отправитель умеет отдавать в xml

получатель читает только csv

Шина это же не только преобразование. Это ещё разные функции отвечающие за доставку сообщений и тд. Например этот функционал у нас для всей системы одинаковый.

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

Reply ↓
premierex 13.02.2016 at 17:40

(16) CheBurator, Вы, очевидно, не видите разницу понятий: централизация и децентрализация. Шина позволяет централизировать данные, отправляемые и принимаемые разными информационными системами. Поэтому схема: pub-sub не является централизованной (читайте текст публикации), а схема pub-esb-sub как раз и будет схемой централизации. В общем, для каждого предприятия схема обмена сообщениями специфична. Где-то необходима централизация (как раз с использованием шины), а где-то — нет. Форматы сообщений не имеют ни какого значения. Главное — чтобы система, которая является координирующей в обмене (шина), могла их трансформировать в форматы сообщений принимающих систем.

Reply ↓
bayce 13.02.2016 at 21:51

А будет ли все это быстро работать на 1С?

Reply ↓
CheBurator 13.02.2016 at 22:47

(18) спсб за пояснения.

вопрос: какая система является более устойчивой — централизованная или децентрализованная?

Reply ↓
premierex 13.02.2016 at 23:54

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

Reply ↓
premierex 14.02.2016 at 00:07

(20) CheBurator, да, насчет устойчивости этих систем… В схеме pub-sub, конечно же, меньше «телодвижений», но она не настолько универсальна как другая. В общем: под каждое предприятие следует подбирать определённую схему обмена сообщениями.

Reply ↓
CheBurator 14.02.2016 at 01:36

(22) угу

Я тут как раз об этом подумываю, бо вопросы коннектов с другими системами начинают задалбывать

На портале даже почти нужное нашел — сборщика файлов с фтп, мыла и прочего

Полезная вещь Инфостарт

Reply ↓
premierex 14.02.2016 at 10:12

(23) CheBurator, не была бы полезной мы сюда и не заходили бы. Здесь многие делятся своим опытом. Кто-то платно, кто-то за «фишки», но портал, несомненно, ценен. Спасибо, Доржи!

Reply ↓
minimajack 15.02.2016 at 12:24
(9) CheBurator,
```
pub -> sub1
pub1 -> sub1
pub2 -> sub2
pub3 -> sub2
```
заменяется на
```
pub -> esb
pub1 -> esb
pub2 -> esb
pub3 -> esb

esb -> sub1
esb -> sub2
```
при этом получаем:
- гарантированную доставку(опционально)
- независимость от количества издателей и слушателей
- одно место контроля
- одно место резервирования
в частном случае проще решить проблему связи между отправителем(получателем) и шиной — чем между конкретными системами пораздельности.

на примере выше было 8 различных вариантов получения данных, после «внедрения шины» осталось 6

Reply ↓
CheBurator 15.02.2016 at 15:12

(25) спсб за пояснения

Reply ↓
premierex 17.02.2016 at 10:04

(26) CheBurator, в (18), мои пояснения были не совсем правильными, точнее, совсем неправильными (странно, что этого никто не заметил). Схема с шиной является, наоборот, схемой децентрализации, т.к. сама она данные не хранит, а всего лишь принимает и передает получателям. Схема централизации же собирает, хранит, обрабатывает и передает данные, полученные из одних иформационных систем другим. Решать, какая схема стабильнее, можно только исходя от специфики и архитектуры информационной системы в целом. Когда паблишер один и получателей немного, вполне подойдёт централизованная схема, а вот, когда паблицеров и получателей становится много — без децентрализации, мне кажется будет не просто обойтись.

Reply ↓
minimajack 17.02.2016 at 11:02

(27) premier, да выкиньте понятие «[де]централизация».

Шина она и в Африке шина. Она принимает и передает(опционально с хранением, транзакцией)!

в вашем понятии:

децентрализация:

отправитель -> шина -> получаетель

централизация:

отправитель -> мегасуперпупершина (хранит, обрабатывает, галстучки вяжет) -> получатель

по сути является:

отправитель -> шина -> обработчик данных -> шина -> получатель

То есть, шина остается все та же, но в каналы встраиваются обработчики которые инфу обрабатывает и возвращают обратно в шину. Грубо говоря, растягивается цепочка доставки. Опять же профит…например конвертация xml->json (html->pdf) универсальная, и достаточно встроить обработчик в шину чем на каждом отправителе(получателе) вызывать отдельно. Опять же одно место контроля за правильностью(работой) кода.

теперь про хранение.

Шина всегда хранит сообщение — ей же нужно как то его передать.

Если выключается свет что делать с сообщениями?

Все зависит от потребностей…если необходима гарантированная доставка — необходимо хранить данные( на диске, в бд и т.п.) в шине персистентно. Проще говоря в шине используется транзакции; между отправителем и шиной — для подтверждения поступления сообщения в шину, между шиной и получателем — для подтверждения доставки. Пока получатель не подтвердит получение — шина хранит сообщение. Пока шина не сказала что она сохранила данные в БД отправитель считает, что отправка не закончилась.

Когда же транзакционность не нужна? Например состояния каких либо датчиков, данных устаревающих которые не имеет смысл хранить дольше определенного срока. В общем все что не персистентно — работает без транзакций и реально быстрее и легче в интеграции.

Reply ↓
premierex 17.02.2016 at 14:46

(28) minimajack,

в вашем понятии:

децентрализация:

отправитель -> шина -> получаетель

централизация:

отправитель -> мегасуперпупершина (хранит, обрабатывает, галстучки вяжет) -> получатель

В моём понятии централизация -это когда шина всегда хранит принятые данные и сама же эти данные раздает, если требуется.

Во втором варианте шине требуется хранить данные только до момента подтверждения приема-доставки сообщения.

Вот, по-моему, и вся разница в этих понятиях.

Reply ↓
FilatovRA 18.02.2016 at 11:05

(28) minimajack, вот по поводу хранения в шине не могу с вами согласиться. В простейшей шине не хранится ничего. Пример схемы: шина мониторит каталог, при появлении файла копирует его в 2 других каталога. У шины лишь 2 интерфейса, откуда брать и куда ложить и одно состояние, получилось/не получилось.

Reply ↓
FilatovRA 18.02.2016 at 11:14

(29) premier, в моем понимании шина в обмене данными может быть только инструментом централизации, т.е. схемы, при которой при потере одного элемента теряется вся цепочка: многабаз ⤑ шина ⤑ многадругихбаз.

Reply ↓
FilatovRA 18.02.2016 at 11:16

(30) поправка, не ничего, а не хранятся сообщения.

Reply ↓
minimajack 18.02.2016 at 15:35

(32) а давайте наоборот!

Откуда шина знает про каталоги? Что значит интерфейс — это то что принадлежит шине или что то стороннее? Если шина потеряет доступ к каталогу — что сломалось, шина или внешняя система? Кто должен сообщить что проблемы, шина которая не может обратиться к каталогу или внешняя система?

И тут возникает вопрос: «Являются ли каталоги частью шины?».

Если нет, тогда почему шина о них знает?

Если да, то каталоги и являются местом хранения информации в шине.

Ответьте для себя на вопросы и тогда все станет ясно.

шина в обмене данными может быть только инструментом централизации

— тут с вами полностью согласен, шина именно что централизует поток сообщений.

Reply ↓
CheBurator 18.02.2016 at 19:23

(27) я обратил внимание на эту «фишку», но раз спец написал — значит написал ;-), хотя навскидку как-то не склеилось, а как понимать централизация/децентрализация — ну хз.. я подумал что шина есть централизация в том смысле что вместо кучи разрозненных обменов, встроенных в прикладные конфиги (что есть децентрализация) функционал выдран, и перенесен в одну конфигу, которая стандартизирована и формализирована (что есть централизация) — так что особо не заморачивался терминами… 😉

Reply ↓
FilatovRA 19.02.2016 at 09:27

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

Reply ↓
minimajack 19.02.2016 at 09:37

(35)

а у нас есть телепорт, которому достаточно сообщить откуда нужно взять груз, и где он должен появиться

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

хочу увидеть телепорт файлов из одного каталога в другой 😀

Reply ↓
premierex 21.02.2016 at 18:01

(34) CheBurator, посмотрите вот этот материал и это.

Скорее всего, поймёте в чём разница (Вы же специалист с большим опытом! 10 лет /а то и больше/ за плечами).

Reply ↓
CheBurator 22.02.2016 at 00:00

(37) ссылки не открываются

У инфостарта какаято глубинная проблема — ссылки в публикациях не любит

Reply ↓
Aleskey_K 10.03.2016 at 10:16

Да, шина вещь хорошая, при большом зоопарке информационных систем.

Вот ещё мощная разработка http://integration.axelot.ru/products/axelot-esb-servisnaya-shina-dannykh/

Reply ↓

Паттерн Pub/Sub для самых маленьких

Related Posts

39 Comments

Leave a Comment Отменить ответ