OLE DB и ODBC представляют собой интерфейсы приложений, которые обеспечивают доступ к целому ряду источников данных. Разработчики Microsoft спроектировали ODBC для доступа к данным SQL, а OLE DB — для доступа к любым данным в среде СОМ.

Одни пользователи до сих пор не понимают, что же послужило причиной внедрения OLE DB, другие переоценивают роль OLE DB в области корпоративных и ориентированных на Internet разработок. В данной статье мне хотелось бы не только объяснить, зачем компании Microsoft понадобилось вводить OLE DB, но и оценить ту роль, которую это средство играет сегодня и, что гораздо важнее, будет играть завтра. Думаю, моя статья заинтересует в первую очередь опытных разработчиков, использующих ODBC и желающих иметь представление об OLE DB.

Внедрение OLE DB не означает отказ от ODBC. В обозримом будущем Microsoft планирует поддерживать ODBC так же, как это делают другие производители СУБД и инструментальных средств. Так чем же не устраивает разработчиков ODBC? Для доступа к данным он вполне адекватен. Опыт подтверждает, что, если ODBC удовлетворяет потребности вашего бизнеса, об OLE DB и связанных с ним технологиях пока можно забыть.

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

Таким образом, ODBC вполне справляется со своими обязанностями. Хорошо известна его производительность, гибкость и архитектура. Существует немало различных инструментальных средств и рабочих сред, построенных на ODBC (например, RDO). Чтобы понять, как скоро предстоит задуматься о переходе к OLE DB, проанализируйте, в какой степени возможности ODBC соответствуют тем усовершенствованиям, которые планируется внедрить в вашей информационной системе. При этом нужно помнить о том, что в течение ближайших пяти лет ODBC будет предоставлять те же самые возможности, что и сегодня. ODBC будет по-прежнему обеспечивать доступ к данным SQL, которые не интегрированы с другими, нереляционными типами данных, такими, как файлы языка XML, документы Microsoft Office или файлы электронной почты. Если же подобного рода файлы являются частью информационных ресурсов компании, стоит рассмотреть вариант OLE DB.

OLE DB представляет собой следующую ступень развития ODBC. Эти средства образуют относительно независимый программный слой, использующий один и тот же набор основных интерфейсов прикладных программ (API) для доступа к разнообразным базам данных. Их работа обеспечивается невидимыми для пользователя программными модулями, которые учитывают специфические особенности каждой СУБД и выступают в качестве драйверов для верхних программных слоев. В OLE DB полностью реализован принцип открытости связей между базами данных. Наибольшие различия проявляются в использовании некоторых основных терминов и в окружающем контексте. В Таблице 1 содержатся трактовки часто употребляемых терминов применительно к ODBC и OLE DB.

С точки зрения функциональности OLE DB обеспечивает доступ ко всем типам информации: реляционным и нереляционным, плоским и иерархическим, постоянным и переменным, ориентированным на SQL или на любой другой язык запросов. Для облегчения доступа к информации источники данных OLE DB представляются компонентами, базирующимися на СОМ, с четко определенным программным интерфейсом. Эти компоненты, называемые поставщиками данных, взаимодействуют с хранилищем информации. При соединении с поставщиком данных клиентское приложение всегда получает в качестве ответа набор записей независимо от того, к чему обращается поставщик данных — к таблице реляционной СУБД или к листингу каталога. Поставщик отвечает за извлечение данных с физического носителя и их форматирование. Данные могут храниться в одном и том же постоянном месте (в файлах на диске или в базе данных), в определенной области памяти или даже на разных машинах и разных платформах. Они могут быть реляционными и иерархическими, структурированными и плоскими, записанными в стандартном и в частном формате, доступными и недоступными для ODBC.

Возвращаемый OLE DB результирующий набор (называемый набором строк или записей) представляет собой не просто поток байтов, записываемых в память клиентского приложения, как в случае ODBC. Этот поток данных содержится в независимом модуле СОМ с отдельным программным интерфейсом. Такой модуль предлагает различные способы манипулирования набором записей — сортировку, фильтрацию, прокручивание текста. При этом он допускает возможность одновременной работы с данными многих пользователей. Работать с набором строк можно даже при отключении от первоначального источника данных, что делает тем самым этот новый мощный тип данных весьма эффективным.

Так ли уж хорош OLE DB? Для ответа на этот вопрос следует тщательно изучить два аспекта. С одной стороны, OLE DB нельзя назвать вполне зрелой технологией. С другой — Microsoft позиционирует его как базовый сервис доступа к данным для будущих платформ Windows. Это означает, что в Microsoft планируют существенно доработать OLE DB. Рассмотрим эти два аспекта более подробно, чтобы попробовать предсказать, какое влияние они окажут на пользователей.

Microsoft предлагает OLE DB в качестве основной технологии доступа к данным для Visual Studio 97. Версия OLE DB 2.5, которую предполагается выпустить вместе с Windows 2000, дебютировала в TechEd 99. Множество изменений, внесенных со времени выхода первой версии, казалось бы, говорят о нестабильности технологии. Однако в начале 1990-х такое же впечатление производила и технология ODBC. Тем не менее уже начиная с версии 3.0 ODBC работает прекрасно, и сегодня разработчики расценивают ее как очень стабильную технологию. Но это потребовало времени. Поскольку данные представляют собой «стратегическое горючее» для большинства компаний, необходимо особенно тщательно прорабатывать любые технологии, влияющие на доступ к данным.

На Рисунке 1 приведены для сравнения архитектуры OLE DB и ODBC.

РИСУНОК 1. Архитектура ODBC и OLE DB.

Обе базируются на специализированных компонентах (драйверах в случае ODBC и поставщиках в архитектуре OLE DB), которые соединяются с источником данных. В рамках ODBC драйвер обычно выступает в роли уполномоченного посредника, который передает команду SQL ядру СУБД, а обратно возвращает результирующий набор данных. Поставщик OLE DB принимает запросы на любом языке запросов (не обязательно на SQL) и возвращает наборы записей. Поставщик, инкапсулирующий СУБД, ограничивается простой передачей команд SQL нижестоящему серверу базы данных. Поставщик, взаимодействующий с нереляционным источником данных (например, с сообщениями электронной почты), выполняет дополнительную функцию: создает набор записей и наполняет его информацией. Такой поставщик мог бы работать с более простым языком запросов, чем SQL. Допустим, для возврата сообщения электронной почты от заказчика поставщику необходимо знать только имя отправителя. Команда типа

OLE DB состоит из двух частей: внешнего интерфейса и внутреннего ядра. Ядро, работающее в фоновом режиме, обрабатывает запросы и производит поиск данных. Часть OLE DB, отвечающая за внешний интерфейс, содержит программные средства, необходимые любому поставщику для взаимодействия с клиентами. Только Microsoft может установить стандарт на развитие OLE DB с точки зрения функциональности и технологии. Для этой цели задается спецификация интерфейса СОМ, который поставщик должен поддерживать. OLE DB 2.5 демонстрирует значительный прогресс по сравнению с более ранними версиями: в ней сняты некоторые ограничения проектирования и добавлены новые возможности. К примеру, OLE DB 2.5 позволяет возвращать нерегулярные, не табулированные наборы записей. OLE DB можно использовать для показа полуструктурированных и иерархических данных, таких, как потоки XML, документы Word и Excel, содержимое директории файловой системы. Кроме того, в новой версии уменьшается объем информации о поставщике, которую необходимо знать потребителю. Вместо спецификации сложных командных строк и строк соединения связаться с нужным набором записей можно посредством синтаксиса URL. Это свойство, называемое прямой URL-связью, позволяет написать такую строку соединения:

В этой интуитивно понятной записи стоят имя поставщика данных outlookprovider и текст команды, предписывающей поставщику просканировать директорию inbox и найти все сообщения, отправленные абонентом Joe User. Последняя версия инструментария разработчика на платформе Microsoft, SDK (Software Development Kit), частично повторяет достижения OLE DB 2.5.

