Двухзвенные клиент-серверные архитектуры

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

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

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

Рассмотрим различные способы организации двухуровневого доступа прикладной программы к серверу базы данных в двух- звенной архитектуре.

Открытый интерфейс баз данных ODBC. Спецификация от­крытого интерфейса баз данных (ODBC — Open Database Connectivity) предназначена для унификации доступа к данным, размещенным на удаленных серверах. ODBC опирается на спе­цификации CLI.

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

В архитектуре ODBC используется один ODBC Driver Manager и несколько ODBC-драйверов, обеспечивающих доступ к конкретным СУБД. Driver Manager связывает приложение и интерфейсные объекты, которые выполняют обработку SQL-за­просов к конкретной СУБД (рис. 7.8).

Такой подход является достаточно универсальным, стандар­тизируемым, что и позволяет использовать ODBC-механизмы

Рис. 7.8. Структурная схема доступа к данным с использованием ODBC

 

для работы практически с любой системой, однако этот способ также не лишен недостатков:

• увеличивается время обработки запросов (как следствие введения дополнительного программного слоя);

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

Мобильный интерфейс к базам данных на платформе Java — JDBC (Java Data Base Connectivity) — это интерфейс прикладно­го программирования (API) для выполнения SQL-запросов к ба­зам данных из программ, написанных на платформенно-незави- симом языке Java, позволяющем создавать как самостоятельные приложения (standalone application), так и аплеты, встраиваемые в Web-страницы.

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

• приложение загружает JDBC-драйвер динамически, следо­вательно, администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места;

• JDBC, как и Java в целом, не привязан к конкретной аппа­ратной платформе, следовательно проблемы с переносимо­стью приложений практически снимаются;

• использование Java-приложений и связанной с ними идео­логии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.

Прикладные интерфейсы OLE DB и ADO. OLE DB (Object Linking and Embedding Data Base), как и ODBC — это приклад­ные интерфейсы доступа к данным с использованием SQL.

OLE DB специфицирует взаимодействие, обеспечивая еди­ный интерфейс доступа к данным через провайдеров — постав­щиков данных не только из реляционных БД. В отличие от ODBC, OLE DB предоставляет общее решение обеспечения СОМ-приложениям доступа к информации независимо от типа источника данных.

OLE DB включает два базовых компонента: провайдер дан­ных и потребитель данных. Потребитель (клиент) — это приложе­ние или СОМ-компонент, обращающийся посредством АР1-вы- зовов к OLE DB. Провайдер (сервер) — это приложение, отвечаю­щее на вызовы OLE DB и возвращающее запрашиваемый объект — обычно это данные в табличном виде.

ADO (Active Data Object) — это универсальный интерфейс высокого уровня к OLE DB. Модель объекта ADO не содержит таблиц, среды или машины БД. Здесь основными объектами яв­ляются следующие: объект Соединение, создающий связь с про­вайдером данных; объект Набор данных и объект Команда — выполнение процедуры, SQL-строки.

В общем случае ADO можно рассматривать как язык про­граммирования с БД, позволяющий выбирать, модифицировать и удалять записи. Поскольку он опирается на универсальный OLE DB, то может использоваться практически в любых прило­жениях Microsoft.