ОБЗОР АРХИТЕКТУР КЛИЕНТ-СЕРВЕР НА ОСНОВЕ ОДНОВРЕМЕННОГО ИСПОЛЬЗОВАНИЯ ПАКЕТОВ РАЗЛИЧНЫХ ФИРМ

I. История развития архитектуры вычислительных систем

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

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

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

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

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

Появилась группа пакетов, хорошо знакомых большинству пользователей персональных компьютеров. Это текстовые и графические редакторы, электронные таблицы, интегрированные пакеты, СУБД и т.д. Пользователи персональных компьютеров также широко используют такие оболочки, как Norton Commander, PC Tools, MS Windows. Пакеты для персональных компьютеров просты в освоении, хорошо используют все преимущества персональных компьютеров. Они облегчают работу по делопроизводству, финишную обработку информации, помогают в принятии решений.

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

Как правило пользователям компьютеров нужны и высокая вычислительная мощность и прекрасные свойства персональных компьютеров. Поэтому там, где для выполнения сложных вычислений используются мощные изолированные центральные компьютеры с терминалами, их пользователям периодически приходится ходить на персональные компьютеры для редактирования текстов или выполнения задач, использующих электронные таблицы. Это заставляет пользователей освоить 2 различные операционные системы (на больших машинах обычно установлены OC MVS, VMS, VM, UNIX, а на персональных - MS DOS/MS Windows, OS/2 или Mac) и не решает задачи совместного использования данных.

В результате опроса представителей 300 крупнейших фирм США, использующих персональные компьютеры, выяснилось, что для 81% опрошенных необходим доступ к данным более чем одного компьютера. Чтобы решить эту задачу, персональные компьютеры начали объединять в локальные сети и устанавливать на них специальные операционные системы, например, NetWare фирмы Novell, для совместного использования компьютерами сети файлов, размещенных в различных узлах сети. Эта технология называется файл-сервер.

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

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

Теперь нет необходимости иметь на столе 2 дисплея, однако большинство недостатков, присущих архитектуре с центральным компьютером, все еще сохраняется. Кроме того, хотя персональные компьютеры, имеющие дисплеи с картой VGA, позволяют работать с графикой, однако использовать их в качестве графического терминала большой центральной машины неудобно. Задача выполняется в центральном компьютере и по проводам передаются графические образы экрана. Эти образы довольно велики и скорость смены изображения на экране может быть очень низкой.

II. Архитектура клиент-сервер

Следующим шагом в решении описанной выше проблемы явилось использование архитектуры клиент-сервер. В такой архитектуре все компьютеры сети разделены на 2 группы: клиенты и серверы. Компьютер-сервер - это мощный компьютер с большой оперативной памятью и большим количеством дискового пространства. На нем хранится база данных и выполняется сложная обработка, требующая больших вычислительных ресурсов. На компьютерах-клиентах выполняются первичная обработка данных при вводе, форматирование данных, а также окончательная (финишная) обработка данных, извлеченных с сервера. В качестве компьютеров-клиентов обычно используются персональные компьютеры типа IBM PC или Macintosh. Преимущества архитектуры клиент-сервер очевидны. Каждый тип компьютера используется по своему назначению, а следовательно обеспечивается более полное использование возможностей компьютеров.

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

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

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

Архитектура клиент-сервер также позволяет ускорить работу приложений за счет минимизации объема информации, передаваемой по сети. Обычно от клиента к серверу передается запрос на обработку данных (а это обычно небольшое предложение на языке SQL). Выполнение запроса осуществляется на сервере и обратно клиенту передаются только те данные, которые удовлетворяют критериям запроса. В случае выполнения операций вставки, удаления, модификации данных или корректировки структуры БД обратно клиенту по сети передается лишь сообщение об успешности/неуспешности выполнения операции. Программы-серверы обычно разрабатываются так, чтобы максимально полно использовать возможности конкретной вычислительной платформы (компьютер + OC) и обеспечить максимальную производительность как можно большего числа одновременно работающих пользователей.

Дальнейшим развитием архитектуры клиент-сервер явилось использование в сети не одного, а нескольких серверов баз данных. Это позволило перейти от работы с локальной БД к работе с распределенной БД. Причем работа с распределенной БД "прозрачна" для пользователя, т.е. он работает с ней так же, как с локальной БД, не задумываясь о том, на каком сервере лежат его данные. Пользователь обращается к одному из серверов, тот, не найдя у себя нужных данных, автоматически обращается к другим серверам.

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

Конечно, реализация распределенной базы данных очень сложна. Требуется обеспечить надежность работы, целостность и непротиворечивость данных в узлах, перекодировку данных при передаче по сети, быстродействие в многопользовательском режиме работы, мощные средства администрирования. Поэтому для создания приложений с распределенной БД и распределенной обработкой используются специальные распределенные СУБД [1]. Наиболее известными из них являются Informix, Ingres, InterBase, Oracle, Sybase. Самые мощные из них, например, Oracle [2], позволяют одновременно использовать в одном приложении, работающем на сети, различные типы компьютеров, операционных систем, сетевых протоколов и СУБД.

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

