gifts2017

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

Опубликовал Рома Филатов (FilatovRA) в раздел Обмен - Обмен с другими системами

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

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

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

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

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

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

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

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

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

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

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

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

  1. Реализовать вариант «с простейшей шиной» на языке 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 пишем строку, нажимаем “Разослать», проверяем наличие записи в базах-приемниках.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей (Che) Коцюра (CheBurator) 12.02.16 16:28
ничего непонятно.
не понял, почему в домашнем задании нельзя

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

???
2. Максим *** (premier) 12.02.16 16:51
(1) CheBurator, потому что шина в данном примере выступает координатором транспорта сообщений и является, по сути, независимой системой.
(0) Интересный пример.
3. Сергей (Che) Коцюра (CheBurator) 12.02.16 16:58
(2) Ничего не понял*2
для чего необходио вводить промежуточную систему.
почему Pub не может сразу положить в Sub

Шина, являясь промежуточным звеном, является в свою очередь ОТПРАВИТЕЛЕМ.
Почему исходному отправителю присущи недостатки/проблемы (описано в постановке задачи в сабже), а шине - которая тоже отправитель - внезапно такие недостатки/проблемы не присущи?

4. Armando Armando (Armando) 12.02.16 20:05
5. Рома Филатов (FilatovRA) 12.02.16 21:35
(4) Armando, всё верно и IBM ESB и Microsoft Biztalk всё о том же :)
6. Рома Филатов (FilatovRA) 12.02.16 21:44
(3) CheBurator, Система(Отправитель1) хранит в себе некоторые данные и реализует определенную (бизнес, технологическую) логику. Шина же в свою очередь(Отправитель2) имеет своей единственной целью доставить сообщение. Поэтому, если бы мы развивали наш пример до масштабов реальной ШПД, то у нас бы выросли резервные каналы, проверки контрольных сумм и даже дубль-системы основной шины, отправляющие данные в резервное хранилище на всякий случай. И это не считая правил преобразования форматов, контроля очередности сообщений и информирования администраторов о неполадках.
7. Сергей (Che) Коцюра (CheBurator) 12.02.16 22:32
(6) Специализация системы понятна.
остался вопрос:
Шина, являясь промежуточным звеном, является в свою очередь ОТПРАВИТЕЛЕМ.
Почему исходному отправителю присущи недостатки/проблемы (описано в постановке задачи в сабже), а шине - которая тоже отправитель - внезапно такие недостатки/проблемы не присущи?

