Содержание


Архитектура на практике

Часть 5. Сценарий SOA № 2: Варианты подключения сервисов

Comments

Серия контента:

Этот контент является частью # из серии # статей: Архитектура на практике

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Архитектура на практике

Следите за выходом новых статей этой серии.

Первая статья серии Архитектура на практикеРеализация Сервис-ориентированной архитектуры была посвящена платформе Service-Oriented Architecture (SOA) Foundation Lifecycle (или SOA Lifecycle) от компании IBM и тому, как она предоставляет клиентам IBM возможность применять концепции жизненного цикла разработки ПО к построению SOA. Были подробно рассмотрены четыре фазы в IBM SOA Lifecycle — моделирование, сборка, развертывание и управление.

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

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

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

Решение бизнес-задач

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

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

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

Сценарий Service Connectivity

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

  • Части 2 нашей серии статей, в которой описан процесс использования SOA-сценариев. Очень важная часть этого процесса - критерии выбора. В таблице 1 части 2 даны два общих случая использования, которые подходят для сценария Service Connectivity. Первый шаг в каждом из четырех случаев - разметка функциональных требований для данной реализации проблемной области.
  • Разработанных реализациях, показывающих, как этот сценарий можно реализовать с помощью выбранных продуктов. Реализации сочетают клиентский сценарий с соответствующими решениями. Имеются готовые типичные реализации, которые помогут клиентам быстро приступить к построению SOA.

В следующем разделе мы покажем реализации для типовых вариантов использования.

Четыре распространенные реализации

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

Безопасное подключение к внешней третьей стороне и к торговым партнерам

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

ESB-шлюз можно использовать автономно, если единственное требование - безопасный доступ к ресурсам. ESB-шлюз может выполнять двойную функцию, предоставляя также базовые функции посредничества и маршрутизации в зависимости от требований к промежуточному ПО и интеграции. В этих случаях рекомендуется использовать IBM Datapower XML Security Gateway XS40 (дальше мы будем называть это устройство Datapower). Datapower – это аппаратное устройство, реализующее следующие функции: XML-трансформацию, канал безопасного доступа для вызова сервисов предприятия и базовые возможности посреднических потоков. Эти устройства предназначены в первую очередь для применения в качестве сетевых прокси-серверов с поддержкой сообщений (message-aware network proxies) для трафика Web-сервисов. Эти устройства обладают огромной производительностью при обработке XML-сообщений. Они также служат пунктами управления сообщениями в архитектуре безопасности приложения.

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

Рисунок 1. Жизненный цикл SOA применительно к подключению сервиса на основе интеграции со сторонним партнером
Жизненный цикл SOA применительно к подключению сервиса на основе интеграции со сторонним партнером
Жизненный цикл SOA применительно к подключению сервиса на основе интеграции со сторонним партнером

В таблице 1 приведены действия для данного варианта использования для каждой фазы жизненного цикла SOA.

Таблица 1. Подключение сервисов при интеграции стороннего партнера
ФазаДействия
Моделирование В действиях высокого уровня в этой фазе нет ничего особенного; они в основном обеспечивают понимание и документирование того, как сервисы третьих сторон влияют на стратегию вашего предприятия, на распределение ролей и на показатели производительности.
СборкаС помощью инструментария IBM Datapower Toolkit на Datapower настраивают простой XML-брандмауэр. К числу важных конфигурационных настроек относятся декодирование и кодирование запросов и ответов, а также определение связанных с этим правил.
РазвертываниеКонфигурационные настройки, заданные в инструментарии Datapower, развертывают на устройстве Datapower. Устройство действует как ESB-шлюз и создает основу для бесперебойной и безопасной интеграции внешних сервисов с бизнес-процессами предприятия.
Управление Сервисы, проходящие через сети предприятия, подвергают мониторингу на предмет безопасности, производительности и доступности. Рекомендуем для этой цели IBM Tivoli® Composite Application Manager (ITCAM) для SOA. Datapower идеально интегрируется с ITCAM и производит мониторинг вызовов сервисов и потоков по всему периметру предприятия.

