Вот и добрался до пера написать об интересной интеграционной платформе, кардинально отличающейся от присутствующих на рынке продуктов данного направления. Интересна она в том, что большинство существующих решений упорно продолжают свое эволюционное развитие на сложившемся «палеонтологическом» пласте под названием application server со всеми вытекающими последствиями. Решения, применяемые в интеграционной платформе с которой хочу немного познакомить, я бы назвал революционными, особенно для того времени когда она родилась (2000 год). Ниже особенности архитектуры, ныне, от Aurea software — дочки Trilogy. Итак, Aurea Sonic ESB (CX Messenger) – это сервисная шина предприятия (ESB – Enterprise Service Bus) состоящая из двух базовых компонент: MQ – обеспечивает обмен сообщениями и ESB – набор сервисов и механизмов для осуществления различных операций над сообщением (Стандартные сервисы реализуют шаблоны интеграции, с которыми можно ознакомиться здесь www.enterpriseintegrationpatterns.com).
Менеджер домена
В архитектуре Sonic ESB центральным компонентом является Domain Manager (далее DM) – менеджер домена. Domain, в свою очередь, это совокупность всех компонент находящихся под управлением одного DM. Менеджер домена объединяет в себе следующие программные компоненты:
1. Directory service (DS) – своеобразный репозитарий, хранилище всех необходимых артефактов для обеспечения работы шины и интеграционных процессов конкретно взятого домена. Конфигурации MQ и ESB, JNDI, библиотеки, конфигурационные файлы, security и пр.
2. Management broker – это message broker, но используется для служебного обмена сообщениями, а так же для получения метрик, регистрации подписчиков и пр.
3. Agent manager – отслеживает состояние всех контейнеров и компонент домена (что такое контейнер будет чуточку ниже).
Для работы всего этого хозяйства указанные компоненты размещаются, в так называемый, MF Container (далее контейнер). Контейнер с перечисленным набором компонент и называют менеджером домена.
Для обеспечения отказоустойчивость имеется механизм Fault tolerance. Который заключается в том, что практически для каждого компонента Sonic ESB (DS, MF Container, Broker) можно создать его backup, который будет работать в связке с основным компонентом. В случае сбоя основного, его роль автоматически берет на себя backup. Для клиента это происходит не заметно.
Контейнер
Предлагаю немного задержаться на понятии контейнера (MF Container). MF Container – это конфигурационная единица в который размещаются различные компоненты шины и исполняется как отдельная Java машина. Он может содержать как один компонент, например, брокер, так и несколько разных компонент, как в случае с менеджером домена. Когда создается новый контейнер он создается как конфигурационный компонент в DS. Для того, что бы его запустить на исполнение необходимо сгенерировать конфигурационный файл и разместить его на хост на котором хотите что бы контейнер исполнялся (в нормальной практике это делается автоматически через инструмент Sonic Deployment Manager). Разумеется на хосте должен быть установлен минимальный необходимый набор из дистрибутива Sonic – Host manager. После этого его можно запустить на исполнение. Он подключится к DM, закачает в свой кэш из DS все необходимое для работы размещенных в нем компонент и запустит их. Соответственно, один контейнер – одна JVM. Таким образом, для работы контейнера и тех компонент которые в него разместили, в большинстве случаев, постоянная связь с DM не требуется, только в момент старта.
Двигаемся дальше и рассмотрим теперь прикладные компоненты, на которых и будет строиться вся интеграция предприятия.
Брокер
И конечно же, самое важное значение здесь играет messaging. За обеспечение обмена сообщениями в интеграционной шине Sonic ESB отвечают message brokers или просто брокера. Брокера это Sonic MQ message servers которые реализуют JMS API плюс дополнительные расширения и функции, относящиеся к обмену сообщениями. Например, есть HTTP acceptor который позволяет принимать сообщения по http протоколу и помещать их в очередь/топик брокера. Каждый брокер имеет свою собственную локальную БД для обеспечения хранения сообщений. Данная база является встроенной в продукт и оптимизирована специально для обмена сообщениями. Но есть возможность подключать внешнюю, например, Oracle. Брокера можно скомпоновать в кластер тем самым выполнив горизонтальное масштабирование и повысив отказоустойчивость.
Однако, если необходима отказоустойчивая гарантированная доставка, то для этого существует технология постоянной доступности (Continuous Availability Architecture – CAA). Смысл которой заключается в том, что для брокера создаётся его backup. При отправке сообщения, перед тем как послать ACK (подтверждение о доставке) клиенту, сообщение будет помещено в БД брокера и реплицировано на его backup брокер. Переключение между брокерами в кластере для клиента происходит не заметно путем расширенного JMS API (Fault Tolerant Connection), необходимо только при подключении указать список URLs брокеров входящих в кластер, а клиентская библиотека сама позаботиться о том, что бы переподключиться к активному брокеру в кластере или к наименее нагруженному при включении опции Load balanced
Технология DRA
Sonic ESB имеет полезный механизм под названием Dynamic Routing Architecture (DRA). Данный механизм позволяет клиенту, имея подключение к одному брокеру, передавать сообщения в очереди/топики других брокеров через указание маршрутного префикса — Routing Node.
Таким образом можем, например, иметь брокера работающие в одном офисе на своих серверах и брокера, работающие в другом офисе на своих серверах при этом ПО первого офиса имеет возможность не меняя подключения и не устанавливая нового отправлять сообщения в ПО второго офиса. Плюс над всем этим еще можно настроить всевозможные политики и права.
ESB
Итак, для тех кто еще с нами двигаемся к части ESB.
Сообщение получили, теперь с ним надо что-то сделать: преобразовать, передать в другую систему, записать в БД, и много другое что вам необходимо или вы готовы это закодить. Для всех этих вещей есть сервисы которые, в обычном сценарии, объединяются в процессы. Сервисы представляют собой Java класс реализующих определенный API (а в последней версии – любой Java класс) и выполняющий обычно одну конкретную функцию (привет micro services), например кодирование/декодирование в base64. Плюс с сервисом должен идти файл описания сервиса необходимый DS, что бы понимать что за сервис, какие параметры уровня инициализации и уровня исполнения (runtime) он имеет, какой jar его реализует и пр. По сути, это еще не сам сервис, а так называемый сервисный тип – описание и реализация. Для работы сервиса, в DS создается его конфигурационный инстанс на основе сервисного типа, где указывается название, определяются параметры инициализации, входные/выходные endpoint-ы, при необходимости. Далее инстансы сервисов в среде разработки можно объединять в процессы – ESB process. При помещении сервиса в процесс ему можно определять параметры уже на уровне runtime. Например, один инстанс сервиса используется в двух местах процесса, но с разными runtime параметрами.
Далее, процессы и сервисы размещаются в конфигурационную единицу под названием ESB контейнер. На уровне ESB контейнера можно определить количество одновременных обработчиков (listeners) для входящих в него процессов и сервисов, в случае необходимости, на уровне его class loader-а подключить библиотеки, используемые кастомными сервисами, установить режим intra-container messaging при котором передача сообщения от сервиса к сервису по процессу будет осуществляться без участия брокера, а непосредственно внутри контейнера. Так же, на уровне ESB контейнера определяется соединения к брокеру с которым будут взаимодействовать процессы и сервисы размещенные в данном контейнере. Далее ESB контейнер размещается в MF-контейнер (а можно и в несколько на разных хостах — еще один уровень масштабирования или композиции). Клиент подключается к брокеру (который зачастую не один, а в кластере) и посылает, например, сообщение в очередь. Для очереди в DS зарегистрирован Endpoint являющийся входным endpoint-ом процесса (или отдельного сервиса, при необходимости). Сообщение попадает в процесс, к сообщению прицепляется контекст процесса, и далее сообщение следует логике которую вы определили в процессе. Сообщение идет от сервиса к сервису в соответствии с контекстом, т.е. всегда известен следующий шаг на который текущий сервис должен передать сообщение.
Конечно же, при большом потоке сообщений можно увеличить количество листенеров процесса (до 100 на один ESB контейнер) и количество одновременных обработчиков для сервисов и, как я писал выше, можно увеличить количество самих ESB контейнеров путем помещения его определения в разные MF контейнеры. Но это уже зависит от ваших потребностей и задач.
Развертывание (deployment)
Но как же все эти артефакты появляются в DS, спросите вы? Не руками же все это создавать в специальной консоли Sonic Management Console – толстый Java клиент позволяющий создавать большинство артефактов и управлять исполнением. Конечно нет. Существует инструмент Sonic Deployment Manager (SDM) который позволяет описывать в виде набора XML файлов модель и топологию вашей интеграционной шины и входящих в нее артефактов с последующим развертыванием. А именно, можно описать хосты, брокера их акцепторы, указать в каких MF-контейнерах они должны размещаться, какие MF-контейнеры на каких хостах запускаются, какие очереди создавать и где, routing nodes, security (users, ACLs, certificates) и многое другое. Затем вы выполняете команду с указанием домена, названия окружения (будет браться соответствующий файл пропертей) и готово – конфигурация проливается в DS и при необходимости все компоненты могут автоматически запуститься.
Заключение
Вкратце пробежал ознакомительно по верхушкам. Если кому-то интересно, готов раскрыть более детально какие-то моменты. В итоге, мы имеем легковесное, хорошо масштабируемое, надежное и довольно производительное решение для обеспечения интеграции без использования тяжеловесных монолитных серверов приложений.
При этом, все это configuration based, т.е. не требует написания кода до тех пор пока не потребуется какой либо нестандартный сервис. Поддержка гетерогенности через технологию DRA и распределенности. В отличие от приложений основанных на web сервисах где SOAP over HTTP используется для каждого вызова, здесь мы можем оптимизировать транспортные накладные расходы (да, да Oracle SOA Suit тоже это умеет делать). Масштабируемость доступна на обоих уровнях – обмен сообщениями и прикладных сервисах. По моему мнению, возможность масштабировать сервисы между многими серверами без необходимости переконфигурации приложения или инфраструктуры на которой построен ESB является важным преимуществом т. к. позволяет выполнять масштабирование когда это необходимо в реальном времени без перерыва в работе сервисов.