Перенос файл-серверных приложений в среду клиент-сервер

Перенос файл-серверных приложений в среду  клиент-сервер

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

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

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

Существует  несколько подходов к интеграции и адаптации файл-серверных приложений к архитектуре клиент-сервер:

  • использование библиотек доступа к серверам БД;
  • связь с сервером БД через открытый протокол ODBC;
  • укрупнение файл-серверных приложений.

Чтобы оценить  возможности этих способов, рассмотрим их несколько подробнее.

3.3.1. Библиотеки доступа к базам  данных

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

Система управления записями Clarion достаточно легко связывается с сервером баз данных Btrieve через библиотеку доступа. Нужно только заметить, что Btrieve не является SQL-сервером БД, что затрудняет программирование с использованием этого средства.

Приложения, построенные на Clipper, можно адаптировать с помощью программного интерфейса с выбранным сервером БД. Для примера рассмотрим библиотеку интерфейса Clipper-Oracle.

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

С помощью  функций этой библиотеки можно выполнять  следующие операции над таблицами  базы данных системы Oracle:

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

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

Кроме того, существует возможность прямого  использования языка SQL, который  является основным языком обработки  данных не только в системе Oracle, но и в большинстве других развитых СУБД.

Версия языка SQL, реализованная в Oracle, ориентирована на стандарт этого языка и содержит ряд ограничений. Например, оператор Fetch позволяет перемещаться по результирующей таблице только в одном направлении, исключая возвраты назад. Функции библиотеки снимают эти ограничения.

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

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

В состав библиотеки входят следующие функции:

INIT ()   подключение к Oracle;

OPEN ()   открытие таблицы;

INSERT () добавление  строки;

UPDATE () корректировка  строки;

DELETE () удаление  строки;

SELECT () поиск строки;

NEXT ()   чтение следующей строки;

SET ()    чтение строки по относительному  номеру;

SKIP ()   пропуск строк;

FILTER () выбор  строк по условию;

GETIND () сохранение  индекса;

SETIND () установка  индекса;

COMMIT () конец  транзакции;

SAVE ()   установка контрольной точки;

ROLL ()   откат транзакции;

LOCK ()   блокировка таблицы;

SQL ()    выполнение оператора SQL;

CLOSE ()  закрытие  таблицы;

STOP ()   отключение от Oracle.

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

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

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

3.3.2. Протокол ODBC и его реализации

Интерфейс прикладного  программирования ODBC API предоставляет  общие методы доступа на основе языка  баз данных SQL как к реляционным, так и к нереляционным (ISAM) источникам данных.

Наиболее  современный стандарт ANSI SQL (фактически, это часть разрабатываемого стандарта SQL-3) включает спецификацию интерфейса на уровне вызовов (CLI - Call-Level Interface), на которую опирается ODBC для обеспечения доступа и работы с данными во многих системах управления базами данных. Интерфейс CLI соответствует требованиям, установленным в 1996 году комитетом SQL Access Group и определяющим общий синтаксис SQL и интерфейса API. Иметь общий метод доступа к источникам данных удобно потому, что тогда база данных на сервере становится прозрачной для приложений, которые написаны в соответствии со специфицированным уровнем совместимости ODBC.

Интерфейс ODBC API реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL - это основная библиотека управления драйверами ODBC, которая содержит функции вызовов специализированных драйверов для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем CLI и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.

Одноуровневые драйверы предназначены для использования  при работе с теми источниками  данных, которые не могут быть прямо  обработаны с использованием ANSI SQL. Обычно это локальные базы данных на персональных компьютерах, такие  как dBase, Paradox, FoxPro и Excel. Драйверы, соответствующие этим базам данных, производят компиляцию ANSI SQL в наборы инструкций более низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.

Многоуровневые  драйверы используют сервер РСУБД для  обработки SQL-предложений и предназначены  для работы в среде клиент-сервер. Помимо обработки ANSI SQL, они также  могут поддерживать и собственные  конструкции конкретной РСУБД, поскольку ODBC может без трансляции передавать SQL-операторы источникам данных (механизм "passthrough"). Драйверы ODBC для баз данных, поддерживаемым в технологии клиент-сервер реализованы для Oracle V 6.0 и Oracle V 7, а также Informix, Microsoft и Sybase SQL Server, Rdb, DB2, Ingres, HP/Image и An SQL. Драйверы можно приобрести в фирмах Microsoft, Intersolv, Visigenic и Openlink, причем только Microsoft и Intersolv выпускают и 32-х, и 16-ти разрядные драйверы.

