Тестируем Sonic ESB. Часть 1.

Как было сказано раньше в статье "Два подхода к интеграции сервисов",
подходы используемые в интеграционном ПО можно весьма условно разделить
на централизованный и распределенный. И если предыдущий
протестированный продукт (BEA AquaLogic)
относится скорее к централизованной схеме (работает на базе сервера
приложений, в котором концентрируется вся логика обработки), то
продукт, к тестированию которого мы приступаем сейчас, претендует на
реализацию распределенной схемы. Так ли это? Особенно учитывая, что оба
продукта используют в названии аббревиатуру ESB (Enterprise Service
Bus).
Итак, для начала разберемся с архитектурой продукта Sonic ESB, компании Progress Software.

На логическом уровне ESB представляет собой набор сервисов, каждый из которых имеет свою входную конечную точку endpoint (на рисунке светло-оранжевая), через которую к данному сервису можно обращаться.
Физически все сервисы можно свободно распределять по различным контейнерам на разных серверах.

Контейнеры, в отличие от сервера приложений, являются очень легкими
и позволяют удобно управлять нагрузкой и резервированием всей системы.
Распределенность, тем не менее, не добавляет сложностей разработчику
или системному архитектору, потому что каждый из сервисов доступен по
его адресу-конечной точке.
Все задачи гарантированного транспорта сообщений между сервисами
берет на себя продукт Sonic MQ, без которого SonicESB не может
существовать. Sonic MQ — это JMS-брокер, поддерживающий дополнительно к
спецификациям JMS ещё набор очень полезных технологий по
резервированию, маршрутизации и управлению — всё то, что помогло бы
разрабатывать сервисы без оглядки на возможные проблемы транспортной
среды (они будут отработаны на уровне Sonic MQ, так утверждает
разработчик).
Далее. А какже происходит создание взаимосвязи сервисов и как это
настраивается? Помимо сервисов на шине живут также процессы. ESB
Process создается разработчиком или системным архитектором в среде
разработки Sonic Workbench. Его задача определить что-то наподобие
маршрутного листа для сообщений, путешествующих по шине. То есть для
поступающего в систему сообщения (события, запроса) определяется его
процесс обработки, определяющий дальнейшие параллельные и
последовательные вызовы сервисов. Это описание прикрепляется к
сообщению при его отправке в первую точку обработки. Таким образом для
дальнейшего определения пути происходит без обращения к какому-либо
центру принятия решений.
Процесс развертывания Sonic ESB и среды разработки будет рассмотрен в следующей статье.
Тестирование Sonic ESB. Часть 2