Составляющие базовой архитектуры SOA

Базовая архитектура SOA состоит из провайдера сервисов, сервиса и (необязательного) каталога сервисов. Для обмена информацией используется механизм обмена сообщениями типа "приложение к приложению".

Сходство между этой моделью и чистыми веб-сервисами совершенно очевидно, поскольку в обоих случаях применяется WSDL-документ, являющийся контрактом по активизации, хранящимся в каталоге сервисов, из которого этот сервис может быть запрошен и извлечен посредством механизма UDDI (UDDI — это отраслевая спецификация для публикации и поиска информации о веб-службах). Веб-сервисы в действительности являются реализацией архитектуры SOA на самом базовом уровне.

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

Роль ESB в архитектуре SOA

ESB играет важную роль в архитектуре SOA. По сути, она предоставляет магистральную сеть и инфраструктуру для соединения провайдеров и потребителей сервисов.

Ниже более подробно перечислены роли ESB:

• Предоставляет интеграционную инфраструктуру, соответствующую принципам SOA:

• Устанавливает явные независимые от реализации интерфейсы для определения сервисов со слабым связыванием.
• Использует коммуникационные протоколы, обеспечивающие независимость от месторасположения и способность к взаимодействию.
• Способствует определению сервисов, инкапсулирующих повторно используемые бизнес-функциональности.
• Предоставляет средства для управления инфраструктурой сервисов.
• Функционирует в распределенной среде, поскольку она:
• Поддерживает синхронное и асинхронное взаимодействие.
• Использует стандартные интерфейсы и стандартные протоколы.
• Централизует управление и распределяет обработку.
• Поддерживает механизм посредничества для формулирования корректных запросов/ответов между различными участниками взаимодействия без необходимости их изменения.
• Реализует защиту и обеспечение качества сервиса в проектах SOA.

Роль веб-сервисов в SOA

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

Веб-сервисы являются основой архитектуры SOA по следующим причинам:

• Они заставляют применять стандарты и тем самым способствуют совместимости и переносимости;
• Они не зависят от платформы и языка программирования;
• Они поддерживаются повсеместно, что существенно облегчает внедрение SOA;
• Они ориентированы на сообщения;
• Они обеспечивают более быструю поддержку инструментальными средствами, что ускоряет реализацию SOA.

2.4 Анализ существующих аналогов ESB технологий

Проанализировав требования заказчика, было определено:

· Приложение должно быть построено на основе SOA;

· Использование ESB в приложении;

· Необходим сервер приложений.

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

Существует множество open-source ESB технологий. Самые известные и используемые из них это:

· Mule ESB;

· Talend-SE;

· UltraESB;

· WSO2 ESB.

Ниже представлен обзор этих ESB технологий.

Mule ESB

Mule ESB – корпоративная интеграционная шина с открытым исходным кодом, с более чем 2500 промышленных внедрений, включая 5 из 10 крупнейших мировых банков и более 35% компаний и списка Global 500.

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

Mule ESB – это лёгкая и гибкая платформа, легко адаптируемая в существующую инфраструктуру, так же достаточно надёжная для обеспечения бесперебойной работы самых крупных и требовательных корпоративных реализаций SOA.

Низкие системные требования упрощают внедрение и поддержку.

Работает как под управлением сервера приложений так и без.

Более 100 транспортов и модулей для интеграции с различными системами, протоколами, SOAP и REST сервисами.

Преимуществами Mule ESB является то, что эта технология поддерживает:

· Различные серверы приложений, в том числе: JBoss и Apache Tomcat;

· СУБД MS SQL Server, которая используется в разрабатываемой системе;

· Средства разработки: Eclipse, IntelliJ, IDEA, Maven и т.д.;

· Транспорты: SOAP, Email, FTP, Hibernate, HTTP/S, WSDL и т.д.;

· Топологии внедрения: ESB, Client/ Server и т.д.;

· Безопасность: Spring Security и т.д.;

· Контейнеры: EJB3, Spring и т.д.;

· Языки: Java, Javascript и т.д.;

· Форматы данных: Byte arrays, HTML/XHTML, Java Objects, JSON, XML и т.д.;

 

Помимо этого, Mule имеет еще несколько продуктов, которые могут помочь в разработке приложения:

· Anypoint Service Registry – платформа управления SOA. Позволяет легко организовывать и обнаруживать сервисы, управлять ими на протяжении всего их жизненного цикла, контролировать их работу и обеспечить строгое соблюдение стандартов, политик и контрактов;

· Tcat - Enterprise Tomcat, сервер приложений, разработанный на базе Tomcat.

Talend-SE

Talend Open Studio ESB — инновационное средство (на базе Eclipse) для моделирования, настройки и развертывания интеграционных решений, использующее корпоративную сервисную шину с открытым исходным кодом Talend ESB на базе Apache. Talend Open Studio ESB устраняет длинную кривую обучения, типичную для большинства интеграционных инструментов. TOS ESB ускоряет развертывание, повышая тем самым продуктивность разработчиков и позволяя им быстро реагировать на интеграционные требования.

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

Talend ESB Studio предоставляет доступ к библиотеке из 450 коннекторов, поддерживающих все типы источников и конечных систем для интеграции, миграции и синхронизации данных.

Ключевые особенности:

· Универсальность и гибкость. Легко разворачиваемые web-сервисы, сервисы данных, REST приложения и сложные маршруты передачи, облегченные пакеты, настраиваемые под любую топологию приложения;

· Динамическая маршрутизация;

· Высокое представление. Шина обеспечивает высокую пропускную способность в сочетании с прозрачными для клиента средствами восстановления после сбоев и балансировкой нагрузки для гарантии того, что будут соблюдены все принятые соглашения об уровне услуг;

· Простота в развертывании. Преднастроена производителем для работы в любом Java окружении.

Функциональные возможности:

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

· Модульная сборка приложения. Модули из одного проекта в дальнейшем можно использовать и в других проектах;

· Поддержка стандартов безопасности веб-сервисов. Talend ESB SE предлагает ряд возможностей для построения безопасности веб-сервисов приложений, применяя при этом принятые отраслевые стандарты для XML шифрования, аутентификации и авторизации;

· Командная строка и инструменты для написания скриптов;

· Обмен сообщениями. Talend ESB SE снижает затраты на аппаратное и программное обеспечение, позволяя более эффективно использовать вычислительные ресурсы. Каждый брокер сообщения может управлять множеством соединений, наряду с обработкой тысяч сообщений в секунду с минимальной задержкой;

· Фреймворк для создания Службы маркеров безопасности (STS). Talend ESB позволяет установить «доверие» между частями приложений, применяя новейшие стандарты безопасности веб-сервисов;

· Перехват управления при отказе и балансировка нагрузки. Talend ESB SE обеспечивает автоматический и прозрачный перехват управления при отказе с помощью протокола обнаружения сервисов (Service Locator), а также балансировку нагрузки с помощью динамической регистрации конечных точек и поиск с помощью Apache Zookeeper. Service Locator поддерживает доступность сервиса для удовлетворения требованиям и принятым соглашениям об уровне услуг;

· Служба мониторинга активности. Служба мониторинга активности (Service Activity Monitoring) отслеживает возникающие события и сохраняет эту информацию для дальнейшего глубого анализа;

· Небольшое дисковое пространство. Шина Talend ESB (под управлением Apache Karaf, занимающая небольшое дисковое пространство, OSGi-ориентированная) предоставляет облегченный контейнер для развертывания различных компонент и приложений. Talend ESB использует ресурсы по минимуму в плане размера загрузки и использования процессора и памяти;

· Поддержка транспортных протоколов (HTTP, Servlet, JMS), привязки данных и форматов(XML, JSON), Bindings (SOAP, REST/HTTP);

· Поддержка стандартов;

· Гибкое развертывание;

· Поддержка различных языков программирования.

 

UltraESB

UltraESB является бесплатным и свободно распространяемым Enterprise Service Bus, впервые выпущенный в январе 2010 года под AdroitLogic Zero-Dollar EULA. С августа 2010 года его исходный код был доступен по лицензии OSI, утвержденный Affero General Public License (AGPL).

Разработка,конфигурирование и тестирование:

· С использованием любого IDE, который предпочитает пользователь (IntelliJ IDEA, NetBeans, Eclipse и т.д.);

· Интеллектуальное автозаполнение и встроенная в IDE пошаговая отладка;

· Отправка более 70 образцов и соответствующих модульных тестов;

· Конфигурация ESB с испольщованием APIDirector AdroitLogic без программирования.

Управление и мониторинг:

· Все средства управления и мониторинга работает вне ядра ESB экземпляра;

· UConsole - веб-консоль управления;

· UTerm - интерфейс для администрирования;

· Встроенные метрики, оповещения и отладка сбоя подключения;

· Автоматизированный шаблон на основе метрик отчетности Zabbix.

 

Кластеризация и высокая доступность:

· Кластеризация на основе Apache ZooKeeper;

· Все узлы эквивалентны, отсутствуют специальные узлы управления;

· Управление всем кластером через любой подключенный узел;

· Репликация состояния и обмен контентом с помощью распределенного кэширования на основе Ehcache.

 

