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

Этот процесс затрагивает не только «унаследованные» системы, но и относительно новые разработки.

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

Классификация проектов миграции

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

СУБД. Начало таким проектам положил переход с настольных и офисных систем на базе некогда популярных dBase, Clipper, FoxPro и Paradox на промышленные серверы баз данных. Сегодня в силу разных обстоятельств — не всегда из-за технических проблем — все чаще осуществляется переход с одного популярного сервера баз данных на другой. Кроме того, уже встречаются проекты перехода на другую СУБД, подразумевающие организацию поддержки более чем одной платформы.

Аппаратные платформы. Программные решения не поспевают за прогрессом аппаратных платформ, темпы которого диктует Закон Мура. Правда, современные программные средства настолько требовательны к ресурсам, что сами формируют спрос на более мощную технику. И если переход на новую версию в рамках одной платформы относительно прост, то миграция на другую технологию требует глобальной перестройки программного кода (например, с 16-разрядного процессора на 32-разрядный).

Программные платформы. Типичный пример — массовая миграция с MS-DOS на Windows и с Novell Netware на Windows NT, либо множество проектов, связанных с миграцией решений на Java, J2EE и EJB. Сегодня на корпоративном рынке растет спрос на .Net, но чаще всего осуществляется переход на следующую версию той же операционной системы. Более серьезные изменения требуются при миграции на качественно иную версию платформы (например, при переходе от COM+ к .Net). В таких случаях производитель базового программного обеспечения обычно предоставляет средства взаимодействия и обеспечения совместимости старых и новых компонентов, которые позволяют постепенно переходить на новую инфраструктуру.

Несмотря на тенденцию к распределенным и многозвенным архитектурам, многочисленные различия в реализации решений обуславливают слабую совместимость и переносимость разработок. Переход с одного сервера приложений на другой, если даже оба поддерживают один и тот же стандарт (к примеру, J2EE и EJB), связан с многочисленными изменениями в соответствии со спецификой платформы и реализацией стандарта. Небольшой, но досадной проблемой может стать то, что один сервер приложений чувствителен к регистрам при передаче параметров, а другой — нет. Другой пример: как каждый Web-сервер интерпретирует запись localhost. А, например, различия в обработке кэша объектов могут серьезно повлиять на производительность перенесенных на новую платформу компонентов JavaBeans. И только организация в таких проектах полномасштабного тестирования обеспечивает работоспособность системы.

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

Последний шаг в развитии программных платформ — Web-службы, обеспечивающие поддержку кросс-платформного взаимодействия в среде Internet. В большинстве случаев данный подход требует переосмысления концепции приложения, с тем, чтобы разделить его функциональность на отдельные объекты и их семейства, «гранулировав» систему, и открыть доступ к функциям объектов (сервисам) в Web-среде.

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

Многозвенные архитектуры. Начало таким проектам положил переход с «настольных» программ на решения «клиент-сервер» с выделением уровня сервера базы данных. Затем начались проекты создания трехзвенной архитектуры, в которых логику приложения перенесли на уровень сервера приложений. С распространением Web-технологий добавились уровни сервера и портала, плюс к этому — «звенья» обеспечения безопасного доступа. И последнее веяние — слой «обертки» Web-служб.

Средства разработки. Инструментарий разработчиков нередко определяет круг их возможностей по обеспечению поддержки различных платформ. Все еще актуален переход с компиляторов для MS-DOS на современные среды разработки. В свое время многие программисты сделали этот шаг, выбрав инструментарий быстрой разработки наподобие Progress, Gupta или PowerBuilder. И если Oracle может себе позволить развивать Oracle Developer, предлагая специальный пакет миграции на Java, а Microsoft достаточно планомерно переходит с Visual FoxPro на Visual Basic и, далее, на Visual Studio.Net, то остальным поставщикам труднее находить средства для миграции. Приверженцы же Delphi остались особняком. Переход на новый инструментарий требует фазы адаптации к новой среде разработки и ее нюансам.