8. Евгений Ванжула (minimajack) 12.02.16 23:59
(7) CheBurator, потому что шина обычно одна, а отправителей-получателей может быть много....
9. Сергей (Che) Коцюра (CheBurator) 13.02.16 03:13
(8) ответ вообще ни о чем
Исходный отправитель на строне отправителя тоже один
Шина как отправитель - тоже одна
При этом исходному отправителю присущи некоторые проблемы
А шине- отправителю эти проблемы внезапно не присущи
Непонятно
ВОПРОС ОСТАЛСЯ
10. Сергей (Che) Коцюра (CheBurator) 13.02.16 03:15
Попутный вопрос чайниколамера
В чем цимес внедрения еще одного звена в путь передачи данных - то есть усложнения пути - добавления добавочных стыков с соответствующим увеличением риска повреждения стыков?
11. Рома Филатов (FilatovRA) 13.02.16 10:35
(3) CheBurator, перечитал пост, о какой именно проблеме присущей отправителю, описанной в тексте, идет речь?
12. Максим *** (premier) 13.02.16 10:48
(9) CheBurator, прочитайте вот эту статью, может быть что-то для себя проясните. ESB - довольно распространенный стандарт обмена данными между различными информационными системами.
А пример приведён "для самых маленьких", т. е. простейший пример использования шины для обмена сообщениями (что и указано в заголовке публикации).
13. Armando Armando (Armando) 13.02.16 11:08
(10) CheBurator, информационных систем может быть туева хуча и все они должны между собой обмениваться, при этом они все могут находиться в разных зонах безопасности. Каждая инф система поддерживает ограниченное количество технологий обмена данными, и имеет свои особенности работы с этими технологиями. Задача источника гарантированно передать на шину пакет данных в своем формате. Задача шины преобразовать входящие данные в формат понятный получателю и обеспечить гарантированную доставку. То есть источника не волнуют особенности целевого получателя, которых много. Это головная боль шины, которая одна и всё умеет. Если шины не будет, то на стороне источников придется учитывать особенности всех получателей и обеспечивать доступ к ним. Если тебе эти проблемы не знакомы, то шина не нужна.
14. Рома Филатов (FilatovRA) 13.02.16 16:04
(10) CheBurator, шина в данной статье использована лишь для демонстрации паттерна, но если цглубиться в тему, то с помощью шины мы можем обеспечить асинхронность обмена, например: есть СверхсекретнаяСистемаКакого-тоНИИСверхзакрытаяИз-заСтарыхНачальников-маразматиковИТакПовелосьИНеСокращатьЖеПервыйОтделУМеняТамТещ­аРаботает, написана индусами на коболе и может отдавать важную цифру файликом только 1 числа каждого месяца и обязательно требует подтверждение доставки, иначе новый не даст. И есть вторая система НеМенееСекретногоНИИКотороеНаходитсяВЮрисдикцииТогоЖеВедомст­ваНоОтЭтогоКакОбычноНеЛегче, которая может принимать этот файлик только по средам при прлной луне, причем во вторник файлика быть не должно ни в коем случае, иначе система встанет. Вот тут на помощь и приходит шина 😊
15. Сергей (Che) Коцюра (CheBurator) 13.02.16 16:46
(13) Спасибо за внятный ответ. По сути: проблем при обмене много. Это не значит в общем случае что эти проблемы нельзя решить на стороне отправителя. Но вопросы взаимодействия отправителя и получателя являются специфическими и их ПРОСТО УДОБНЕЕ ВЫДЕЛЯТЬ В ОТДЕЛЬНУЮ НЕЗАВИСИМУЮ СПЕЦИАЛИЗИРОВАННУЮ СИСТЕМУ(ШИНУ) ОБМЕНА.

Все. Вот так я понял те "сопли", которые были развешаны в публикации (спасибо комментам).
16. Сергей (Che) Коцюра (CheBurator) 13.02.16 16:54
Но, получается, шину все равно не сделать достаточно независимой.
например, отправитель умеет отдавать в xml
получатель читает только csv
вопрос: на основании чего шина преобразует одно в другое? человек, работающий на шине - идет к отправителю, выспрашивает, идет к получателю, выспрашивает, думает, пишет коннектор-преобразователь. если это все в рамках одного предприятия/холдинга - концы еще можно склеить. Если отправители и получатели - разные конторы - превращается - даже на простых вещах - в приличную (_._) - так и живем (zркий пример - EDI)
17. борян петров (TODD22) 13.02.16 17:04
(16) CheBurator,
Но, получается, шину все равно не сделать достаточно независимой.
например, отправитель умеет отдавать в xml
получатель читает только csv