Поскольку разработчики Microsoft рассматривают OLE DB в качестве основной технологии доступа к данным в среде Windows, пользователи в обозримом будущем получат всю необходимую поддержку для применения OLE DB. Поставщики важнейшего продукта Microsoft в классе серверов баз данных, SQL Server, незамедлительно отразят в нем все нововведения OLE DB. Воспримут ли эти новшества производители других баз данных? На мой взгляд, недостаток OLE DB в том, что его единственной надежной опорой являются производители SQL Server версий 6.5 и 7.0. Известно, что изготовители OLE DB для Jet и Oracle выпустили функционально неполные продукты, в которых обнаружены ошибки, так что разработчикам они вряд ли будут полезны. Версия OLE DB для Oracle производства корпорации Microsoft тоже не поражает воображения, но тем не менее представляется наиболее приемлемой. Версия OLE DB 2.1 обеспечивает доступ к данным из множественных программных сред, но это пока еще проблематично. Для того чтобы технология OLE DB превратилась в стандарт, всем производителям баз данных и, возможно, независимым компаниям необходимо выпустить полные версии поставщиков данных для различных СУБД. Не исключено, что потребуется совместными усилиями совершенствовать эти компоненты.

В общем, OLE DB еще предстоит завоевать признание и получить репутацию надежного средства, т. е. повторить путь, проделанный за последние годы ODBC. Но OLE DB обладает достаточным потенциалом для того, чтобы превзойти ODBC по разнообразию поддерживаемых источников данных, гибкости и удобству программных интерфейсов. Более того, центральная роль OLE DB в архитектуре работающих под управлением Windows распределенных приложений для Internet, DNA (Distributed InterNet Applications), а также в архитектуре DNS делает эту технологию реальным кандидатом на место ODBC. По всей вероятности, OLE DB станет важным компонентом при планировании будущих стратегий доступа к данным. Но слепо применять ее не следует.

Если принимать решение относительно OLE DB предстоит уже сегодня, то на какие факторы следует обратить внимание? Разработчики Microsoft спроектировали OLE DB с учетом требований производительности, но с точки зрения архитектуры вызов OLE DB пересекает больше программных слоев, чем запрос SQL, запущенный непосредственно из кода через интерфейс API в ODBC. Поэтому при использовании ODBC процесс происходит немного быстрее. Чтобы компенсировать этот недостаток, разработчики предусмотрели следующую возможность: OLE DB позволяет агрегировать и интегрировать структурно различные типы данных и использовать их в Web-приложениях.

Нужно помнить о том, что перейти к OLE DB не так-то просто. Это предостережение актуально даже для тех пользователей, которые уже применяют объектную модель: RDO, или Data Access Object (DAO), или даже ADO версии более ранней, чем 2.х. Особенно сложным может быть переход в случае использования СУБД, отличной от SQL Server. Расходы при этом окупятся только тогда, когда начнется реальная эксплуатация преимуществ интеграции с приложениями и системными услугами, которые предоставляет OLE DB. Если пользователи не знают, как реализовать достоинства гетерогенных запросов, не задействуют хранилища данных и не планируют интегрировать нереляционные типы данных (документы, электронные таблицы, электронную почту), они рискуют потерять производительность! (Или не обнаружить конкретных улучшений после обновления системы.)

Обычно я советую своим клиентам переходить к OLE DB только тогда, когда это обусловлено насущными потребностями бизнеса (как описано выше). То же рекомендуется и при создании новых систем, так как в процессе проектирования можно сразу заложить в них все возможности, предоставляемые OLE DB. Гибкость, интеграция и однородность — важные качества OLE DB. Если они необходимы для бизнеса компании, то переход к OLE DB может стать экономически эффективным.

Системы, базирующиеся на Internet, представляют собой обширную область применения для OLE DB, хотя низкое качество услуг некоторых провайдеров способно дискредитировать все усилия. Для вызова удаленных компонентов через HTTP в сети Web можно использовать службы удаленного доступа к данным, Remote Data Services (RDS). Реализовать такую возможность позволяет применение в качестве ключевой технологии разработанных компанией Microsoft компонентов доступа к данным, Microsoft Data Access Components (MDAS), которые включают и OLE DB. Наконец, на клиентской стороне OLE DB предоставит для обработки отсоединенные наборы записей.

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

Дино Эспозито специализируется на разработках сценариев для среды СОМ. Является автором справочника для программистов по написанию сценариев Windows Scripting Host Programmer’s Reference (Wrox Press); работает в Риме преподавателем и консультантом.