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

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

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



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

Ответы

Ответ 1

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



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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

Интеграционное тестирование .Net приложений

#c_sharp #юнит_тесты #тестирование #интеграция

Здравствуйте, мне необходимо реализовать интеграционные тесты настольного .Net приложения,
которые будут запускаться после каждого билда. Тестируется бизнес-логика, описан ряд
сценариев, которые нужно проверить. Писать юнит-тесты и пытаться замокать все компоненты
- не очень здравая идея, нужно тестировать именно приложение. Юнит-тесты уже есть.
Запускать тесты хотелось бы автоматически, используя Bamboo или Jenkins, сами тесты
писать на C#. Была идея использовать Jmeter, но там только java.
Подскажите пожалуйста, есть ли какое-то средство для реализации интеграционных тестов
под .net, какой-нибудь аналог JMeter? Насколько правильно реализовывать интеграционные
тесты, используя MSTest или NUnit? Как правильно запускать нужное окружение, на котором
проводить тестирование?
    

Ответы

Ответ 1

Писать интеграционные тесты, используя MSTest вполне нормально как и NUnut или XUnit
это же все лишь фреймворки для выполнения теста как такового. А какой уж это будет
тест: Unit, интеграционный, UI, уже дело того, что вы проверяете внутри теста.

По поводу окружения, тут есть разные подходы, например вы можете развернуть MSTest
Agent на виртуальных машинах с нужным окружением и подключить их к контроллеру. Для
выбора на каком конкретно контроллере вы хотите запустить тест используйте соответствующий
.testsettings и .runsettings файлы, у NUnit агентов примерно все так же. При таком
подходе код теста выполняется на агенте.

Либо если вы тестируете UI, то можете использовать Selenium Grid, и управлять окружением
на уровне Selenium Node. тогда у вас будет один агент например NUnit на нем будет выполняться
теста и для работы с UI от будет обращаться к Grid для определенного окружения, а тот
уже выбирает свободную ноду.

Резюмирую:
Одно окружение устанавливается на все агенты одного контроллера
или при другом подходе на все ноды одного грида.

Для выбора окружения нужно выбрать соответствующий контролер или грид.

Интеграционное тестирование .Net приложений

Здравствуйте, мне необходимо реализовать интеграционные тесты настольного .Net приложения, которые будут запускаться после каждого билда. Тестируется бизнес-логика, описан ряд сценариев, которые нужно проверить. Писать юнит-тесты и пытаться замокать все компоненты - не очень здравая идея, нужно тестировать именно приложение. Юнит-тесты уже есть. Запускать тесты хотелось бы автоматически, используя Bamboo или Jenkins, сами тесты писать на C#. Была идея использовать Jmeter, но там только java. Подскажите пожалуйста, есть ли какое-то средство для реализации интеграционных тестов под .net, какой-нибудь аналог JMeter? Насколько правильно реализовывать интеграционные тесты, используя MSTest или NUnit? Как правильно запускать нужное окружение, на котором проводить тестирование?

Ответ

Писать интеграционные тесты, используя MSTest вполне нормально как и NUnut или XUnit это же все лишь фреймворки для выполнения теста как такового. А какой уж это будет тест: Unit, интеграционный, UI, уже дело того, что вы проверяете внутри теста.
По поводу окружения, тут есть разные подходы, например вы можете развернуть MSTest Agent на виртуальных машинах с нужным окружением и подключить их к контроллеру. Для выбора на каком конкретно контроллере вы хотите запустить тест используйте соответствующий .testsettings и .runsettings файлы, у NUnit агентов примерно все так же. При таком подходе код теста выполняется на агенте.
Либо если вы тестируете UI, то можете использовать Selenium Grid, и управлять окружением на уровне Selenium Node. тогда у вас будет один агент например NUnit на нем будет выполняться теста и для работы с UI от будет обращаться к Grid для определенного окружения, а тот уже выбирает свободную ноду.
Резюмирую: Одно окружение устанавливается на все агенты одного контроллера или при другом подходе на все ноды одного грида.
Для выбора окружения нужно выбрать соответствующий контролер или грид.

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

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

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

Ответ

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

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

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