пр_ИС_Тем15

Тема 15. Межсистемные интерфейсы и интерфейсы в распределенных системах

15.1. Архитектура Microsoft Universal Data Access

Согласно утверждению Microsoft Universal Data Access представляет собой стратегию обеспечения доступа ко всем типам информации, используемой в масштабах предприятия (фирмы). Она обеспечивает высокопроизводительный доступ к различным информационным источникам: реляционные данные, иерархические базы данных; файлы электронной почты и файловая система, текстовым, графическим и географическим данным и так далее.

Главная цель Microsoft Universal Data Access состоит в обеспечении доступа ко всем вышеупомянутым типам данных с помощью единой модели. Если вы знакомы с ODBC, вы можете представить себе Universal Data Access как "ODBC для всех типов данных — реляционных и нереляционных".

В настоящее время Universal Data Access взаимодействует со всеми основными платформами баз данных, а также с некоторыми источниками данных, не относящимися к СУБД, облегчая разработку приложений с использованием баз данных посредством общих интерфейсов.

Архитектура Universal Data Access включает в себя следующие элементы.

•Microsoft ActiveX Data Objects (ADO) представляет собой высокоуровневый интерфейс прикладного программирования для доступа к реляционных и нереляционных данным, хранящимся в различных источниках.

•OLE DB предоставляет низкоуровневый интерфейс доступа к данным в масштабе предприятия. ADO работает "за кулисами" с OLE DB, однако, в случае необходимости, мы можем непосредственно использовать OLE DB.

•Open Database Connectivity (ODBC) является стандартом Microsoft для работы с реляционными данными. Этот компонент служит для обеспечения совместимости с более ранними разработками, так как в современных решениях его роль играют

собственные провайдеры OLE DB.

Архитектура Microsoft Universal Data Access представлена на рис. 15.1.

Приложение

ADO

OLE DB

ODBC

Рис. 15.1. Архитектура Microsoft Universal Data Access

15.2. Архитектура OLE DB

OLE DB представляет собой набор низкоуровневых интерфейсов, которые предоставляют приложению-клиенту унифицированный доступ к различным источникам данных — реляционным и нереляционным, содержащим текст, графические и географические данные, к файлам электронной почты, содержимому файловых систем и создаваемым пользователями бизнесобъектам. OLE DB определяет набор интерфейсов, включающих в себя службы различных систем управления базами данных для обеспечения универсального доступа к данным. С помощью этих интерфейсов программисты могут создавать дополнительные сервисы баз данных. В отличие от доступа, предоставляемого посредством драйверов OBDC, OLE DB позволяет реализовывать доступ к источникам данных, как с применением языка SQL (к SQL-серверам), так и к любым другим произвольным источникам данных

На самом верхнем уровне можно определить три главных компонента OLE DB. Это — потребители (consumers), провайдеры данных (data providers) и провайдеры сервисов (служб) (service providers).

Любой компонент программного обеспечения, который использует интерфейсы OLE DB, является потребителем (consumer) OLE DB. Это может быть бизнес-приложение,

инструментальное средство разработки программного обеспечения, например, Borland Delphi,

сложные приложения (sophisticated applications) или же объектная модель ActiveX Data Objects,

использующая интерфейсы OLE DB. Потребители используют либо те ActiveX Data Objects (ADO), которые являются интерфейсом прикладного уровня для обеспечения косвенного (indirect) доступа к данным с применением OLE DB, либо непосредственно OLE DB — для прямого доступа к данным с помощью провайдера OLE DB.

Провайдер (provider) — это часть программного обеспечения, реализующая и предоставляющая набор базовых интерфейсов OLE DB. С точки зрения OLE DB, может быть два вида провайдеров: OLE DB — провайдеры данных (data providers) и провайдеры сервисов (служб) (service providers).

Провайдер данных (data provider) представляет собой компонент программного обеспечения, "владеющий" данными. Он находится между потребителем и непосредственным массивом данных. В OLE DB все провайдеры представляют данные в табличном формате (с которым мы уже знакомы по реляционным базам данных и электронным таблицам), в виде виртуальных таблиц.

Провайдер данных выполняет следующие задачи.

1.Принимает запросы, поступающие от потребителя, на доступ к данным. 2.Выполняет выборку или обновление данных из массива данных. 3.Возвращает эти данные потребителю.

