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

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

• общий шаблон интеграционного архитектурного решения
• тип взаимодействия, применяемый к конечным точкам процесса
• эксплуатационные аспекты
• выбор модели безопасности

Все это вместе и определяет в итоге шаблоны организации взаимодействия.

В этой статье представлен набор шаблонов проектирования, часто встречающихся в интеграционных решениях на основе семейства WebSphere Enterprise Service Bus: WebSphere Message Broker, WebSphere ESB и WebSphere DataPower Integration Appliance XI50. Детальное описание этих шаблонов, особенности реализации и примеры активно дополняются; подробную актуальную информацию можно найти в ассоциированной с developerWorks википедии Enterprise Connectivity Patterns.

>

С точки зрения общей архитектуры интеграции можно выделить следующие 6 категорий шаблонов интеграции:

• Виртуализация сервиса
• Поддержка сервиса
• Шлюз
• Интеграция на основе обмена сообщениями
• Обработка файлов
• Событийно-ориентированная интеграция

Ниже каждая из перечисленных категорий рассматривается подробно.

>

Шаблоны виртуализации сервиса описывают, каким образом можно организовать гибкое взаимодействие между сервисами, используя дополнительные уровни абстракции в Enterprise Service Bus. С другой стороны, эти шаблоны также направлены на выполнение требований интеграции сервисов (маршрутизация, конвертирование протоколов, преобразование данных, журналирование и т.д.), если в сервис-ориентированной архитектуре требуется адресное взаимодействие.

Шаблоны виртуализации сервиса инкапсулируют определение шины сервисов и обычно используются для выполнения определенных требования, включая:

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

Некоторые примеры таких шаблонов приведены ниже.

• Простой сервис-посредник

  Использование сервиса-посредника - один из фундаментальных шаблонов ESB, поддерживающий гибкое связывание, требуемое в большинстве сервис-ориентированных архитектур. Этот шаблон развертывает на ESB на основе уже существующего сервиса новый виртуальный сервис, обращение к которому происходит через контролируемую точку, и, возможно, через другой протокол обмена, чем в исходном сервисе. Тем самым вводится точка посредничества, в этом простейшем из шаблонов ESB зачастую ограниченная различного рода настройками безопасности и журналированием. Однако представление ESB в виде точки посредничества также позволяет реализовать управления сервисом, например, обработку ошибок и предупреждений, управление трафиком, контроль загрузки сервиса и измерения производительности. На этом базовом шаблоне основаны многие другие шаблоны.

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

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

• Селектор сервисов (Маршрутизатор)

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

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

• Сервис-транслятор

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

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

• Сервис-нормализатор

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

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

• Селектор версии

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

>

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

Важные примеры шаблонов данной категории:

• Простой сервис-фасад

  В своей простейшей форме шаблон "Простой сервис-фасад" близок к «Сервису-посреднику», но запрос к сервису выполняется не провайдером сервиса, а существующим унаследованным приложением, к которому обращаются посредством обмена сообщениями, через адаптер или другие API. Адаптеры могут располагаться внутри самого приложения, но в типичном случае они реализуются в виде компонентов ESB.

  В данном шаблоне также может использоваться маршрутизация, преобразование и нормализация, как при виртуализации сервисов.

• Сложный сервис-фасад

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

  Интеграционная логика может быть построена множеством различных способов, наиболее типичные - последовательность вызовов, обработка нескольких запросов с агрегацией ответов или распределение информационных потоков.

• Клиентский доступ

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

>

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

Пограничные функции обычно определяют необходимое действие по данным из стандартных заголовков (транспортных, SOAP или других уровней), но не требуют полного разбора данных сообщения или его тела. Шаблон шлюза может далее вызвать напрямую сервис или какой-то иной шаблон. Типичные пограничные функции:

• маршрутизация запроса
• аутентификация
• авторизация
• журналирование и аудит
• преобразование протоколов
• коррелирование откликов

Примеры шаблонов шлюза:

• Шлюз безопасности

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

• Коннектор сервисов

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

• Граничный посредник

  Шаблон "Граничный посредник" расширяет шаблон "Коннектор сервисов", добавляя стандартные взаимодействия, которые могут применяться ко всем входящим (и/или исходящим) запросам или сообщениям. Эти стандартные и не зависящие от содержания взаимодействия разрабатываются для шлюза один раз и могут использоваться для всех входящих сообщений. Эти взаимодействия могут включать любое (или даже все) из нижеперечисленных: валидацию, журналирование, аудит, аутентификацию и авторизацию. Они могут применяться универсально или выборочно, в зависимости от настроек шлюза или данных запроса/сообщения (обычно из заголовков).

