Содержание


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

Часть 4. Сценарий SOA №1: Варианты создания сервиса

Comments

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

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

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

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

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

Первая публикация в серии Архитектура ПО на практике, "Реализация сервис-ориентированной архитектуры" - была посвящена рассмотрению жизненного цикла IBM® SOA Foundation и тому, как он позволяет клиентам IBM подходить к SOA как к жизненному циклу разработки программного обеспечения. В ней были подробно описаны четыре этапа жизненного цикла SOA от IBM: моделирование, сборка, развертывание и управление.

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

Решение бизнес-проблемы

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

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

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

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

Шаблоны доступа к сценарию создания сервиса Service Creation

IBM выделяет три основных источника сервиса для SOA, как показано на рисунке 1.

Рисунок 1. Три источника сервисов
Три источника сервисов
Три источника сервисов

Существует четыре часто используемых архитектурных шаблона, описывающих использование сервисов из трех источников для создания ИТ-решения на основе сервисов. Рекомендуется сначала сравнить то, что вы имеете, с тем, что вам необходимо. Вы можете создать сервисы с нуля, купить их или обеспечить поддержку сервисов существующим коммерческим или собственным ПО. Вы можете использовать все три источника при помощи следующих подходов:

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

Перевод существующих ресурсов на сервисные принципы

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

Рисунок 2. Перевод существующих ресурсов на сервисные
Перевод существующих ресурсов на сервисные
Перевод существующих ресурсов на сервисные

В таком подходе отдельно взятый сервис может реализовать свою функцию, используя коммерческое или заказное приложение либо сразу несколько систем. Например, адресная запись в системе управления взаимодействием с клиентами SAP может быть объединена с функциями унаследованной автоматизированной системы бухгалтерского учета на базе мэйнфрейма в единый сервис для поддержки открытия нового лицевого счета. Комбинированный сервис может поддерживать часть бизнес-процесса обработки заказов клиентов – а именно, доставку и обработку счет-фактур. При этом снижается риск того, что окажетесь на пути размножения сервисов, когда любая существующая ИТ-функция будет рассматриваться как отдельный сервис и будет открыта для использования - независимо от степени ее детализации. Применяя соответствующие методологии SOA, такие как сервис-ориентированные моделирование и архитектура (Service-Oriented Modeling and Architecture, SOMA) от корпорации IBM (см. раздел Ресурсы), вы сможете решить проблемы детализации сервисов.

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

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

Например, можно непосредственно использовать технологию web-сервисов IBM CICS® Transaction Server V3.1 для представления приложений COMMAREA напрямую как web-сервисов. Минимальным требованием является соответствие представляемого сервиса основному профилю WS-I Basic Profile. (Дополнительная информация об архитектурных шаблонах и представлении существующих унаследованных функций как сервисов содержится в разделе Ресурсы.)

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

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

  • Пользователи сервиса привязываются к определениям унаследованных активов, которые, зачастую могут быть некачественно спроектированы изначально.
  • Этот шаблон предполагает, что существующая платформа приложения поддерживает современные технические средства для обращения к сервисам.
  • Такая реализация шаблона часто возлагает тяжелую нагрузку по обработке сервисов и сообщений на системы, которые традиционно оптимизировались для микропроцессоров без состояний задержки конвейера (MIPS).
Рисунок 3. Прямое представление существующих функций как сервисов
Прямое представление существующих функций как сервисов
Прямое представление существующих функций как сервисов
Непрямое представление функций как компонентов сервисов
Этот архитектурный шаблон перевода на сервисные принципы представляет ситуации, когда посреднический программный компонент, называемый сервисным компонентом, вводится между существующими функциями приложения и сервисом. На рисунке 4 показан пример такого шаблона.

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

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

Использование посреднического сервисного компонента имеет очевидные преимущества:

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

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

Рисунок 4. Сервисный компонент как посредник между функциями операционной системы и сервисов на прикладном уровне
Непрямое представление функций как компонентов сервисов
Непрямое представление функций как компонентов сервисов

Использование сервисов сторонних поставщиков

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

Рисунок 5. Использование сервисов сторонних поставщиков
Сторонние поставщики сервисов
Сторонние поставщики сервисов

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