В последнее время архитектура клиент-сервер получила дальнейшее развитие. Появилась архитектура, называемая равный к равному (peer to peer). Она реализована, например, в СУБД InterBase фирмы Borland и в СУБД Oracle7. При этой архитектуре все узлы сети являются равноправными, т.е. они являются и клиентами и серверами одновременно. Из любого узла сети можно запросить и обновить данные, хранящиеся на любом другом компьютере сети. При таком подходе деление компьютеров на серверы и клиенты становится условным, однако, поскольку программы-серверы требуют достаточно больших вычислительных ресурсов, архитектура равный к равному требует установки в узлах компьютеров с большой оперативной и дисковой памятью.

Очевидно, на сегодняшний день наиболее реально организовать работу с распределенной БД гетерогенной структуры, в которой часть узлов является и серверами и клиентами, а часть выступает только в роли клиентов. Следует заметить, что поскольку сервер БД обеспечивает одновременную работу с данными нескольких пользователей, он должен работать в многозадачной или многопользовательской операционной системе (например, OS/2, NetWare, Unix, VMS, MVS, VM, Windows NT).

Какими же соображениями следует руководствоваться при выборе компьютера для сервера? В первую очередь следует обратить внимание на быстродействие, стоимость и надежность компьютера. Так для задач, предъявляющих высокие требования по надежности работы могут использоваться особо надежные (Fault Tolerant) машины, машины и операционные системы, выполняющие дублирование записи на диски (mirroring), многопроцессорные машины, продолжающие работу при выходе из строя нескольких процессоров (High availibility).

Для приложений с небольшим количеством одновременно работающих пользователей (несколько десятков) и не очень большой БД в качестве машины сервера можно использовать компьютеры с Pentium или 486 процессором. Для более мощных приложений широко используются компьютеры фирм DEC, HP, Sun, RISC/6000. Очень перспективна в качестве сервера многопроцессорная машина фирмы Sequent. Она имеет достаточно низкую цену, высокое быстродействие и надежность. Причем быстродействие может легко повышаться за счет увеличения числа процессоров (от 2 до 30).

Важным критерием для выбора компьютера служат результаты специальных тестов, проводимых независимыми западными фирмами [3]. По ним можно определить, какую производительность конкретная СУБД показывает на различных типах компьютеров, операционных систем и в различных архитектурах.

III. Программное обеспечение для поддержки архитектуры клиент-сервер

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

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

Наиболее типичными решениями являются следующие:

1. Использование на всех компьютерах программных средств одной фирмы;

2. Использование на персональных компьютерах-клиентах популярных персональных СУБД с "дополнительными" пакетами для этих СУБД, позволяющими им работать с сервером БД конкретной фирмы;

3. Использование для разработки клиентских приложений специальных высокоуровневых инструментальных средств разработки приложений, умеющих работать с основными реляционными серверами БД;

4. Использование в качестве платформы для клиентских приложений персональных компьютеров с MS Windows, на которых работают пакеты, обеспечивающие стандарт обмена данными DDE;

5. Использование на компьютерах-клиентах и компьютерах-серверах пакетов, поддерживающих один из стандартов интерфейса клиент-сервер (ODBC, IDAPI, DAL и т.д.);

6. Использование пакетов, поддерживающих совокупность стандартов интерфейса клиент - сервер и позволяющих использовать в макрокомандах и процедурах на языке 4GL различных прикладных пакетов единый набор команд для работы с БД, файлами, почтовыми системами и т.д.;

7. Использование на компьютерах-серверах БД специальных пакетов-шлюзов;

8. Использование систем распределенных транзакций (мониторов транзакций).

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

1. ИСПОЛЬЗОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ ОДНОЙ ФИРМЫ

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

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

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

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

2. РАБОТА ПРИЛОЖЕНИЙ, СДЕЛАННЫХ ДЛЯ РС, С СЕРВЕРОМ БД

На персональных компьютерах, обычно используемых в качестве компьютеров-клиентов существует большое количество популярных, легких в использовании СУБД. Наиболее известными из них являются СУБД dBase, FoxPro, Clarion, Clipper, Paradoх, [4]. С помощью этих СУБД разработано большое количество приложений. Перечисленные СУБД были созданы специально для персональных компьютеров и наиболее полно используют их возможности. Вначале были созданы однопользовательские версии этих СУБД, однако потом, когда понадобилось реализовывать многопользовательские приложения, были созданы версии этих пакетов, работающие в сети.

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

Фирмы-производители СУБД для PC хорошо осознают эту проблему и потому разрабатывают программное обеспечение, позволяющее их СУБД работать с сервером БД конкретной фирмы. Обычно в качестве сервера используется одна из самых популярных и распространенных СУБД (Oracle, Informix, Inqres). Больше всего таких пакетов известно для СУБД Oracle, которая занимает около половины всего рынка серверов БД. Например, СУБД Paradox имеет компоненты SQL Link for Oracle и SQL Link for InterBase. С помощью этих пакетов приложения для Paradox будут работать с БД Oracle или InterBase.

Если у Вас есть программы для FoxPro или Clipper, и Вы хотите, чтобы они начали работать с БД Oracle, то можете воспользоваться пакетами BITON for FoxPro или BITON for Clipper. Это библиотеки подпрограмм. В программе на языке Clipper, например, Вам придется заменить операторы, работающие с dbf-файлами на вызов подпрограмм из этой библиотеки. После перекомпиляции программа начнет работать с локальной или удаленной БД Oracle. Интерфейс и алгоритмы обработки не меняются. В СУБД Clarion (версия 3 и выше) реализуется подход на основе сменных драйверов. С CLARION должны поставляться драйверы для работы с SQL-серверами, например с Oracle. После подключения такого драйвера приложение начнет работать с БД Oracle.

Во всех перечисленных случаях пакет позволяет связать конкретную СУБД для РС (например Paradox) с конкретным сервером БД (например Oracle). Универсального пакета, позволяющего конкретной СУБД для PC работать с различными серверами БД, нет. Кроме того, при изменении версии сервера БД необходимо изменять этот пакет связи, а это может сделать только разработчик. Поэтому часто приходится использовать старую версию БД. Еще одним недостатком такого подхода является то, что для передачи данных и запросов между клиентом и сервером по сети приходится использовать дополнительную компоненту сервера, устанавливаемую на клиенте (если она существует и поддерживает имеющийся сетевой протокол). Не все операции для работы с данными файлов персональной СУБД может обработать сервер БД и наоборот, многие преимущества сервера использовать при таком подходе не удается.

3. СРЕДСТВА РАЗРАБОТКИ ПРИЛОЖЕНИЙ

Сегодня многие фирмы выпускают пакеты для разработки приложений, работающих с несколькими наиболее популярными реляционными СУБД. Эти пакеты поддерживают мощные языки 4 поколения и имеют диалоговые средства, автоматизирующие отдельные этапы разработки (например, генераторы форм, отчетов, меню). Эти средства имеются для различных платформ (DOS, Windows, Unix и т.д.) и позволяют быстро разрабатывать и модифицировать приложения с графическим пользовательским интерфейсом и сложной логикой обработки.

Обычно в документации, поставляемой с этими пакетами, перечислены реляционные СУБД, использующие язык SQL, с которыми могут работать приложения. Список этих СУБД достаточно постоянен. Это "большая четвертка" Oracle, Informix, Inqres, Sybase[1]. Иногда к ним добавляются InterBase, DB2, Rdb, MS SQL Server. В качестве примеров таких пакетов можно указать JAM фирмы Convergent Solutions Inc., Power House фирмы Cognos Inc., Contessa фирмы Contexture Systems., SC/ADS фирмы Convergent Solutions Inc., Pro*IV фирмы McDonall Daugsas., Accel фирмы Unify и т.д.

Недостатки у этого подхода те же, что и при использовании Paradox, Clipper и т.д. Приложения должны либо использовать стандартный SQL (Ansi Level 1 или 2) и следовательно, они могут работать с разными СУБД, но не используют их в полной мере, либо в приложениях явно записываются специфические операторы конкретной СУБД. При этом переход к другой СУБД требует модификации приложений. Кроме того, обычно языки и технологии СУБД и средства разработки приложений сильно различаются. Не всегда "стыковка" с конкретными СУБД выполняется качественно. Еще одним недостатком является то, что этот и предыдущий подходы не позволяют связываться между собой двум серверам БД различных фирм. Они подходят только для связи клиентов с серверами одной фирмы.

4. КЛИЕНТСКИЕ ПРИЛОЖЕНИЯ, ПОДДЕРЖИВАЮЩИЕ ПРОТОКОЛ DDE

Очень часто в качестве компьютеров-клиентов используются персональные компьютеры с MS Windows. Эта дружественная графическая среда очень удобна для создания клиентских приложений. Появление операционной системы Windows NT очевидно еще больше повысит популярность приложений, работающих в этой среде. Наиболее известными среди них являются электронные таблицы Lotus 1-2-3, Excel, Quattro Pro, редактор текстов MS Word, СУБД MS Access.

Для того, чтобы приложения MS Windows могли обмениваться между собой данными, фирма Microsoft разработала протокол динамического обмена данными DDE (Dynamic Data Exchange). Согласно этому протоколу одно из приложений MS Windows, называемое DDE клиентом, может посылать сообщения, запросы на выполнение действий, запросы на данные другому приложению для MS Windows, называемому DDE сервером (не следует путать DDE клиентов и серверов с клиентами и серверами в архитектуре клиент-сервер СУБД). Архитектура работы с DDE сервером приведена на рисунке 1.

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

Если в качестве DDE сервера используется приложение MS Windows, умеющее обмениваться данными с некоторой СУБД и пересылать на выполнение SQL-команды в эту СУБД, то любые приложения для MS Windows, поддерживающие протокол DDE, смогут работать с данной СУБД. Правда для каждой СУБД нужно иметь свой DDE сервер и язык SQL приложения должен быть понятен тем СУБД, с которыми оно будет работать. Однако, если приложение использует базовый набор команд SQL (например SQL ANSI Level 1), то оно сможет работать без изменения с различными серверами реляционных БД.

Если приложение умеет работать c макрокомандами и поддерживает протокол DDE (а это справедливо для всех выше перечисленных пакетов для MS Windows), то очень просто настроить такое приложение на работу с одной СУБД или группой однородных реляционных СУБД. Вопросы передачи данных по сети либо должен решать сам DDE сервер, либо он может использовать транспортные средства СУБД, например SQL*NET .Примером DDE сервера для работы с СУБД Oracle является пакет Oracle for Windows фирмы Oracle.