Если требуется повышенный уровень безопасности, не ограничивающийся защитой на уровне сообщений, которую обеспечивает Datapower, можно использовать IBM Tivoli Access Manager (ITAM). Он отлично интегрируется с Datapower и повышает безопасность. Если в инфраструктуре уже имеется реализация механизма безопасности (например, ITAM), не обязательно конфигурировать Datapower для проверки безопасности сообщений, можно оставить для него только ускоренную обработку XML.

Подключение внутренних бизнес-систем, основанное на открытых стандартах

Иногда интересы бизнеса и ИТ требуют применения технологий, основанных на стандартах, для организации связи между разными типами сервисов, поддерживающих бизнес-процессы на базе инфраструктуры промежуточного ПО на основе WebSphere® Application Server. Если предприятию нужно обслуживать много клиентов, использующих различные механизмы вызова сервисов на основе стандартов, мы рекомендуем использовать IBM WebSphere ESB.

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

На рисунке 2 показаны высокоуровневые шаги по реализации жизненного цикла SOA.

Рисунок 2. Жизненный цикл SOA и шаги по подключению сервисов на основе открытых стандартов
Жизненный цикл SOA и шаги по подключению сервисов на основе открытых стандартов
Жизненный цикл SOA и шаги по подключению сервисов на основе открытых стандартов

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

В таблице 2 показаны действия для данного варианта использования в каждой из фаз жизненного цикла SOA.

Таблица 2. Действия при подключении внутренних бизнес-систем на основе открытых стандартов
ФазаДействия
МоделированиеВ центре внимания - идентификация и документирование бизнес-каналов, которые используют сервис-провайдеры для получения доступа к процессам. Производится имитационное моделирование бизнес-процессов, собранные при этом данные метрик используются для разработки бизнес-плана автоматизации и модернизации бизнес-процессов с использованием подключения на основе стандартов для сервисов, реализующих эти процессы.
Сборка Выполняется проектирование и реализация посреднических потоков, которые выполняют маршрутизацию и трансформацию сообщений. Для построения посреднических механизмов и потоков WebSphere ESB рекомендуется инструмент IBM WebSphere Integration Developer. Посреднические потоки применяются для обработки входящих сообщений, ведения журналов для целей аудита и декомпозиции сообщений, если это необходимо перед направлением их к адресату. См. дополнительную информацию в разделе Ресурсы.
РазвертываниеПосреднические потоки, собранные и скомпонованные в WebSphere Integration Developer, развертывают на платформе выполнения WebSphere ESB. WebSphere ESB располагается поверх WebSphere Application Server и наследует все его стандартные и расширенные механизмы безопасности, производительности, кластеризации и отказоустойчивости. WebSphere ESB предоставляет:
  • Транспортные протоколы на основе открытых стандартов, необходимые для поддержки различных бизнес-каналов при выполнении клиентских запросов.
  • Платформу выполнения промежуточного ПО, на которой работают механизмы медиации, выполняющие интеллектуальную трансформацию и маршрутизацию сообщений.
Рекомендуем WebSphere ESB в качестве ведомственного или внутрисетевовго ESB. Безопасность и сервис сообщений обычно не являются прерогативой при разрешении подключения приложений и систем.
УправлениеМеханизмам медиации, развернутым в WebSphere ESB, требуется управление и мониторинг на соответствие конкретным соглашениям об уровне сервиса (SLA). В качестве инфраструктуры для управления и отслеживания механизмов медиации WebSphere ESB -- рекомендуется ITCAM для SOA.

ПО ITCAM для SOA предоставляет полное административное решение для предприятий, которые развертывают SOA-приложения на основе Web-сервисов. Оно позволяет обнаруживать, отслеживать, диагностировать и управлять Web-сервисами, использующими открытые стандарты, например, SOAP/HTTP или SOAP/JMS. Оно помогает выявлять и решать проблемы развернутых сервисов.

Доступ к имеющимся бизнес-процессам по новым бизнес-каналам

