Читала статью про способы взаимодействия приложений. И что мне осталось совершенно непонятным, это как различаются топологии интеграционного решения "шлюз" и "шина":
Буду благодарна, если кто-нибудь пояснит разницу между ними.
Ответ
В статье "немного" ошиблись с определениями, отсюда и непонятки. Дело в том, что та статья написана, по сути, про одно конкретное решение - и все остальное приведено только для общего сведения.
Интеграционная шина - это прежде всего среда передачи сообщений, позволяющая доставлять сообщения на основе логических признаков. "На пальцах", это означает, что в самих сообщениях не содержатся никакие физические адреса.
Простейшие варианты интеграционных шин держат у себя справочник соответствия логических и физических адресов. Логические адреса формируются исходя из назначения приложения, его названия или оргструктуры. Этого достаточно чтобы называться шиной :)
Более сложные варианты дают возможность доставки сообщений по системе pub/sub (публикатор - подписчик).
Интеграционная шина может быть построена вокруг центрального узла (или нескольких узлов), где "крутится" маршрутизатор (см. далее) - или же быть распределенной, существуя в виде кучи адаптеров (см. далее) на стороне каждого приложения с общей базой адресов.
Маршрутизатор сообщений - это приложение, смысл существования которого - передавать сообщения от одного приложения к другому.
Обычно маршрутизатор сообщений можно найти внутри интеграционный шины - но не каждый маршрутизатор образует вокруг себя шину. Как минимум, нужна работа с логическими адресами.
Также маршрутизаторы сообщений иногда реализуют другие инфраструктурные сервисы, вроде гарантированной доставки, ведения журнала сообщений или преобразования форматов.
Интеграционный шлюз - это маршрутизатор сообщений, связи которого можно поделить на "внешние" и "внутренние".
Эти связи могут работать по одному и тому же протоколу - в таком случае смысл шлюза в разбиении общей шины на сегменты с целью добавления отказоустойчивости или защищенности. К примеру, при наличии филиалов в разных городах, в каждый можно "поставить" шлюз, который будет передавать сообщения в головной офис по шифрованному каналу.
В таком случае общая интеграционная шина окажется разбита на сегменты, которые могут продолжать ограниченно функционировать при падении интернет-канала.
Кроме того, интеграционный шлюз может соединять приложения, работающие по разным протоколам - в таком случае он будет еще и адаптером.
Адаптер - это маршрутизатор сообщений, разные связи которого работают по разным протоколам.
Брокер - это маршрутизатор сообщений повышенной крутизны сложности. К примеру, он может работать с децентрализованной шиной. Или выполнять хитрые трансформации, выступая универсальным центральным адаптером.
Как можно заметить, ни один терминов не исключает другие. Вполне можно себе представить счастье архитектора-перфекциониста в виде мега-интеграционной шины, построенной на маршрутизаторе сообщений, который является брокером, шлюзом и адаптером. Он будет уметь работать по любому протоколу, делать SQL-запросы, проводить XSLT-трансформации - и станет кошмарным сном любого разработчика :)
Однажды я написал свой интеграционный шлюз просто потому что КРОК 2 месяца отказывался предоставлять нашей подсистеме второй адрес на своей интеграционной шине...
А отсюда есть еще один вывод: любую достаточно сложную программу можно обозвать любым словом. Поэтому, чтобы коллеги вас понимали - старайтесь называть ее теми словами, которые используются в официальном названии программы.
К примеру, WebSphere Message Broker имеет в своем названии слово "Брокер" (и заслуженно носит его за свою непомерную сложность крутизну) - поэтому и называть его надо брокером, а не маршрутизатором сообщений, адаптером, шлюзом или шиной.
С другой сторону, если на основе WebSphere Message Broker был сделан свой проект по работе со СМЭВ, который был назван "шлюз для работы со СМЭВ" - то и называть его надо шлюзом, несмотря на то, что он является еще и адаптером и маршрутизатором сообщений.
Или, к примеру, сама СМЭВ по сути является простейшей интеграционной шиной, а внутрях крутится на WebSphere Message Broker (я видел типичные для него сообщения об ошибках) - но называть ее надо СМЭВ, а то не поймут.
Комментариев нет:
Отправить комментарий