Существует 4 важных этапа (шага) процедуры запроса  данных через ODBC API.

  • Шаг 1 - установление соединения. Первый шаг состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.
  • Шаг 2 - выполнение оператора SQL. Выделяется указатель оператора, локальные переменные связываются со столбцами в SQL-выражении (это необязательное действие), и выражение представляется главному ODBC-драйверу для обработки.
  • Шаг 3 - извлечение данных. Перед извлечением данных возвращается информация о результирующем наборе, в частности, число столбцов в наборе. Исходя из этого числа, результирующий набор помещается в буфер записей, выполняется цикл его просмотра и содержимое каждого столбца помещается в соответствующую локальную переменную. Этот шаг необязателен, если используется связывание столбцов с локальными переменными.
  • Шаг 4 - освобождение ресурсов. После того, как данные получены, ресурсы освобождаются путем вызова функций освобождения указателей оператора, соединения и среды. Указатели оператора и соединения могут быть использованы в процессе обработки.

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

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

3.3.3. Укрупнение приложений (Upsigsing)

Пакет Microsoft Access Upsizing Tools позволяет автоматизировать процесс перехода от настольных баз данных к архитектуре клиент-сервер, в данном случае - от Microsoft Access к Microsoft SQL Server для Windows NT. Данный продукт добавляет к Access такие модули, как Upsizing Wizard и SQL Server Browser. Upsizing Wizard позволяет задать все параметры процесса переноса данных с помощью серии диалогов, а затем создает саму базу данных, журнал транзакций, таблицы, индексы, правила проверок значений данных, отношения между таблицами и поля типа timestamp (временная метка). Browser позволяет управлять объектами Access Server с помощью Access-подобного интерфейса. В комплект поставки также входит дискета с ODBC 2.0 и ODBC-драйвером для Microsoft SQL Server. База данных Access (файл с расширением .MDB) содержит таблицы данных и индексы, а также компоненты управления данными (запросы, макросы, модули, формы и отчеты).

Применение  Microsoft Access Upsizing Tools основывается на концепции прозрачного для пользователя размещения данных: перенос информации в базу данных SQL Server при сохранении в исходном виде остальной части Access MDB. Access способен работать в качестве клиента в архитектуре клиент-сервер, поэтому разработчикам, переносящим приложения с помощью этого инструмента, не нужно отказываться от Access. Запросы, отчеты и прочие объекты остаются в неизменном виде, так как Upsizing Wizard перенаправляет их на экспортированные таблицы, переименовывая при этом локальные таблицы.

Upsizing Wizard учитывает при переносе ряд архитектурных различий между Microsoft Access и SQL Server для Windows NT. Он экспортирует таблицы и их свойства, такие как правила проверок, значения по умолчанию и индексы. Он выполняет такие операции, как добавление поля типа timestamp, преобразование отношений между таблицами Access в триггеры, поддерживающие ссылочную целостность, и даже создание INSERT-триггеров для аналогов автоинкрементируемых полей Access типа Counter. Upsizing Wizard не экспортирует из базы данных Access сведения о пользователях, группах и правах доступа, поэтому администратор базы данных должен устанавливать права доступа вручную. Upsizing Wizard создает подробный отчет, содержащий имена баз данных и размеры, параметры переноса, триггеры, таблицы (старые и новые), а также информацию об ошибках, возникших в процессе работы.

Модули Microsoft Wizard - это инструменты для автоматизации операций, направляющие действия пользователя в нужной последовательности. Access Upsizing Wizard не является примитивным продуктом, так как пользователю может понадобиться вручную конфигурировать систему для обеспечения нормальной работы, но, несмотря на это, покупка Microsoft Access Upsizing Tools будет оправдана для тех, кому необходимо перемещать данные из Access в SQL Server. Эта программа автоматизирует большинство рутинных моментов процесса, которые могут оказаться утомительными и нетривиальными, а документация включает специальный раздел по оптимизации использования Microsoft Access в качестве клиента в приложениях типа клиент-сервер.


Перенос файл-серверных приложений в среду клиент-сервер