Одним из важных принципов SOA-экосистемы является бесперебойная и прозрачная связь потребителей сервиса с сервис-провайдерами. Разнотипность типичных сред бизнеса и ИТ создает определенные трудности при интеграции потребителей и провайдеров. Форматы сообщений потребителя могут быть:

  • нестандартными
  • разными у разных клиентов
  • слишком крупномодульными и требующими декомпозиции

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

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

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

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

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

Для этого сценария нам идеально подойдет продвинутая ESB, выполняющая как минимум следующие функции:

  • Преобразования между протоколами коммуникации
  • Преобразование разнородных форматов данных в каноническую модель сообщений с возможностью медиации
  • Маршрутизация запросов сервисjd соответствующим сервис-провайдерам
  • Компоновка сервисов для выполнения запроса сервисов
  • Управление транзакциями
  • Магистраль обмена сообщениями

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

Рисунок 3. Шаги жизненного цикла SOA при распространении бизнес-процессов на несколько каналов
Шаги жизненного цикла SOA при распространении бизнес-процессов на несколько каналов
Шаги жизненного цикла SOA при распространении бизнес-процессов на несколько каналов

В таблице 3 приведены действия для данного варианта использования в каждой из фаз жизненного цикла SOA.

Таблица 3. Действия для предоставления доступа к имеющимся бизнес-процессов по новым бизнес-каналам
ФазаДействия
МоделированиеВыполняется глубинный анализ бизнес-процессов, которые выходят за рамки вашей организации. Сервисы, которые вы используете в нескольких бизнес-процессах, в зависимости от контекста, возможно, должны поддерживать различные бизнес-каналы для взаимодействия с потребителями сервисов. Необходима поддержка всех протоколов и форматов сообщений, которые используют потребители сервисов. Требования и результаты, полученные в этой фазе, помогают получить более объективное представление о продвинутых функциях, которые могут потребоваться от ESB.
СборкаПроизводится проектирование и сборка оркестровки сервисов и связанных с ними потоков сообщений. Для этого рекомендуется инструментарий WebSphere Message Broker Toolkit, который представляет собой плагин Eclipse на основе IBM Rational Application Developer. Этот инструмент помогает в разработке потоков сообщений наборов сообщений, а также предоставляет брокер сообщений и компоненты времени исполнения (группы исполнения и развернутые внутри них потоки сообщений). Это ускоряет и облегчает разработку потоков сообщений. Усовершенствованная поддержка Web-сервисов, в том числе генерирование и использование WSDL, создает систему оркестровки сервисов на основе стандартов.
Развертывание Используюется по меньшей мере три продукта. Брокер сообщений Message Broker - в качестве ESB, поддерживащей, наряду с другими возможностями, мощные средства медиации; при этом WebSphere MQ отличного справляется с ролью персистентной магистрали сообщений. При наличии множества унаследованных систем технология WebSphere Adapter обеспечивает подключение Message Broker к разнообразным унаследованным приложениям.

Инфраструктура WebSphere Adapter содержит более ста адаптеров и обеспечивает подключение и интеграцию практически с любым производителем и готовыми пакетами.

УправлениеITAM предоставляет централизованное, гибкое и масштабируемое решению по управлению доступом пользователей к защищенной информации и ресурсам. Для распространения прав доступа между защищенными областями используется Tivoli Federated Identity Manager (TFIM).

Если Message Broker и WebSphere MQ служат инфраструктурой для ESB, IBM Tivoli OMEGAMON XE для WebSphere Business Integration рекомендуется для управления и мониторинга инфраструктуры ESB. Omegamon улучшает доступность Message Broker и WebSphere MQ, осуществляет профилактику проблем и упрощает управление благодаря применению единого инструмента. Это ПО также предлагает инструмент с Web-поддержкой, который сообщает в режиме реального времени о доступности и производительности управляемых им ресурсов.

Адаптация сторонних систем для Web-сервисов