Ниже приведены некоторые важные архитектурные аспекты, которые необходимо учитывать:

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

Построение сервиса "с нуля"

В данном сценарии сервис проектируют, определяют и разрабатывают с нуля. Ни существующие приложения, ни какие-либо сторонние поставщики сервисов не могут обеспечить функции или сервис, удовлетворяющие вашим требованиям. Сценарий базируется на сервере приложений платформы Java™ 2 J2EE, поддерживающем создание сервисов. Основные бизнес-функции обычно разрабатывают с использованием стандартногоJ2EE, как правило, в виде корпоративных JavaBeans (EJBs) или простых Plain Old Java Objects (POJO). Стандартными средствами интегрированной среды разработки (IDE) J2EE компоненты EJB и POJO преобразуют в основанные на стандартах Web-сервисы.

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

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

Рецепты определения и реализации сервисов

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

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

В этом разделе в контексте жизненного цикла SOA рассматриваются следующие архитектурные шаблоны и их высокоуровневые действия:

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

Представление существующих функций

Как и все проекты SOA, непосредственное представление существующих функций (преобразование в сервисы существующих ИТ-ресурсов) лучше всего рассматривать в контексте жизненного цикла. Здесь мы используем хорошо знакомый жизненный цикл сервиса в том виде, в каком он определен в IBM SOA Foundation. На рисунке 6 показано, как жизненный цикл SOA можно применить к преобразованию в сервисы существующих ресурсов.

Рисунок 6. Жизненный цикл SOA испприменительно к преобразованию в сервисы существующих ресурсов
Жизненный цикл SOA применительно к преобразованию в сервисы  существующих ресурсов
Жизненный цикл SOA применительно к преобразованию в сервисы существующих ресурсов

К преобразованию в сервисы применимы все фазы жизненного цикла SOA. Рекомендуются следующие действия высокого уровня:

Моделирование
На этапе моделирования проведите инвентаризацию ресурсов, имеющихся в текущих ИТ-приложениях и комплексе системв . На этом этапе самое важное - методология моделирования сервиса. Метод SOMA от IBM – эффективный и проверенный метод сервис-ориентированного моделирования. Rational® ® Unified Process (RUP) был также распространен на сервис-ориентированную методологию (RUP для SOA). RUP для SOA основан на методологии SOMA. Инструментарий IBM Rational Software Architect (RSA) предоставляет инфраструктуру моделирования для создания и разработки сервисных моделей.
Сборка
Используйте методы, позволяющие преобразовывать активы в сервисы многократного использования без изменения предоставляемых ими базовых бизнес-функций. Процесс преобразования по сути представляет собой заключение существующих функций в оболочку с четким, хорошо описанным интерфейсом.

На этом этапе наиболее часто используемым инструментальным средством для преобразования в сервисы CICS -приложений , традиционно работающих на системах IBM System z™ (ранее - системами IBM eServer™ zSeries®), является интегрированная среда разработки IBM WebSphere® Developer для zSeries (WDz). Существующий программный код, который необходимый оснастить поддержкой сервисов, импортируется в рабочую область WDz. Это инструментальное средство позволяет создавать определения на языке описания Web-сервисов (WSDL). Во время этого процесса над данными и языковыми структурами существующего приложения, возможно, придется выполнить некоторые преобразования и отображения. WSDL и конкретные привязки данных приложения можно сгенерировать прямо из интегрированной среды разработки.

Фаза сборки также включает в себя модульное тестирование разработанного кода. WDz имеет среду тестирования для сервера транзакций CICS (TS) со всеми базовыми функциями для тестирования WSDL, которое можно выполнять на реальном производственном сервере CICS. Сгенерированные WSDL-определения можно протестировать помодульно в тестирующей среде CICS TS на этапе сборки.

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

На этом этапе помодульно протестированные WSDL и сгенерированный исходный код COBOL (после возможного перевода данных и языка) развертываются на CTS. CTS 3.1 поддерживает множество функций, относящихся к Web-сервисам, в том числе WS-Security, настройку которой можно выполнить на фазе развертывания.

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

Линия продуктов Tivoli® корпорации IBM предназначена для мониторинга и управления системами в целом и включает широкий спектр продуктов, ориентированных на мониторинг и управление сервисами. Для управления и мониторинга CICS TS на IBM z/OS® обычно применяется Tivoli Omegamon-XE для CICS 3.1. Tivoli также включает набор продуктов, нацеленных на некоторые аспекты вызова и безопасности сервисов, например:

  • IBM Tivoli Federated Identity Manager (ITFIM), предоставляющий слабосвязанную интегрированную модель идентификации для управления идентификационной информацией в рамках компании и за ее пределами
  • IBM Tivoli Identity Manager (ITIM), для централизованного управления идентификационной информацией внутри компании
  • IBM Tivoli Access Manager (ITAM), для поддержки функций единой регистрации и авторизации
Управление и процессы
Обеспечьте соответствие сервисов политикам, стандартам и передовым методикам управления жизненным циклом сервиса, а также в эффективности их контроля и управления.

На этом этапе применяется WebSphere (WSRR), поддерживающий весь жизненный цикл SOA. WSRR позволяет поставщикам сервисов безопасно регистрировать бизнес-сервисы для их поиска и привязки потребителями. Он также позволяет публиковать метаданных, необходимые для управления жизненным циклом сервиса в SOA.

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

  • RSA для визуального моделирования и проектирования сервисов.
  • WebSphere Developer zSeries для сборки существующих функций в сервисы и их помодульного тестирования внутри среды тестирования CICS TS.
  • CICS TS 3.1 для развертывания определений сервисов и сгенерированого унаследованного кода.
  • Программные продукты Tivoli для управления и мониторинга, такие как Tivoli Omegamon-XE, ITFIM, ITAM и другие, в первую очередь для управления и мониторинга SLA сервисов.
  • WebSphere Service Registry and Repository для управления сервисами на протяжении всего их жизненного цикла в SOA.

Непрямое представление существующих функций.

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

Как мы объясняли в разделе Шаблоны доступа к сценарию создания сервиса Service Creation, основным отличием непрямого представления от непосредственного является добавление уровня сервисного компонента. Сервисный компонент предоставляет сервисные интерфейсы, отвечающие потребностям бизнеса – реализуя тем самым подход «сверху вниз». Анализируя существующие активы, вы можете получить представление о том, какие функции приложений и в каких системах можно будет использовать при реализации интерфейсов сервисов, определяемых сервисными компонентами. Сервисный компонент действует как посредник между точкой зрения бизнеса и существующими приложениями. Поэтому внедрение этого нового фасадного компонента требует ряда дополнительных шагов на этапе сборки.

Во время этапа моделирования вы можете использовать методологию SOMA и ее спецификации высокого уровня для идентификации сервиса. Это мало отличается от первого шаблона доступа. В обоих случаях вы выполняете этап идентификации сервиса (Service Identification) SOMA. Отличие, однако, заключается в том, на что делается акцент на этом этапе. При непосредственном представлении упор делается на анализ существующих средств и ресурсов. В сценарии непрямого представления внимание уделяется преимущественно идентификации ориентированных на бизнес сервисов с использованием нисходящего подхода. В качестве программного инструмента IBM здесь - рекомендует Rational Software Architect.

Во время фазы сборки наиболее часто используемым инструментом является Rational Application Developer (RAD). При использовании RAD в качестве интегрированной среды разработки на данном этапе следуйте приведенной ниже последовательности шагов:

  • Создайте проект Web или J2EE в рабочей области RAD, в идеале - новой. Опишите WSDL на основе бизнес-ориентированного представления о том, каким должны быть сам сервис и его интерфейс. Используйте входные данных фазы идентификации в SOMA для определения бизнес-ориентированных сервисов (бизнес-сервисов). Если WSDL уже определен и доступен, просто импортируйте его в рабочую область проекта в RAD.
  • Сгенерируйте структуру сессионного EJB из WSDL. Бизнес-логика всех операций теперь должна быть реализована. В случаях, когда унаследованная система выполняется в другом окружении, используйте технологии адаптеров на этапе реализации. Например, если приложение CICS выполняется на отдельной машине System z (zSeries), то необходимо использовать адаптер ресурсов CICS ECI для связи с системой CICS.

    Адаптер ресурсов, обычно в виде архивного файла ресурсов (.rar), импортируется в рабочую область RAD. Пакет адаптера ресурсов содержит прикладные программные интерфейсы (APIs) для упрощения доступа к приложению CICS из сессионных EJB. Также надо использовать подходящие способы привязки данных Java для конкретного языка, используемого в унаследованной системе.

  • Описания WSDL вместе с реализованными сессионными EJB, привязка данных Java и добавочные адаптеры ресурсов упаковываются в файл EAR для развертывания.

Хотя использование RAD на этапе сборки является достаточно распространенной практикой, многие ИТ-фирмы узко специализируются только на унаследованных системах. В таких клиентских средах рекомендуется использовать WebSphere Developer for z (WDz). WDz V6.0.1 имеет встроенную тестирующую среду CICS TS, которая в сочетании с CICS Transaction Gateway V6.0.2 предоставляет мощную инфраструктуру для представления сервисов из унаследованных систем.

Стандартным и рекомендуемым продуктом IBM для управления жизненным циклом сервисов является WebSphere Service Registry and Repository, о чем уже было сказано в предыдущем разделе.

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

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

Действия высокого уровня для данного сценария соотносятся с этапами жизненного цикла SOA, как показано на рисунке 7.

Рисунок 7. Включение сторонних сервисов в SOA компании
Жизненный цикл SOA во время разблокирования сервиса для сторонних сервисов
Жизненный цикл SOA во время разблокирования сервиса для сторонних сервисов

Все фазы жизненного цикла SOA можно соотнести с процессом реализации сервисов. Рекомендуемые действия высокого уровня вкратце сводятся к следующему:

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

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

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

На этапе сборки выполняется основная часть работы. Рекомендуется использование продукта IBM RAD. Выполните следующие шаги:

  1. Получите WSDL у поставщика сервиса.
  2. Проверьте WSDL и совместно с поставщиком доведите WSDL до успешной валидации.
  3. Создайте новый проект корпоративного приложения в RAD.
  4. Импортируйте WSDL в рабочую область проекта.
  5. Сгенерируйте клиентские заглушки из WSDL. На этом этапе тщательно проанализируйте, какой тип XML-привязки вам подходит (JAX-RPC, JAXB и т.д.)
  6. Разработайте клиентское приложение из клиентских заглушек для вызова сервиса.
  7. Упакуйте проект в развертываемый файл EAR.
Развертывание
Скомпонованные сервисы можно развернуть, не обращая внимания на происхождение каждого отдельно взятого сервиса.

На этом этапе развертываемый файл EAR устанавливается на совместимый с Web-сервисом сервер промежуточного ПО. Рекомендуемым продуктом IBM здесь является сервер приложений WebSphere (WebSphere Application Server). Установленный файл EAR предоставляет API- интерфейсы клиентской стороны для потребления сторонних сервисов.

Мониторинг
Если реализацией занимается поставщик сторонних сервисов , особенно важно проводить мониторинг сервисов для соблюдения диктуемых бизнесом SLA и ключевых показателей эффективности (KPI), предусмотренных контрактом. IBM Tivoli Composite Application Management (ITCAM) для SOA является наиболее полным продуктом Tivoli для мониторинга соответствия характеристик сервисов во время исполнения..
Управление и процессы
Создайте и поддерживайте каталог внешних сервисов в реестре для удобства доступа и управления.

На этом этапе развертываются определения WSDL для внешних сервисов. Рекомендуемый программный продукт IBM для этого этапа - WebSphere Service Registry and Repository (WSRR). Любые изменения функциональных возможностей и структуры сервиса задаются в WSRR, который управляет жизненным циклом сервиса..

Реализация сервисов с нуля

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

Рисунок 8. Применение жизненного цикла SOA к созданию сервиса "с нуля"
Применение жизненного цикла SOA к созданию сервиса с нуля
Применение жизненного цикла SOA к созданию сервиса с нуля

С точки зрения жизненного цикла SOA действия по созданию сервиса "с нуля" выглядят следующим образом:

Модель
Акцент делается на проектирование бизнес-ориентированных сервисов, учитывающих как текущие, так и будущие потребности. Рекомендованным подходом является применение принципов идентификации сервиса SOMA при использовании Rational Software Architect для моделирования сервиса и последующего создания артефактов физического моделирования..
Сборка
Рекомендуемым продуктом IBM для использования при разработке сервиса является Rational Application Developer (RAD) – надежная, функционально насыщенная интегрированная среда разработки J2EE, также предоставляющая как простые, так и продвинутые возможности для разработки и реализации сервисов. Она содержит простые функции для стандартной реализации сервиса и представляет их в виде файлов WSDL. Rational Application Developer позволяет вводить дополнительные функциональные возможности на всех этапах реализации Web-сервиса, начиная с совместимости с WS-I и далее с пошаговым добавлением реализаций для WS-Addressing, WS-Transactions и т.д. Общими шагами при использовании Rational Application Developer для разработки сервиса (аналогично Реализации сервиса, предоставленного сторонним поставщиком) являются следующие:
  1. Создайте проект корпоративного приложения J2EE в новой рабочей области Rational Application Developer.
  2. Создайте определение WSDL на основе проектных спецификаций сервиса. Если WSDL уже имеется, импортируйте его в рабочую область.
  3. Сгенерируйте каркас сессионного EJB-сервиса из WSDL.
  4. Завершите реализацию бизнес-логики для всех операций, определенных в каркасе сервиса.
  5. При желании создайте клиентскую программу Web-сервиса для вызова сервиса. Для клиентов приложений J2EE, обращающихся к сервисам, этой клиентской программы достаточно. Клиентам не-J2EE приложений необходимо предоставить клиентскую программу поддержки сервиса с учетом специфики конкретной технологии.
  6. Упакуйте артефакты реализации в файл EAR для развертывания.
Для комплексных решений, в которых корпоративные бизнес-процессы реализуются как система сервисов, этот сценарий может толковаться как конструирование и разработка сервиса; сборка же представляет собой хореографию этих сервисов в контексте бизнес-процессов.

Рекомендуемый IBM инструментарий для использования в этой ситуации - WebSphere Integration Developer (Integration Developer), предоставляющий среду разработки Business Process Execution Language (BPEL). Помимо других возможностей, он обеспечивает встраивание существующих сервисов в схему бизнес-процесса. Результирующий процесс может быть развернут в среде исполнения BPEL, предоставляющей средства хореографии для выполнения бизнес-процессов корпоративного уровня.

Развертывание
Упакованные модули развертывания EAR устанавливаются в рабочей среде сервера приложений WebSphere. Для распределенных сред рекомендуемым промежуточным программным обеспечением для запуска сервисов является WebSphere Application Server Network Deployment Edition V6. Для развертывания упомянутых выше бизнес-процессов IBM рекомендует WebSphere Process Server V6 (входит в состав промежуточного ПО IBM WebSphere Business Service Fabric).
Управление
Развернутые сервисы требуют мониторинга и управления. Мониторинг, как правило, необходим для контроля SLA, при превышении установленных пороговых значений выводятся предупреждения или инициируются соответствующие события. Если сервисы размещены вне пространства компании, требуется как минимум их защита от неавторизованного доступа. Все программные продукты Tivoli, перечисленные в предыдущих разделах, применимы и в этом сценарии. Вот их краткий перечень:
  • IBM Tivoli Composite Application Management (ITCAM) for SOA - для мониторинга сервисов на соответствие SLA
  • IBM Tivoli Federated Identity Manager (ITFIM) - для единого управления идентификацией в рамках предприятия
  • IBM Tivoli Identity Manager (ITIM) - для централизованного развертывания идентификационной информации в рамках предприятия
  • IBM Tivoli Access Manager (ITAM) - для единой регистрации в сети и авторизации до обращения к сервисам
Управление и процессы
Рекомендуемый IBM продукт для управления жизненным циклом сервисов - WebSphere Service Registry and Repository – мощное решение, позволяющее наращивать функциональные возможности по модульному принципу..

Резюме

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

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


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


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=658816
ArticleTitle=Архитектура ПО на практике: Часть 4. Сценарий SOA №1: Варианты создания сервиса
publish-date=05162011