Универсальный доступ к данным: Microsoft UDA

Алексей Федоров

 

Решение — Microsoft Universal Data Access

OLE DB

ADO

RDS

ODBC

Какую технологию выбрать

Вместо заключения

Приложение

 

Разработчики, создающие решения с использованием данных, часто сталкиваются со следующей проблемой. Необходимо работать с «обычными», реляционными данными, а также с данными, которые хранятся в файлах, почтовых системах, электронных таблицах и в различных других форматах... Естественно, что каждое современное приложение, например Microsoft Office, позволяет в какой-то мере использовать данные, хранимые в его собственных форматах, но создание приложения, которое бы, например, работало с данными в формате Microsoft SQL Server или Microsoft Access и при этом поддерживало бы электронные таблицы или работу с электронной почтой, часто бывает затруднительным. Множество имеющихся на сегодняшний день данных показано на следующем рисунке:   

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

Решение — Microsoft Universal Data Access

Microsoft Universal Data Access (UDA) — это новая архитектура фирмы Microsoft, обеспечивающая доступ к реляционным и нереляционным данным в различных форматах, которые могут храниться на различных платформах в рамках организации. UDA предоставляет простой программный интерфейс, использование которого возможно практически из любого современного средства разработки приложений. Чтобы освоить новую архитектуру, вам не потребуется менять само средство разработки, будь то Visual Basic, C++, Delphi или Microsoft Office.

Microsoft UDA базируется на открытых стандартах и не требует использования технологий, предоставляемых только одним производителем. В настоящее время Microsoft UDA поддерживается всеми основными базами данных. Одним из достоинств данной архитектуры является то, что для ее использования не требуется переноса существующих данных в единое хранилище. Напротив, Microsoft UDA поддерживает все существующие источники данных и даже облегчает их использование, предоставляя единый, универсальный способ доступа к данным.

Прежде чем обратиться к более детальному рассмотрению Microsoft UDA, следует отметить, что данная архитектура является одной из составных частей стратегии Microsoft Windows Distributed Internet Applications (Windows DNA), о которой более подробно можно прочитать в статье «Microsoft PDC: Создание Web-приложений в эпоху Internet» в КомпьютерПресс № 12’98.

Для разработчиков архитектура Microsoft UDA доступна через компоненты Microsoft Data Access Components (MDAC), которые включают в себя ActiveX Data Objects (ADO), Remote Data Services (RDS), OLE DB и ODBC. Именно эти компоненты лежат в основе Microsoft UDA и делают данную архитектуру работоспособной. Назначение каждого из компонентов Microsoft UDA описано в следующей таблице:   

В настоящее время Microsoft поставляет версию 2.0 Microsoft Data Access Components — она доступна как отдельно (на Web-узле Microsoft), так и в составе Visual Studio 6.0. Версия 2.1 будет поставляться в составе SQL Server 7.0 и будет интегрирована в Windows 2000.

На следующей иллюстрации показано, как компоненты Microsoft UDA взаимодействуют между собой:   

ADO представляет собой программный интерфейс клиентских приложений для доступа к данным. Этот интерфейс позволяет создавать различные приложения — как чисто клиентские (так называемые толстые клиенты), так и Web-приложения (так называемые тонкие клиенты), а также бизнес-объекты, работающие на среднем (middle-tier) уровне систем трехуровневой архитектуры.

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

OLE DB является низкоуровневым интерфейсом для доступа к корпоративным данным. Из диаграммы видно, что ADO напрямую взаимодействует с OLE DB. При необходимости приложения могут непосредственно использовать сервисы OLE DB. И, наконец, ODBC — стандартный способ доступа к реляционным данным. Отметим, что основная нагрузка в Microsoft UDA ложится на провайдеров данных (native providers) OLE DB, а ODBC используется для обеспечения совместимости с уже существующими приложениями и данными.

На диаграмме показана роль RDS. Как мы отметили выше, RDS обеспечивает клиентские сервисы. Например, компоненты, поддерживающие данные, обращаются к ADO как к источнику данных; управление курсорами осуществляется через OLE DB.

Данный компонент является важной частью архитектуры Microsoft UDA, так как он улучшает производительность клиентских приложений и делает всю архитектуру Windows DNA более гибкой.

Отметим, что компонентная модель Microsoft UDA, построенная на базе COM-модели, гарантирует, что в каждый момент будут использоваться только те компоненты, функциональность которых необходима. Этот подход отличается от ODBC, где, как мы помним, тот или иной драйвер должен всегда присутствовать в памяти, независимо от того, используем мы все его функции или только малую их часть.

Разобравшись с архитектурой Microsoft UDA и ее основными компонентами, мы получили общее представление о том, что составляет ядро этой архитектуры и какие технологии при этом используются. Давайте более подробно рассмотрим каждый из компонентов архитектуры Microsoft UDA.

 

В начало

В начало

OLE DB

OLE DB является основой Microsoft UDA и представляет собой низкоуровневый программный интерфейс к корпоративным данным. OLE DB является открытой спецификацией, разработанной на основе ODBC, и обеспечивает доступ к данным любого типа. Первая версия OLE DB была выпущена в августе 1996 года в составе Microsoft ActiveX Data Objects (ADO) 1.0. В сентябре того же года была выпущена версия 1.1, затем — версия 1.5. В настоящее время Microsoft предлагает Data Access Components версии 2.0, в состав которых входит OLE DB 2.0.

Спецификация OLE DB описывает набор COM-интерфейсов для доступа к данным. Для того чтобы стать поставщиком данных (OLE DB Provider), приложению необходимо реализовать ряд компонентов с соответствующими интерфейсами. Такая модель позволяет унифицировать доступ к данным, оставляя возможность ее расширения в будущем.

Основные интерфейсы OLE DB показаны на следующей диаграмме:   

Компоненты OLE DB можно разделить на три категории: поставщики данных (data providers), потребители данных (data consumers) и сервисные компоненты. Основная характеристика поставщика данных — это то, что он является владельцем этих данных и «публикует» их в табличном формате через виртуальные таблицы.

Потребитель данных — это компонент, который обращается к данным от OLE DB-поставщиков; это может быть компонент как системного, так и прикладного уровня. К этой категории относятся средства разработки, языки программирования и различные приложения.

Сервисные компоненты реализуют функциональность СУБД. К ним относятся процессоры запросов, средства управления курсорами, управления транзакциями и т.п. Основной характеристикой сервисных компонентов является то, что они представляют собой отдельные продукты, включаемые в OLE DB при необходимости.

В следующей таблице перечислены основные объекты OLE DB:   

Объект Data Source включает все необходимые функции для непосредственного доступа к источнику данных. Именно этот объект возвращается в результате поиска источников данных объектом Enumerator. Помимо этого можно создать экземпляр объекта Data Source вызовом CoCreateInstance для любого поставщика данных OLE DB. Программисты, знакомые с ODBC, могут рассматривать этот объект как аналог источника данных в ODBC.

Объект Session обеспечивает контекст для транзакций и отвечает за генерацию данных и наборов данных из источника. С одним источником данных могут быть ассоциированы несколько объектов типа Session. Если поставщик данных OLE DB поддерживает команды, объект Session может выполнять роль фабрики классов для объектов типа Command. Объект Session включает в себя всю функциональность соединений ODBC. Если поставщик данных OLE DB поддерживает запросы, он также должен уметь порождать объект типа Command. Несколько объектов этого типа могут быть ассоциированы с объектом Session.

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

Объект Rowset представляет данные в табличном формате. С одним объектом типа Session или Command может быть ассоциировано несколько объектов типа Rowset. Для получения этого объекта обычно выполняется метод IOpenRowser::OpenRowset объекта Session, или же он является результатом запроса, выполненного через объект Command.

К дополнительным объектам относятся объекты Enumerator, Transaction, Error, которые служат для расширения функциональности описанных выше базовых объектов.

Таким образом, использование OLE DB (напомним, что Microsoft рекомендует пользоваться более высокоуровневыми интерфейсами ADO) сводится к следующим шагам:

  1. Инициализация
  2. Поиск источника данных и подключение к нему
  3. Создание и выполнение команды (запроса)
  4. Обработка результатов запроса
  5. Завершение

Эти шаги показаны на следующей диаграмме:   

Отметим, что в OLE DB 2.0 появилась более простая возможность нахождения поставщика данных — вместо использования объекта Enumerator мы обращаемся либо к сервису IDataInitialize, либо к сервису IDBPromptInitialize. Последний использует специальные файлы свойств источников данных и связей — UDL-файлы.

Примечание. Более подробную информацию об OLE DB можно получить из книги «Справочник по Microsoft OLE DB 1.1», изданной «Русской Редакцией».