Использование открытых стандартов, например, SOAP/HTTP и JMS, становится все более распространенным требованием в компаниях, но на большинстве предприятий все еще имеется достаточное количество ИТ-решений на основе унаследованных приложений и систем. Фундаментальный принцип SOA - раскрывать бизнес-ценность имеющихся старых и сторонних приложений, систем и технологий, адаптируя их к открытым стандартам посредством технологии Web-сервисов.

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

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

  • Адаптеры WebSphere Business Integration (WBI) позволяют гетерогенным бизнес-приложениям (ERP-, кадровым, CRM-системам, системам управления цепочками поставок) координированно обмениваться данными через бизнес-объекты..
  • Адаптер WebSphere JCA предоставляет механизм хранения и получения данных о предприятии в J2EE™. Он поддерживает подключение систем предприятия к JDBC, неформатированным файлам и таким системам, как SAP, PeopleSoft и Siebel.

Использование адаптеров WBI и WebSphere JCA предполагает следующее:

  • У клиента имеется инфраструктура WebSphere Application Server либо планируется ее установка.
  • Нет сложных стратегий безопасности, например, WS-Security.
  • Нет многочисленных требований по синхронизации данных между клиентом и корпоративными информационными системами.
  • Объем запросов - умеренный.

Выбор адаптеров WBI или WebSphere JCA – это архитектурное решение, которое принимают исходя из специфики клиентских требований и имеющихся сторонних систем. В число WebSphere-адаптеров входят:

  • IBM WebSphere Adapter для неформатированных файлов (Flat Files), Version 6.0
  • IBM WebSphere Adapter для JDBC, Version 6.0
  • IBM WebSphere Adapter для PeopleSoft Enterprise, Version 6.0
  • IBM WebSphere Adapter для бизнес-приложений Siebel, Version 6.0
  • IBM WebSphere Adapter для SAP-приложений, Version 6.0

В таблице 4 показаны действия при адаптации сторонних систем для Web-сервисов по фазам жизненного цикла SOA.

Таблица 4. Жизненный цикл SOA и действия по адаптации сторонних систем для Web-сервисов
ФазаДействия
МоделированиеПри отображении действий в этом варианте подключения сервисов ничего особенного не требуется
СборкаПри создании возможностей медиации при работе с WebSphere ESB используют инструмент для разработки и сборки WebSphere Integration Developer. Посреднические (медиационные) функции в такой реализации включают возможности поиска в масштабах предприятия, которые нужны для внедрения адаптеров WebSphere BI или JCA в посреднические приложения.
Развертывание Используются WebSphere ESB и адаптеры WebSphere Adapters. WebSphere Adapters предоставляют адаптеры для корпоративных информационных систем, нужные для подключения к серверным и сторонним системам. WebSphere ESB обеспечивает возможности медиации при выполнении XSLT-трансформации данных и содержит функцию протоколирования сообщений по мере их прохождения через медиацию.
Управление ITCAM для SOA рекомендуется в качестве компонента инфраструктуры для мониторинга и управления трафиком между вызовами Web-сервисов. Требуется интегрированное (federated) решение по управлению идентификацией для контроля количества удостоверений на разных уровнях архитектуры - особенно между уровнем бизнес-логики и EIS-системами. Рекомендуем IBM TFIM в качестве решения по управлению идентификацией и по доступу к ресурсам, которые располагаются в различных доменах безопасности.

Обзор типов медиации

Медиациями в контексте соединения сервисов в SOA называют:

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

Среда выполнения WebSphere ESB может выполнять медиацию сообщений. Технология для задания медиации сообщений основана на Service Component Architecture (SCA). Базовой единицей в развертывании медиации сообщений является посреднический (медиационный) модуль. Он содержит компоненты посреднических потоков, которые обрабатывают запросы и ответы сообщений. В готовом пакете посреднического модуля содержится по крайней мере один экспорт (определяющий интерфейс, через который клиенты сервиса вызывают медиацию) и один импорт (определяющий подключение к сервис-провайдеру). Все посреднические потоки им модули проектируют и компонуют в пакеты с помощью редактора посреднических потоков в WebSphere Integration Developer.

Медиации разрабатывают на основе четырех распространенных шаблонов:

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

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

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

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

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

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

Выбор ESB

Мы говорили о трех ESB-продуктах: WebSphere DataPower Appliance, WebSphere ESB и WebSphere Message Broker. В этом разделе мы даем рекомендации по выбору продукта, отвечающего вашим требованиям по ESB.

