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

Разворачиваем сервисную шину от Progress Sotfware для тестирования и
разработки. Напомню, что с её архитектурой мы разобрались в Части 1.
Установка Sonic происходит так просто, что даже не имеет смысла её
описывать. Визард с несколькими Next и выбором путей установки.
Важно отметить, что устанавливаем:

1. На сервере был установлен брокер сообщений Sonic MQ 7.5 и поверх него установлена сервисная шина Sonic ESB 7.5 (сервер работает по линуксом RHEL4).
2. На рабочей станции быа установлена среда разработки Sonic
   Workbench 7.5, включающая в свой состав Java, Eclipse, набор плагинов к
   Eclipse (собственно Sonic Workbench), а также на рабочей станции
   девелопера автоматически устанавливаются SonicMQ и SonicESB (таким
   образом тестирование разрабатываемых сервисов можно делать "не отходя
   от кассы"). Станция работает под ОС Windows.

Управление всем происходящим в Sonic MQ+ESB как на сервере, так и на рабочей станции осуществляется через отдельное приложение Management Console,
запускаемое на произвольной рабочей станции. Оно работает на java и
удаленно подсоединяется к управляемому узлу. Чтобы было понятно, что
есть узел, сделаю небольшое отступление про архитектуру.
В первой части было сказано, что архитектура полностью
распределенная и состоит из сервисных контейнеров, тем не менее в
архитектуре всё-таки присутствуют узлы "централизации". Во-первых, это MQ-брокеры, отвечающие за гарантированную доставку сообщений. Брокер сообщений поселяется в одном из контейнеров.
Во-вторых, контейнеры объединяются в домены. Домен задается
единой конфигурацией или, подругому говоря, каждый домен описан в своей
Directory Service, которая живет в одном из контейнеров. Все остальные
контейнеры знают, где живет их Directory Service, и обращаются к нему
за конфигурацией (на случай пропадания физического соединения
существует локальная копия параметров).
Таким образом, с точки зрения физической архитектуры сервисная
шина Sonic ESB — это множество доменов, взаимодействующих между собой,
каждый из доменов состоит из набора брокеров гарантированной доставки
сообщений, через которые взаимодействуют сервисы, живущие в контейнерах.

По умолчанию в установленной конфигурации Sonic ESB присутствует
главный контейнер DomainManager, в котором живут Directory Service и
брокер сообщений.
Для загрузки сервисов был создан дополнительный контейнер
MsgContainer и брокер сообщенйи MsgBroker. Не буду подробно расписывать
их создание и настройку, тем не менее, там есть весьма неочевидные
шаги, требующие предварительного изучения документации или подсказки
эксперта. Шаги были успешно пройдены и контейнер успешно стартовал.
Как видно на скриншоте, в конфигурации данного домена присутствует
ещё много контейнеров, начинающихся на префикс dev_. Весь секрет в том,
что скриншот снят с домена, идущего в составке среды разработки
Workbench, поэтому в нём уже созданы контейнеры с примерами сервисов и
приложений.
В следующей части тестирования мы обязательно попробуем создать собственный сервис и включить его в пробный ESB-процес.