В настоящее время существуют OLE DB-провайдеры для большинства коммерческих реляционных СУБД, включая Oracle, Microsoft SQL Server, IBM DB2, Sybase, Informix, CA-Ingres, а также ODBC-совместимые источники данных. Кроме того, существуют провайдеры для VSAM, файлов AS-400, IMS/DB и файловой системы Windows NT через Microsoft Index Server. Также разработаны процессоры запросов для OLE DB-данных фирм International Software Group, B2Systems, Intersolv и Microsoft SQL Server.

 

В начало

В начало

ADO

Если рассмотренный нами выше интерфейс OLE DB представляет собой интерфейс низкого уровня, то ActiveX Data Objects (ADO) — это интерфейс прикладного уровня, который Microsoft рекомендует использовать в создаваемых программных решениях. ADO обеспечивает высокопроизводительный доступ к данным, поддерживает практически все задачи, которые встают перед разработчиками, — от создания пользовательских интерфейсов к базам данных до бизнес-объектов, располагаемых на среднем звене (middle-tier), а также может использоваться в любых современных средствах разработки, языках программирования или Internet-браузерах.

ADO 2.0 является третьей версией интерфейса ADO. В первой версии ADO была реализована базовая функциональность уровня «клиент/сервер». В ней также появилась и первая версия OLE DB с поставщиком данных OLE DB Provider for ODBC. В ADO 1.0 было реализовано лишь подмножество функций Remote Data Objects (RDO) 2.0, основным назначением которых являлось обеспечение доступа к данным из Active Server Pages (ASP).

Следующей версией стала ADO 1.5, которая входила в состав Internet Information Server 4.0 и Internet Explorer 4.0. Основным отличием здесь стала интеграция с RDS. Также были добавлены некоторые функции RDO 2.0, отсутствовавшие в первой версии ADO. К новым возможностям также можно отнести поддержку отключенных наборов записей (disconnected recordsets), удаленную работу (remoting), schema-запросы и поддержку команд на уровне методов объекта Connection. Это была первая версия ADO, входившая в состав Microsoft Data Access Components (MDAC) — набора компонентов для доступа к данным из различных программных продуктов и средств разработки.

Версия ADO 2.0 рассчитана в первую очередь на использование совместно со средствами, входящими в состав Visual Studio. В ADO 2.0 реализованы наиболее функциональные элементы RDO 2.0. Помимо этого к основным новинкам ADO 2.0 можно отнести:

  • поддержку асинхронных операций и событий;
  • расширения для C++, позволяющие извлекать данные в форматах данных C и C++;
  • иерархические курсоры и наборы записей;
  • настраиваемые DataFactory;
  • облегчение создания набора записей;
  • сохраняемость наборов записей;
  • поддержку индексов при поиске, сортировке и фильтрации;
  • возможность непосредственной работы с Visual J++ 6.0;
  • поддержку Visual Studio Analyzer;
  • разрешение противоречий при использовании клиентских курсоров;
  • расширенную поддержку защиты информации.

Более подробно эти и другие функции ADO 2.0 мы рассмотрим в одном из следующих номеров.

На приведенной ниже диаграмме показаны основные объекты ADO 2.0:   

Объект Connection представляет собой соединение с источником данных и позволяет выполнять команды и запросы. Для выполнения команды вы используете метод Execute объекта Connection. Если команда возвращает записи, создается и возвращается объект типа Recordset. Для задания более сложного набора записей вы создаете новый объект типа Recordset, ассоциируемый с данным объектом Connection, и открываете курсор.

Объект Command представляет собой команду (запрос или выражение), которая может быть обработана источником данных. Команды могут возвращать ряды и, если позволяет данный поставщик данных, обрабатывать параметры. Объект Command является необязательным объектом в модели ADO, так как некоторые поставщики данных не поддерживают выполнение команд, но поддерживается для тех поставщиков, которые «умеют» это делать.

Команды могут быть простыми SQL-запросами (или написанными на других языках, распознаваемых поставщиками данных) или запросами к хранимым в базе данных процедурам. Команды могут выполняться либо с помощью метода Execute, либо путем создания объекта типа Recordset и ассоциации его с объектом Command при открытии курсора.

Объект Command включает коллекцию объектов типа Parameter. Как мы отметили выше, каждый поставщик данных может поддерживать команды с параметрами. В этом случае коллекция Parameters будет содержать один объект типа Parameter для каждого заданного параметра. Имеется возможность создания объектов типа Parameter и непосредственного добавления их в коллекцию Parameters — тем самым обеспечивается возможность генерации параметризованных команд.

Объект Parameter представляет собой один параметр команды (объект Command). Как мы отметили выше, вы можете непосредственно создавать объекты типа Parameter и добавлять их в коллекцию Parameters.

Объект Recordset является наиболее комплексным из всех объектов ADO. Он содержит большое число свойств и методов, и именно их использует большая часть создаваемого вами кода. Наборы записей используются для просмотра и манипуляции данными, извлеченными из источника. Объект Recordset обеспечивает перемещение по записям, поиск записей, их сортировку и обновление.

Объект Field представляет собой колонку в наборе записей (объект Recordset). Этот объект, который является частью коллекции Fields, можно использовать для получения данных, модификации их значений и ряда других операций.

Объект Error содержит ошибку, возвращаемую источником данных. Этот объект необходим только в том случае, когда в результате вызова одного метода источник данных вернул более одной ошибки. Если поставщик данных при вызове одной функции вернул одну ошибку, вы можете воспользоваться стандартными механизмами обработки ошибок COM.

Ниже приводятся некоторые примеры использования ActiveX Data Objects в различных продуктах.

Использование ADO в Active Server pages (ASP)

<html>
<body>

<% Set cnn = Server.CreateObject(“ADODB.Connection”)
			cnn.Open “dsn=myserver;uid=sa;pwd=”
			set rst = cnn.Execute(“SELECT * FROM authors”)

			For Each col In rst.Fields
				Response.Write col.Name & “ : “ & col.Value
%> <br>
<% Next %>

</body>
</hmtl>

Использование ADO в Internet Explorer 4

<OBJECT classid=”clsid:BD96C556-65A3-11D0-983A-00C04FC29E33"
	ID=ADC HEIGHT=1 WIDTH = 1>
</OBJECT>
<INPUT NAME=Author SIZE=70 DATASRC=”#ADC”>
<SCRIPT LANGUAGE= “VBScript” onLoad = “Init”>

SUB Init
			rst = CreateObject(“ADODB.Recordset”)
			rst.Open(“select * from Products”, “Provider=MS
			Remote;Remote Server=http://deneb;Remote
			Provider=http://myserv;dsn=AdvWorks”
			ADC.Recordset = rst
	END SUB
</SCRIPT>

Использование ADO в Visual Basic

Dim cnn As New ADODB.Connection
Dim rst As New ADODB.Recordset


cnn.Connectionstring = “dsn=mysql;uid=sa;pwd=” 
cnn.Open


rst.CursorType = adOpenStatic 
rst.LockType = adLockBatchOptimistic 
rst.Open “SELECT * FROM authors”, cnn


For Each col In rst.Fields 

			Debug.Print col.Name & “ : “ & col.Value 
			Debug.Print 
Next

Использование ADO в Visual J++

import com.ms.com.Variant;
import msado15.*;
public static void main(String args[])
{
			_Recordset	rs;
			rs = new Recordset();
			Variant vConString = new Variant();
			vConString.putString(“dsn=pubs;uid=sa;pwd=”);


			Variant vCmdText = new Variant();
			vCmdText.putString(“select * from authors”);


		rs.putCursorLocation(CursorLocationEnum.adUseClient);
			rs.Open(vCmdText, vConString,
	CursorTypeEnum.adOpenForwardOnly,
			LockTypeEnum.adLockReadOnly, CommandTypeEnum.adCmdText);
}

Использование ADO в Visual C++

#import “c:\program files\common files\system\ado\msado15.dll”
 no_namespace rename(“EOF”, “EndOfFile”)
//

// Здесь должны находиться дополнительные включаемые файлы
//
FieldPtr *rgflds = NULL;

if (FAILED(hr = ::CoInitialize(NULL)))
			_com_issue_error(hr);
		
_ConnectionPtr pCnn(“ADODB.Connection.1.5”);
pCnn->Open(“dsn=test;uid=sa;pwd=;database=pubs”, 
 “”, “”, adOptionUnspecified);
_RecordsetPtr pRs(“ADODB.Recordset.1.5”);
pRs->CacheSize = 15;
pRs->putref_ActiveConnection(pCnn);
pRs->Open(“select * from authors”, vtMissing, 
	adOpenForwardOnly, adLockReadOnly, adOptionUnspecified);
   //
// Здесь мы обрабатываем полученный набор записей
//
В начало

В начало

RDS

Одной из задач Universal Data Access является интеграция удаленных сервисов, которая выражается в объединении функциональности ADO и Active Data Connector. В результате Active Data Connector преобразовался в RDS, часть сервисов ADO.

RDS обеспечивают удаленное кэширование ADO-объектов типа Recordset и повышают производительность за счет сокращения числа обращений к сетевым ресурсам. Это достигается за счет того, что RDS извлекает наборы записей как бинарные объекты и обеспечивает связь между объектами типа Recordset и интерфейсными элементами, поддерживающими отображение данных, используемыми в Web-страницах. На следующей диаграмме показано использование основных компонентов RDS в Web-приложении:   

Приложения, которым требуется отображение данных или доступ к «живым» данным, должны использовать сервисы RDS. Основным отличием RDS от ADO является то, что ADO позволяет вам поддерживать соединение с источником данных, тогда как RDS всегда использует «отсоединенные» данные (disconnected data).

В следующей таблице перечислены объекты, составляющие объектную модель RDS, их свойства и методы:   

 

В начало

В начало

ODBC

Как видно из рисунка, приведенного в начале данной статьи, OLE DB может обращаться к реляционным базам данных через существующие ODBC-драйверы. Это обеспечивается через OLE DB Provider for ODBC. Напомним, что ODBC — это ставший индустриальным стандартом способ доступа к реляционным данным на любой платформе. К основным преимуществам ODBC, обеспечивающим гибкость данного интерфейса, относятся следующие:

  • приложения не привязаны к программному интерфейсу какого-то одного поставщика;
  • SQL-запросы могут быть включены непосредственно в исходный код приложения либо генерироваться «на лету»;
  • приложения могут полностью игнорировать коммуникационные протоколы, используемые для непосредственного доступа к данным;
  • данные могут получаться или отсылаться в форматах, «удобных» для конкретного приложения;
  • ODBC поддерживает планируемый к принятию стандарт ISO Call-Level Interface;
  • в настоящее время существует более 170 драйверов для различных баз данных, включая ODBC-драйверы для 55 наиболее популярных баз данных.

Архитектура ODBC показана на следующей диаграмме:   

Здесь видны следующие четыре основных компонента ODBC:

  • программный интерфейс (API). С его помощью приложение вызывает ODBC-функции для подключения к источнику данных, посылки и приема данных и отключения от источника;
  • менеджер ODBC-драйверов обеспечивает приложение списком доступных источников данных, динамически загружает драйверы по мере необходимости и выполняет проверку передаваемых аргументов;
  • драйвер обрабатывает вызовы ODBC-функций и управляет обменом между приложением и определенной реляционной базой данных. При необходимости драйвер может преобразовывать стандартные SQL-запросы в запросы для конкретного источника данных;
  • источник данных — собственно данные и соответствующее ядро базы данных.

За счет интеграции OLE DB и ODBC через упомянутый выше OLE DB Provider for ODBC обеспечивается набор COM-интерфейсов (объектов OLE DB) для любого существующего ODBC-драйвера, что позволяет OLE DB-приложениям иметь доступ к SQL-данным от ODBC-поставщиков и работать в архитектуре Windows DNA уже существующим приложениям и решениям.

 

В начало

В начало

Какую технологию выбрать

Итак, мы рассмотрели технологии, составляющие Microsoft Universal Data Access. Остался открытым только один вопрос — какую из представленных здесь технологий выбрать? Данная таблица поможет вам в этом.   

 

В начало

В начало

Вместо заключения

В данном обзоре мы рассмотрели компоненты новой архитектуры фирмы Microsoft — Microsoft Universal Data Access (UDA), которая является неотъемлемой частью архитектуры Windows DNA. В следующих номерах мы более детально рассмотрим перечисленные здесь компоненты Microsoft UDA и приведем примеры их использования в приложениях, создаваемых с учетом архитектуры Windows DNA.

 

В начало

В начало

Приложение

Наилучшим источником информации о рассмотренных здесь технологиях является Web-узел фирмы Microsoft:

http://www.microsoft.com/data/default.htm

С этого узла мы можете перейти на страницы, посвященные отдельным компонентам Microsoft UDA:

Помимо этого существуют соответствующие группы новостей, расположенные на сервере новостей Microsoft — msnews.microsoft.com:

 

  • ActiveX Data Objects
  • Remote Data Service
  • OLE DB
    • Providers
    • SDK
    • Specification
  • ODBC
    • SDK

microsoft.public.ado

microsoft.public.ado.rds

microsoft.public.oledb

microsoft.public.oledb.providers

microsoft.public.oledb.sdk

microsoft.public.oledb.specification

microsoft.public.odbc

microsoft.public.odbc.sdk

 

КомпьютерПресс 1'1999