CC BY
17
А.В.Черноусов, Л.В.Масседь
Интеграция унаследованных программных комплексов в ИТ-инфраструктуру научных исследований _
Введение. Современное состояние информационных технологий (ИТ) позволяет решить многие проблемы, связанные с ведением территориально распределенных проектов, предполагающих тесное взаимодействие различных элементов одной виртуальной организации, Под виртуальной организацией можно понимать как совокупность нескольких филиалов одной реальной корпорации, так и коллектив ученых, работающих в различных институтах над одной проблемой или в рамках одного проекта, Последнее носит в основном междисциплинарный характер или связано с консолидации усилий нескольких научных институтов для решения поставленной задачи.
Относительно недавно на смену разработки монолитных, поставляемых заказчику продуктов пришли продукты, разрабатываемые в режиме ИТ-аутсорсинг1, Современные тенденции развития программного обеспечения (ПО) связаны с переходом к удаленному использованию вычислительных, информационных и других ресурсов. Доступ посредством ,Л'еЬ-приложений к вновь создаваемому ПО сейчас является основным направлением развития корпоративных приложений,
Использование в рамках \^/еЬ-приложений уже разработанных программных комплексов позволяет в значительной степени ускорить процесс разработки, К сожалению, существующие программные комплексы в большинстве практически не позволяют интегрировать свою функциональность в другие системы (под функциональностью понимается конкретная реализация алгоритмов и методов обработки данных). Такая ситуация существует, как правило, вследствие использования морально устаревших технологий и методов программирования.
Актуальность проблемы интеграции функциональности научного ПО в современную ИТ-инфраструктуру обусловлена современными тенденциями развития, с одной стороны, программного обеспечения, а с другой, самого процесса организации научных исследований. Процесс организации научных исследований в настоящее время эволюционирует в сторону виртуальных территориально распределенных проектных групп, что, в свою очередь, обуславливает необходимость обеспечения одинаковой доступности информационных
1 ИТ-аутсорсинг (IT Outsourcing) — передача специализированной компании функций, связанных с информационными технологиями._
и вычислительных ресурсов проекта для всех его участников [1, 2].
Уже существующие программные комплексы (ПК) и другие ресурсы благодаря сервис-ориентированной архитектуре могут быть в большинстве случаев адаптированы к современным условиям. Сервис-ориентированная архитектура ($ОА) - это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде [3]. Благодаря БОА отдельные сервисы могут быть быстро интегрированы в распределенную вычислительную инфраструктуру.
В статье предлагается методика интеграции унаследованных программных комплексов в современную ИТ-инфраструктуру с использованием УУеЬ-сервисов,
Основные проблемы интеграции. Основными проблемами организации научных исследований с точки зрения ИТ являются разобщенность групп исследователей: как территориальное, так и организационное разделение. Главным последствием такой разобщенности является большое количество закрытого ПО, доступ к которому ограничен. Программное обеспечение зачастую просто недоступно для представителей сторонних исследователей даже в рамках одной научной организации, В связи с закрытостью программных комплексов многократно, с разным успехом, решаются одни и те же задачи. Исходя из этого, можно выделить следующие проблемы:
1. Проблема интеграции по данным - трудности при обмене данными с другими программами, связанные с применением различных кодировок, типов данных и различных форматов их хранения.
2. Проблема доступности. Часто разработчики даже не знают, какие функции уже реализованы даже в одном учреждении, Использование различных языков программирования и платформ также является значительным препятствием для интеграции по функциям.
3. Отсутствие документации. При утрате технической документации в отсутствие разработчика функции практически нереально интегрировать ее в другой ПК.
4. Административный барьер. В случае если группы разработчиков относятся к разным организационным подразделениям, личные отношения и амбиции руководства этих подразделений могут осложнить их взаимодействие [1].
Решение этих проблем при использовании старых подходов к созданию программных комплексов крайне проблематично, а иногда просто непреодолимо.
Технологии интеграции приложений. Для интеграции программных комплексов в единую ИТ-инфраструктуру следует опираться на мировые тенденции в разработке программного обеспечения [1]. Признанными лидерами среди технологии по интеграции программного обеспечения являются SOA (сервис-ориентированная архитектура) [4] и GRID [2. 5].
Технология Grid при ее реализации и применении является сложной с точки зрения решения административных вопросов (создания виртуальных организаций) в связи с объединением имеющихся ресурсов (как программных, так и аппаратных) в единую систему. Самая большая трудность при применении Grid-технологии - это авторские права на разработку в связи с созданием единой системы,
Технология SOA предоставляет функциональность приложений в виде независимых сервисов и позволяет обеспечить доступ к ним независимо от используемых ОС и языков программирования. SOA — это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс [6]. Другими словами, SOA — это компонентная модель, в которой разные функциональные единицы приложений, называемые сервисами, взаимодействуют по сети посредством интерфейсов. SOA является более предпочтительной при реализации распределенной системы, так как в целом является более простой в реализации и исключает недостатки GRID технологии.
При реализации полной SOA необходимо реализовать три основных компонента: реестр; провайдер сервисов; потребитель сервисов, При этом реализация реестра носит необязательный характер при несложном взаимодействии компонентов ИС. На рис. 1 пред-
ставлена концептуальная модель взаимодействия компонентов SOA [7].
Под реестром понимают компонент, отвечающий за публикацию служб и хранение ссылок на зарегистрированные службы. Он используется провайдерами и потребителями сервисов, для регистрации и нахождения служб, соответственно. Провайдер сервисов -компонент, предоставляющий службу, а потребитель сервисов - компонент, использующий эту службу,
Для реализации SOA предлагается использовать технологии и стандарты Web-сервисов, так как, по сути, в настоящее время эти стандарты и технологии позволяют наиболее полно реализовать SOA.
Разработка клиента Web-сервиса в качестве Web-приложения позволяет решить еще ряд второстепенных задач [8]:
■ обновление ПО может быть оперативно реализовано для всех пользователей системы одновременно;
• клиентское приложение, т.е. браузер, не требует установки, так как включено в поставку всех современных desktop-ориентированных операционных систем;
• имеются широкие возможности для реализации работы (в том числе и предоставление услуг) в глобальной сети.
SOA-ориентированный подход идеально подходит для организации взаимодействия между различными программными комплексами. Исходя из этого, предлагаемая методика опирается на SOA, Для решения проблем доступности и интеграции по данным в методике предлагается использование SOA совместно с применением XML как формата хранения данных.
Методика интеграции унаследованных программных комплексов в современную ИТ-инфраструктуру. Для интеграции унаследованного ПО в современную ИТ-инфраструктуру необходимо, чтобы оно было написано на современном языке программирования (например, Java) и имело специальный
USE
REALIZE
ServiceConsumer
ServiceDescription
CONTAINS Л
<н
Serviceprovider
j + invokeServiceQ j + bindService()
DESCRIBED IN
ServiceBroker
j + findServiceQ
Рис.1. Концептуальная модель взаимодействия компонентов SOA
интерфейс, с помощью которого можно было бы вызвать функции вычислительного ядра. Так как большинство унаследованных систем написано на устаревших языках программирования и не имеют такого интерфейса, то сопряжение их с другими элементами ИТ-инфраструктуры предлагается посредством: командной строки, чтения-записи и анализа данных из файлов, используемых программным комплексом (ПК), стандартного интерфейса ввода-вывода.
Исходя из вышесказанного, предлагаемая методика состоит из следующих комплексных, последовательно выполняемых этапов:
1. Рефакторинг исходного кода унаследованного комплекса,
2. Реинжиниринг программного комплекса.
3. Создание промежуточного программного обеспечения.
4. Разработка Web-сервиса.
5. Разработка Web-приложения.
6. Внедрение.
При выполнении первого комплексного этапа методики ставятся задачи выполнить:
■ Инвентаризацию унаследованного программного вычислительного комплекса (включающую получение исходных кодов ПК, поиск спецификаций форматов данных, поиск документации, составление текущих вариантов использования ПК (use cases), разработка блока тестов (test collection)),
* Анализ исходного кода (включает поиск потоков данных, поиск логических структур и мест их обработки, а также идентификации алгоритмов и методов обработки данных).
■ Проведение рефакторинга кода (включает улучшение читабельности кода, составление документации, оптимизацию выполняемых операций, тестирование).
Результатами этого комплексного этапа являются: полное понимание группой разработчиков функциональности программного комплекса, вариантов (режимов) его использования и набор тестов для проверки производительности и корректности ПО, а также форматы входных, выходных и промежуточных данных. Группа разработчиков должна иметь полное понимание внутренней структуры программного комплекса. Одним из важных результатов является документация, восстановленная в ходе выполнения этапа,
Реинжиниринг не затрагивает уникальных методов, реализованных в программном комплексе, он проводится исключительно для выполнения следующих целей:
■ Приведение форматов данных к современному
виду.
■ Выделение вычислительного ядра комплекса.
Приведение форматов данных к современному
виду вызвано необходимостью интеграции с другими частями ИТ-инфраструктуры. Трудности при обмене данными с другими программами в основном связаны с применением различных кодировок, типов данных и
различных форматов их хранения. Решить эту проблему, по мнению автора, можно благодаря приведению входных/выходных данных к единому стандарту XML,
Единый стандарт бизнес-документов - очень важный аспект интеграции, так как, однажды преобразовав документ в представление XML, можно беспрепятственно работать с ним дальше или конвертировать в любой необходимый внешний формат. Не менее 50% успеха интеграции ПО заключается в выборе правильного формата XML сообщений.
Отделение графического (псевдографического) пользовательского интерфейса (GUI) и выделение вычислительного ядра комплекса - один из самых трудоемких процессов в данной методике. Трудность заключается в том, что часто GUI и вычислительное ядро программного комплекса значительно переплетены друг с другом.
Результатом выполнения данного этапа является консольное приложение, готовое к интеграции, где все use cases реализуются посредством командной строки (в идеале - с помощью ключей при запуске приложения), а формат входных,/выходных данных основан на XML.
Разработка ПО промежуточного уровня (middleware) вызвана необходимостью реализовать предложенную в [1] архитектуру распределенного программного комплекса. Основная суть middleware заключается в облегчении доступа приложений к ресурсам. Такая функциональность важна, прежде всего, для разработчиков информационных систем, поскольку позволяет им большую часть времени уделять созданию бизнес-логики, а не разработке механизмов доступа к ресурсам.
Результатом выполнения этапа является такое приложение на современном языке программирования (например, Java), которое, с одной стороны, работает с вычислительным ядром комплекса, а с другой стороны, предоставляет современный интерфейс для интеграции в ИТ-инфраструктуру.
На этапе разработки Web-сервиса создается серверное ПО, которое должно выполнять следующие функции:
■ Сохранение переданных на обработку данных.
■ Обеспечение взаимодействия с middleware (его локальный вызов, обработка исключительных ситуаций).
■ Постановка задач в очередь.
■ Уведомление о текущем состоянии выполнения задачи (если вычислительное ядро программного комплекса это позволяет).
■ Подготовка результата в требуемом формате и отправка его клиенту.
Прежде чем приступать к созданию Web-сервиса, создается интерфейс, в соответствии с которым происходит взаимодействие сервиса и его потребителя. Согласно SOA, Web-сервис должен работать по протоколу SOAP.
МОДЕЛЬ
Инкапсулирует состояние приложения Отвечает на запросы о состоянии модели Реализует функциональность приложения Уведомляет вид(ы) об изменении состояния
вид
Обеспечивает визуальное представление модели Запрашивает у модели информацию об обновлениях ! Уведомляет контроллер о действиях пользователя ! Позволяет контроллеру выбирать тип визуального | представления
КОНТРОЛЛЕР
Определяет поведение приложения
Транслирует действия пользователя в изменения в модели Определяет вид представления результатов Один для каждой выполняемой функции
Рис. 2. Отношения между компонентами архитектуры MVC
В случае, если принято решение о создании «Реестра сервисов», необходимо предусмотреть реализацию функции регистрирования ШеЬ-сервиса в нем. Следует четко понимать, что \А/еЬ-сервис, рассмотренный ранее, занимается только вычислениями, а доступ конечного пользователя к системе осуществляется через УУеЬ-приложение. Пользователь для работы с \Л/еЬ-приложением применяет Web-бpаyзep,
Web-бpayзep отвечает за передачу данных от клиента и обратно, за безопасность и за представление данных. Это полноценный настраиваемый клиент. Настройка заключается в написании кода страницы, по которому браузер генерирует представление данных, обрабатывает интерактивность- страницы и отсылает обратно данные по безопасному соединению. Его не надо устанавливать на каждом компьютере, с которого нужен доступ к разработанной системе.
Так как ^/еЬ-браузер берет на себя все действия по отображению результатов, работа \УеЬ-приложения заключается в генерации кода страниц, Для этого предпочтительно использовать паттерн «Модель - Вид -Контроллер» (МУС) представленный на рис. 2,
Паттерн МУС означает четкое отделение пользовательского интерфейса (представления - вида) от бизнес-логики (модели). Контроллер управляет вводом и
выводом. К общеизвестным преимуществам этой модели относятся простота сопровождения, улучшенная гибкость и более понятный код [9].
В качестве контроллера выступает ряд сервлетов, управляющих поведением Web-приложения. Вид представляет собой набор JSP страниц, концептуально связанных друг с другом. JSP генерируют конечный код, который интерпретирует Web-браузер. Совокупность набора JavaBean и ряда некоторых классов, хранящих состояние системы и отвечающих за взаимодействие с Web-сервисом, является Моделью.
Предложенная методика завершается всесторонним тестированием развернутого распределенного приложения, реализованного в архитектуре SOA, С помощью предложенной методики возможно решение двух основных проблем:
■ адаптация унаследованных программных комплексов и последующая интеграция их в ИТ инфраструктуру,
■ разработка Web-сервисов на основе программ- вычислителей.
Применение методики. В настоящее время предложенная методика успешно проходит тестирование в рамках проекта создания вычислительного сервера для
Рис 3. Диаграмма развертывания IУеЬ-сервера для решения задач нелинейной оптимизации.
BrowserClient
Web-browser
HTTP
J
Web-container
NotLineClient.war
SOAP
Application Server
notlineopt.exe i
MiddleWareNLopt
NotLineService
MiddieWareGateway
MiddleWareNotLine
XMLStore
Locator
решения задач нелинейной оптимизации2. Положительными факторами, способствовавшими успешной адаптации, явились доступность разработчиков базового комплекса программ, а также применение ими достаточно современного языка программирования.
На рис. 3 представлена схема развертывания компонентов распределенной системы.
В качества потребителя сервиса будет выступать Web-приложение, так как предполагается интеграция вычислительного сервера в ИТ-инфраструктуру системных исследований в энергетике.
Библиографический список
1. Болдырев Е.А, Вычислительная инфраструктура научных исследований и подход к ее реализации// Информационные и математические технологии в науке, технике и образовании. - 2005, - 4.1. - С,65 - 72.
2, The Anatomy of the Grid: Enabling Scalable Virtual Organizations, I, Foster, C, Kesselman, S. Tuecke. International J. Supercomputer Applications, 15(3), 2001,
2 Вычислительным ядром сервера является комплекс программ, разработанный И.В.Мокрым под руководством О.В.Хамисова._
3. Jeremy Westerman SOA Today: Introduction 1o Service-Oriented Architecture,/ DM Review Online, 2004 http://www,dmrevievv',com/editorial/dmreview/print action,cfm? articleld—7992
4. Eric Pulier, Hugh Taylor Understanding enterprise SOA, -Greenwich,: Manning Publications Co, 2006, - 242c.
5. Ворожцова T.H, Скрипкин С.К, Черноусов А.В, GRID-проекты: обзор состояния и перспективы I Под ред. Массель ЛВ, - ИСЭМ СО РАН препринт № 2006. - 42с.
6. К, Channabasavaiah, К, Holey, Е.М, Tuggle, Migrating to а service-oriented architecture, IBM, 2003,
7. Ali Arsanjani Sen/ice-oriented modeling and architecture, IBM, 2004,
8. Черноусов А,В, Обеспечение безопасного доступа к WEB-приложениям,// Информационные и математические технологии в науке, технике и образовании, - 2005. -4,1, - С,126 - 130,
9. Тейт Б, Горький вкус Java: Библиотека программиста, -СП.: Питер, 2003, - 333 с,
