Максимов Н.В., Голицына О.Л., Васина Е.Н. Управление данными

Подождите немного. Документ загружается.

241

особенностей доступа к каждой отдельной СУБД отвечает соответст-

вующий специальный ODBC-драйвер. Пользовательское приложение

этих особенностей не видит, т.к. взаимодействует с универсальным про-

граммным слоем более высокого уровня. Таким образом, приложение

становится в значительной степени независимым от СУБД. Вместо соз-

дания в каждом отдельном случае СУБД-приложения с обращениями

через «родной», но быстро устаревающий интерфейс, можно использо-

вать один общий стандартизированный программный интерфейс.

В архитектуре ODBC используется один ODBC Driver Manager и

несколько ODBC-драйверов, обеспечивающих доступ к конкретным

СУБД. Driver Manager связывает приложение и интерфейсные объекты,

которые выполняют обработку SQL-запросов к конкретной СУБД.

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

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

практически с любой системой.

Однако этот способ также не лишен недостатков:

− увеличивается время обработки запросов (как следствие введения

дополнительного программного слоя);

− необходимы предварительная инсталляция и настройка ODBC-

драйвера (указание драйвера СУБД, сетевого пути к серверу, базы данных

и т.д.) на каждом рабочем месте. Параметры этой настройки являются ста-

тическими, т.е. приложение их изменить самостоятельно не может.

8.3.2.4. Мобильный интерфейс к базам данных на платформе Java

JDBC (Java Data Base Connectivity) – это интерфейс прикладного

программирования (API) для выполнения SQL-запросов к базам данных

из программ, написанных на платформенно–независимом языке Java,

позволяющем создавать как самостоятельные приложения (standalone

application), так и апплеты, встраиваемые в web-страницы.

242

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

JDBC

JDBC во многом подобен ODBC, он также построен на основе

спецификации CLI, однако имеет ряд следующих отличий.

− приложение загружает JDBC-драйвер динамически, следова-

тельно, администрирование клиентов упрощается, более того, появляет-

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

стройки клиентского рабочего места.

− JDBC, как и Java в целом, не привязан к конкретной аппаратной

платформе, следовательно проблемы с переносимостью приложений

практически снимаются.

− использование Java-приложений и связанной с ними идеологии

"тонких клиентов" обещает снизить требования к оборудованию клиент-

ских рабочих мест.

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

ем JDBC приведена на рис. 8.12.

Се

ве

Сервер

Клиент

ODBC –

совместимая

СУБД

СУБД 1

Драйвер

сети

СУБД 2

Драйвер

сети

Сеть

Java

программа

JDBC-driver manager

Драйвер сети

JDBC

Драйвер

СУБД 1

JDBC

Драйвер

СУБД 1

Мост

JDBC

JDBC-

Net

Drive

243

8.3.2.5. Прикладные интерфейсы OLE DB и ADO

OLE DB (Object Linking and Embedding Data Base), как и ODBC –

это прикладные интерфейсы доступа к данным с использованием SQL.

OLE DB специфицирует взаимодействие, обеспечивая единый ин-

терфейс доступа к данным через провайдеров – поставщиков данных не

только из реляционных БД. В отличие от ODBC, OLE DB предоставляет

общее решение обеспечения COM-приложениям доступа к информации

независимо от типа источника данных.

OLE DB включает два базовых компонента: провайдер данных и

потребитель данных. Потребитель (клиент) – это приложение или

COM-компонент, обращающийся посредством API-вызовов к OLE DB.

Провайдер (сервер) - это приложение отвечающее на вызовы OLE DB и

возвращающее запрашиваемый объект – обычно это данные в таблич-

ном виде.

ADO (Active Data Object) – это универсальный интерфейс высоко-

го уровня к OLE DB. Модель объекта ADO не содержит таблиц, среды

или машины БД. Здесь основными объектами являются следующие:

объект Соединение, создающий связь с провайдером данных; объект На-

бор данных и объект Команда – выполнение процедуры, SQL-строки

В общем случае ADO можно рассматривать как язык программи-

рования с БД, позволяющий выбирать, модифицировать и удалять запи-

си. И поскольку он опирается на универсальный OLE DB, то может ис-

пользоваться практически в любых приложения Microsoft.

8.3.2.6. Взаимосвязь механизмов доступа к данным

Рассмотренные технологии построения приложения ориентирова-

ны на извлечение данных непосредственно из статического источника

(хранилища данных) и не могут обращаться за данными к другому при-

кладному модулю.

Один из способов организации доступа к данным заключается в

непосредственном использовании API. Однако это означает полную за-

висимость создаваемого приложения от используемой СУБД. В этом

случае переход к другой системе (например, для перехода от настольной

системы к системе типа клиент/сервер) влечет за собой переписывание

большей части программного кода клиентского приложения.

Таким образом, следующим этапом в обеспечении доступа кли-

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

низма доступа к БД, обеспечивающего для клиентского приложения

стандартный набор функций, классов или сервисов (служб), необходи-

мых для работы с различными системами управления базами данных.

Эти стандартные функции (классы или сервисы) должны размещаться в

библиотеках, именуемых драйверами или провайдерами баз данных

(data base drivers (providers)). Каждая такая библиотека реализует набор

244

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

к конкретной СУБД.

Наиболее популярными механизмами доступа к данным (Universal

Data Access, UDA) в настоящий момент являются:

 ODBC

 OLE DB

 ADO

 BDE

Первые три являются фактически промышленными стандартами.

Последний долгое время был единственным механизмом доступа к дан-

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

нии Borland (например. Delphi, C++Builder).

На рис. 8.13 схематически представлены различные механизмы

доступа к данным, включая непосредственные вызовы клиентской ча-

стью API системы управления базой данных.

8.4. Технологии межмодульного взаимодействия

Следующий тип промежуточного ПО ориентирован на архитекту-

ру приложения, в которой один прикладной модуль, используя специ-

альные протоколы, получает данные из другого модуля.

245

8.4.1. Спецификация вызова удаленных процедур

Средства вызова удаленных процедур (RPC) поддерживает син-

хронный режим коммуникаций между двумя прикладными модулями

(клиентом и сервером).

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

ентский и серверный процессы обращаются к специальным процедурам

– клиентскому и серверному суррогатам (client stub и server stub). Эти

процедуры не реализуют никакой прикладной логики и предназначены

только для организации взаимодействия удаленных прикладных моду-

лей.

Каждая функция на сервере, которая может быть вызвана удален-

ным клиентом, должна иметь такой суррогатный процесс. Если клиент

вызывает удаленную процедуру, вызов вместе с параметрами передается

клиентскому суррогату. Он упаковывает эти данные в сетевое сообще-

ние и передает его серверному суррогату. Тот, в свою очередь, распако-

вывает полученные данные и передает их реальной функции сервера и

затем проделывает обратную процедуру с результатами. Таким образом

Сервер БД

СУБД

База данных

Клиентское приложение для работы с БД

ADO BDE

OLE

ODBC

Link

SQL Link

ODBC

Программное обеспечение клиента СУБД

Рис. 8.13. Взаимосвязь механизмов дост

па к данным

246

изолируются прикладные модули клиента и сервера от уровня сетевых

коммуникаций.

По существу, RPC реализует в распределенной среде принципы

традиционного структурного программирования. Клиент обращается к

процессу-суррогату так, как будто он и есть реальный серверный про-

цесс, и этот вызов ничем не отличается от вызова локальной функции.

Как и в случае нераспределенной программы, вызов процедуры на уда-

ленном компьютере влечет за собой передачу управления этой процеду-

ре, то есть блокирует выполнение клиентской программы на время об-

работки вызова.

В общем случае механизм RPC создает статические отношения

между компонентами распределенного приложения – привязка клиент-

ского процесса к конкретным серверным суррогатам происходит на эта-

пе компиляции и не может быть изменена во время выполнения. Этим

RPC отличается от таких более выгодных решений, как ТР-мониторы,

которые поддерживают возможности оптимального распределения на-

грузки на серверы и средства восстановления при сбоях.

Ключевым компонентом RPC является язык описания интерфей-

сов (interface definition language – IDL), предназначенный для определе-

ния интерфейсов, которые задают контрактные отношения между кли-

ентом и сервером. Интерфейс содержит определение имени функции и

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

Язык IDL обеспечивает независимость механизма RPC от языков

программирования – вызывая удаленную процедуру, клиент может ис-

пользовать свои языковые конструкции, которые IDL-компилятор пре-

образует в свои описания. На сервере IDL-описания обратно преобразу-

ются в конструкции языка программирования, на котором реализован

серверный процесс.

8.4.2. Мониторы обработки транзакций

Первоначально основной задачей мониторов обработки транзак-

ций (ТР-мониторов) в среде клиент-сервер было сокращение числа со-

единений клиентских систем с базами данных. При непосредственном

обращении клиента к серверу базы данных для каждого клиента уста-

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

процесса в рамках операционной системы. ТР-мониторы брали на себя

роль концентратора таких соединений, становясь посредником между

клиентом и сервером базы данных.

Постепенно, с развитием трехзвенной архитектуры клиент-сервер

функции ТР-мониторов расширились, и они превратились в платформу

для транзакционных приложений в распределенной среде с множеством

баз данных под различными СУБД.

ТР-мониторы представляют собой одну из самых сложных и мно-

гофункциональных технологий в мире промежуточного ПО. Основное

247

их назначение – автоматизированная поддержка приложений, оформ-

ленных в виде последовательности транзакций. Каждая транзакция – это

законченный блок обращений к ресурсу (как правило, базе данных) и

некоторых действий над ним, для которого гарантируется выполнение

четырех условий:

− атомарность – операции транзакции образуют неразделимый,

атомарный блок с определенным началом и концом. Этот блок либо

выполняется от начала до конца, либо не выполняется вообще. Если в

процессе выполнения транзакции произошел сбой, происходит откат

(возврат) к исходному состоянию;

− согласованность – по завершении транзакции все задейство-

ванные ресурсы находятся в согласованном состоянии;

− изолированность – одновременный доступ транзакций различ-

ных приложений к разделяемым ресурсам координируется таким обра-

зом, чтобы эти транзакции не влияли друг на друга;

− долговременность – все изменения данных (ресурсов), осущест-

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

В системе без ТР-монитора, обеспечение этих свойств берут на се-

бя серверы распределенной базы данных, использующие двухфазный

протокол (2РС- two-phase commit). Протокол 2РС описывает двухфаз-

ный процесс, в котором перед началом распределенной транзакции все

системы опрашиваются о готовности выполнить необходимые действия.

Если каждый из серверов баз данных дает утвердительный ответ, тран-

закция выполняется на всех задействованных источниках данных. Если

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

кат для всех частей транзакции.

Однако в системе с распределенными базами данных выполнение

протокола 2РС можно гарантировать только в том случае, если все ис-

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

ной распределенной среды, которая обслуживает тысячи клиентских

мест и работает с десятками разнородных источников данных, без мони-

тора транзакций не обойтись. ТР-мониторы способны координировать и

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

различных поставщиков благодаря тому, что большинство этих продук-

тов помимо протокола 2РС поддерживают транзакционную архитекту-

ру (ХА), которая определяет интерфейс для взаимодействия ТР-

монитора с менеджером ресурсов, например, СУБД Oracle или Sybase.

Спецификация ХА является частью общего стандарта распределенной

обработки транзакций (distributed transaction processing – DTP), разрабо-

танного X/Open (рис. 8.14).

Функции современных ТР-мониторов не ограничиваются под-

держкой целостности прикладных транзакций. Большинство продуктов

этой категории способны распределять, планировать и выделять при-

оритеты запросам нескольких приложений одновременно, тем самым,

248

сокращая процессорную нагрузку и время отклика системы. Обработка

запросов организуется в виде «нитей» ОС, а не полновесных процессов,

тем самым значительно снижая загруженность системы.

Рис. 8.14. Архитектура распределенной обработки транзакций

Таким образом снимается одно из серьезных ограничений произ-

водительности и масштабируемости клиент-серверной среды – необхо-

димость поддержки отдельного соединения с базой данных для каждого

клиента.

8.4.3. Корпоративные серверы приложений

Появление серверов приложений как отдельных готовых решений

связано и с бурным вторжением Web-технологий в сферу корпоратив-

ных высоко-критичных систем. Однако возможности протокола НТТР

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

формации о состоянии, поэтому он не подходит для поддержки мощных

корпоративных систем

На рис. 8.15 приведен «идеальный» состав сервера приложений с

максимальным набором необходимых служб и средств связи с клиент-

скими системами и информационными ресурсами.

XA API

TX API

Сервер

RM API

Приложение

TP-монитор

Приложение

Менеджер

ресурса

Менеджер ресурса

TX API

Клиент

XA API

249

Рис. 8.15. Обобщенная структура сервера приложений

Сегодня прикладные разработки базируются на одной из двух

компонентных моделей – MTS/DСОМ и CORBA, способных интегриро-

вать объекты на удаленных платформах.

Обе модели распространяют принципы вызова удаленных проце-

дур на объектные распределенные приложения и обеспечивают про-

зрачность реализации и физического размещения серверного объекта

для клиентской части приложения; поддерживают возможность взаимо-

действия объектов, созданных на различных объектно-ориентированных

языках и скрывают от приложения детали сетевого взаимодействия.

Средства разработки

Управление сеансами

Защита

Оповещение о событиях

Служба каталогов

Контроль доступа к разделяемым

ресурсам

Оптимизация распределения нагруз-

ки

Управление транзакциями

ORB, TP-монитор,

SQL-шлюзы

Унаследованные

приложения и

данные

Другие серве-

ры приложе-

ний

Внешние

приложения

СУБД

COM кли-

ент

CORBA кли-

ент

Java клиент

Браузер

Web-сервер

HTML-

документы

CGI-

приложения

250

Рис. 8.16. DCOM-технология взаимодействия «клиент-сервер»

В DCOM взаимодействие удаленных объектов, представленное на

рис. 8.16, базируется на спецификации DCE RPC, а CORBA использует

брокер объектных запросов (ORB), синхронный механизм которого во

многом схож с RPC.

В DCOM-технологии взаимодействие между клиентом и сервером

осуществляется через двух посредников. Клиент помещает параметры

вызова в стек и обращается к методу интерфейса объекта. Это обраще-

ние перехватывает посредник Proxy, упаковывает параметры вызова в

COM-пакет и адресует его в Stub, который в свою очередь распаковыва-

ет параметры в стек и инициирует выполнение метода объекта в про-

странстве сервера.

CORBA-технология также использует интерфейс объекта, но в

этом случае, схема взаимодействия объектов (рис. 8.17) включает про-

межуточное звено (Smart agent), реализующее доступ к удаленным объ-

ектам. Smart agent установленный на машинах сетевого окружения (сер-

вере локальной сети или Internet-узле), моделирует сетевой каталог из-

вестных ему серверов объектов. При создании сервера происходит авто-

матическая регистрация его объектов в каталоге одного или нескольких

Smart agent.

Связи между брокерами осуществляется в соответствии с требова-

ниями специального протокола General Inter ORB Protocol, определяю-

щего низкоуровневое представление данных и множество форматов со-

общений.

Рис. 8.17. CORBA-технология взаимодействия клиент-сервер

Процесс клиента

Клиент Proxy

Процесс сервера

Stub Объект

Машина клиента

Клиент

Stub ORB

Сетевое

окруже-

ние

Smart

agent

Машина сервера

ORB BOA

Объект

Skele-

ton