В чём заключается отличие таких способов взаимодействия приложений, как шлюз и шина?

#архитектура #интеграция

Читала статью про способы взаимодействия приложений. И что мне осталось совершенно
непонятным, это как различаются топологии интеграционного решения "шлюз" и "шина":



Буду благодарна, если кто-нибудь пояснит разницу между ними.
    

Ответы

Ответ 1

В статье "немного" ошиблись с определениями, отсюда и непонятки. Дело в том, что
та статья написана, по сути, про одно конкретное решение - и все остальное приведено
только для общего сведения.



Интеграционная шина - это прежде всего среда передачи сообщений, позволяющая доставлять
сообщения на основе логических признаков. "На пальцах", это означает, что в самих сообщениях
не содержатся никакие физические адреса.

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

Более сложные варианты дают возможность доставки сообщений по системе pub/sub (публикатор
- подписчик).

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

Маршрутизатор сообщений - это приложение, смысл существования которого - передавать
сообщения от одного приложения к другому.

Обычно маршрутизатор сообщений можно найти внутри интеграционный шины - но не каждый
маршрутизатор образует вокруг себя шину. Как минимум, нужна работа с логическими адресами.

Также маршрутизаторы сообщений иногда реализуют другие инфраструктурные сервисы,
вроде гарантированной доставки, ведения журнала сообщений или преобразования форматов.

Интеграционный шлюз - это маршрутизатор сообщений, связи которого можно поделить
на "внешние" и "внутренние".

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

В таком случае общая интеграционная шина окажется разбита на сегменты, которые могут
продолжать ограниченно функционировать при падении интернет-канала.

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

Адаптер - это маршрутизатор сообщений, разные связи которого работают по разным протоколам.

Брокер - это маршрутизатор сообщений повышенной крутизны сложности. К примеру, он
может работать с децентрализованной шиной. Или выполнять хитрые трансформации, выступая
универсальным центральным адаптером.



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

Однажды я написал свой интеграционный шлюз просто потому что КРОК 2 месяца отказывался
предоставлять нашей подсистеме второй адрес на своей интеграционной шине...

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

К примеру, WebSphere Message Broker имеет в своем названии слово "Брокер" (и заслуженно
носит его за свою непомерную сложность крутизну) - поэтому и называть его надо брокером,
а не маршрутизатором сообщений, адаптером, шлюзом или шиной.

С другой сторону, если на основе WebSphere Message Broker был сделан свой проект
по работе со СМЭВ, который был назван "шлюз для работы со СМЭВ" - то и называть его
надо шлюзом, несмотря на то, что он является еще и адаптером и маршрутизатором сообщений.

Или, к примеру, сама СМЭВ по сути является простейшей интеграционной шиной, а внутрях
крутится на WebSphere Message Broker (я видел типичные для него сообщения об ошибках)
- но называть ее надо СМЭВ, а то не поймут.