>

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

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

Ключевые примеры шаблонов данной категории включают:

• Маршрутизатор сообщений

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

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

  
  
• Транслятор сообщений

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

  
  
• Мост сообщений

  Шаблон "Мост сообщений" отображает данные из одного транспортного механизма в другой, без изменений формата или содержимого сообщений. Реализация данного шаблона должна также пересылать сообщения между разными схемами адресации, которые могут использоваться в отдельных системах пересылки сообщений.

  Частым примером этого шаблона является мост между реализациями JMS от различных поставщиков.

  
  
• Компоновщик сообщений

  Шаблон "Компоновщик сообщений" предназначен для сбора нескольких сообщений от одного или нескольких приложений в единое сообщение и передачи этого скомпонованного единого сообщения целевому приложению. Входящие сообщения могут быть получены из нескольких независимых приложений-отправителей либо быть ответными асинхронными сообщениями, полученными от нескольких приложений, совместно обработавших запрос, разделенный с помощью шаблона "Разделитель сообщений" (описывается ниже).

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

  
  
• Разделитель сообщений

  Шаблон "Разделитель сообщений" формирует последовательность сообщений из единого сообщения приложения-отправителя. Далее сформированный набор сообщений отправляется для обработки нескольким приложениям-обработчикам. Набор правил определяет, каким образом первоначальное входящее сообщение необходимо разделить на составляющие для создания набора сообщений.

  
  
• Коррелятор запросов/ответов

  Типичная система брокера сообщений часто обрабатывает несколько запросов из потока или очереди в параллельном асинхронном режиме. Когда такие сообщения пересылаются в другую систему (или системы), могут возникать требования соблюдения последовательности ответных сообщений обработчика в соответствии с последовательностью исходных сообщений-запросов. Коррелятор запросов/ответов решает эту проблему.

  
  

>

ESB может предоставлять управляемую среду для обработки и исполнения файлов (как локальных, так и получаемых по протоколу FTP).

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

• Обработчик записей файла

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

  
  
• Группировщик записей

  Шаблон "Группировщик записей" получает данные в виде запросов сервиса, сообщений или через адаптер, обрабатывает их и создает записи по временных файлах, которые после обработки передаются целевой системе. Тем самым он поддерживает взаимодействие между новыми сервис-ориентированными системами и унаследованными системами, которые используют интерфейс пакетной обработки. Этот шаблон может быть первым шагом к преобразованию инфраструктуры предприятия в сервис-ориентированную или может служить для интеграции полученного в результате корпоративного слияния приложения с интерфейсом пакетной обработки в транзакционную среду. Кроме того, шаблон может быть использован для сбора в единый пакет данных для ночной обработки (например, счетов, договоров, контрактов, напоминаний для сотрудников компании).

  
  
• Распределитель записей файла

  Шаблон "Распределитель записей файла" разбивает файл на последовательность записей и использует каждую из сформированных записей для формирования запроса к сервису или для передачи сообщения к одной или нескольким целевым системам в транзакционном контексте. Обычно этот шаблон используется для обработки файлов электронного документообмена, содержащих несколько транзакций различных типов, которые маршрутизируются в разные системы и обрабатываются раздельно. Кроме того, его можно использовать для обновления справочных данных, особенно тех, время обновления которых не является критичным (например, если обновления должны вступить в силу только с определенного момента времени).

  
  

>

В данной статье рассматриваются шаблоны, ориентированные на взаимодействие посредством ESB. Статья не претендует полное рассмотрение шаблонов событийно-ориентированной архитектуры.

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

Примеры этого типа шаблонов:

• Маршрутизатор событий

  Шаблон "Маршрутизатор событий" поддерживает возможность распределения событий (с классификацией их по заголовкам и присоединенным данным) на множество получателей событий, зарегистрировавшихся с целью получения подмножеств публикуемых событий в зависимости от заголовка и содержимого. Данные публикуются в точке публикации ESB и распределяются из этой точки публикации всем подписчикам, зарегистрировавшимся для получения информации о событиях.

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

• Фильтр событий

  Шаблон "Фильтр событий" предоставляет возможность обработки событий (взаимодействий), путем добавления в ESB фильтра и преобразования общего потока событий в поток значимых событий, который далее перенаправляется в механизм обработки. Это может быть механизм обработки сообщений, распознающий сложные события, или система, отслеживающая бизнес-сообщения (например, приложение информационной панели). Шаблон поддерживает только однонаправленное взаимодействие и работает исключительно как препроцессор механизма обработки событий.

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

• Экстрактор событий

  Шаблон "Экстрактор событий" отслеживает взаимодействия приложений с ESB и обрабатывает их с целью выделения определенных событий и передачи их для обработки в механизм обработки сообщений. Этот шаблон также поддерживает только однонаправленное взаимодействие и работает исключительно как препроцессор механизма обработки событий.

• Реактор событий

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

>

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

• валидацию
• журналирование
• аудит
• обработку ошибок
• SLA (соглашения об уровне сервиса)/ показатели эффективности

Данные аспекты организации взаимодействия являются абстрактными и комбинируются с соответствующими интеграционными шаблонами в соответствии с потребностями архитектуры.

>

Шаблоны договорного поведения определяют типы взаимодействия и качество сервиса. Сейчас выделено восемь ключевых шаблонов взаимодействия:

• Однонаправленная гарантированная доставка
• Синхронный запрос на чтение
• Синхронный нетранзакционный запрос на изменение
• Синхронный запрос на изменение в контексте глобальной транзакции
• Синхронный запрос на изменение с уведомлением и обратным вызовом
• Синхронный запрос на изменение с уведомлением; провайдер услуги гарантирует выполнение действия
• Синхронный запрос на изменение с уведомлением; ошибки обрабатываются ESB
• Однонаправленный запрос с асинхронным обратным вызовом
• Однонаправленное взаимодействие с опросом о завершении

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

Отличие данного шаблона состоит в том, что все запросы гарантированно будут доставлены и обработаны.

• Все каналы связи устойчивы
• Каждый вызываемый компонент надлежащим образом извещает об ошибках
• Сообщения в случае системных ошибок сохраняются
• ESB не отказывает сообщению в обработке, а всегда пытается его обработать
• Ошибки фиксируют все содержимое сообщения
• Обработчик ошибок (вне области видимости ESB) исправляет ошибку
• SLA измеряется как пропускная способность (количество сообщений/запросов в единицу времени)

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

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

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

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

Назначение данного шаблона - предоставление механизма для обработки синхронных запросов на изменение данных для цепочки "сервис-клиент - ESB - сервис-провайдер".

• Все участники должны поддерживать протокол двухфазного подтверждения транзакции, например WS-AtomicTransaction
• Ошибка при завершении транзакции вызывает откат всех выполненных изменений во всех компонентах-участниках
• Используемые ресурсы блокируются до окончания транзакции
• Все участники транзакции должны подготовиться к откату изменений в установленный период времени
• SLA измеряется как время ответа, т.е. время, требующееся для завершения транзакции

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

• Приложение-отправитель запроса использует только синхронные протоколы/поведение
• Приложение-отправитель запроса формирует запрос на изменение и получает уведомление о том, что запрос был принят (или отклонен)
• ESB не отсылает извещения, пока сообщение не будет гарантированно принято
• ESB производит гарантированную доставку запроса на изменение провайдеру
• Сервис-провайдер поддерживает обратный вызов (асинхронный) с возвратом результата изменений
• Приложение-отправитель запроса может хранить список запросов на изменение, находящихся на стадии выполнения
• Брокер обязан гарантировать, что приложение-отправитель получит обратный вызов (если лимит времени ожидания превышен - брокер производит повторную отправку)
• Обработка ошибок может быть возложена на любого участника
• SLA измеряется как время получения извещения, а также как время выполнения запроса

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

• Приложение-отправитель запроса использует только синхронные протоколы/поведение
• Приложение-отправитель запроса формирует запрос на изменение и получает уведомление о том, что запрос был принят (или отклонен)
• ESB производит гарантированную доставку запроса на изменение провайдеру или вызывает обработку в случае ошибки
• Сервис-провайдер гарантирует, что либо изменение будет выполнено, либо будет вызван обработчик ошибок
• SLA измеряется как время получения извещения, а также время выполнения запроса

• Поведение такое же, как и в случае синхронного однонаправленного запроса, но сервис-провайдер может производить асинхронный обратный вызов отправителю запроса
• SLA измеряется как пропускная способность (количество сообщений/запросов в единицу времени)