Технические особенности:

· Кэширование файлов на RAM дисках;

· Возможность динамической загрузки и перезагрузки единиц развертывания (то есть сервисы, логика посредничества и т.д.) автоматически во времени выполнения.

WSO2 ESB

WSO2 ESB придерживается стандартов веб-сервисов, включая SOAP, WS-*, REST.

WSO2 ESB может выполнять множество операций над сообщениями, проходящими через него, таких как маршрутизация к конечным точкам (endpoints), посредничество (mediation), преобразование, логирование информации, балансировка нагрузки и многое другое. Архитектура WSO2 ESB содержит различные функциональные компоненты, такие как транспорты, последовательности, прокси-сервисы, медиаторы, конечные точки, компоненты QoS (качества обслуживания) и так далее. Прием сообщений в ESB первоначально возлагается на транспортную составляющую, которая поддерживает общие транспортные протоколы, такие как HTTP / S, JMS, VFS, и т.д.

На транспортном уровне получение сообщений идентифицируется тегом content-type и созданием обрабатываемого xml документа с описанием маршрутизации и назначения медиаторов и конвертации к оригинальному формату сообщения путем направления content-type к точке выхода.

Сообщения отсылаются через канал сообщений по транспорту к фреймворку-медиатору(посреднику). В канале аспекты качества обслуживания (например, безопасность и надежность сообщений) добавляются к сообщениям. Обычно посредничество между сообщениями происходит в одном канале сообщений, но в случае с прокси-сервисами каждый из них дожжен поддерживать свой канал сообщений.

Фреймворк-медиатор, разработанный Synapse принимает решение о маршрутизации и трансформации сообщения и внедряет сообщения в различные каналы в зависимости от обозначенных точек назначения. Транспортный слой должен снова позаботиться о преобразовании транспортного протокола, необходимого в ESB. С помощью REST API любую реализацию SOAP сервиса можно представить как REST клиент для сервиса.

Изображение внизу показывает архитектуру WSO2 ESB.

Рис. 5 Архитектура WSO2 ESB

WSO2 ESB имеет следующие особенности: полная поддержка XML и веб-сервисов, высокое качество использования регулирования соединения, неблокированный I/O и модель непрерывного разбора XML. Другой важной особенностью является поддержка событийно-ориентированной архитектуры. Процесс посредничества сообщениями расширяется поддержкой разбиения на части, агрегации, кэширования и регулирования сообщений. WSO2 ESB также обеспечивает всесторонний мониторинг производительности, через консоль управления, а так же через JMX.

Особенности

• Подключения

• Транспорт: HTTP, HTTPS, JMS, TCP, UDP, FTPS, SFTP и др.;
• Форматы и протоколы: JSON, XML, SOAP 1.1, SOAP 1.2, WS-*, HTML, Text, JPEG, все бинарные форматы и др.;
• Маршрутизация, посредничество и преобразование
• Маршрутизация: на основе заголовка, содержания, основанная на правилах и приоритетно- основанная маршрутизация;
• Посредничество: гарантированная доставка сообщений, интеграция с базами данных, публикация событий, логирование и аудит, валидация;
• Преобразование: XSLT 1.0/2.0, XPath, XQuery, Smooks.
• Сообщения, API и безопасная маршрутизация
• Предоставление доступа к существующим приложениям и сервисам через различные протоколы и форматы сообщений;
• Виртуализация услуг для слабой связи и управления SOA;
• Балансировки нагрузки для обеспечения масштабируемости и отказоустойчивости для обеспечения высокой доступности конечных точек системы;
• Централизованное обеспечение и управление безопасностью, в том числе аутентификацией, авторизацией доступом;
• Предоставление доступа к сервисам и приложениям через RESTful APIs с управлением ключами.

 

Проведение тестов

Для того чтобы определиться, какая из представленных систем лучше всего удовлетворяет поставленным целям, было решено проанализировать их производительность и другие характеристики, проведя несколько соответствующих тестов. Было решено сравнивать производительность самых последних версий технологий, о которых было сказано выше: WSO2 ESB 4.6.0, Mule 3.3.0, Talend-SE-5.1.1 и UltraESB 1.7.1- Enhanced. Так как по результатам тестов WSO2 ESB 4.6.0 показал одни из лучших результатов, то так же было решено проанализировать и одну из предыдущих версий этого продукта: WSO2 ESB 4.5.1, а так же особое внимание будет уделяться именно этому продукту, чтобы дать более полные его характеристики и объяснить достоинства его использования в проекте.