Недостатком описанного подхода является то, что он справедлив только для приложений, работающих в MS Windows и написанных с соблюдением протокола DDE. Кроме того, DDE серверы существуют лишь для немногих СУБД, а возможность работы конкретного DDE клиента с другой СУБД очень сильно зависит от используемого набора предложений SQL и используемых типов данных. Скорее всего данный подход позволит Вам обеспечить работу конкретного пакета для MS Windows, например Excel, c конкретной СУБД.

5. СТАНДАРТ ODBС

Все рассмотренные выше подходы не позволяли создавать клиентские приложения, не зависимые от используемого сервера БД. Каждый сервер реализовывал свое множество функций, имел свой диалект SQL и т.д. Для того, чтобы можно было создавать приложения и серверы, которые будут обмениваться командами и данными, ничего не зная друг про друга, было решено выработать стандарт интерфейса клиент-сервер. Этим занималась группа SQL-Access Group (SAG), в состав которой входили ведущие фирмы - разработчики СУБД, операционных систем, компьютеров, такие как DEC, Hewlett-Packard, Bull, Inqres, Oracle, Informix, Sybase, Microsoft, Novell, Information Builders, NCR/Teradata, Tandem.

Группе удалось создать стандарт, который определяет:

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

- синтаксис языка SQL, используемого в приложении и реализуемого на сервере;

- стандартный набор кодов ошибок;

- стандартный способ связи с БД и начала сеанса;

- стандартное представление типов данных.

Первую программную реализацию этого стандарта выполнила фирма Microsoft, назвав ее Open Data Base Connectivity (ODBC). Эта реализация позволяет различным приложениям для MS Windows работать с различными серверами БД (удаленными и локальными) и с БД для PC.

Основная идея ODBC заключается в следующем: Фирма Microsoft создала динамическую библиотеку связи (DLL) для Windows, называемую Driver Manager. Кроме нее для каждого сервера разрабатывается свой драйвер (он выполнен тоже в виде DLL). Пользовательское приложение загружает и инициализирует Driver Manager и затем общается только с ним. Оно передает ему команды стандарта ODBС для связи с БД, выполнения запросов, извлечения данных и т.д. В свою очередь Driver Manager подключает необходимый для работы с данной БД драйвер. Все это программное обеспечение работает на той же машине, что и приложение в среде MS Windows.

Драйвер преобразует команды ODBС в операторы SQL конкретной СУБД. Он также преобразует данные и коды ошибок. Драйвер может работать с локальной СУБД, использовать для связи с удаленной СУБД ее транспортные средства (например SQL*Net) или сам реализовывать связь по сети. На рисунке 2 приведена схема архитектуры ODBС.

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

Планируется, что фирма Microsoft будет поставлять Driver Manager вместе с MS Windows, а каждая фирма - производитель СУБД будет поставлять DLL драйвер к своей СУБД. Однако, пока и Driver Manager и драйвер поставляются вместе с приложениями (например, MS Access, Visual Basic, Lotus 1-2-3). Microsoft разрабатывает драйверы совместно с фирмами-разработчиками СУБД (SQL Server, Oracle, XLS, Text, Paradox, Btrieve, dBASE). Планируется выпуск еще 33 драйверов (отличающихся быстродействием и набором функций). Так для СУБД Oracle есть драйвер фирмы Oracle, драйвер фирмы Gupta Technologies [5] и драйвер фирмы Microsoft (поставляется с MS Access).

Драйверы могут быть однослойными (single-tier) или многослойными (multiply-tier). Однослойные драйверы характерны, например, для СУБД типа dBASE на РС. Эти драйверы получают команды на языке SQL и сами их выполняют (т.е. извлекают данные или модифицируют файлы dBASE в данном примере). Многослойные драйверы получают команды SQL, преобразуют их и передают для дальнейшего выполнения серверу БД.

Кроме того, каждый драйвер характеризуется уровнем поддержки функций ODBС и уровнем реализации SQL и типов данных. Приложение может запросить у драйвера информацию об этих уровнях. Дело в том, что в стандарте ODBС определено 54 функции работы с БД. Базовый уровень состоит из 23 функций, их должны поддерживать все драйверы и реализовывать все СУБД. Использование функций этого уровня обеспечивает полную независимость от сервера БД.

Драйвер уровня 1 (Level 1 API) должен поддерживать еще 15 функций (нестандартная связь с БД, требующая дополнительных параметров, извлечение части результата, получение общих данных из словаря БД и от драйвера и т.д.). Драйвер уровня 2 (Level 2 API) позволяет обмениваться массивами данных, использовать прокрутку курсора, специфические функции СУБД, специфический синтаксис SQL и т.д.).

Аналогично существует разделение драйверов на 3 типа по уровню поддержки синтаксиса SQL и типов данных. Например, драйвер с минимальным уровнем синтаксиса (Minimum SQL) обрабатывает только тип данных CHAR, простые выражения, простые операторы SQL. Драйвер с базовым уровнем SQL (Core SQL) позволяет работать с индексами, сложными выражениями и основными типами данных и т.д. Драйвер с расширенным уровнем SQL (Extended SQL) поддерживает расширенные соединения , специфические функции (substring, ABS, DECODE и т.д.), работу с временем и датой, вызов хранимых процедур, пакетный SQL, специфические типы данных и т.д. Все эти уровни зафиксированы в стандарте и обычно драйвер поддерживает все функции, операторы и типы некоторого уровня (к которому он принадлежит) плюс некоторое множество функций, операторов и типов более высоких уровней.

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

ODBC позволяет использовать в своих операторах динамически формируемые операторы SQL. Поэтому предусмотрены команды определения формы результата оператора Select (количество переменных, их тип и т.д.) Простое ODBC приложение должно работать следующим образом:

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

- выполнять SQL операторы транзакции;

- завершать или откатывать транзакцию;

- завершить сеанс работы с источником.

В свою очередь выполнение SQL оператора состоит из следующих шагов:

- формирование в буфере строки оператора SQL, установка значений параметров;

- для операций выборки установление имени курсора данных оператора SQL;

- выполнение оператора;

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

- проверка и обработка кода завершения оператора.

Microsoft ODBC успешно работает в Windows и Windows NT, сейчас разрабатываются драйверы для платформы Mac, планируется переход и на другие платформы. Однако, поскольку ODBC был первой реализацией стандарта группы SAG, он имеет и ряд недостатков. К сожалению многие пакеты под Windows не поддерживают стандарт ODBС, более того фирма Borland (владелец таких пакетов, как dBASE, Paradox, QuatroPro, InterBase) создала свой собственный стандарт IDAPI, альтернативный ODBC. ODBC не обеспечивает прозрачность работы в сети. Забота об этом переложена либо на драйверы, либо на транспортные пакеты СУБД. При работе с несколькими СУБД одновременно используется несколько драйверов, функции которых частично дублируются. Драйверы при этом занимают оперативную память. ODBC не поддерживает работу с распределенной БД, не позволяет выполнять в запросе операции соединения таблиц из разных БД. ODBC пока работает только под MS Windows и не позволяет переносить ODBC совместимые приложения на другие платформы.

Microsoft ODBC предназначен для манипулирования данными с помощью языка SQL. Работать с навигационными СУБД на РС (группа dBASE, Paradox и т.д.) можно и с помощью SQL, однако программы получаются громоздкими, а быстродействие снижается. Операторов для работы с навигационными СУБД и файлами в ODBС нет.

6. СТАНДАРТ IDAPI

Фирма Borland разработала свой альтернативный стандарт интерфейса клиент-сервер, учитывая недостатки стандарта ODBC и свой опыт связывания Paradox и QuatroPro с Interbase. Стандарт называется IDAPI (Integrated Database Application Programming Interface) [6]. В его разработке также участвовали фирмы IBM, Novell, WordPerfect. Архитектура IDAPI более сложна, чем ODBC, и позволяет хорошо работать как с SQL серверами, так и с навигационными записе-ориентированными базами (см. рисунок 3). Для этого язык программного интерфейса (API) был расширен за счет добавления команд для работы с навигационными СУБД (NAV/CLI - навигационный CALL-интерфейс), а в программной реализации IDAPI кроме средств обработки SQL (Relational Engine) имеется средство обработки NAV/CLI.

Планируется реализовать IDAPI среду на нескольких платформах: DOS, OS/2, NetWare, MS Windows. Это позволит переносить приложения. IDAPI предусматривает работу с ODBC - совместными серверами, но не позволяет использовать ODBC - совместимые приложения. IDAPI также планирует поддерживать свой транспортный уровень связи клиента с сервером в сети с различными протоколами. Еще одним достоинством IDAPI является возможность работы с распределенной БД и выполнения в запросе операций соединения таблиц из разных СУБД. Пользователи IDAPI смогут работать с большими двоичными объектами (BLOB), в которых может хранится изображение и звук.

Стандарты IDAPI и ODBC во многом пересекаются и очевидно некоторые время будут конкурировать не рынке. Очевидно Microsoft вскоре учтет недостатки ODBC и реализует его версию на новых вычислительных платформах.

7. ПОДДЕРЖКА ГРУППЫ СТАНДАРТОВ ИНТЕРФЕЙСА

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

Развитие этого подхода привело к появлению пакетов, позволяющих связать множество клиентских приложений, поддерживающих разные стандарты интерфейса, с множеством СУБД, почтовых серверов, файл-серверов, palmtop компьютеров и Personal Digital Assistants (PDA) компьютеров. Эти пакеты должны работать на разных вычислительных платформах и иметь средства для быстрого наращивания числа клиентских приложений переднего плана (front end) и числа серверов (back end). Хорошим примером такого продукта является пакет Oracle Glue фирмы Oracle.

Oracle Glue - это адаптируемый, переносимый, интегрированный пакет, позволяющий склеить в единую прикладную систему клиентские приложения, выполненные с помощью Visual Basic, MS Access, Excel, Amipro, Lotus 1-2-3, Authorware, MS Word, QuattroPro, Asymmetrix ToolBook и любых DDE совместимых пакетов в среде MS WINDOWS; приложения, выполненные с помощью HyperCard на MAС; приложения, выполненные с помощью WINGZ на Unix; приложения, выполненные с помощью Oracle Card или Pen Apps на перьевых компьютерах, с множеством серверов БД, файловых и почтовых серверов, среди которых: Oracle6, Oracle7, Oracle*Mail, DB2, SQL/DS, Tandem, Sybase, MS SQL Server, dBASE, Paradox, Sharp Wizard & PDA, серверы БД, к которым имеются шлюзы Oracle, серверы БД, поддерживающие стандарты ODBC, DAL, PIA, IDAPI, почтовые серверы, поддерживающие стандарты MHS, VIM, MAPI и т.д. (см. рисунок 4).

В первой версии пакета реализован front end для пакетов, работающих в MS Windows, и back end для Oracle 6 и Oracle 7, Oracle Mail, Palmtop компьютеров. В следующей версии пакета число front end, back end и вычислительных платформ будет увеличено. Oracle Glue предназначен в первую очередь не для создания новых прикладных программ, работающих с разными СУБД (хотя это можно делать используя, например, стандарт DDE, работу с DLL и т.д.), а для того, чтобы с множеством серверов смогли работать уже существующие пакеты, позволяющие писать макросы, или имеющие языки 4 поколения. Особенноcтью Oracle Glue является универсальный для всех пакетов язык прикладного программного интерфейса, учитывающий особенности конкретного прикладного пакета. Он может работать с ячейками электронных таблиц, полями и управляющими структурами (клавиши, списки и т.д.) MS Access и т.д. Единство синтаксиса языка позволяет переносить приложения без изменений на другие платформы. Например, приложения для Excel в MS Windows можно перенести в Excel для Mac.

Oracle Glue будет работать в MS Windows, Windows NT, Apple Macintosh, OS/2, PenWindows, PenPoint, Unix. (Первая версия работает в MS Windows). Пакет использует транспортное средство Oracle SQL*Net и поэтому поддерживает все сетевые протоколы от Async и TCP/IP до LU6.02.

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

Между базовым слоем и драйверами нижнего уровня также добавлен уровень обработчиков для СУБД, электронной почты, файлов, palmtop компьютеров. В зависимости от того, какая команда используется в языке Oracle Glue (execsql, execmail, execfile, execlink), будет подключаться то или иное средство обработки.

В версии Oracle Glue для MS Windows все драйверы, базовый уровень и обработчики выполнены в виде DLL- модулей.

Обработчики для Visual Basic и Excel поставляются с системой. Для DDE совместимых приложений имеется DDE сервер, выполняющий роль драйвера верхнего уровня. Приложения, умеющие загружать и использовать DLL библиотеки, могут напрямую загружать DLL базового уровня и использовать его функции. Очевидно, что такая архитектура позволяет легко добавлять драйверы, поддерживающие другие стандарты, и новые обработчики. Кроме того, в одном приложении можно работать и с СУБД и с файлами и с электронной почтой.

Другим примером пакета, реализующего несколько стандартов, является пакет SQL-Retriever 3 фирмы Visionware. Он позволяет приложениям стандарта ODBC и DDE работать СУБД Ingres, InterBase, Informix, Oracle, Sybase, Rdb. Для работы с DDE приложениями имеется драйвер-конвертор DDE-ODBC. SQL-Retriever также сам поддерживает передачу данных по сети, для чего часть его программного обеспечения устанавливается на сервере (поддерживаются платформы Sun OS/Solaris, IBM AIX, DEC Ultrix, DEC VMS, SCO Unix, NCR, ICL, Altos Unix и сетевые протоколы TCP/IP, Async, DECnet, SPX/IPX, AT&T StarLAN, ICL OSLAN, ALTOS ISO/OSI [7].

8. ШЛЮЗЫ

Шлюз - это программное обеспечение, заставляющее сервер БД одной фирмы выглядеть для работающих с ним клиентов как сервер БД другой фирмы. Например, если на компьютер mainframe с OC MVS, где работает СУБД DB2, поставить шлюз Oracle Transparent Gateway to DB2, то все программы-клиенты, работающие с СУБД Oracle, смогут работать с СУБД DB2. Шлюз обычно ставится на том же компьютере, где работает СУБД, работу которой надо "закамуфлировать".

Большинство фирм-производителей популярных коммерческих серверов БД имеют шлюзы к серверам БД других фирм ("чужим" серверам). Шлюз позволяет работать с "чужой" СУБД не только клиентским приложениям, но и серверам БД (в приведенном примере приложения Oracle и сервер БД Oracle могут работать с СУБД DB2). Это позволяет перекачивать данные между различными СУБД и, если шлюз обеспечивает поддержку двухфазного протокола фиксации изменений (2 phase commit), создавать распределенную БД, в узлах которой находятся СУБД различных фирм. Например, в распределенной СУБД Oracle один из узлов может использовать СУБД DB2 на mainframe или СУБД SQL/400 на компьютере AS/400 (где СУБД Oracle не реализована).

Шлюзы помогают интегрировать данные различных СУБД и использовать мощные инструментальные средства одних фирм для работы с данными СУБД других фирм. Кроме того, шлюзы могут "камуфлировать" не только реляционные СУБД, но и СУБД с другими моделями данных (иерархической, инвертированные списки), а также файловые системы. Используя, например, шлюз Oracle к Adabas можно работать с СУБД Adabas, имеющей специфическую модель данных, как с реляционной СУБД и использовать для работы команды языка SQL. Аналогично, шлюзы Oracle к VSAM и RMS позволяет работать с файлами с таким методом доступа как с реляционной СУБД.

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

Некоторые шлюзы имеют ограниченные функции, т.е. позволяющие выполнять только чтение из "чужой” БД. Существуют также "двунаправленные" шлюзы, которые позволяют не только обращаться к "чужой" СУБД для чтения/записи, но и позволяют "чужой" СУБД самой обращаться к другим серверам БД для выполнения чтения/записи (пример таких двунаправленных шлюзов - Database Gateway фирмы MicroDecisionware Inc и Open Server фирмы Sybase) [8].

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

- проверяет синтаксис и семантику поступающих SQL предложений;

- конвертирует синтаксис и семантику SQL "родной" СУБД в команды "чужой" СУБД или файловой системы;

- конвертирует типы данных;

- позволяет видеть и использовать каталог "чужой" СУБД, как каталог "родной" СУБД;

- транслирует коды и сообщения об ошибках "чужой" СУБД в коды и сообщения "родной" СУБД;

- возвращает данные, полученные в результате выполнения запроса на выборку данных.

Иногда шлюз может заниматься оптимизацией выполнения запроса, обеспечивать работу с удаленными процедурами RPC (remote procedure calls).

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

Наибольшее количество шлюзов сделано к СУБД для mainframe. Это объясняется тем, что их приложения, СУБД и данные плохо переносимы, там накоплены большие объемы данных и много наработок. Шлюзы помогают плавно "мигрировать" с больших машин на миникомпьютеры.

По принципу действия все шлюзы делятся на 2 группы: шлюзы для данных (Transparent Gateway) и процедурные шлюзы (Procedural Gateway). У Oracle, например, шлюз для данных устанавливается на той же машине, что и "чужая" СУБД (или на дополнительной машине - для DRDA и Teradata), и для Oracle и его продуктов связка шлюз +"чужая" СУБД выглядят как Oracle - сервер. Шлюз принимает SQL запросы от продуктов и серверов Oracle и преобразует их в команды "чужой" СУБД. Преобразуются и данные. При выборке данных из "чужой" СУБД шлюз преобразует их в структуры Oracle.

Процедурный шлюз устанавливается на дополнительной машине и позволяет использовать в качестве узла распределенной БД СУБД и файловые системы, работающие в среде мониторов транзакций CICS, IMS/TM, CA-IDMS/DC. Причем работа ведется с использованием механизма RPC - процедур (Remote Procedural Control), что обеспечивает более быстрый доступ к данным, чем Transparent Gateway.

Развитием идеи шлюзов стало создание средств разработки шлюзов (Open Gateway Toolkit). Они создаются не для камуфлирования одной СУБД под другую, а для камуфлирования группы СУБД и файловых систем, работающих на одной вычислительной платформе, под одну другую СУБД. В составе этих пакетов имеются инструментальные средства и языки, позволяющие описать правила преобразования предложений SQL, кодов, типов данных и т.д. "родной" СУБД в SQL, коды, типы данных других СУБД. В качестве примеров можно привести пакет Open Gateway Toolkit фирмы Oracle, Open Server фирмы Sybase. Например, Open Gateway Toolkit позволяет строить процедурные шлюзы и шлюзы для данных для любых источников данных (файлы, СУБД, банкоматы, устройства для работы со штрих-кодом и т. д.). Однако построение новых шлюзов требует написания дополнительных программ на языке 3GL.

Некоторые пакеты - шлюзы кроме реализации функций шлюза также обеспечивают передачу данных по сети. Они обычно поддерживают 1-2 сетевых протокола. Иногда при передаче приходится выполнять конвертацию одного сетевого протокола в другой (например, TCP/IP в LU6.2). Пример такой работы - пакет EDA/SQL фирмы Enterprise Builder Inc. Однако лучше использовать шлюзы, позволяющие работать с транспортными компонентами мощных СУБД (Oracle SQL*Net, Inqres*Net), поддерживающими множество протоколов. Oracle SQL*Net 2 поддерживает преобразование протоколов.

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

Однако фирмы - разработчики коммерческих распределенных СУБД и фирмы, специализирующиеся на разработке шлюзов, продолжают успешно создавать шлюзы (для данных и процедурные) к новым СУБД и файловым системам. Например, фирма Oracle имеет шлюзы для данных к следующим СУБД: DB2, SQL/DS, TurboIMAGE, Adabas, IDMS, SQL/400, VSAM, Rdb, RMS, IMS, Teradata, DRDA (DB2 на MVS, SQL/DS на VM, SQL/400 и DataManager на OS/2), XDM/RD, Nonstop SQL, SESAM, IDMSX и разрабатывает шлюзы для данных к Ingres, Informix, DB2 на OS/2 и RISC 6000, EDA/SQL(VSAM, ISAM, ADABAS, TOTAL, Teradata, IMS, CA-IDMS/DB, System 2000, FOCUS, Infoman, QSAM, CA-Datacom, Supra, SAP, Model 204) и процедурные шлюзы к данным IMS, VSAM, ADABAS, CA_IDMS/DB, DB2, Model 204.

9. СРЕДСТВА ОБРАБОТКИ РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ

Средства обработки распределенных транзакций (Distributed Transaction Processing - DTP) еще мало известны в нашей стране. Эти средства позволяют связывать разнородные компьютеры с различными операционными системами и различными СУБД в единую среду обработки приложений. Причем в этой среде поддерживается расширенная архитектура клиент-сервер.

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

Наиболее известными сегодня средством обработки распределенных транзакций является пакет TUXEDO ETP System, Release 4.2 фирмы USL (Unix system Laboratories) [9]. Он позволяет связать в единую среду персональные компьютеры с MS DOS, MS Windоws, OS/2, Unix; машины среднего класса с Unix и mainframe с MVS/CICS. Приложения работают на персональных компьютерах, а различные СУБД - на Unix-компьютерах среднего класса. Кроме того, поддерживается интерактивное взаимодействие по схеме запрос/ответ с MVS/CICS процессами через протокол LU6.2.

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

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

Для того, чтобы приложения могли работать в среде DTP, они должны быть написаны с использованием высокоуровнего специализированного интерфейса приложение - монитор транзакций. У TUXEDO он называется ATMI (Application Transaction Monitor Interface). Некоторые производители СУБД выпускают библиотеки для поддержки этого интерфейса из своих продуктов. Например, фирма Informix имеет пакет INFORMIX - TP/ToolKit для поддержки своего языка 4GL в среде TUXEDO. Oracle имеет библиотеку интерфейсных модулей Oracle XA Library. Cредства разработки и выполнения приложений Oracle CDE 2 могут работать в среде DTP.

В свою очередь СУБД, используемые в узлах системы, должны поддерживать стандарт X/Open XA. Он был разработан комитетом стандартов X/Open и описывает особенности управления транзакциями, работающими с несколькими разнородными СУБД. Этот стандарт реализован, например, в СУБД Oracle 7, Informix - Onfine 5.0, HP Allbase/SQL F.0, Ingres, TUXEDO System/D. TUXEDO позволяет, например, заменить одну из этих СУБД в узле на другую, однако обе эти СУБД должны использовать один и тот же стандарт языка SQL, на котором формулируются запросы к БД.

Среди недостатков DTP следует указать ограниченное количество поддерживаемых сетевых протоколов и СУБД. В приложении должен использоваться SQL конкретной СУБД или стандарт SQL. Использование специфического языка интерфейса с монитором транзакций не позволяет "уйти" из среды DTP. Опыт использования систем такого класса у нас в стране ограничен (а они достаточно сложны в использовании).

Однако уникальные возможности этих систем по обеспечению распределенного управления приложениями очень привлекательны. TUXEDO, например, сегодня доступен на компьютерах Amdahi, AT&T, Bull, Dec, Data General, FUJITSU, HP, IBM, ICL, Oki, Olivetti, Pyramid, Sequent, Sun, Tandem, Teradata, Toshiba, Unisys.

ЛИТЕРАТУРА

1. Ривкин М.Н. Распределенные СУБД // Мир ПК, 1993, N 5

2. Беляев В.И., Ривкин М.Н. Oracle7 - новое поколение распределеннных СУБД // Мир ПК, 1993, N 8

3. Дрожжинов В.И. От теста не уйдешь // Мир ПК, 1993, N 2

4. Смородинский А.В., Ривкин М.Н. Системы управления базами данных и оболочки экспертных систем для персональных компьютеров. - Тверь, 1991

5. Squires G. Oracle and Microsoft Windows from an Open Systems Perspective // Select, 1993, v 1, N 1

6. IDAPI Architecture White Paper, Borland, 1992, November

7. SQL-Retriever 3.0: Bring Openness" to PDBC. - A Visionware White Paper, 1992, November

8. Finkelstein R. Client/Server Middleware: Making Connections Across the Enterprise // DBMS, 1993, v 6, N 1

9. Ладыженский Г.М. Система обработки распределенных транзакций TUXEDO // Открытые системы, 1993, Весна

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ ¦ MS Windows ¦

¦ +-----------------+ +-----------------+ ¦

¦ DDE совместимое ¦ ¦ DDE сервер для ¦

¦ ¦ приложение ¦<---------------->¦ Oracle ¦ ¦

+-----------------+ +--------_--------+

¦- - - - - - - - - - - - - - - - - - - - - - - -¦- - - -- - ¦ ¦ +--------_--------+ ¦

¦ SQL*Net для PC ¦

¦ +-----------------+ ¦

+- - - - - - - - - - - - - - - - - - - - - - - -¦- - - - - -+ ¦/¦

¦/¦

¦ +------------------------+ ¦ SQL*Net для сервера БД ¦ +-----------_------------+

+-----------_------------+ ¦ ¦

¦ СУБД Oracle ¦ +------------------------+

Рисунок 1. Пример DDE сервера для работы с СУБД Oracle

+------------------------+

¦ Приложение ¦

¦XXXXXXXXXXXXXXXXXXXXXXXX¦_-- ODBC интерфейс