Проекты интеграции приложений не являются проектами реинжиниринга в прямом смысле, но нередко сопровождаются изменениями информационной системы предприятия. К примеру, задачи поддержки единой системы аутентификации (single sign-on) или включения приложений в единый портал приводят к необходимости модификации на уровне исходных текстов программ. И наоборот, при миграции систем приходится задуматься о подходе к интеграции приложений. Например, при наличии территориально-распределенной инфраструктуры эта задача решается за счет применения шин обмена сообщениями или данными. Пересечения с рассмотренными типами проектов можно найти в проектах интеграции приложений на уровне взаимодействия компонентов, в которых необходимо обеспечить поддержку стандартов и протоколов, подобных SOAP, на уровне каждого модуля.

Миграция баз данных

Многие тиражируемые решения разрабатываются для предприятий разного масштаба и для широкого круга клиентов, каждый из которых имеет свои предпочтения. Даже если вести разработку в соответствии с требованиями отдельной фирмы, вполне может возникнуть необходимость в применении различных серверов. Скажем, в территориально-распределенной компании центральный офис может работать на платформе Oracle, филиалы, оперирующие меньшими объемами данных и имеющие не очень много сотрудников, — MS SQL Server, а мобильные пользователи — MS SQL Desktop или Sybase.

Фундаментальные работы исследователей IBM легли в основу языка SQL, который стал стандартом для реляционных баз данных. Кроме того, как минимум три значимые спецификации SQL были подготовлены в ANSI, но ни одна из них не удовлетворяет всем требованиям разработчиков и пользователей к более-менее сложной обработке данных. Достаточно сравнить длинный список реализованных на различных серверах математических, строковых, финансовых и иных функций с коротким перечнем возможностей, декларированных в стандарте ANSI.

Если неукоснительно следовать стандартам, можно столкнуться с проблемой производительности, и придется обращаться к специальным функциям, обеспечиваемым поставщиком платформы. К примеру, Oracle для хранимых процедур и сценариев применяет собственный язык PL/SQL, а Microsoft еще со времен совместной работы с Sybase использует Transact-SQL или T-SQL. Побочный эффект — несовместимость решений, означающая для потребителей либо выбор в пользу конкретной платформы, либо программирование с ориентацией на несколько серверов баз данных.

Специфичны для каждого из серверов баз данных логическая и физическая организация хранения данных, соответствующий набор операторов и команд для управления сервером и объектами базы данных. Так, для Oracle это datafiles, tablespaces и schemes, в то время как в SQL Server такого набора операторов нет.

Возможны следующие типы расхождений при работе с различными СУБД:

  • логическая и физическая организация хранения данных (распределение таблиц, индексов и других объектов базы по файлам, областям, пакетам, владельцам, схемам и т.п.);
  • аутентификация, распределение прав доступа и система безопасности (пользователи, группы, роли);
  • структура баз данных (типы данных и размеры полей, ограничения на поля, индексы и т.п.);
  • ссылочная целостность (первичные и внешние ключи, ссылки между таблицами);
  • программирование триггеров, хранимых процедур и пользовательских функций (встроенные языки программирования сценариев), SQL-запросы, команды и операторы (поддержка уровня ANSI, конструкции запросов, встроенные функции и т.п.);
  • преобразование данных (обработка пустых полей и значений NULL, конвертация дат в числа или строк в числа и т.п.);
  • программный интерфейс клиентской части для прямого доступа к программам, составляющим СУБД, например, Oracle Call Interface (поддержка связанных переменных, обработка массивов записей в пакетном режиме, обработка результатов запросов);
  • драйверы верхнего уровня (интерфейсы ODBC, JDBC, OLEDB, ADO, DAO);
  • поддержка транзакций (однофазных и двухфазных, протокола XA и т.п.);
  • администрирование и сопровождение сервера, резервные копии, оптимизация производительности и масштабируемости, балансировка нагрузки;
  • поддержка нижележащей операционной системы — клоны Unix (Sun Solaris, HP-UX, IBM AIX, Linux) и Windows, протокол взаимодействия клиента с сервером и поддержка транспортного уровня (TCP/IP, IPX/SPX, NetBIOS).

Применяя те или иные языки программирования, среды и инструменты разработки, готовые компоненты третьих фирм и модули, поставляемые производителем сервера баз данных, можно абстрагироваться от части перечисленных типов различий, но не от всех. Например, драйверы ODBC и OLEDB «третьих» производителей (таких как Merant/Intersolv или OpenLink) хотя кое-как и позволяют работать с базой, но не гарантируют отсутствия проблем при обработке специфических запросов.

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

  1. Общий (разветвленный) код для различных источников данных. Специфика учитывается за счет разветвленного кода, а также через константы, функции, унаследованные классы и другие возможности языка программирования.
  2. Один компонент (единая точка) для разных источников данных. Программа целиком разрабатывается с ориентацией на одну из СУБД или определенный стандарт, абстрактный уровень, а специфика учитывается за счет перехвата подготовленных текстов запросов и обращения к драйверам доступа к базе в единой точке обработки запросов.
  3. Много компонентов (специфичный код) для разных источников данных. Слой приложения, ответственный за взаимодействие с базой данных, полностью выделен; для каждого сервера баз данных применяется свой компонент с общими входными и выходными параметрами и различной реализацией.

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

Если применять разветвленный код, он теряет стройность, занимает в скомпилированном виде больше места и становится тяжелым в поддержке и отладке. Разработчикам сложно синхронизировать изменения, создавая несколько модулей для СУБД разных поставщиков. Это также доставляет неудобства администраторам и сопровождающему персоналу. В отношении оптимизации отдельные компоненты эффективнее, а использование разветвленного кода обуславливает потери производительности на многочисленных проверках, цель которых состоит в выяснении того, для какого именно сервера составляется запрос, или данные из какого источника обрабатываются.

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

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

Применение CASE-средств и ERD-нотаций (Entity-Relationship Diagrams — диаграммы «сущность-связь») сокращает усилия по поддержке различных серверов баз данных или их переносу на другую платформу, но не стоит полагаться на штатные средства генерации структуры, триггеры и процедуры, предназначенные для конкретной СУБД. Результат генерации CASE-средств необходимо проверять и корректировать «вручную». Мощные инструменты класса PowerDesigner или ERwin позволяют настраивать логику генерации логической схемы базы на физические объекты с учетом конкретного целевого сервера.

На этапе проектирования следует обратить внимание на именование объектов базы данных. Такие параметры, как длина имени, наличие в нем цифр и специфичных символов, могут оказаться причиной серьезных проблем. Если SQL Server поддерживает имена длиной до 128 символов, то Oracle по умолчанию — не более чем до 18 (иначе необходимо использовать кавычки), а DB2 — до 8 для ОС AIX.

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

Обычно проектировщики и программисты стараются отложить «на потом» логическое и физическое распределение объектов базы данных по файлам, пакетам, областям, схемам и владельцам. Но, в зависимости от типа сервера и его функций, такое распределение может сыграть серьезную роль в обеспечении безопасности, производительности, масштабируемости и даже совместимости с другими приложениями, если они эксплуатируются на том же физическом сервере, что и база данных. Простой пример: если создавать по умолчанию таблицы, каждая СУБД будет выделять определенный временной квант под их начальное размещение и последующий рост. Если же два приложения попытаются создать таблицы с одним и тем же именем, возникнет конфликт.

Типы, размеры и точность данных, даже указанные в стандарте ANSI, различаются в реализации каждого сервера баз данных; соответственно, при работе с ними система будет вести себя неоднозначно. Самое сложное — обработка данных большого размера, а также бинарных и текстовых (image и text у MS SQL Server; LONG, BLOB и CLOB у Oracle и т.д.). Для каждого сервера характерны свой подход, свои ограничения, свой набор функций. Так, в SQL Server есть отдельный сервис MS Search, обеспечивающий функции Full-Text Search, а Oracle предлагает пакет PLSQL. Другой пример: SQL Server оперирует отдельными административными функциями при заполнении списка шумовых слов (noise words) для каждого из языков посредством импорта из внешних файлов, а аналогичная функция в Oracle (stop words) доступна только для одного языка и хранится в системных таблицах с доступом через представление CTX_STOPWORDS. Такие функции требуют вспомогательных специальных индексов, для создания которых SQL Server использует системную процедуру sp_fulltext_table, а Oracle — специальный тип CTXSYS.CONTEXT и процессы job.

Каждый сервер баз данных содержит свои системные поля, которые могут быть полезны при разработке определенных алгоритмов, но станут камнем преткновения при миграции на другой сервер. К примеру, генерация значений для ключей и кодов при помощи IDENTITYCOL в SQL Server имеет аналог в Oracle в виде отдельных объектов-нумераторов SEQUENCE; в других СУБД при генерации следующего значения последовательности необходимо реализовывать сложный механизм с триггерами, дополнительными таблицами и алгоритмами разрешения конфликта блокировки. Еще один пример: уникальный идентификатор записи, по-своему интерпретируемый серверами баз данных (скажем, ROWID у Oracle и DB2). Для одного сервера этот идентификатор свидетельствует о физическом расположении строки и меняется при реорганизации хранения таблиц, в то время как для другого — означает версию строки, меняется при каждой операции INSERT, UPDATE и DELETE над данной строкой и может использоваться в запросах наряду с первичными ключами для определения того, не менялась ли запись.

В корне различаются языки программирования скриптов, триггеров, хранимых процедур и пользовательских функций. Если для Oracle это PL/SQL, для MS SQL Server — T-SQL, то IBM DB2 и вовсе оперирует модулем, скомпилированным при помощи внешнего компилятора. В последнее время некоторые производители стали применять виртуальные Java-машины для создания хранимых процедур, но их совместимость со спецификациями Java — разная.

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

Информационные системы масштаба предприятия должны быть надежно защищены, а потому в них следует обеспечивать разделение доступа к данным. Однако, из-за пробела в стандартах на откуп производителям СУБД отдана организация управления пользователями и их профилями, определение групп и ролей, а также распределение привилегий. В Oracle имеется достаточно развитая собственная система аутентификации и авторизации пользователей, с некоторыми ограничениями возможна поддержка операционной системы (к примеру, только аутентификация в Windows), в то время как DB2 целиком полагается на ОС, и, как следствие, реализации для AIX и Solaris различаются. MS SQL Server может применять как встроенную авторизацию отдельных пользователей и их групп, так и интегрированную с Windows NT или Active Directory.

Наконец, разница в реализации стандарта SQL: это синтаксис SQL-выражений (например, внешние соединения outer join, «+» в Oracle и LEFT JOIN в SQL Server), конструкции SQL-запросов (например, вложенные подзапросы) и т.д. Нюансы могут проявиться в обработке значений пустого поля и NULL-значения (при сортировке строк один сервер помещает пустые строки в начало, а другой — в конец результирующего множества). По-разному интерпретируются и правила преобразования данных в различных системах. Некоторые программисты любят полагаться на «умолчания» — и напрасно: если один сервер позволяет использовать операнды разных типов и приводит их к единому знаменателю, то другой генерирует ошибку.

Каждый производитель снабжает свою СУБД определенным числом встроенных системных функций, переменных, процедур и ключевых слов. Самый простой пример — получение системной даты в SQL-выражениях: вызов функции GETDATE () в SQL Server, вставка ключевых слов CURRENT DATETIME в IBM DB2 и SYSDATE в Oracle. Более сложный пример — обработка полнотекстового поиска. Для обработки объектов большого размера (текстовых полей) Oracle поставляет отдельный пакет interMediaText, который добавляется в пакет PL/SQL вместе с набором функций, а у SQL Server — это отдельный же компонент MS Search.

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

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

Заключение

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

Артак Оганесян (ArtakO@moscow.vdiweb.com) — руководитель проектов компании Vested Development (Москва). Примеры, которые иллюстрируют статью, взяты автором из богатого реального опыта своей компании.

ПРИМЕР1: Миссия невыполнима

После провала двух проектов никто не верил, что CRM-решения компании Pivotal можно перенести на сервер баз данных Oracle — слишком тесной была их интеграция с MS SQL Server. Двухзвенная архитектура первых версий таких решений (тогда их еще относили к категории Sales Force Automation) основывалась на цепочке технологий Microsoft — VC++, DCOM, ODBC, SQL Server 7.5. В систему изначально был заложен собственный инструментарий быстрой разработки структуры данных и логических объектов, поисковых схем и пользовательских запросов, экранных меню, форм, отчетов и т.д. На его основе Pivotal разработала трехзвенную архитектуру следующих версий с использованием Internet Explorer, ActiveX, COM+, OLE DB и SQL Server 2000. Представляя Windows 2000, Билл Гейтс среди решений масштаба крупных предприятий отметил и Pivotal eRelationship 2000.

На волне популярности CRM продукты компании Pivotal стали бестселлерами. Появились действительно крупные заказчики, часть которых в качестве корпоративного стандарта использовала СУБД от Oracle и IBM. Поэтому в Pivotal решили пополнить семейство своих продуктов. Проект их перевода на платформу Oracle был передан на аутсорсинг в Индию, затем в Ирландию, но обе попытки оказались неудачными. Разработчики не сумели реализовать формирование SQL-запросов к динамической базе данных, не справившись с непредсказуемостью пользовательских функций и запросов. Проблемой оказалось и обеспечение полной совместимости функционала версий Oracle и MS SQL Server. Но после прихода в Pivotal нового руководителя отдела разработок, имевшего положительный опыт аутсорсинга в России, шанс реализовать данный проект получила третья проектная группа.

Для снижения риска проект разбили на фазы. Первая из них заключалась в тщательном анализе исходных текстов. Проектная группа, исследовав драйверы ODBC и OLEDB, поставляемые Microsoft, Oracle и другими производителями, собрала статистику результатов конструирования динамических и пользовательских SQL-запросов и протестировала «поведение» аналогичных SQL-конструкций при выполнении в MS SQL Server и Oracle. Было сформулировано техническое задание, на 150 страницах которого описывались стратегия переноса, выявленные различия, проблемы и методы их решения, давались фрагменты специфичного программного кода и SQL-предложения в качестве примеров реализации.

Проблема динамически составляемых запросов была решена за счет встраивания в точки вызова драйверов ODBC и OLEDB процедуры синтаксического разбора конструкций SQL, которая сперва разбирала их на составные части, а затем собирала с реструктуризацией, заменами и подстановками текст запросов для СУБД Oracle. Для конечного пользователя эти изменения были прозрачными, и на обоих серверах баз данных система работала одинаково. Единственным дополнением стали функции администрирования базы данных — управления логической и физической структурой данных Oracle. Предоставляемые Oracle средства аутентификации и распределения прав доступа адаптировали к аналогичным средствам продуктов Pivotal на базе MS SQL Server.

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

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

Наконец, финальная фаза заключалась в обеспечении работоспособности решений на базе Oracle и SQL Server при совместной работе в распределенной среде.

Теперь с помощью решений от компании Pivotal, крупные организации имеют возможность размещать автономные центры обработки CRM-данных в разных офисах, настраивая регламент синхронизации такой информации и поддерживая серверы баз данных разных производителей. Это позволяет создавать масштабируемые решения, оптимальные по стоимости владения, например, при установке в центральном офисе СУБД Oracle, а в территориально-удаленных филиалах или просто небольших подразделениях — автономного сервера MS SQL Server Enterprise Edition. Более того, мобильные сотрудники (они составляют немалую часть пользователей CRM) могут работать с SQL Server Personal Edition, реплицируя подмножество корпоративной базы данных.

ПРИМЕР2: Перенос унаследованного решения с мэйнфрейма

Компания Xenergy была основана в 1975 году, в самый разгар энергетического кризиса на Западе. Ее единственным продуктом была программа XenCAP, которая предназначалась для оптимизации потребления электроэнергии, природного газа и коммунальных услуг за счет сбора статистических данных и их последующего анализа. Экономия различных предприятий, госучреждений и частных домовладельцев от применения этой программы оказалась настолько ощутимой, что она получила широкое распространение в США и Канаде.

Одним из компонентов системы был модуль печати, ввода и обработки опросников для частных потребителей энергии, позволявший энергетическим корпорациям и коммунальным службам планировать пики нагрузок и избегать кризисов в поставках для множества малых клиентов. Благодаря распространению Internet появилась возможность облегчить процедуру заполнения опросников. Кроме того, в последние годы продажам XenCAP стала мешать устаревшая платформа: код на PL/1 и компьютеры DEC VAX с СУБД DB2. Поддержка системы обходилась все дороже.

Были сформулированы следующие цели реинжиниринга:

  • перейти на современную платформу с условием возврата инвестиций за три года;
  • обеспечить масштабируемость «в обе стороны» — от малого до очень большого числа пользователей;
  • перевести опросники и АРМ ввода исходной информации на Web-технологии, чтобы устранить необходимость в администрировании клиентских станций;
  • автоматизировать импорт данных и обработку опросников;
  • упростить администрирование системы, создав удобный АРМ сопровождающего персонала.

Был объявлен тендер на реализацию проекта. Выбранное предложение включало в себя полное технико-экономическое обоснование рекомендуемого подхода к реинжинирингу системы. Заказчику был представлен сравнительный анализ возможных целевых серверов приложений (Java/J2EE/EJB и VC++/COM+) и серверов баз данных (Oracle, DB2, SQL Server). Более того, была произведена предварительная оценка совокупной стоимости владения системой с учетом всех работ, затрат на лицензии и требований к сопровождению для платформ IBM, Sun Microsystems, Oracle, BEA Systems и Microsoft. В Xenergy остановили свой выбор на решении, основанном на технологиях Microsoft; для сохранения гомогенности платформы и снижения общей стоимости владения было намечено обеспечить поддержку только одного сервера базы данных.

Оказалось, однако, что исходные тексты PL/1 были не документированы, а заложенная в программу математическая модель нигде не была описана. Аналитикам подрядчика пришлось провести обратное проектирование («реверс-инжиниринг«), чтобы восстановить алгоритмы, разобраться в структуре данных и назначении тех или иных частей системы. Лишь после документирования математической модели удалось приступить к проектированию системы.

Разработчики создали прототип пользовательского интерфейса, который был согласован с представителями заказчика и усовершенствован в ходе тестирования. Техническая реализация включала в себя перенос математических расчетов на VC++; при этом использовались механизмы распределенных вычислений и балансировки нагрузки для реализации требований масштабируемости. Был переработан функционал создания и обработки опросников, и персонал Xenergy смог с помощью визуального конструктора составлять списки вопросов и варианты ответов, расширяя реквизиты форм.

Для поддержки новых функций при переходе с DB2 на SQL Server была перепроектирована структура базы данных, но преемственность сохранилась. Сегодня расчетное ядро системы основано на структуре данных и алгоритмах, созданных в 1975 году и полностью «реставрированных».

Советы и выводы

Нельзя полностью доверять производителям, поставщикам и консультантам, которые говорят о стандартах, гарантирующих переносимость и совместимость. Подтверждением этого может послужить цитата из книги Майка Вилсона «Разница между Богом и Ларри Эллисоном»: «Переносимая программа подобна танцующей свинье. Поразительно не то, насколько хорошо свинья танцует, а сам факт того, что она танцует». Эти строки были написаны на заре становления индустрии разработки программного обеспечения, но проблемы миграции актуальны до сих пор.

Конечно, давно прошло время, когда программы писались в машинных кодах, но и отделенные от низкоуровневого программирования разработчики все еще привязаны к платформе и конкретной реализации того или иного стандарта. Ни один запрос к базе данных, составленный в соответствии со столь известным стандартом ANSI SQL, не дает полностью одинаковых результатов на различных серверах баз данных. Более того, при работе через драйверы, совместимые с ODBC, JDBC или OLEDB, на запрос накладываются специфические ограничения конкретной реализации средств доступа к базе данных. Даже не самые критичные, на первый взгляд, различия (скажем, точность представления даты или зависимость от регистра символов при сравнении строк) могут серьезно повлиять на работоспособность приложения.

Различия имеются и на уровне серверов приложений: обещанная по отношению ко всем Java-платформам совместимость со стандартом J2EE не всегда оказывается полной.

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

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

Еще одно распространенное заблуждение таково: при переносе решения на новую платформу или его создании «с нуля» достаточно лишь дополнить прежнюю функциональность новыми возможностями — в соответствии с изменившимися требованиями. Как показывает опыт, количество накопившихся пожеланий и замечаний может вылиться в переосмысление всего функционала, пользовательского интерфейса и архитектуры системы в целом. Яркий пример — средства разработки 4GL, популярные во времена архитектуры «клиент-сервер». Они не сумели адаптироваться к Web-технологиям, поэтому многозвенная архитектура, имитируемая средой исполнения 4GL-программ, получилась достаточно тяжеловесной.

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

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