 | Уровень сложности: средний Шантану Бхаттачарья, главный консультант, Siemens Information Systems Limited
02.11.2009 Вы хотите внедрить сервис-ориентированную архитектуру (SOA) в своей организации, чтобы сделать свои бизнес-процессы гибкими и адаптируемыми, но эти процессы уже осуществляются рядом ИТ-систем. Выход из этой ситуации — интегрировать SOA с вашими унаследованными приложениями и тем самым извлечь из них большую пользу. Настоящая статья расскажет вам о тех шагах, которые необходимо для этого предпринять — и о подводных камнях на этом пути.
Для чего нужно внедрять унаследованные системы в SOA
Организации, использующие унаследованные ИТ-системы, испытывают все большую потребность во внедрении SOA для увеличения бизнес-ценности этих систем. Унаследованные системы осуществляют наиболее действенные бизнес-процессы, так как именно они были автоматизированы раньше других современных систем. Большинство из средств автоматизации не способны эффективно использовать унаследованные системы, поскольку эти системы старше, чем хотелось бы специалистам по автоматизации, занимающимся включением их бизнес-ценности в автоматизационные проекты. В результате всякий подход, направленный на создание новой бизнес-ценности, но не предполагающий при этом вовлечения унаследованных систем, оказывается успешным лишь отчасти.
Унаследованные системы, первоначально игравшие центральную роль в соответствующих проектах, постепенно утратили привлекательность как источники долговременного развития, поскольку считалось, что в этом случае вы будете обречены на постоянное нагромождение устаревших технологий. С учетом того, что смена поколений в компьютерных технологиях происходит всего за три года, описанная здесь проблема надвигается поистине впечатляющими темпами.
С другой стороны, однако, ясно, что унаследованные системы представляют собой тот базис, отталкиваясь от которого предприятие может начать совершенствовать существующие процессы. Поэтому бизнес-стратегия, направленная на технологические перемены, должна включать в себя унаследованные системы.
В настоящей статье предпринимается попытка классификации унаследованных систем, встречающихся в сегодняшних организациях, согласно следующим критериям:
- Какая среда выполнения необходима соответствующему ПО?
- Для каких платформ оно разрабатывалось?
- Какую среду пользовательского интерфейса оно использует?
Унаследованная система для своего исполнения может нуждаться в среде наподобие Oracle Frames — или же непосредственно исполняться в операционной системе. Системы, способные непосредственно исполняться в операционной системе, легче включить в структуру SOA. Одним из таких примеров могут служить системы, которые разрабатывались под DOS или мэйнфреймы. Таким образом, следует со всей серьезностью подходить к выбору используемого языка и технологии.
Среди унаследованных приложений можно выделить следующие типы в зависимости от применяемого пользовательского интерфейса:
- Приложения с эмуляцией терминала ("с зеленым экраном").
- Приложения без графического пользовательского интерфейса (GUI).
- GUI-приложения, работающие по схеме клиент-сервер.
- Web-приложения.
Из всего перечисленного проще всего в силу своей внутренней сути поддаются интеграции с SOA-приложениями Web-приложения и GUI-приложения типа клиент-сервер. В таких приложениях проведено четкое различие между поставщиком сервиса и интерфейсом пользователя, который легко трансформировать в SOA-сервис. Сказанное не означает, что другие приложения не могут быть включены в структуру SOA, однако для придания им вида SOA-сервиса требуются некоторые манипуляции.
Хотя мы упомянули здесь различные типы унаследованных приложений, ниже мы рассмотрим общие проблемы, возникающие в процессе трансформации унаследованных приложений в SOA-приложения. Особенности работы с унаследованными приложениями различных типов выходят за рамки данной статьи.
Определите, какие из унаследованных приложений необходимо внедрить в SOA
Следует отметить, что на пути интеграции унаследованных систем в SOA имеются свои сложности, и пытаться приспособить к SOA все приложения в рамках одного этапа модернизации было бы нецелесообразно. Это чрезмерно усложнило бы данный этап и существенно снизило бы вероятность успеха.
Чтобы определить, какие из унаследованных приложений необходимо приспособить к SOA:
- Классифицируйте все унаследованные приложения в соответствии с тем, какой бизнес-результат они обеспечивают и какие расходы понесет организация на поддержание их работоспособности.
- Оцените потенциальную ценность: насколько велик потенциал приложения, не используемый из-за его неприспособленности к SOA?
Приложения с высокой бизнес-ценностью следует включать в структуру SOA в первую очередь. Также в числе первых кандидатов на трансформацию следует рассматривать приложения с высоким нереализованным потенциалом.
Определите сервисы и преимущества для бизнеса
Определившись с унаследованными приложениями—кандидатами на трансформацию, не менее важно определиться с кандидатурами-сервисами. Этот выбор влияет на успешность всей процедуры трансформации.
Данный процесс состоит из двух этапов. На первом из них вы определяете, что именно можно выделить как сервис. Второй этап связан с той пользой для бизнеса, которую вы сможете извлечь из одних сервисов по сравнению с другими.
Этап 1:
Идентификация сервисов
Чтобы идентифицировать бизнес-процесс как сервис, необходимо проверить следующее:
- Число входящих и исходящих параметров не должно быть слишком велико; в противном случае такой бизнес-процесс, как правило, можно подразделить на несколько сервисов. Почему это так, понятно: в случае такого сервиса вам придется потратить слишком много времени на преобразование параметров в исходный формат и обратно.
- Каждый сервис должен реализовывать одну конкретную функцию. Добиться этого можно, сохраняя сервис в виде небольшого, элементарного вида деятельности. Это также упростит его использование в различного рода других сценариях.
- Каждый сервис должен иметь бизнес-функцию, а не техническую функцию. Следует всячески избегать технических сервисов, которым не соответствуют никакие бизнес-процессы. Дело в том, что бизнес-аналитикам бывает непросто разобраться в технических сервисах, в то время как сделать сервисы понятными для бизнес-аналитиков — одна из наиболее существенных целей SOA.
В качестве примера идентификации потенциальных сервисов рассмотрим работу приложения по приему заказов, основные операции которого могут быть следующими:
- Подтверждение надежности покупателя.
- Корректировка складских запасов.
- Выставление счета покупателю.
- Обработка задержанных заказов.
Каждое из приведенных выше действий может рассматриваться как потенциальный сервис. Следует, однако, иметь в виду, что элементарные бизнес-операции, такие как корректировка запасов, непосредственно допускают многократное выполнение в другом контексте. А вот выставление счета покупателю — операция более сложная, поэтому ее следует в свою очередь подразделить на составляющие:
- Сведение покупок в единый счет.
- Вычисление налога на продажу.
- Получение информации об адресе покупателя.
- Составление счета.
- Отправка счета.
Этап 2: Выбор сервисов, порождающих наибольшую бизнес-ценность в SOA
Второй этап включает в себя выбор сервисов, обладающих наибольшей целесообразностью в смысле бизнес-ценности в SOA-среде. Критерии выбора таких сервисов с небольшими отличиями аналогичны тем, по которым выбираются приложения-кандидаты. Избранные сервисы должны иметь высокий коэффициент ценности. Коэффициент ценности потенциального сервиса можно определить как
(Бизнес-ценность сервиса – Стоимость обслуживания) / Стоимость замены
Таким образом, наилучшие кандидаты для внедрения в проект — это сервисы с наибольшей бизнес-ценностью и наименьшей стоимостью замены, требующие наименьших затрат на обслуживание. Например, если код, реализующий данный сервис, будет распределен по множеству модулей и файлов, это существенно увеличит затраты на обслуживание.
Имеющиеся компоненты ПО можно классифицировать по языку, предназначению, типу и критичности. Определение ценности того или иного компонента основывается на анализе стоимости разработки, оценке затрат на замену ПО и той бизнес-ценностью, которую данный компонент порождает каждый год.
Восстановление унаследованного кода
Один из первых шагов в этом процессе — восстановление кода из унаследованных приложений для его повторного использования. Чтобы извлечь код из имеющейся унаследованной кодовой базы, прежде всего необходимо идентифицировать его и установить степень целесообразности его повторного использования. В том, чтобы проанализировать и оценить код, рассеянный по нескольким небольшим программам, нет ничего сложного; любой знакомый с этим кодом программист может проделать эту работу, вооружившись удобным ему текстовым редактором. Совсем другое дело — анализировать несколько сотен больших программ в поисках нескольких фрагментов кода, допускающих повторное использование. Безусловно, здесь необходим специалист в предметной области, однако ему, кроме того, следует вооружиться автоматизированными средствами реверсивного проектирования, такими как Refine/C, Imagix4D, Sniff+ или Rigi.
Один из наиболее важных этапов в восстановлении унаследованного кода — это идентификация бизнес-процессов, которым этот код соответствует. Самый простой путь определения бизнес-операций — по производимым ими результатам. Иными словами, речь идет о том, чтобы идентифицировать бизнес-процессы по результатам исполнения унаследованного кода. Такой подход позволит отслеживать бизнес-процессы, не прилагая чрезмерных усилий. Идентифицируя переменные, возвращаемые функциями, посредством которых реализуются те или иные бизнес-операции, можно идентифицировать и сами эти функции. Если программы структурированы таким образом, что определенным бизнес-функциям соответствует конкретный фрагмент кода, скажем, функция в языке C или параграф в КОБОЛе, задача оказывается совсем простой — но так бывает редко. Более вероятно, что реализация бизнес-функции окажется распределена по нескольким фрагментам кода в разных модулях. В свою очередь, один фрагмент кода может выполнять обработку нескольких бизнес-функций. Соответствие между фрагментами кода и бизнес-операциями оказывается, таким образом существенно неоднозначным.
Путем анализа потока данных на основании конечных результатов бывает возможно отследить все операторы, которые внесли вклад в получение того или иного результата. Определив эти операторы, вы имеете возможность выяснить, в каких фрагментах кода — процедурах, параграфах и т. д. — они расположены. Именно эти фрагменты подлежат последующему копированию — вместе с переменными, к которым они обращаются. Такая методика широко известна под названием "очистки кода" (code stripping).
Следующий шаг после идентификации кода бизнес-операции — извлечение этого кода и реассемблирование его в виде отдельного модуля со своим собственным интерфейсом. Это делается путем копирования перепакованных фрагментов кода в общую структуру и помещения всех элементов данных, к которым они обращаются, в общий интерфейс данных. В языке C такими интерфейсами являются параметры структуры типа, а в КОБОЛе объектами являются элементы первого уровня в секции связей. Конечным результатом во всех случаях становится подпрограмма с интерфейсом запроса. Первоначальные входные аргументы становятся входными параметрами, а выходные аргументы — выходными параметрами. В этом смысле код бизнес-логики отрывается от первоначального пользовательского интерфейса и оформляется в самодостаточную подпрограмму. Это одно из необходимых условий построения оболочки для этого кода.
Построение оболочки для восстановленного кода
После того, как код, соответствующий той или иной бизнес-операции, локализован, документирован и сочтен пригодным для повторного использования, переходят к следующему шагу — построению для него оболочки. Цель заключения кода в оболочку состоит в построении для компонента, извлеченного из унаследованного кода, интерфейса языка WSDL (Web Services Description Language). Соответствующая методика требует преобразования каждого компонента в метод, а каждого параметра — в элемент данных XML. Структуры данных становятся при этом сложными элементами, включающими в себя один или более субэлементов. Аргументы и результаты методов работают как ссылки на описания элементов данных. Как методы, так и параметры встраиваются в XML-схему.
На рынке имеется целый ряд средств, автоматизирующих такое преобразование для КОБОЛа и C++. Помимо создания описания WSDL-интерфейса, они также снабжают заключенный в оболочку компонент двумя дополнительными модулями:
- Первый модуль предназначен для синтаксического анализа входящего сообщения и извлечения из него данных. Извлеченные значения присваиваются затем соответствующим аргументам заключенного в оболочку компонента.
- Второй модуль предназначен для создания возвращаемого сообщения по результатам работы заключенного в оболочку компонента. Таким образом, та или иная элементарная операция может быть многократно применена как Web-сервис без необходимости изменения кода.
Две эти вновь созданные процедуры служат мостом между WSDL-интерфейсом и интерфейсом вызова из оригинального кода.
Привязка сервисов к бизнес-процессу
Третий и последний этап создания Web-сервисов из унаследованного кода заключается в привязке этих Web-сервисов к опирающимся на них бизнес-процессам. Делается это с помощью прокси-компонента. Бизнес-процесс, по существу, активизирует прокси, доступный в том же адресном пространстве, что и определение процесса. Как и в CORBA, прокси проверяет параметры и генерирует WSDL-интерфейс, который затем пересылается при помощи того или иного сервиса сообщений — например, IBM® WebSphere® MQ, — на сервер приложения.
На сервере приложения имеется планировщик, который принимает входящее сообщение, определяет, какой Web-сервис следует выполнить, и пересылает WSDL-контент этому сервису — в нашем случае, заключенному в оболочку унаследованному коду. Оболочка кода анализирует входные XML-данные и передает соответствующие значения по нужным адресам компонента-содержимого.
После того, как компонент-содержимое исполнен, оболочка преобразует полученный им результат в XML-структуру выходных данных, и он поступает обратно в планировщик и далее в Web-клиент. При таком подходе бизнес-процесс может исполняться где угодно на каком угодно клиенте и при этом иметь доступ к унаследованным функциям первоначального сервера приложения.
Выводы
Заключение унаследованных приложений в оболочку с целью приспособления их к корпоративным SOA-проектам — важная составляющая сегодняшней тенденции внедрения SOA на предприятиях. Если процесс подготовки к внедрению SOAосуществляется должным образом, эта задача решается легко и без ошибок. В настоящей статье я попытался помочь вам проникнуть в детали этого процесса и изложить его настолько просто и логично, насколько это возможно.
Ресурсы Научиться
- Оригинал статьи "Integrate legacy systems into your SOA initiative. Convert legacy applications into SOA-based applications" (EN).
- Прочтите статью "Разработка стратегии миграции от унаследованной ИТ-инфраструктуры предприятия к архитектуре, основанной на SOA" (developerWorks, апрель 2005 г.).(EN)
- Ознакомьтесь со статьей "Стратегии разработки для включения унаследованных систем в SOA-решения" (developerWorks, апрель 2007 г.).(EN)
- Прочтите статью "Адаптация устаревших систем к SOA" (developerWorks, июнь 2007 г.).
- Раздел SOA и Web-сервисов на сайте IBM developerWorks содержит сотни полезных статей, а также руководств по разработке приложений Web-сервисов — начального, среднего и профессионального уровня.
- Играйте в SOA-Песочнице IBM! Повышайте свою квалификацию, получая непосредственный практический опыт в точках входа IBM SOA.(EN)
- На сайте IBM SOA вы найдете обзор SOA и узнаете, как IBM может помочь вам освоиться в этой области.(EN)
- Следите за техническими событиями и Web-трансляциями на developerWorks. В частности, посетите следующие технические брифинги, посвященные SOA и Web-сервисам:(EN)
- Ищите книги по этой и другим техническим темам в
книжном магазине Safari.
- Ознакомьтесь с краткой демонстрацией на тему Web-сервисов по запросу.(EN)
Получить продукты и технологии
- Придайте новизну своему следующему проекту разработки ПО при помощи
ознакомительных версий ПО IBM, которые можно загрузить с сайта или заказать на DVD.(EN)
Обсудить
Об авторе | 
| | Шантану Бхаттачарья (Shantanu Bhattacharya) имеет огромный опыт разработки и проектирования прикладного ПО (в сфере розничной торговли, системной интеграции и медицины), сетевого ПО (на протоколах SNMP и TCP/IP), файловых систем (первый индийский суперкомпьютер) и ПО реального времени (для индийской ракетной программы). Он является автором ряда публикаций и выступает с обзорами в журнале ACM Computing Surveys. Сегодня Шантану работает в сфере медицинской промышленности и является главным системным архитектором отделения фирмы Siemens в г. Бангалор (Индия). |
Выскажите мнение об этой странице
| |
