Файл: Лекция 01. Основные принципы построения распределенных информационных систем Скворцов С. Е. 15 января 2019.docx

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

Такой подход является достаточно универсальным, стандартизируемым, что и позволяет использовать ODBC-механизмы для работы практически с любой системой. Однако этот способ также не лишен недостатков:

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

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

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

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

• 
  приложение загружает JDBC-драйвер динамически, следовательно, администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места.
  
• 
  JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно, проблемы с переносимостью приложений практически снимаются.
  
• 
  использование Java-приложений и связанной с ними идеологии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.
  

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

Прикладные интерфейсы OLEDB и ADO

OLEDB (Object Linkingand Embedding Data Base), как и ODBC – прикладные интерфейсы доступа к данным с использованием SQL.

OLEDB специфицирует взаимодействие, обеспечивая единый интерфейс доступа к данным через провайдеров – поставщиков данных не только из реляционных БД. В отличие от ODBC, OLEDB предоставляет общее решение обеспечения COM-приложениям доступа к информации независимо от типа источника данных.

OLEDB включает два базовых компонента: 

---

провайдер данных и потребитель данных. Потребитель (клиент) – приложение или COM-компонент, обращающийся посредством API-вызовов к OLEDB. Провайдер (сервер) – приложение, отвечающее на вызовы OLEDB и возвращающее запрашиваемый объект – обычно это данные в табличном виде.



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

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

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

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

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

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

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

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

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

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

---

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

В общем случае механизм RPC создаёт статические отношения между компонентами распределённого приложения – привязка клиентского процесса к конкретным серверным суррогатам происходит на этапе компиляции и не может быть изменена во время выполнения. Этим RPC отличается от таких более выгодных решений, как ТР-мониторы, поддерживающие возможности оптимального распределения нагрузки на серверы и средства восстановления при сбоях.

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

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

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

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

Постепенно, с развитием трёхзвенной архитектуры клиент-сервер функции ТР-мониторов расширились, и они превратились в платформу для транзакционных приложений в распределённой среде с множеством БД под различными СУБД.

ТР-мониторы представляют одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Основное их назначение – автоматизированная поддержка приложений, оформленных в виде последовательности транзакций. Каждая транзакция – законченный блок обращений к ресурсу (как правило, базе данных) и некоторых действий над ним, для которого гарантируется выполнение четырёх условий:

---

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

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

Однако в системе с распределёнными БД выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределённой среды, обслуживающей тысячи клиентских мест и работающей с десятками разнородных источников данных, без монитора транзакций не обойтись. ТР-мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру (ХА), определяющую интерфейс для взаимодействия ТР-монитора с менеджером ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА является частью общего стандарта распределённой обработки транзакций (distributed transaction processing – DTP), разработанного X/Open.



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

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

---

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

---