Алешин Л.И., Максимов Н.В. Информационные технологии

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

371

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

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

ка;

• драйвер БД определяет допустимые типы сетевых интерфейсов;

• библиотечные функции обычно неунифицированы.

Некоторой модификацией данного способа является использова-

ние «встроенного» языка SQL. В этом случае текст программы на языке

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

посредственно предложения SQL, которые предваряются выражением

«EXEC SQL». Перед компиляцией в машинный код такая программа об-

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

«собственного» языка СУБД и SQL-предложений в промежуточный

«чистый» исходный код, а затем коды SQL замещаются вызовами соот-

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

СУБД. Такой подход позволяет несколько снизить степень привязанно-

сти к СУБД, например, при переключении ПП на работу с другим серве-

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

пилировать программу.

Программный интерфейс уровня вызовов

Стандарт SQL2 определил интерфейс уровня вызова (CLI – Call

Level Interface), в котором стандартизован общий набор рабочих проце-

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

веров баз данных.

Технологическая основа CLI – размещаемая на компьютере клиен-

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

понентов для организации связи с сервером. Это ПО поставляется обыч-

но в составе среды разработки и поддерживает разнообразные сетевые

протоколы.

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

му операции на компьютере-клиенте. В общем случае клиент формирует

оператор языка SQL в виде строки и пересылает её на сервер посредст-

вом процедуры исполнения (execute). Когда же сервер в качестве ответа

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

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

столбцов полученной таблицы могут быть связаны с соответствующими

переменными приложения. Вызов специальной процедуры позволяет

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

каждом столбце.

372

Открытый интерфейс доступа к базам данных

Спецификация открытого интерфейса баз данных (ODBC – Open

Database Connectivity), предназначена для унификации доступа к дан-

ным, размещённым на удалённых серверах. ODBC опирается на специ-

фикации CLI.

ODBC представляет программный слой, унифицирующий интер-

фейс взаимодействия приложений с БД. За реализацию особенностей

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

альный ODBC-драйвер. Пользовательское приложение этих особенно-

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

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

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

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

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

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

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

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

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

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

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

ODBC

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

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

практически с любой системой. Однако этот способ также не лишен не-

достатков:

СУБД 1

райвер

СУБД 2

райвер

Сеть

Локальны

диск

Прикладная

пр

грамма

ODB

driver ma

локальный

ODB

драйвер

ODBС-драйвер

СУБД

ODBС-драйвер

СУБД 1

Файловая

Др

айве

сети

373

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

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

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

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

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

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

жет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ем JDBC приведена на Рис. 19-12.

Прикладные интерфейсы 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 и воз-

374

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

виде.

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

JDBC

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервер

Се

ве

лиент

ODBC –совместимая

СУБД

СУБД 1

Драйвер

сети

СУБД 2

Драйвер

сети

Сеть

Java

программа

JDBC-driver manager

Драйвер сети

JDBC

Драйвер

СУБД 1

JDBC

Драйвер

СУБД 1

Мост

JDBC

ODBC

JDBC-

Net

Driver

375

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

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

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

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

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

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

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

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

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

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

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

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

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

лей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

376

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

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

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

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

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

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

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

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

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

единений клиентских систем с БД. При непосредственном обращении

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

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

рамках ОС. ТР-мониторы брали на себя роль концентратора таких со-

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

данных.

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

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

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

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

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

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

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

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

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

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

вий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

377

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

дый из серверов БД даёт утвердительный ответ, транзакция выполняется

на всех задействованных источниках данных. Если хотя бы в одном мес-

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

транзакции.

Однако в системе с распределёнными БД выполнение протокола 2РС

можно гарантировать только в том случае, если все источники данных

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

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

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

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

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

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

протокола 2РС поддерживают транзакционную архитектуру (ХА), оп-

ределяющую интерфейс для взаимодействия ТР-монитора с менеджером

ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА явля-

ется частью общего стандарта распределённой обработки транзакций

(distributed transaction processing – DTP), разработанного X/Open (Рис.

19-13).

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

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

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

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

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

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

XA API

TX API

Се

вер

RM API

Приложение

TP-монитор

Приложение

Менеджер

ресурса

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

TX API

XA API

378

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

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

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

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

мость поддержки отдельного соединения с БД для каждого клиента.

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

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

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

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

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

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

ных систем.

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

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

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

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

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

удалённых платформах.

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

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

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

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

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

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

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

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

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

Защита

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

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

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

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

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

ORB, TP-

монито

р,

Унаследо-

ванные

Другие

серв

ры

Внешние

прил

о-

СУБД

COM

CORBA

Java кли-

Браузер

Web-

сервер

HTML-

докуме

379

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ких Smart agent.

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

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

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

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

общений.

На машине клиента создаются два объекта-посредника: Stab и

ORB (Object Required Broker – брокер вызываемого объекта). Также как

и в DCOM-технологии, Stub передаёт перехваченный вызов брокеру, ко-

торый посылает широковещательное сообщение в сеть. Smart agent, по-

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

Клиент Proxy

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

Stub Объект

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

Клиент

Stub ORB

Сетевое

окружение

Smart

agent

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

ORB BOA Объект

Skele-

380

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

брокеру, размещённому на машине сервера. Вызов требуемого объекта

производится через специальный базовый объектный адаптер (BOA).

При этом данные в стек пространства вызываемого объекта помещает

особый объект сервера (Skeleton), вызываемый адаптером.

Кроме того, CORBA помимо механизма взаимодействия с помо-

щью ORB, включает в себя ряд общих служб CORBA Services (служба

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

ряд других), а также реализаций объектов для разных прикладных об-

ластей.

Ключевым компонентом архитектуры CORBA является язык опи-

сания интерфейсов IDL, на уровне которого поддерживаются «кон-

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

зависимость от конкретного объектно-ориентированного языка. CORBA

IDL поддерживает основные понятия объектно-ориентированной пара-

дигмы (инкапсуляцию, полиморфизм и наследование).

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

Microsoft язык IDL, который, однако, играет вспомогательную роль и

используется в основном для удобства описания объектов. Реальная ин-

теграция объектов в DCOM происходит не на уровне абстрактных ин-

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

чий этих двух объектных моделей.

И DCOM, и CORBA, в отличие от процедурного RPC, дают воз-

можность динамического связывания удалённых объектов: клиент мо-

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

мации об этом объекте на этапе компиляции. В CORBA для этого суще-

ствует специальный интерфейс динамического вызова DII, а СОМ ис-

пользует механизм OLE-Automation. Информацию о доступных объек-

тах сервера на этапе выполнения клиентская часть программы получает

из специального хранилища метаданных об объектах – репозитария ин-

терфейсов Interface Repositary в случае CORBA, или библиотеки типов

(Type Library) в модели DCOM. Эта возможность очень важна для

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

расширять функциональность серверов, не внося существенных измене-

ний в код клиентских компонентов программы. Например, банковское

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

в центральном офисе, а клиентские системы разбросаны по филиалам в

разных городах.

Доступ к данным с помощью ADO.NET

ADO.NET является преемником Microsoft ActiveX Data Objects

(ADO). Это W3C-стандартизированная модель программирования для

создания распределённых прикладных программ, нацеленных на совме-

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