СМ-Консалт
 

Работа с Web-сервисами в корпоративных SOA: Часть 14. Как мигрировать унаследованные сервисные компоненты gри обнаружении их Web-сервисами с помощью IBM Rational RequisitePro и Rational ClearCase

Статьи Технологии разработки ПО SOA и Web-сервисы

Введение

Часть 2 серии «Работа с Web-сервисами в корпоративных SOA» показала, как корпоративное унаследованное приложение, состоящее из двух компонентов, может быть связано с Web-сервисами как более целесообразный способ обработки часто обновляемых служебных данных. В Части 9 Web-сервисы были объединены в EAI-приложения как буфер унаследованных систем в множественных SOA.

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


Зависимости унаследованной системы

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

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

Мы можем либо принять зависимости, основанные на требованиях пользователя и характеристиках целевой операционной среды, либо отказаться от них. Чтобы быть уверенными в том, что извлеченные сервисные компоненты не приведут к избыточности сервисов, мы должны проанализировать зависимости, которые можно принять, такие как обеспечение прямых вызовов продуктов IBM DB2. Если извлеченные сервисные компоненты обусловливают выполнение похожих соединений, например, с IBM Database Add-Ins для Visual Studio 2005, их необходимо объединить, чтобы обеспечить единую функциональность сервиса, уменьшая или исключая избыточность сервисов.

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


Ограничения SOA

Вторая проблема связана с шестью ограничениями SOA на мигрирующие сервисные компоненты. Это 

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

 

URL-местоположение

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

Преобразование данных

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

Сервисные компоненты многократного пользования

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

Целевая операционная система

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

Внешнее обнаружение

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

Недостаток документации

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


Мигрирующие сервисные компоненты

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

Перед тем, как продолжить реконструировать архитектуру и разрабатывать оркестрирование Web-сервиса вам необходимо определить требования пользователя к функциям сервиса и характеристики целевой операционной среды: карманных компьютеров, нотубуков и рабочих станций. Вам также необходим доступ к документации по унаследованным служебным компонентам — к справочникам, схемам, комментариям в коде и т.д. Если документации не достаточно, вы можете проанализировать требования пользователя и операционной среды с помощью IBM Rational Requisite Pro.

Реконструкция

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

Во время процесса реконструкции выясните, планируют ли продавцы использовать Unix-версию сервисных компонентов унаследованной системы. Это устранит необходимость непосредственной связи с операционной системой Windows или коммерческими продуктами, основанными на Windows.

Затем вам, возможно, придется изменить порядок распутывания унаследованных компонентов. Вы можете обратиться к IBM Rational ClearCase, чтобы более эффективно управлять изменениями.

Оркестрирование Web-сервисов

Некоторые зависимости, которые можно использовать с продуктами IBM для управления информацией, такими как DB2®, должны храниться в сервисных компонентах. Другие зависимости, которые не могут быть использованы с продуктами IBM, должны быть проанализированы с целью определить, следует ли их удалить или заменить. При обнаружении избыточности, такой как расширение Net Visual Studio, вам необходимо разработать оркестрированный Web-сервис в SOA, чтобы объединить избыточные компоненты в одну сервисную функциональность.

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


Рисунок 1. Оркестрирование одиночного функционального сервиса
Оркестрирование одиночного функционального сервиса

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


Web-сервис репозитория

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

Сложив все это вместе, Web-сервис репозитория должен содержать не менее четырех библиотек:

  • Компоненты многократного использования
  • Отклоненные компоненты
  • Извлеченные компоненты
  • Список пожеланий

Заключение

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

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

21.02.2008

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта