Технология Клиент-Сервер 1999'1

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Опыт применения пакета “Informix – Gateway to the Future” для перевода Clipper-систем в среду клиент-сервер

Иванов Сергей Васильевич,
Молодыка Сергей Петрович,
Тетенев Алексей Леонидович, компания Корвус

1. У истоков проблемы

Характерной особенностью развития автоматизированных систем на постсоветском пространстве стало широкое распространение файл-серверной архитектуры и баз данных DBF-формата. Как правило, эти системы работали под управлением ОС MS-DOS и NetWare. Использование такой программной платформы позволяло с относительно небольшими затратами создавать приложения, способные с достаточными быстродействием обеспечивать одновременную работу десятков пользователей.

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

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

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

Причиной этому явились общеизвестные недостатки файл-серверных технологий:

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

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

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

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

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

Однако, возникает правомерный вопрос: “Что делать с устаревшими программными комплексами и вложенными в них средствами и знаниями?”

2. Возможные решения

Существуют несколько вариантов решения проблемы устаревших файл-серверных систем:

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

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

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

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

Достоинствами подобной технологии являются:

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

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

3. Решение от Informix

Свой вклад в развитие идеи миграции внесла и компания Informix, предложив пакет “Informix – Gateway to the Future”, программным компонентом которого является Informix Direct Driver (IDD).

Информацию об этом продукте можно получить из статей, которые уже появлялись в Informix Magazine/RE, а также из документации производителя. Поэтому здесь мы ограничимся только самыми общими сведениями.

Алгоритм работы драйвера основан на идее замещения стандартного драйвера доступа к данным (RDD). Новый драйвер динамически интерпретирует Clipper-команды, переводя их в SQL-запросы, а затем преобразует полученные данные в формат Clipper и возвращает их клиентскому приложению.

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

Промежуточный компонент может работать под управлением ОС Solaris, SCO Unix и MS Windows NT. Кроме того, по сообщениям разработчиков, этот список вскоре пополнит и Linux, что позволит получить надежность и функциональность Unix за скромную цену.

Клиентская часть состоит из программы ipxclien.exe, а также скомпонованного с библиотекой ifx.lib Clipper-приложения. При этом, ipxclien.exe обеспечивает сетевое взаимодействие рабочей станции с промежуточным компонентом, а библиотека - преобразование обращений Clipper к базе данных и возвращаемые результаты.

В полном соответствии с концепцией миграции, предлагаемая технология позволяет практически не изменять тексты программ клиентских приложений. Исключение составляют некоторые конструкции Clipper, которые не поддерживаются драйвером. Кроме того, учитывая, что драйвер обеспечивает использование механизмов выполнения транзакций и контроля целостности данных СУБД Informix, можно смело исключить из старых текстов соответствующую (и немалую) часть кода.

Для работы с промежуточным компонентом используется протокол IPX/SPX, который используется в сетях под Novell NetWare. Это позволяет клиентам параллельно работать как с файл-сервером, так и с промежуточным компонентом.

4. Дополнительные возможности

Помимо собственно внедрения Clipper-приложения в новую среду, данная технология предоставляет также ряд дополнительных возможностей, которые позволяют значительно повысить производительность модернизированной системы. Среди наиболее интересных хотелось бы отметить:

использование хранимых процедур СУБД Informix и SQL-операторов в приложениях, написанных на Clipper;
собственный механизм фильтрации;
буферизацию часто используемых данных на промежуточном компоненте.

Использование хранимых процедур и SQL-операторов

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

Достаточно большой интерес представляет возможность вызова хранимых процедур СУБД Informix. Рекомендуется максимально использовать ее в задачах, где производительности Clipper не достаточно. К таким задачам относятся, прежде всего, обработка и, особенно, модификация больших объемов данных, например, подготовка данных для сложных отчетов.

Новый механизм фильтрации

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

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

Управление буферизацией

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

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

5. Первый эксперимент

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

Этот продукт был разработан для решения задач взаимодействия банка второго уровня с платежными системами и реализовал следующие функции:

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

Текст программ содержит более 45 тысяч строк, используются 51 экранная форма. База данных состоит из 82-х DBF- и 102-х индексных файлов. Объем данных поддерживается (за счет периодической упаковки) на уровне 50 Мб. В общей сложности на разработку этого комплекса было затрачено 3,2 ч/м.

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

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

6. Особенности перевода

Открытие базы данных

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

Вариант с установкой драйвера IFX драйвером по умолчанию нас не устроил. Система работает не только с “постоянными” таблицами, но и с разного рода обменными файлами в формате DBF, что становится невозможным при подобном подходе.

Внесенные нами изменения достаточно невелики и сходны с кодом обработки других RDD-драйверов, например, DBFCDX (см. приведенный ниже пример программы). Суть сводится к передаче функции открытия типа используемого драйвера и замены функций проверок (на наличие файлов данных и индексных файлов) аналогичными функциями драйвера.

FUNCTION OpenDbf(cDbfName,aNtxNames,cAlias,lExclusive)
LOCAL k, nCount:=0, nSel

  IF !TabExist(cDbfName)
    Diagn("Не найдена таблица Informix "+cDbfName,11)
    RETURN .F.
  ENDIF

  WHILE nCount++<10

 DBUSEAREA(.T.,'IFX',cDbfName,cAlias,!lExclusive)
     IF (nSel:= SELECT(cAlias))#0
       DBSELECTAR(nSel)
       EXIT
     ENDIF
     MILLISEC(500)
   ENDDO
 
   IF nCount>10
     Diagn("База данных "+cAlias+" блокирована другим пользователем",11)
     RETURN .F.
   ENDIF

 
   IF LEN(aNtxNames)>0  // если есть индексные файлы
     FOR k:=1 TO LEN(aNtxNames)
       IF !IdxExist(cDbfName,aNtxNames[k])  // файл не найден - ошибка
        Diagn("Не найден индекс "+aNtxNames[k]+ " для таблицы”;
        +”Informix "+cDbfName,11)

        RETURN .F.
      ENDIF
    NEXT
    AEVAL(aNtxNames,{|x|DBSETINDEX(x)}) // открытие индексных файлов
    DBSETORDER(1)
  ENDIF
RETURN .T.

Переиндексация баз данных

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

Программные изменения также аналогичны переводу системы на другой драйвер. Отличием является обработка отсутствия в Informix Direct Driver возможности модификации индексного выражения (см. текст программы). Для корректной работы процедуры переиндексации требуется удаление и последующее создание нового индекса, с тем же именем.

 FUNCTION ReindexBase(cDbfName,aIdx)
LOCAL nSqlErr, cIdx, cKey, j

  FOR j:=1 TO LEN(aIdx)
     cIdx:=aIdx[j,1]
     IF IdxExist(cDbfName,cIdx) // если уже  существует индекс с таким
                                //именем, то его нужно удалить
      DropIdx(cDbfName,cIdx)
       // удаление индекса Informix
      nSqlErr:=IFXSQL("DROP INDEX "+cIdx) 
       IF !nSqlErr==-319.AND.!nSqlErr==0 // 319:  Индекс не существует

         Diagn("Ошибка "+ALLTRIM(STR(nSqlErr))+": "+IFXERRMSG(),11)
      ENDIF
    ENDIF
  NEXT

  IF !OpenDbf(cDbfName,{},cDbfName,.T.)
    RETURN .F.
  ENDIF
 
   FOR j:=1 TO LEN(aIdx)
     cIdx:=aIdx[j,1]
     cKey:=aIdx[j,2]
     INDEX ON &(cKey) TO &(cIdx) // создание индекса Clipper
     ifxCreateIndex(SELECT(), cIdx, cIdx) // создание индекса Informix
   NEXT
   USE
 RETURN .T.

Помимо эмуляции индекса Clipper драйвером предоставляется возможность создавать и индекс Informix, что существенно ускоряет работу с базой данных. Для этого используется функция ifxCreateIndex(). Однако, следует помнить, что при удалении индекса средствами Clipper не производится удаление индекса Informix. Для корректной обработки следует использовать SQL-оператор удаления индекса Informix.

Конструкции драйвера, работающие отлично от аналогичных в Clipper

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

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

Для корректной работы приложения рекомендуется использовать функцию
подсчета числа записей в таблице, удовлетворяющих условию фильтрации SQL-фильтра IFXRECCOUNT(). Данная функция возвращает корректное значение и без установки SQL-фильтра. Более того, по результатам экспериментов выяснилось, что установка “пустого” фильтра значительно увеличивает время выполнения функции. Что касается времени работы функции IFXRECCOUNT, то для таблицы, содержащей 100000 записей, время работы меньше одной сотой секунды.

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

Существует проблема с использованием процедуры ZAP для больших таблиц. В Clipper эта процедура удаляет данные на уровне файла, формируя заголовок “пустой” таблицы и заголовки “пустых” индексных файлов. Драйвер же удаляет данные по записям, видимо преобразуя ZAP в SQL-выражение delete from <имя таблицы>. При таком подходе процедура работает очень медленно. Более того, удаление производится в одну транзакцию, что не всегда возможно при больших объемах удаляемых данных.

В отличие от DBFNTX, где существует возможность доступа к записи, помеченной на удаление, в этой версии Informix Direct Driver записи сразу же удаляются из таблицы. Отсутствие такой возможности практически не сказалось на нашей системе, но, возможно, для некоторых других потребуется пересмотр логики отдельных задач.

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

7. Обнаруженные ошибки

В процессе нашего эксперимента были выявлены некоторые ошибки, часть которых уже устранена разработчиками. Так, в нынешней версии драйвера (Direct Driver for Clipper Version 0.96) существует ошибка в реализации механизма транзакций. Ошибка проявляется, когда после вызова SQL-оператора ROLLBACK WORK записываемых данных уже нет, а Clipper пытается сбросить все буфера при DBCLOSEALL(). Эта ошибочная ситуация исправляется добавлением DBCOMMIT() или DBUNLOCK() перед IFXSQL(“ROLLBACK WORK”).

  USE kodkl NEW VIA "IFX"
  SELECT kodkl
  IFXSQL("BEGIN WORK")
  DBAPPEND()
  Kodkl->lastkod:=1
  DBAPPEND()
  Kodkl->lastkod:=2
  DBCOMMIT()  // ¬
  IFXSQL("ROLLBACK WORK")
  CLOSE ALL

8. Некоторые недостатки

В текущей версии драйвера существуют некоторые недоработки. Например, не поддерживаются memo-поля и условные индексы.

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

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

9. Перспективы применения для перевода больших систем

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

Эта система содержит более 275 тысяч строк исходного текста. Ее база данных состоит из 276 DBF- и 417 индексных файлов. Интерфейс пользователя базируется на 504 экранных формах. На разработку системы было затрачено 207 ч/м. По нашим оценкам, прямой перевод этого программного продукта в архитектуру клиент-сервер потребовал бы не менее 480 ч/м.

Основываясь на результатах эксперимента и сравнительном анализе объемных характеристик вышеупомянутого терминала и данной системы, были рассчитаны планируемые трудозатраты на ее перевод с помощью Informix Direct Driver. По нашим оценкам, в этом случае прямые трудозатраты составят около 2 ч/м.

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

Сюда, конечно, следует добавить необходимые затраты на предварительный анализ исходных текстов с учетом особенностей IDD, приводимых в параграфах 6-8, однако, общие трудозатраты все равно будут существенно меньше, чем на прямой перевод системы в архитектуру клиент-сервер.

Понятно, что приведенные выше цифры не учитывают доработки программ, которые неизбежны при переводе столь крупных систем. Изменять придется, прежде всего, те компоненты ПО, которые сильно завязаны на особенности прежней архитектуры. В нашем случае это - процедуры автоматизированной замены версии и механизмы, использующие некоторые специфические возможности Clipper при работе с таблицами. Кроме того, без некоторых доработок модернизированная система будет работать медленнее старой. Здесь, можно использовать те дополнительные возможности по повышению производительности системы, которые предлагает IDD. Наконец, в каждой сложной системе, проработавшей несколько лет, всегда найдутся компоненты, бизнес-логику которых хотелось бы обновить.

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

10. Поддержка производителя

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

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

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

11. Выводы

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

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

Коротко о компании Корвус

Компания образована в октябре 1990 года. Приоритетным направлением деятельности является разработка интегрированных систем автоматизации. Среди заказчиков - Национальный Банк, Казначейство и Народный Сберегательный Банк Казахстана, Государственный Банк Внешнеэкономической Деятельности Туркменистана, ряд коммерческих банков, Министерство Национальной Безопасности Узбекистана, Высший Арбитражный Суд РФ.

по материалам Informix Magazine/RE