ВведениеПлан
Часть I - Реструктуризация унаследованных систем
Потребности бизнеса во взаимодействии составляющих его структур породили в необходимость в интеграции обслуживающих бизнес разрозненных инфраструктур. Наибольшее сопротивление этому начинанию оказывают вышеупомянутые устаревшие программные комплекы (Legacy Systems), потому как в силу своей архитектуры они практически совсем не расширяемы, модернизация и интеграция их друг с другом и с вновь разрабатываемыми ИС требует огромных финансовых и временных затрат. Созданные когда-то интерфейсы к этим системам давно устарели и совершенно не удовлетворяют текущим потребностям пользователей, привыкших к гораздо большей функциональности GUI-интерфейсов. Эта проблема особенно остро стоит перед большими корпорациями, целыми отраслями промышленности, имеющими в своем арсенале подобное наследство, потому что ограниченность их возможностей в быстро меняющемся мире уменьшает их конкурентоспособность и может однажды привезти к информационному коллапсу. Поэтому так остро стоит вопрос об эффективных с точки зрения затрат времени и человеческих ресурсов методах модернизации или миграции унаследованных систем. И острота его вряд ли уменьшится в ближайшие десятилетия. В данном обзоре будет сделана попытка описать в общих чертах текущее состояние на этом фронте.
К сожалению, до сих пор существует немало производственных (и не только)
процессов, которые по каким-либо причинам нельзя даже приостанавливать
(например, для той же модернизации ПО), поэтому с неизбежностью наличия
морально устаревших систем в таких случаях придется еще долго мириться.
Возникает проблема интеграции с современными ИС. Вытекающий логически
более общий вопрос взаимодействия подсистем сам по себе весьма интересен
и распостраненные на сегодня способы будут также рассмотренны в этом обзоре.
Унаследованные системы [15] (legacy systems) - это системы, по тем или иным причинам переставшие удовлетворять изменившимся потребностям применений, которые тем не менее продолжают использоваться ввиду больших затруднений, возникающих при попытке их замены. Унаследованные системы используют морально устаревшие технологии, архитектуры, платформы, а также собственно программное и информационное обеспечение. При проектировании таких систем, как правило, не предусматриваются должные меры для их пошаговой миграции в новые системы. Для таких систем характерны также монолитность и закрытость. Практически любая система до последнего времени после создания противодействала изменениям и имела тенденцию быстрого превращения в бремя организации, потому что при ее создании использовались "уставшие" технологии, архитектуры, платформы.Что подразумевается под понятием "унаследованная система"
В статье Энн Мак-Крори "Что такое унаследованные системы?" [1] раскрывается сложность и запутанность этого понятия. Это может быть комбинацией из:
а) компьютерные системы, которые по тем или иным причинам перестали вас устраивать;Некоторой неопределенностью в данном вопросе мы обязаны постоянному развитию отрасли. Одно время под наследуемыми системами понимались повсеместно заменявшиеся мэйнфреймы. Сегодня устаревшими можно считать любые системы, снятые с производства всемирно известными компаниями.
б) системы для мэйнфреймов, написанные на Cobol и прослужившие более 5 лет;
в) исчерпавшие себя системы для мини-компьютеров или мэйнфреймов;
г) приложения с интерфейсом для Unix;
д) совокупность аппаратного и программного обеспечения, которое успешно выполняло возложенные на него задачи до тех пор,пока не пришла пора заменить его новыми средствами;
е) любая морально устаревшая система
Некоторые под термином "наследуемая" подразумевают "непригодная". Ее трудно или совсеи невозможно связать с другими системами. У нее большие проблемы с маштабируемостью, ее трудно поддерживать, развивать дальше. Для них подобная система - тяжкое бремя. От нее нельзя отказаться, хотя она значительно снижает производительность труда.
С момента создания первой ЭВМ было создано поистине гигантское количество программного обеспечения. На начальных этапах информационной эры больше беспокоились об оптимизации алгоритмов для повышения скорости вычислений (собственно для этого и были созданы компьютеры) и мало задумывались о таких понятиях, как масштабируемость, взаимодействие с другими системами в гетерогенной сетевой среде, переносимость на другие аппаратные платформы. Теперь, например, мы имеем наследие в 70% написанного на языке COBOL кода (в основном, для мэйнфреймов) от всего ПО, созданного за все эти годы. Тратятся огромные усилия для поддержки и доработки таких ИС. Нет нужды объяснять, что любая организация, которая расчитывает на выживание в конкурентной борьбе, стремится избавиться от этого тяжкого груза. Потребность в реструктуризации унаследованной системы часто является также следствием потребности интеграции ее с другими ИС (2-я часть данного обзора).Причины, приводящие к реструктуризации унаследованной системы
В классической постановке решение задачи разработки программной системы (инжениринг) представляет собой спиральный цикл, основанный на итеративном чередовании этапов анализа, проектирования и программирования (реализации). Инжиниринг предполагает построение различных моделей программной системы, которые отражают различные взгляды на нее и служат основой для программирования. Система создается как последовательность исполняемых релизов, каждый из которых все более полно отвечает предъявляемым к системе требованиям.Реверс-инжениринг наследуемой системы как основной метод ее реструктуризации
В реальной жизни разработка программной системы редко начинается "с нуля". Обычно программная система имеет некоторую предысторию в виде совокупности программ, реализующих - частично или полностью - требования к системе. Ярким примером являются рассматриваемые здесь унаследованные системы. Поэтому разработка такой системы сопровождается реконструкцией (re-engineering) старой системы через непрерывный процесс формирования и уточнения требований предметной области. В этом процессе часто используется так называемый реверс-инжениринг программных кодов, при котором путем анализа текстов программ восстанавливается исходная модель-алгоритм программы, которая затем развивается теми же методами, что и при инжиниринге. Система должна быть сконструирована так, чтобы произвольные ее составляющие могли быть реконструированы при сохранении целостности системы.
Каковы главные цели реинжинирингового подхода? Во-первых [6] , это создание оптимальной структуры, нацеленной на достижение определенной иерархии целей. Во-вторых, получение нового или добавленного качества в каждом элементарном процессе в отдельности и, в конечном итоге, на выходе всей системы в целом. В-третьих, это оптимизация предшествующих двух шагов с целью достижения максимальной гибкости и настраиваемости системы в непрерывно меняющейся окружающей среде. Определив цели реинжиниринга, можно с уверенностью утверждать, что макросистема, образованная из подвергнутых реинжинирингу систем, должна в целом обладать добавленным качеством, а также продуктивностью наряду с соответствующими свойствами гибкости и самоадаптации.
Метод эмуляции или иммитации работы системы для каких-то внешних по отношению к ней систем стар как мир компьютеров (и не только). Начиналось это еще с эмуляции терминалов к мэйнфремам. Сейчас он запечатлен, например, в стандартах взаимодействия открытых систем (ISO OSI - Open Systems Interaction), в драйверах доступа к внешней аппаратуре из ЭВМ, в протоколе доступа к SQL-ориентированным базам данных (ODBC - Open Data Base Connectivity), многочисленным шлюзам кМетод создания промежуточного ПО - эмулятора доступа к устаревшей системе
В [21] описан типичный пример ситуации миграции к новой системе. Предположим, что вы хотите интегрировать вашу систему с устаревшей системой бухгалтерского учета. Документации на интерфейс нет, и все необходимые сведения придется черпать из системы, которую мы заменяем. Из этого положения можно выйти слеующим образом:
Еще одним следствием эволюции подхода ПО промежуточного слоя стал компонентый
метод разработки ПО. Это когда каждый модуль системы представляет из себя
полностью автономный компонент, имеющей для доступа к себе некий стандартный
API (Application Programming Interface). Причем, компоненты эти при определенных
обстоятелствах (когда возможна совместимось) могут быть написаны на разных
программных языках. В связи с бурным развитием распределенных (по разным
ЭВМ) систем этот метод получил широкое распостранение. В объектном
подходе такие компоненты рассматривают как распределенные по сети объекты.
Приемущества описываемой архитектуры в черезвычайной гибкости и масштабируемости
получаемого на ее основе ПО.
Эволюция данного подхода будет рассмотрена немного ниже.
Опишем основные признаки, указывающие на то, что перед нами действительно
большая система [6]:
В понятие большой системы следует ввести термин открытости, не забывая
при этом, что могут существовать также закрытые большие системы и открытые
малые.
Итак, определив (например, по вышеприведенным признакам), что система
является большой, мы пытаемся ее разбить на части до тех пор, пока в них
мы не перестанем видеть все эти признаки. А затем поэтапно заменяем каждый
модуль на новую версию.
Производить реенжиниринг даже небольшой ИС на основе машинных кодов
даже с использованием инструментария - черезвычайно сложная задача. На
среднем уровне обычно используется дизассемблер, но и здесь для программиста
остается море работы. Для небольших программ это вполне приемлемый способ
восстановления алгоритма их работы и вероятность ошибок слишком высокая.
Для языков высокого уровня имеется множестов инструментов по переносу систем,
на них написанных, на другие более современные. Например, есть такой замечательный
продукт, как RescueWare, который позволяет делать реверс-инжениринг со
старого COBOL на новый либо на С/С++/Java. Тем не менее сами такие инструменты
могут стоить от нескольких сотен до нескольких милионов долларов, и сам
процесс также не назовешь дешевым: по порядку это обычно не меньшие цифры.
Среднего размера организации обычно довольствуются ручной переделкой кода
их программистами (либо консультантами со стороны, но это опять же дорого).
В этом случае проще держать при себе создателей системы с использованием
различных стимулов (высокий оклад, отличная пенсия, льготы и др.).
Для 4GL языков (4-го поколения, языков, встроенных в интегрированные
интерактивные среды разработки ПО) на сегодня дела обстоят довольно неплохо.
Для некоторых сочетаний созданы утилиты регенерации с одного языка на другой.
Также в CASE (инструментах проектирования систем) 2-го поколения (например,
в Oracle Designer 2000 Release 2) появились утилиты для закачки в их репозитарии
алгортимов из кодов на 4GL языках (старый знакомый реверс-инжениринг).
Однако, надо признать, что диапазон языков по своему охвату оставляет желать
лучшего. Но и здесь не все потеряно: разрабатываются стандарты по переносу
проектной информации между различными CASE, создан стандарт универсального
хранилища проектов в виде объектной базы данных. Мы постепенно пришли к
высшему на данный момент уровню - уровню модели ИС. Имея описание системы
на уровне ее модели (например, описанной на UML (Unified Modeling Language)
- Унифицированном языке моделирования), можно легко произвести с помощью
соответствующей утилиты (ре-)генерацию кода на нужном языке (и 3-го, и
4-го поколений). При этом система легко интегрируется с другими системами,
если имеется их описание на этом или аналогичных ему языках моделирования.
Этап 1
Допустим, когда-то была создана система S (см рис.). Эта система состоит
из 3-х независимых между собой подсистем (Ss - Subsystem).
Этап 2
На очередном этапе развития системы возникла потребность взаимодействия
между Ss1 и Ss2, Ss1 и Ss3.
Разработчик пишет интерфейсы для каждой связи Ss-i <-> Ss-j. Обозначим
стрелками направления взаимодействия между подсистемами. Интерфейсы представляют
из себя описания вызовов процедур, исполняемых на данной подсистеме. Стрелки
- это передача параметров вызова и возвращаемый результат.
Этап 3
Далее, разработчик видит, что интерфейсы к Ss1 содержат пересекающееся
множество описаний функций, и он решает объединить их в один интерфейс.
Этап 4
Предположим, что система усложнилась до такой степени, что стало слишком
накладно каждый раз писать индивидуальные интерфейсы для новой подсистемы
(вернее, ее части, которая обращается к остальным Ss).
Возникает идея создания промежуточного программного слоя-шины, который
инкапсулировал бы в себе эту задачу. Назовем его "Middleware" (связующее
ПО).
Этап 5
На сегодняшний день уже разработано несколько стандартов такого промежуточного
ПО, среди них описываемые ниже OMG CORBA и Microsoft DCOM/COM+. Поэтому
в какой-то момент рациональнее будет не изобретать велосипед, а использовать
эти стандарты для построения их собственной реализации либо продукты стороних
призводителей ПО. Это прямой путь к технической интероперабильности подсистем.
Еще можно добавить стандарт открытых систем и мы получим сегодняшнюю
мечту многих разработчиков крупных ИС уровня корпорации.
Этап 6
Заглянем на секунду в будущее. Мы там видим, как подсистемы представляют
из себя автономные объекты, которые живут своей жизнью и общаются друг
с другом на уровне смысловых понятий их предметной области.
Это уже уровень семантической интероперабильности компонентов. По сложности
стоящих перед исследователями задач он приближается к проблемам исскуственного
интелекта.
Весьма интресным был бы количественный анализ необходимости перехода от одной версии взаимодействия к другой. Описанные выше критерии затрат на миграцию унаследованной системы частично дают ответ на вопрос, что же нужно учитывать при оценке. При попытке использования какого-либо стандарта на любом этапе появляется потребность сравнительного анализа выбора между разработкой собственного, использования уже разработанного какой-либо авторитетной организацией(-ми), либо программных продуктов сторонних производителей (которые, в свою очередь, тоже могут как использовать, так и не применять общепризнанные стандарты). В реалиях невообразимого разнообразия аппаратного и программного обеспечения становится весьма разумным использовать 2-й подход - использования общепризнанных стандартов. Одним из наиболее известных в этой области является стандарт взаимодействия открытых систем. Но что такое "открытая система"?
OMG определяет управление объектом как разработку программного обеспечения, которое моделирует реальный мир через представление "объектов". Эти объекты есть инкапсуляция аттрибутов, отношений и методов программного обеспечения опознаваемые программных компонент . Ключевое преимущество объектно-ориентированной системы - ее способность расширять свои функциональные возможностях расширяя существующие компоненты и добавляя новые объекты к системе. Объектное управление имеет результатом более быструю разработку приложений, более легкое обслуживание, огромную масштабируемость и многократное использование программного обеспечения.
На этой иделогической платформе была разработана спецификация OMA - Object Management Architecture (Архитектура Управления Объектом). Ее ключевыми составляющими являются:
Центральным звеном данной архитектуры является программа-брокер ORB, которая помогает формировать запросы на доступ к объектам, т. е. служит посредником (брокером) между клиентом и сервером. Системы CORBA состоят из объектов - компонентов с четко определенными интерфейсами, описывающими услуги, которые они предоставляют другим объектам системы (продолжение идеи технологии клиент-сервер). Указанные объекты могут являться как компонентами, реализованными на объектно-ориентированном языке типа C++ или Java, так и представлять собой простые оболочки крупных фрагментов кода (возможно, унаследованного).
На рисунке показан запрос(Request) клиента(Client) серверу - реализации объекта(Object Implementation) посредством ORB.
В состав брокера ORB обычно входят библиотека, которая связывается с каждым процессом CORBA, и процесс-"демон", участвующий в формировании соединения, но не в других коммуникационных операциях. Процессы узла-клиента осуществляют вызовы объектов, принадлежащих процессам сервера, причем система обладает гибкостью, выражающейся в том, что серверы также могут вызывать объекты (т. е. вести себя подобно клиентам), а клиенты - сами содержать объекты.
Брокеры ORB поддерживают и другие функциональные возможности. Например, интерфейс динамической активизации (Dynamic Invocation Interface, DII) и интерфейс динамических схем (Dynamic Skeleton Interface, DSI) позволяют производить доступ к объектам, не используя заглушки и структуры (skeletons), специфические для конкретных типов объектов.
Описание интерфейса на языке IDL состоит из имени интерфейса, списка наследуемых параметров (необязательный компонент) и списка операций и атрибутов. Для каждой операции указывается имя, возвращаемое значение, несколько параметров (хотя их может и не быть) и предложение raises (необязательный компонент). Атрибуты используются в качестве удобного варианта задания значения, допускающего чтение и запись; впрочем, в результате обработки запроса на чтение возвращаемое значение может быть пересчитано, так что атрибуты не должны представлять внутренние переменные (переменные-члены). Определения интерфейсов хранятся в репозитарии интерфейсов (Interface Repository).
Как и язык IDL, протокол IIOP является отражением общей тенденции к стандартизации средств взаимодействия, поскольку стандартизация самих вычислительных сред (что означает устранение их гетерогенности) представляется маловероятной.
В области связующих технологий наиболее важными (можно сказать, основополагающими) для работы в среде ORB являются 3 сервиса:
В рамках модели COM был предложен стандарт двоичного интерфейса, позволившего организовывать службы (в виде динамически компонуемых библиотек или приложений) на разных языках программирования. Однако возможности этой модели существенно ограничивались тем, что она не поддерживала распределенные среды. В модели DCOM этот недостаток устранен: клиентам разрешено обращаться к имеющимся службам с удаленных компьютеров через сеть. Технологии OLE сравнительно недавно были переименованы в ActiveX, а термин OLE вновь обрел свой первозданный смысл.
Модель DCOM изначально разрабатывалась с целью обеспечить возможность интеграции приложений. Идея поддержки распределенной обработки появилась позднее. Характер этой объектной модели отражает историю ее создания. DCOM поддерживает объектно-ориентированную модель, но такую, которая кардинально отличается от классических образцов. Объект DCOM предоставляет сервис посредством одного или нескольких отличающихся друг от друга интерфейсов. Он может использовать все свои интерфейсы самостоятельно, а может прибегнуть к так называемому методу агрегирования и передать один или несколько интерфейсов в распоряжение других объектов DCOM. Агрегирование позволяет строить приложение из повторно используемых компонентов DCOM.
Другое расхождение с классическими объектно-ориентированными моделями выражается в том, что DCOM не поддерживает полиморфизм. Сторонники DCOM считают, что такая поддержка является излишней в модели, главное предназначение которой - построение приложений из двоичных компонентов. Заметим, однако, что DCOM не накладывает никаких ограничений на использование в процессе разработки языка, поддерживающего полиморфизм.
Узел-клиент может запросить объект DCOM (используя стандартные методы интерфейсов, реализуемые всеми объектами DCOM) через какой-либо конкретный интерфейс, идентифицируемый уникальным номером (UUID). Интерфейс считается постоянным: после того как он опубликован, его не разрешается изменять. Добавление новых функций в объект DCOM может производиться только путем создания новых интерфейсов.
Хотя между технологиями CORBA и DCOM имеются существенные различия, обе они поддерживают интеграцию компонентов. Так, DCOM позволяет преодолевать ограничения, связанные с сетевой средой, языком программирования, унаследованным ПО и парадигмой. Минусы этой модели связаны с тем, что она не является открытым стандартом. Хотя Microsoft и заявляет о своем сотрудничестве с такими авторитетными объединениями производителей, как IETF и W3C, в настоящее время модель DCOM доступна только на платформах Microsoft. Возможно, в ближайшие месяцы ситуация изменится, если другие компании начнут переносить DCOM на иные платформы, но пока что модель DCOM не обеспечивает прозрачности границ, связанных с операционной системой и фирмой-производителем.
Представители Microsoft утверждают, что с выходом в свет их нового продукта
- сервера транзакций (Transaction Server) - модель DCOM станет полноценной
системой масштаба предприятия, поддерживающей службы именования, событий,
защиты, транзакций и жизненного цикла объектов. Мы надеемся, что безконфликтное
сосуществование моделей CORBA и DCOM рано или поздно будет достигнуто;
кстати, OMG уже рассматривает вопрос взаимодействия COM/CORBA.
В данном обзоре авторы попытались охватить спектр проблем, стоящих перед
разработчиками интероперабельных ИС и методов решения задач по интеграции
их с унаследованными ИС.