Шина это же не только преобразование. Это ещё разные функции отвечающие за доставку сообщений и тд. Например этот функционал у нас для всей системы одинаковый.
Ну а преобразование это только часть функционала. Его уже по принципу подключаемых модулей можно модифицировать.
18. Максим *** (premier) 13.02.16 17:40
(16) CheBurator, Вы, очевидно, не видите разницу понятий: централизация и децентрализация. Шина позволяет централизировать данные, отправляемые и принимаемые разными информационными системами. Поэтому схема: pub-sub не является централизованной (читайте текст публикации), а схема pub-esb-sub как раз и будет схемой централизации. В общем, для каждого предприятия схема обмена сообщениями специфична. Где-то необходима централизация (как раз с использованием шины), а где-то - нет. Форматы сообщений не имеют ни какого значения. Главное - чтобы система, которая является координирующей в обмене (шина), могла их трансформировать в форматы сообщений принимающих систем.
19. Dima Dima (bayce) 13.02.16 21:51
А будет ли все это быстро работать на 1С?
20. Сергей (Che) Коцюра (CheBurator) 13.02.16 22:47
(18) спсб за пояснения.
вопрос: какая система является более устойчивой - централизованная или децентрализованная?
21. Максим *** (premier) 13.02.16 23:54
(20) CheBurator, всё зависит от предприятия, в котором та или другая система будут работать. Для крупного холдинга, я думаю, централизованная система достаточно важна, поскольку данные распределены по многим информационным системам. Для небольших организаций (опять же моё мнение) централизация не так необходима.
22. Максим *** (premier) 14.02.16 00:07
(20) CheBurator, да, насчет устойчивости этих систем... В схеме pub-sub, конечно же, меньше "телодвижений", но она не настолько универсальна как другая. В общем: под каждое предприятие следует подбирать определённую схему обмена сообщениями.
23. Сергей (Che) Коцюра (CheBurator) 14.02.16 01:36
(22) угу
Я тут как раз об этом подумываю, бо вопросы коннектов с другими системами начинают задалбывать
На портале даже почти нужное нашел - сборщика файлов с фтп, мыла и прочего
Полезная вещь Инфостарт
24. Максим *** (premier) 14.02.16 10:12
(23) CheBurator, не была бы полезной мы сюда и не заходили бы. Здесь многие делятся своим опытом. Кто-то платно, кто-то за "фишки", но портал, несомненно, ценен. Спасибо, Доржи!
25. Евгений Ванжула (minimajack) 15.02.16 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
26. Сергей (Che) Коцюра (CheBurator) 15.02.16 15:12
27. Максим *** (premier) 17.02.16 10:04
(26) CheBurator, в (18), мои пояснения были не совсем правильными, точнее, совсем неправильными (странно, что этого никто не заметил). Схема с шиной является, наоборот, схемой децентрализации, т.к. сама она данные не хранит, а всего лишь принимает и передает получателям. Схема централизации же собирает, хранит, обрабатывает и передает данные, полученные из одних иформационных систем другим. Решать, какая схема стабильнее, можно только исходя от специфики и архитектуры информационной системы в целом. Когда паблишер один и получателей немного, вполне подойдёт централизованная схема, а вот, когда паблицеров и получателей становится много - без децентрализации, мне кажется будет не просто обойтись.
28. Евгений Ванжула (minimajack) 17.02.16 11:02
(27) premier, да выкиньте понятие "[де]централизация".
Шина она и в Африке шина. Она принимает и передает(опционально с хранением, транзакцией)!
в вашем понятии:
децентрализация:
отправитель -> шина -> получаетель
централизация:
отправитель -> мегасуперпупершина (хранит, обрабатывает, галстучки вяжет) -> получатель

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

теперь про хранение.
Шина всегда хранит сообщение - ей же нужно как то его передать.
Если выключается свет что делать с сообщениями?
Все зависит от потребностей...если необходима гарантированная доставка - необходимо хранить данные( на диске, в бд и т.п.) в шине персистентно. Проще говоря в шине используется транзакции; между отправителем и шиной - для подтверждения поступления сообщения в шину, между шиной и получателем - для подтверждения доставки. Пока получатель не подтвердит получение - шина хранит сообщение. Пока шина не сказала что она сохранила данные в БД отправитель считает, что отправка не закончилась.
Когда же транзакционность не нужна? Например состояния каких либо датчиков, данных устаревающих которые не имеет смысл хранить дольше определенного срока. В общем все что не персистентно - работает без транзакций и реально быстрее и легче в интеграции.
29. Максим *** (premier) 17.02.16 14:46
(28) minimajack,
в вашем понятии:
децентрализация:
отправитель -> шина -> получаетель
централизация:
отправитель -> мегасуперпупершина (хранит, обрабатывает, галстучки вяжет) -> получатель

В моём понятии централизация -это когда шина всегда хранит принятые данные и сама же эти данные раздает, если требуется.
Во втором варианте шине требуется хранить данные только до момента подтверждения приема-доставки сообщения.
Вот, по-моему, и вся разница в этих понятиях.
30. Рома Филатов (FilatovRA) 18.02.16 11:05
(28) minimajack, вот по поводу хранения в шине не могу с вами согласиться. В простейшей шине не хранится ничего. Пример схемы: шина мониторит каталог, при появлении файла копирует его в 2 других каталога. У шины лишь 2 интерфейса, откуда брать и куда ложить и одно состояние, получилось/не получилось.
31. Рома Филатов (FilatovRA) 18.02.16 11:14
(29) premier, в моем понимании шина в обмене данными может быть только инструментом централизации, т.е. схемы, при которой при потере одного элемента теряется вся цепочка: многабаз ⤑ шина ⤑ многадругихбаз.
32. Рома Филатов (FilatovRA) 18.02.16 11:16
(30) FilatovRA, поправка, не ничего, а не хранятся сообщения.
33. Евгений Ванжула (minimajack) 18.02.16 15:35
(32) FilatovRA, а давайте наоборот!
Откуда шина знает про каталоги? Что значит интерфейс - это то что принадлежит шине или что то стороннее? Если шина потеряет доступ к каталогу - что сломалось, шина или внешняя система? Кто должен сообщить что проблемы, шина которая не может обратиться к каталогу или внешняя система?
И тут возникает вопрос: "Являются ли каталоги частью шины?".
Если нет, тогда почему шина о них знает?
Если да, то каталоги и являются местом хранения информации в шине.

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

шина в обмене данными может быть только инструментом централизации
- тут с вами полностью согласен, шина именно что централизует поток сообщений.
34. Сергей (Che) Коцюра (CheBurator) 18.02.16 19:23
(27) я обратил внимание на эту "фишку", но раз спец написал - значит написал ;-), хотя навскидку как-то не склеилось, а как понимать централизация/децентрализация - ну хз.. я подумал что шина есть централизация в том смысле что вместо кучи разрозненных обменов, встроенных в прикладные конфиги (что есть децентрализация) функционал выдран, и перенесен в одну конфигу, которая стандартизирована и формализирована (что есть централизация) - так что особо не заморачивался терминами... ;-)
35. Рома Филатов (FilatovRA) 19.02.16 09:27
(33) minimajack, Попробую: Каталоги не являются частью шины. Шина знает о каталогах потому что мы сообщили ей о них через её интерфейс(сеттер). Вопрос оказоустойчивости и доступности ресурсов(папок) в абстрактной шине не рассматривается, т.к. это модель и в данной модели мы по-умолчанию устанавливаем, что шина гарантирует транспортировку пакета между каталогами. Если для примера взять логистику: есть 2 завода, из одного завода в другой нужно доставить тонну груза. В реальном мире мы бы использовали грузовик(т.е. на время транспортировки груз хранится в транспорте), а у нас есть телепорт, которому достаточно сообщить откуда нужно взять груз, и где он должен появиться.
36. Евгений Ванжула (minimajack) 19.02.16 09:37
(35) FilatovRA,
а у нас есть телепорт, которому достаточно сообщить откуда нужно взять груз, и где он должен появиться

ну если взять сферического коня в вакууме то да, но на компьютере информация все равно будет проходить через участок памяти(буфер) для копирования, типа взяли мы не грузовик, а тележку и перекидываем сколько влезет в буфер и мотаемся туда-сюда так пока все не вывезем...
хочу увидеть телепорт файлов из одного каталога в другой :D
37. Максим *** (premier) 21.02.16 18:01
(34) CheBurator, посмотрите вот этот материал и это.
Скорее всего, поймёте в чём разница (Вы же специалист с большим опытом! 10 лет /а то и больше/ за плечами).
38. Сергей (Che) Коцюра (CheBurator) 22.02.16 00:00
(37) ссылки не открываются
У инфостарта какаято глубинная проблема - ссылки в публикациях не любит
39. Алексей Попов (Aleskey_K) 10.03.16 10:16
Да, шина вещь хорошая, при большом зоопарке информационных систем.
Вот ещё мощная разработка http://integration.axelot.ru/products/axelot-esb-servisnaya-shina-dannykh/
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа