Введение

Система связи в архитектуре, ориентированной на сервисы

Корпоративная шина данных (ESB) реализует систему связи между взаимодействующими программными приложениями в архитектуре, ориентированной на сервисы (SOA). Она представляет собой программную архитектуру для распределенных вычислений и является специальным вариантом более общей модели «клиент-сервер», в которой любое приложение может выступать в роли сервера или клиента. ESB повышает гибкость и адаптивность при высокоуровневом протокольном взаимодействии между приложениями. Её основное применение – интеграция корпоративных приложений (EAI) в гетерогенных и сложных сервисных ландшафтах.

Архитектура

Концепция корпоративной сервисной шины аналогична концепции шины, используемой в архитектуре компьютерного оборудования, в сочетании с модульной и параллельной архитектурой высокопроизводительных компьютерных операционных систем. Мотивацией для разработки данной архитектуры было создание стандартного, структурированного и универсального подхода к описанию реализации слабосвязанных программных компонентов (называемых сервисами), которые должны быть развёрнуты независимо, функционировать в гетерогенной и распределённой сетевой среде. ESB также является распространенным шаблоном реализации сервисно-ориентированной архитектуры, включая изначально принятую сетевую структуру Всемирной паутины. Глобальных стандартов для корпоративных сервисных шин или их реализации не существует. Большинство поставщиков промежуточного программного обеспечения, ориентированного на обмен сообщениями, приняли концепцию корпоративной сервисной шины как де-факто стандарт для сервисно-ориентированной архитектуры. Реализации ESB используют промежуточное программное обеспечение, ориентированное на события и стандарты, в сочетании с очередями сообщений в качестве технологической основы. Однако некоторые производители программного обеспечения переименовывают существующие решения для промежуточного программного обеспечения и коммуникаций как ESB, не реализуя ключевой аспект концепции шины.

ESB как программное обеспечение

ESB реализуется в программном обеспечении, которое функционирует между бизнес-приложениями и обеспечивает их взаимодействие. В идеале, ESB должен заменить все прямые обращения к приложениям, подключенным к шине, чтобы вся коммуникация осуществлялась через ESB. Для достижения этой цели ESB должен эффективно инкапсулировать функциональность, предоставляемую его компонентами. Обычно это достигается посредством использования корпоративной модели обмена сообщениями. Модель обмена сообщениями определяет стандартный набор сообщений, которые ESB передает и принимает. Когда ESB получает сообщение, он направляет его в соответствующее приложение. Зачастую, поскольку данное приложение разрабатывалось без использования той же модели обмена сообщениями, ESB должен преобразовать сообщение в формат, который приложение может интерпретировать. Программный адаптер выполняет задачу этих преобразований, аналогично физическому адаптеру. ESB опираются на точное построение корпоративной модели обмена сообщениями и правильное проектирование функциональности, предоставляемой приложениями. Если модель обмена сообщениями не полностью охватывает функциональность приложения, другие приложения, которым требуется эта функциональность, могут быть вынуждены обходить шину и обращаться непосредственно к несовместимым приложениям. Это нарушает принципы модели ESB и сводит на нет многие преимущества использования данной архитектуры. Преимущество ESB заключается в его платформенно-независимом характере и способности интегрироваться с любыми системами в любых условиях. Важно, чтобы поставщики решений для управления жизненным циклом приложений в полной мере использовали все возможности ESB в своих интеграционных продуктах при внедрении SOA. Следовательно, перед поставщиками EAI стоят задачи и открываются возможности по предоставлению интеграционного решения, которое было бы недорогим, легко настраиваемым, интуитивно понятным, удобным для пользователя и открытым для любых инструментов, выбираемых клиентами.

Характеристики

Категория Функции Поддержка вызова синхронных и асинхронных транспортных протоколов, сопоставление сервисов (поиск и привязка) Адресуемость маршрутизации, статическая/детерминированная маршрутизация, маршрутизация на основе содержимого, маршрутизация на основе правил, маршрутизация на основе политик Медиационные адаптеры, преобразование протоколов, сопоставление сервисов Обработка сообщений, преобразование сообщений и расширение сообщений Хореография процессов¹ реализация сложных бизнес-процессов Оркестрация сервисов² координация нескольких сервисов реализации, представленных как единый агрегированный сервис Обработка событий, интерпретация событий, корреляция, сопоставление с образцами Другое качество обслуживания безопасность (шифрование и подпись), надежная доставка, управление транзакциями Управление мониторинг, аудит, журналирование, измерение, административная консоль, BAM (BAM не является функцией управления, то есть ESB не реагирует на конкретный порог. Это возможность бизнес-сервиса, предоставляемая конечным пользователям.) Агностицизм общий агностицизм к операционным системам и языкам программирования; например, обеспечение взаимодействия между приложениями Java и .NET Преобразование протоколов всесторонняя поддержка актуальных протоколов связи стандарты сервисов Шаблоны обмена сообщениями поддержка различных шаблонов обмена сообщениями (MEP) (например: синхронный запрос/ответ, асинхронный запрос/ответ, отправка и забыть, публикация/подписка) Адаптеры адаптеры для поддержки интеграции с устаревшими системами, возможно, на основе стандартов, таких как JCA Безопасность стандартизированная модель безопасности для авторизации, аутентификации и аудита использования ESB Преобразование содействие преобразованию форматов и значений данных, включая сервисы преобразования (часто с использованием XSLT или XQuery) между форматами отправляющего и принимающего приложений Валидация проверка сообщений на соответствие схемам для отправки и получения Управление возможность применения бизнес-правил единообразно Обогащение обогащение сообщений данными из других источников Разделение и объединение разделение и объединение нескольких сообщений и обработка исключений Абстракция предоставление унифицированной абстракции через несколько уровней Маршрутизация и преобразование условная маршрутизация или преобразование сообщений на основе политики, не требующей централизованного механизма правил (без необходимости в центральном движке правил) Общие сервисы предоставление общеиспользуемых функций в качестве общих сервисов в зависимости от контекста

¹ Некоторые не считают хореографию процессов функцией ESB. Например, см. M. Richards. ² В то время как хореография процессов поддерживает реализацию сложных бизнес-процессов, требующих координации нескольких бизнес-сервисов (обычно с использованием BPEL), оркестрация сервисов позволяет координировать несколько сервисов реализации (наиболее подходящим образом представленных в виде агрегированного сервиса) для обслуживания отдельных запросов. Эти решения часто ориентированы на функции ESB низкого уровня, такие как подключение, маршрутизация и преобразование, и требуют кодирования или написания сценариев для реализации оркестрации. Разработчики, работающие на проектном или тактическом уровне, например, просто пытаясь решить проблему, часто отдают предпочтение легковесным технологиям шины обслуживания, но часто существует напряженность между этими инициативами и корпоративной архитектурой, целью которой является оптимизация инфраструктуры в нескольких проектах. Если брокер сообщений, программное обеспечение ESB, преобразует сообщение из одного формата в другой, то, как и в случае любого перевода, возникает вопрос семантики сообщения. Например, запись может быть преобразована из JSON в XML, но один и тот же набор полей может быть интерпретирован по-разному различными приложениями, особенно в случае различных краевых случаев, которые обычно известны только разработчикам, имеющим большой опыт работы с приложением, подключенным к ESB. Для известных краевых случаев количество тестов, охватывающих все краевые случаи, экспоненциально увеличивается с каждым приложением, подключенным к ESB, поскольку каждое приложение, подключенное к ESB, должно быть протестировано с каждым другим приложением, подключенным к ESB.