• Все каналы связи устойчивы
• Все участники ожидают остальных поведения, соответствующего ожидаемому
• Каждый вызываемый компонент должен надлежащим образом отсылать извещения об ошибках обработчику ошибок
• Сообщения в случае системных ошибок сохраняются
• Приложение-отправитель запроса опрашивает провайдера, чтобы определить, что требуемые изменения были выполнены
• SLA измеряется как пропускная способность (количество сообщений/запросов в единицу времени)

>

При определении моделей безопасности и шаблонов необходимо учитывать два фактора:

• состав участников
• набор предопределенных политик безопасности

Участники должны совместно реализовывать функции безопасности в соответствии с требованиями к аутентификации, авторизации, аудиту, конфиденциальности, целостности и удобству использования без снижения производительности системы до неприемлемого уровня.

>

Любое основанное на сервисах взаимодействие включает следующих основных участников:

• Приложение или процесс, отправляющие запрос
• Посреднические сервисы: промежуточное ПО, предоставляющее функциональность сохранения целостности данных при пересылке между отправителями запросов и провайдерами сервисов-обработчиков; часто классифицируется как шина данных/ESB
• Приложение или сервис-провайдер, обрабатывающий запрос

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

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

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

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

• Брандмауэры и прокси-серверы
• Сетевые компоненты
• Реестр сервисов, если политики безопасности/профили хранятся с определениями сервисов в реестре

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

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

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

>

Важнейшие примеры шаблонов моделей доверительных отношений:

• Доверительные отношения между конечными участниками

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

  Данный сценарий часто используется, когда все компоненты являются внутренними и работают под единым управлением системы безопасности и базы пользователей. Рассматриваемая модель применяется для интеграции CRM-системы, выполняющей функции аутентификации и авторизации, с внутренними системами предприятия.

• ESB контролирует идентификацию приложений-отправителей запросов

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

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

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

• ESB контролирует права конечных получателей

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

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

• Доверительная аутентификация приложения-отправителя запроса

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

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

• Идентификация между конечными участниками, требуется обеспечение целостности и секретности передаваемых данных

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

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

• Публикация/подписка
  • управление правами доступа к функциональности
  • управление правами доступа к темам

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

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

>

Мы представили и описали ряд часто встречающихся шаблонов, обеспечивающих взаимодействие в инфраструктуре предприятия, построенной с использованием линейки продуктов IBM Enterprise Service Bus. Эти и относящиеся к ним шаблоны более подробно описаны в соответствующем вики-разделе developerWorks; там же приведены замечания по конкретным реализациям и примеры использования.

>

Идеи, представленные в данной статье, выросли из многочисленных дискуссий с множеством участников, но особенную благодарность хотелось бы выразить Робу Фиппену, Киму Кларку и Грегу Фларри, чьи отзывы и рекомендации были очень полезны при создании статьи.

Научиться

Получить продукты и технологии

• Загрузите ознакомительные версии продуктов IBM и создавайте приложения самостоятельно с помощью инструментов разработки и интеграционных продуктов DB2®, Lotus®, Rational®, Tivoli® и WebSphere®. (EN)
  
  

Обсудить

Хелен Уайли (Helen Wylie) - архитектор интеграционных решений группы разработки IBM WebSphere Messaging and ESB. Хелен активно работает с клиентами, использующими интеграционные решения на основе продуктов IBM WebSphere, в последнее время она также занимается формализацией шаблонов, воплощающих этот опыт в виде улучшений соответствующих продуктов IBM.

Питер Ламброс (Peter Lambros) - штатный старший технический сотрудник IBM, его область ответственности - выбор стратегии развития и архитектуры технологий интеграции приложений в продуктах ESB и сервисов сообщений линейки IBM WebSphere. Особый интерес для него представляют технологии преобразования сообщений, разработка шаблонов проектирования и в целом создание удобных инструментов разработки.

Спасибо. Эта запись была помечена для модератора.

>

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.

>

developerWorks: вход

>

При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

>

Вся введенная информация защищена.

SITE_ID=40

Zone=SOA и Web-сервисы, WebSphere

ArticleID=480109

ArticleTitle=Шаблоны взаимодействия приложений в корпоративных системах: Интеграционные решения с использованием продуктов IBM Enterprise Service Bus

publish-date=04022010