WSO2 ESB 4.6.0 является последней версией ESB на момент проведения анализа, и данные ниже показывают прирост производительности по сравнению с WSO2 ESB 4.5.x.Критерии оценки эффективности работы выполняются в Amazon EC2, поэтому они могут быть независимо проверены и повторены. Amazon EC2 — веб-сервис, который предоставляет вычислительные мощности в облаке. Простой веб-интерфейс сервиса позволяет получить доступ к вычислительным мощностям и настроить с минимальными затратами ресурсы. Он предоставляет пользователям полный контроль над вычислительными ресурсами, а также доступную среду для работы. Сервис сокращает время, необходимое для получения и загрузки нового сервера.

Сценарии тестирования:

 

· DirectProxy;

· CBRProxy;

· CBRSOAPHeaderProxy;

· XSLTProxy;

· XSLT Enhanced Proxy (Используется FAST XSLT медиатор, управляемый сквозным(passthrough) траспортом);

· SecureProxy.

Для каждого сценария были проведены тесты с использованием различных значений: размеров сообщений и количества пользователей. Размеры образца сообщения колебались от 512 до 100K байт, с одновременным количеством 20, 40, 80, 160, 320, 640, 1280 и 2560 пользователей.

Общие наблюдения.

В следующей таблице и графике показаны результаты теста производительности. Этот график показывает среднее значение среди сообщений всех размеров.

Количество сообщений для одного клиента N = 1000 при подключении до 320 параллельных клиентов и N = 10 для реализации более высокого параллелизма (1280/2560 клиентов).

 

	Mule 3.3.0	Talend-SE-5.1.1	UltraESB 1.7.1 -Enhanced	WSO2 ESB 4.5.1	WSO2 ESB 4.6.0
DirectProxy	3,375	3,315	4,839	2,879	8,278
CBRProxy	1,458	3,108	4,703	2,694	7,765
CBRSOAPHeaderProxy	2,262	3,185	5,063	3,118	7,573
CBRTransportHeaderProxy	2,225	3,751	5,523	3,502	11,024
XSLTProxy	2,225	2,333	3,387	1,735	2,504
XSLTEnhancedProxy (Fast XSLT mediator)	2,225	2,333	3,387	N/A	5,473
Security

 

 

Тем не менее, было обнаружено, что результаты данного теста были, возможно, ненадежными. Данный факт был исследован более подробно и было отмечено, что в опубликованных тестах при большом количестве параллельных клиентов для WSO2 ESB проявляются неожиданно высокие показатели. Для тестов было задано очень низкое количество сообщений на одного клиента (N = 10) при большом количестве параллельных клиентов. Это не позволяет дать JVM достаточного количества времени, чтобы разогреться, а также не представляет собой длительных испытаний, которые могут показать правдоподобные результаты.

Поэтому было решено повторно запустить тест для WSO2 ESB с использованием 200 сообщений на клиенте с большим числом параллельно работающих клиентов. После этого аномальных данных больше не наблюдалось. Также были перезапущены тесты для UltraESB в EC2 с 200 сообщениями на каждом клиенте для более высокого числа параллельно работающих клиентов. Наблюдения для N = 200 и с большой степенью параллелизма с UltraESB были намного ниже, чем ранее опубликованные. Тесты для Mule и Talend с использованием N = 200 не перезапускались. Результаты показаны в следующей диаграмме и таблице.

В будущих тестах будет использовано N = 200 для высокого числа параллельно работающих клиентов для обеспечения приемлемых результатов.

Количество сообщений в клиенте N = 1000 в случае до 320 параллельных клиентов и N = 200 для большего числа параллельных клиентов (1280/2560).

	Mule 3.3.0	Talend-SE-5.1.1	UltraESB 1.7.1-Enhanced	WSO2 ESB 4.5.1	WSO2 ESB 4.6.0
DirectProxy	3,375	3,315	4,839	3,311	5,278
CBRProxy	1,458	3,108	4,703	2,920	4,078
CBRSOAPHeaderProxy	2,262	3,185	5,063	3,270	4,634
CBRTransportHeaderProxy	2,225	3,751	5,523	3,849	5,998
XSLTProxy	2,225	2,333	3,387	1,856	1,800
XSLTEnhancedProxy (Fast XSLT mediator)	2,225	2,333	3,387	N/A	3,456
Security

 

 

На приведенном выше графике показано, что WSO2 ESB 4.6.0 работает значительно быстрее, чем ESB 4.5.1 и является конкурентоспособным с UltraESB. Заметно, что XSLTProxy на WSO ESB проходит значительно медленнее, чем эквивалентный тест для UltraESB. Но эта проблема решается путем включения в WSO2 ESB 4.6.0 новой опции FastXSLT, которая обеспечивает производительность на уровне UltraESB.