WebSphere DataPower Appliances -- – это набор из трех аппаратных устройств для SOA-решений, выводящих на новый уровень возможности ПО промежуточного уровня. Эти специализированные клиентские устройства расширяют возможности SOA Foundation, обеспечивая высокую производительность и надежность. Такие устройства можно использовать на периметре предприятия для ускорения обработки XML (до уровня скорости передачи) и повышения безопасности при обработке данных SOA (защита XML-уровня, обработка структурированных данных). Они также предоставляют базовые возможности медиации и прозрачно интегрируюется в инфраструктуру безопасности на основе IBM TFIM, Access Manager и т.д. Мы рекомендуем использовать устройства WebSphere DataPower Appliances, если вам нужен ESB-шлюз, способный осуществлять базовую медиацию сообщений.

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

WebSphere Message Broker - наиболее продвинутое ESB-решение из пакета продуктов WebSphere. Оно предоставляет универсальное (любой с любым) подключение как для основанных на стандартах, так и для прочих технологий и приложений. Message Broker также поддерживает трансформацию любых сообщений и данных для реализации SOA-решений даже в самых сложных и гетерогенных средах. Этот продукт обеспечивает обработку транзакций, почти универсальное подключение по различным транспортам (в том числе WebSphere MQ, JMS и HTTP), а также обеспечивает беспрецедентную надежность и производительность. Он поддерживает расширенный диапазон преобразований и функций медиации, а также интеграцию ресурсов как с поддержкой Web-сервисов, так и без нее. Если необходимы высокая пропускная способность и качество сервиса, Message Broker значительно предпочтительнее, чем WebSphere ESB.

Совместная работа нескольких ESB-продуктов

Устройство WebSphere DataPower может сочетаться как с WebSphere ESB, так и с Message Broker. На рисунке 4 показано, как можно совместно использовать различные ESB-продукты.

Рисунок 4. Совместная работа различных ESB-продуктов
Совместная работа esb-продуктов
Совместная работа esb-продуктов

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

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

DataPower может быть эффективным дополнением к решениям на основе Message Broker, как и к решениям на основе WebSphere ESB. Поскольку Message Broker - самый продвинутый ESB-продукт в портфеле решений WebSphere, он также позволяет придать больше возможностей решениям на базе устройств DataPower, чем WebSphere ESB. Помимо прочего, Message Broker предоставляет более широкую поддержку протоколов (поддержка любых сторонних JMS 1.1, телеметрия, интеграция устройств); тесную интеграцию с системами обработки транзакций IBM, например, с CICS и IMS; усовершенствованную обработку сообщений и сложных действий; продвинутые сервисы планировщика и оповещений; а также среду программирования общего назначения (Java, ESQL, C и т.п.) для реализации любой программной логики.

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

Заключение

Корпорация IBM выделила восемь различных SOA-сценариев, наиболее часто встречающихся в типичных ИТ-проектах на основе SOA. Чтобы помочь клиентам начать работу с SOA, IBM предлагает точки входа и сценарии SOA, ориентированные на задачи бизнеса и ИТ, а также предоставляет подробные рекомендации по моделированию, проектированию и реализации каждого сценария с помощью инструментов, продуктов и методик IBM.

Из этой статьи вы узнали о втором SOA-сценарии - подключении сервисов. Сценарий Service Connectivity является реализацией точки входа «Подключение». Эта точка входа позволяет осуществить эффективное подключение вашей инфраструктуры, интегрировать всех специалистов, процессы и информацию в рамках компании. Используя гибкие SOA-подключения между сервисами и в рамках всей вашей среды, вы можете без труда взять имеющийся бизнес-процесс и доставить его по другому бизнес-каналу. Можно также безопасно подключаться к внешним партнерам за пределами вашего брандмауэра. Наконец, можно с помощью технологии Web-сервисов адаптировать унаследованные и сторонние приложения для раскрытия их бизнес-ценности и их многократного использования.

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=659655
ArticleTitle=Архитектура на практике: Часть 5. Сценарий SOA № 2: Варианты подключения сервисов
publish-date=05182011