Одним из примеров провайдера данных служит Microsoft Jet 4.0 OLE DB Provider. Он используется совместно с механизмом доступа к базам данных Microsoft Jet, применяемым для обработки информации в базах данных Microsoft Access, а также для доступа к информации, упорядоченной с помощью так называемого инсталлируемого индексно-последовательного метода доступа (Indexed Sequential Access Method, I-ISAM), который поддерживается в Jet. К

таким данным относятся таблицы, хранимые в рабочих книгах Excel, почтовые файлы Outlook и Microsoft Exchange, таблицы dBase и Paradox, текстовые и HTML-файлы и т. д. Другим провайдером OLE DB является Microsoft OLE DB Provider for SQL Server, используемый для работы с базами данных Microsoft SQL Server 6.5 и 7.0.

Провайдер сервисов (служб) (service provider) (недавно корпорация Microsoft изменила это название на "компонент сервисов (служб)" (service component)) реализует расширенные функциональные возможности, которые не поддерживаются обычными провайдерами данных, но провайдер сервисов (служб) сам не "владеет" данными.

Таким образом, провайдер сервисов представляет не владеющий данными компонент, который реализует такие функции как сортировка, фильтрация, управление транзакциями, обработка SQL-запросов, функции указателя (курсора) (cursor functions) и т. д.

Провайдер сервисов может напрямую работать с массивами данных или же через соответствующий провайдер данных; в этом случае он выступает в роли потребителя и провайдера. Например, такие провайдеры сервисов, как Microsoft Cursor Service for OLE DB и Microsoft Data Shaping Service for OLE DB могут интегрироваться с базовыми провайдерами данных OLE DB для расширения их функциональных возможностей. На рис. 15.2 показано взаимодействие между тремя компонентами OLE DB и пути доступа к данным для потребителей.

Потребитель OLE DB

Провайдер сервиса OLE DB

Провайдер данных OLE DB

Массив данных

Рис. 15.2. Компоненты OLE DB

Как видно на рис. 15.2, потребитель может получать данные как непосредственно от провайдера данных, так и используя службы, предоставляемые провайдером сервисов. В следующей главе мы подробно рассмотрим провайдеры данных и сервисов, входящие в состав пакета Microsoft Data Access Components, а также некоторых других программных продуктов

Microsoft.

15.3. Архитектура ODBC

Интерфейс ODBC (Open Database Connectivity) был разработан фирмой Microsoft как открытый интерфейс доступа к базам данных. Он предоставляет унифицированные средства (драйверы) взаимодействия прикладной программы, называемой клиентом (или приложениемклиентом), с сервером - базой данных.

В основу интерфейса ODBC были положены спецификация CLI-интерфейса (Call-Level Interface), разработанная X/Open, и ISO/IEC для API баз данных, а также язык SQL (Structured Query Language) как стандарт языка доступа к базам данных.

Интерфейс ODBC проектировался для поддержки максимальной интероперабельности приложений, которая обеспечивает унифицированный доступ любого приложения, использующего ODBC, к различным источникам данных. Так, если приложение, соответствующее стандарту ODBC и SQL, первоначально разрабатывалось для работы с базой данных Microsoft Access, а затем таблицы этой базы были перенесены в базу данных Microsoft SQL Server или базу данных Oracle, то приложение сможет и дальше обрабатывать эти данные без внесения дополнительных изменений.

Для взаимодействия с базой данных приложение-клиент вызывает функции интерфейса ODBC, которые реализованы в специальных модулях, называемых ODBC-драйверами. Как правило, ODBC-драйверы - это DLL-библиотеки, при этом одна DLL-библиотека может поддерживать несколько ODBC-драйверов. При установке на компьютер любого SQL-сервера (базы данных, поддерживающей один из стандартов языка SQL, например, SQL-92) автоматически

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

Клиентом является приложение, посылающее запрос на обслуживание сервером. Задачей клиента являются инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера результата обслуживания, подтверждение окончания обслуживания.

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

В общем случае схема клиент-серверной архитектуры включает три уровня представления: уровень представления (презентации) данных пользователем; уровень обработки данных приложением и уровень взаимодействия с базой данных.

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

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

Рассмотрим различные схемы клиент-серверной архитектуры (рис. 15.4).

•Централизованная система

•Архитектура "Файл-сервер"

•Двухуровневая архитектура "Клиент-сервер"

