Составляющие базовой архитектуры 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.