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

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

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

Таким образом, следующим этапом в обеспечении доступа клиентского приложения к данным является создание универ­сального механизма доступа к БД, обеспечивающего для клиент­ского приложения стандартный набор функций, классов или сервисов (служб), необходимых для работы с различными систе­мами управления базами данных. Эти стандартные функции (классы или сервисы) должны размешаться в библиотеках, име­нуемых драйверами или провайдерами баз данных (data base drivers (providers)). Каждая такая библиотека реализует набор стандартных функций, классов или сервисов, используя обраще­ния API к конкретной СУБД.

Наиболее популярными механизмами доступа к данным (Universal Data Access — UDA) в настоящий момент являются: ODBC, OLE DB, ADO, BDE.

Первые три являются фактически промышленными стандар­тами. Последний долгое время был единственным механизмом доступа к данным, реализованным в инструментальных средст­вах разработки компании Borland-Inprise (например, Delphi, С++ Builder).

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

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

 

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

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

На рис. 7.10 приведен обобщенный состав сервера приложе­ний с набором служб и средств связи с клиентскими системами и информационными ресурсами.

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

 

Спецификация вызова удаленных процедур. Протокол вызова удаленных процедур (Remote Procedure Calls — RPC) реализует асимметричное взаимодействие программных компо­нентов, когда можно выделить клиента, которому требуется не­которая услуга, и сервер, который такую услугу способен ока­зать, причем, как правило, клиент не может продолжать свое выполнение, пока сервер не произведет требуемые от него дей­ствия. С точки зрения клиентской программы обращение к сер­веру ничем не отличается от вызова локальной процедуры.

Средства вызова удаленных процедур (RPC) поддерживают синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером).

Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным процедурам — клиентскому и серверному суррогатам (client stub и server stub). Эти процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодейст­вия удаленных прикладных модулей.

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

Ключевым компонентом RPC является язык описания интерфейсов (interface definition language — IDL), предна­значенный для определения интерфейсов, которые задают кон­трактные отношения между клиентом и сервером. Интерфейс содержит определение имени функции и полное описание пере­даваемых параметров и результатов выполнения.

Язык IDL обеспечивает независимость механизма RPC от языков программирования — вызывая удаленную процедуру, клиент может использовать свои языковые конструкции, кото­рые IDL-компилятор преобразует в свои описания. На сервере IDL-описания обратно преобразуются в конструкции языка про­граммирования. на котором реализован серверный процесс.

Транзакции в распределенных БД

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

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

В современных СУБД предусмотрен так называемый прото­кол двухфазовой (или двухфазной) фиксации транзакций (two-phase commit).

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

Фаза 2 — сервер распределенной БД направляет команду «зафиксировать» всем узлам, затронутым транзакцией, и гаран­тирует, что транзакции на них будут зафиксированы. Если связь с локальной базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД принимает решение о фиксации транзакции, и моментом, когда сервер локальной БД подчиняется его команде, то сервер распределенной БД про­должает попытки завершить транзакцию, пока связь не будет восстановлена.

Мониторы обработки транзакций. Мониторы обработки транзакций (Transaction Processing Monitor — ТРМ), или мони­торы транзакций — это программные системы (которые относят к категории middleware, т. е. к посредническому или промежуточному ПО), решающие задачу эффективного управле­ния информационно-вычислительными ресурсами в распреде­ленной системе.

Первоначатьно основной задачей ТРМ в среде клиент—сер­вер было сокращение числа соединений клиентских систем с ба­зами данных. При непосредственном обращении клиента к сер­веру базы данных для каждого клиента устанавливается соедине­ние с СУБД, которое порождает запуск отдельного процесса в рамках операционной системы. TP-мониторы брали на себя роль концентратора таких соединений, становясь посредником между клиентом и сервером базы данных. Основное назначение TP-мониторов — автоматизированная поддержка приложений, представленных в виде последовательности транзакций.

Одна из основных функций ТРМ — обеспечение быстрой обработки запросов, поступающих к серверу приложений от множества клиентов (от сотен до тысяч). ТРМ выполняет ее, мультиплексируя запросы на обслуживание, направляя их серве­рам приложения, число которых контролируется им самим.

Важнейшая характеристика ТРМ — поддержка многомашин­ных конфигураций с возможностью миграции серверов прило­жений и их групп на резервный компьютер в случае сбоев в ра­боте основного — является фундаментом, на котором может быть построена система, по надежности близкая к абсолютной. Действительно, применение так называемых безотказных (fault tolerant) компьютеров гарантирует сохранение работоспособно­сти лишь при случайных сбоях, но бессильно перед злоумыш­ленником или в случае механического повреждения.

На современном рынке мониторов транзакций основными являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO Sytem (Novell). Наиболее известной из этой группы является система CICS (Customer Information Control System), работавшая на мэйнфрейме IBM.

Модель обработки транзакций. Понятия транзакции в ТРМ и в традиционных СУБД значительно отличаются. Суть остается одной, но в понимании СУБД транзакция — это атомарное дей­ствие над базой данных, в то время как в ТРМ транзакция трак­туется гораздо шире. Она включает не только операции с данны­ми, но и любые другие действия — передачу сообщений, выдачу отчетов, запись в индексированные файлы, опрос датчиков и т. д. Это позволяет реализовать в 1 I'M прикладные транзак­ции, бизнес-транзакции, которые в СУБД не предусмотрены.

ТРМ опирается на модель обработки распределенных тран­закций X/Open DTP, которая описывает взаимодействие трех субъектов обработки транзакций — прикладной программы (в качестве прикладной программы фигурирует как сервер прило­жения, так и клиент приложения), менеджера транзакций (Transaction Manager — ТМ) и менеджера ресурсов (Resource Manager — RM). Модель представлена на рис. 7.11.

Рис. 7.11. Модель обработки распределенных транзакций X/Open DTP

 

На RM возложено управление информационными ресурса­ми — будь то файлы, базы данных или что-то другое. Прило­жение взаимодействует с RM либо с помощью набора специ­альных функций, либо (если в качестве RM выступает реляци­онная SQL-ориентированная СУБД) посредством операторов языка SQL, инициируя необходимые операции с данными. По­следние оформляются как транзакции, обработку которых бе­рет на себя ТМ. Если с помощью монитора транзакций необ­ходимо решать задачи обработки распределенных транзакций, то роль менеджера ресурсов должна играть СУБД, поддержи­вающая двухфазовый протокол фиксации транзакций и удовле­творяющая стандарту X/Open ХА (например, Oracle 7.x, OpenlNGRES, Informix-Online 7.x).

Роль ТМ в модели X/Open DTP — это роль диспетчера, глав­ного координатора транзакций. Он обладает полным набором функций управления как локальными, так и глобальными рас­пределенными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управле­ние данными на них, вообще говоря, осуществляется различны­ми RM. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации тран­закций, который гарантирует целостность данных в информаци­онной системе, распределенной по нескольким узлам, независи­мо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность как раз и позволяет рассматривать ТРМ как средство интеграции в гетерогенной ин­формационной среде.

Функции ТМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также ко­ординацию взаимодействия клиента и сервера (поэтому иногда его называют менеджером транзакций и коммуникаций). При этом используется высокоуровневый интерфейс ATMI, пред­ставляющий собой набор вызовов функций на языке третьего поколения (например, на языке Си). С его помощью разработ­чик реализует один из нескольких режимов взаимодействия кли­ента и сервера в рамках расширенной модели «клиент — сер­вер». Ни сервер приложения, ни клиент приложения не содер­жат явных вызовов менеджера транзакций — они включены в библиотечные функции ATMI и «невидимы» извне. Таким обра­зом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что и дает основание гово­рить об ATMI как о высокоуровневом интерфейсе.

Функциональный подход. Фундаментальная характеристика ТРМ — функциональный (function-centric) подход к проектиро­ванию бизнес-приложений — сосредоточение всех прикладных функций в серверах приложений по сути означает поставку (или предоставление) функций (functions shipping) для программы-клиента, в отличие от традиционной архитектуры с сервером базы данных, следующей парадигме поставка (или предоставление) данных (data shipping).

Возможность декомпозиции приложений по нескольким уровням с четко очерченными функциями и стандартными ин­терфейсами позволяет создавать легко модифицируемые систе­мы со стройной и целостной архитектурой. Концентрация чисто прикладных функций в серверах приложений и использование унифицированных интерфейсов с другими логическими компо­нентами делает прикладную систему практически полностью не­зависимой как от конкретной реализации интерфейса с пользо­вателем, так и от необходимого ей менеджера ресурсов. Первое означает, что для реализации интерфейса с пользователем может быть выбран практически любой удобный и привычный для раз­работчика инструментарий, будь то Microsoft Visual С++ или Visual Basic; следствием второго является то, что менеджер ре­сурсов (например, СУБД) может быть заменен на другой, под­держивающий тот же стандарт интерфейса с прикладной про­граммой. Для реляционных СУБД в качестве унифицированного интерфейса используется встроенный (embedded) SQL. Разуме­ется, в реализации ESQL для каждой конкретной СУБД имеются различия, порой весьма существенные. Поэтому приложение должно быть либо разработано специально с целью работы с конкретной СУБД, либо оно должно быть спроектировано так, чтобы максимально безболезненно перенастраиваться на работу с другой СУБД.

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

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