•Трехуровневая архитектура "Клиент-сервер"

•Многоуровневая архитектура "Клиент-сервер"

Рис. 15.4. Варианты клиент-серверной архитектуры КИС

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

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

Использование файл-серверов предполагает, что вся обработка данных выполняется на рабочей станции, а файл-сервер лишь выполняет функции накопителя данных и средств доступа.

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

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

Сервер базы данных отвечает за сохранение данных в файлах, создание резервных копий, поддержание целостности ссылок, представление доступа пользователю, а также за безопасность данных, ведение журнала базы данных, и, конечно же, за выполнение пользовательских запросов на изменение, создание и удаление данных.

Сервер базы данных отличается от файл-сервера тем, что в его оперативной памяти, помимо сетевой операционной системы, функционирует централизованная СУБД, которая обеспечивает совместное использование рабочими станциями базы данных, размещенной во внешней памяти этого DB-сервера.

Сервер базы данных дает возможность отказаться от пересылки по сети файлов данных целиком и передавать только ту выборку из базы данных, которая удовлетворяет запросу пользователя. При этом возможно разделение пользовательского приложения на две части: одна часть выполняется на сервере и связана с выборкой и агрегированием данных из базы данных, а вторая часть по представлению данных для анализа и принятия решения выполняется на клиентской машине. Таким образом, увеличивается общая производительность информационной системы в результате объединения вычислительных ресурсов сервера и клиентской рабочей станции.

Обращение к базе данных осуществляется на языке SQL, который фактически стал стандартом для реляционных баз данных. Отсюда сервер баз данных часто называют SQLсервером, который поддерживается всеми реляционными СУБД: Oracle, Informix, MS SQL, ADABAS D, InterBase, SyBagg и др. Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер (Open Data Base Connectivity), который обеспечивает возможность пересылки и преобразования данных из глобальной базы данных в структуру базы данных клиентского приложения. Применение этой технологии позволило разработчикам не заботиться о специфике работы с той или иной СУБД и делать свои системы переносимыми между базами данных. За время своего существования ODBC стал стандартом де-факто на алгоритм доступа к разнородным базам данных, и на сегодняшний день насчитывается более 160 прикладных систем, которые работают с источниками информации через драйверы ODBC.

Архитектура клиент/сервер имеет следующие преимущества.

1.Нагрузка сети при выполнении запросов к базе данных не возрастает. При использовании серверов баз данных выбор последних пяти заказов из 10000 приводит к отправке этих пяти записей по сети. Все операции по их выбору выполняются сервером базы данных. Время выполнения такого запроса, конечно, зависит от того, есть ли соответствующий индекс, но во всех случаях клиентскому приложению посылается в итоге только пять записей.

2.Бизнес-правила и правила обеспечения целостности на уровне ссылок могут храниться на сервере. Они реализованы в различных объектах базы данных, содержащихся в базе данных, и специально разработанных для этих целей. Это позволяет избежать дублирования программного кода в различных клиентских приложениях.

3.Любой сервер СУБД обеспечивает безопасность данных, применяя список пользователей

ипредоставляя им различные привилегии при использовании объектов базы данных. Далее мы обсудим этот вопрос в данной главе.

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

Втрехуровневой архитектуре уровень бизнес-сервисов соединен с уровнем сервисов данных СУБД.

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

Рис. 15.5. Схема потока данных в трехуровневой и четырехуровневых архитектурах клиент-сервер

Многоуровневая архитектура «Клиент-сервер» создается для территориально-

распределенных предприятий. Для нее в общем случае характерны отношения «многие ко многим» между клиентскими рабочими станциями и серверами приложений, между серверами приложений и серверами баз данных. Такая организация позволяет более рационально организовать информационные потоки между структурными подразделениями в процессе выполнения общих деловых процессов. Так, каждый сервер приложений, как правило, обслуживает потребности какой-либо одной функциональной подсистемы и сосредоточивается в головном для подсистемы структурном подразделении, например, сервер приложения по управлению сбытом - в отделе сбыта, сервер приложения по управлению снабжением - в отделе закупок и т.д. Естественно, что локальная сеть каждого из подразделений обеспечивает более быструю реакцию на запросы основного контингента пользователей из соответствующего подразделения. Интегрированная база данных находится на отдельном сервере, на котором обеспечиваются централизованное ведение и администрирование общих данных для всех приложений.

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