Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Серверы ODBC: новое слово в технологии БД

Энтони Фрей

В свое время корпорация Microsoft задумала разработать технологию упрощенного доступа к данным из любого источника и в любом месте. Теперь можно с уверенностью сказать, что она выполнила свою задачу. Разработчики получили стандартный интерфейс прикладного программирования ODBC (Open Database Connectivity), с которым можно работать, не задумываясь о том, каким инструментарием им придется пользоваться и на какой платформе будет расположена сама база данных. Таким образом, этот программный интерфейс во многом облегчил задачу разработчиков, но прибавил хлопот сетевому администратору. Эти хлопоты связаны с инсталляциями дополнительного ПО, поскольку на каждом клиентском месте для доступа к источнику данных необходимо иметь соответствующий драйвер. Что, например, будет, если в вашей сети, скажем, 1000 клиентов и вы только что установили еще один сервер СУБД?

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

Проблему "размножения" клиентских драйверов ODBC может решить применение так называемых "серверов ODBC" (также известных как "драйверы ODBC со стороны сервера"). При этом на клиентских машинах нужно установить лишь один драйвер ODBC. Свое небольшое исследование этой технологии мы провели с помощью серверной платформы Microsoft Windows NT 3.51 Server, сервера баз данных Sybase SQL Server 10, а также серверов ODBC OpenLink фирмы OpenLink Software и OpenChannel фирмы Visigenic Software. Необходимо отметить, что существуют и другие серверы ODBC, такие, как HotSockets фирмы Ensodex и DataRamp Server фирмы DataRamp.

Какова она, новая архитектура?

Рассмотрим традиционную технологию использования ODBC, с тем чтобы сравнить ее с новой. Архитектура ODBC является многослойной (рис. 1. Стандартная архитектура ODBC). Доступ к соответствующей базе данных обеспечивается тремя уровнями программного интерфейса. С помощью последнего уровня определяется уже непосредственный источник данных. Большинство из нас знакомы с так называемым управляющим модулем ODBC (ODBC Driver Manager), т. е. с той частью стека ODBC, которая доступна администратору клиентской машины и с помощью которой он добавляет дополнительные драйверы и осуществляет их конфигурацию.

Ниже управляющего модуля ODBC находятся сами драйверы ODBC. Для каждого источника данных (data source) реализован собственный интерфейс в виде драйвера ODBC. Существуют два типа драйверов: одноуровневый (single-tier) и многоуровневый (multitier). Одноуровневые драйверы обычно используются для непосредственного доступа к источникам данных, которые представлены неструктурированными файлами. Вся логика доступа к данным и обработки запросов заключена в самом драйвере.

В случае же многоуровневых драйверов логика взаимодействия с базами данных, как правило, сосредоточена в связующем ПО (middleware), которое зависит от конкретного сервера СУБД. Разумеется, при этом требуется установка самого связующего ПО соответствующего производителя (SQL*Net, DB-Library, OpenClient и пр.). Наиболее сложной частью в архитектуре ODBC является "цепочка" от драйвера ODBC через сетевой стек к серверу БД.

Для сервера ODBC (рис. 2. Архитектура с использованием серверов ODBC) мы имеем те же самые логические слои, что и в традиционной архитектуре ODBC. Но теперь для каждого клиента необходим лишь один драйвер, который предназначен только для доступа к серверу ODBC. Естественно, что на сервере ODBC для каждого источника данных нужно установить драйвер, часто называемый агентом базы данных. В этом случае задача администрирования намного легче, чем внесение изменений в ПО на каждой клиентской машине. Причем у вас по-прежнему есть возможность установить наряду с универсальным драйвером ODBC одноуровневый или любой многоуровневый драйвер, хотя делать это не имеет смысла, поскольку для каждого типа баз данных на сервере уже установлен соответствующий агент.

По сути, серверы ODBC являются типичными шлюзами, хотя вы и не прочтете этого в сопровождающей их документации. Известно, что стандартные драйверы ODBC часто бывают не менее эффективны, чем собственные программные интерфейсы уровня вызовов CLI (Call-level Interface) фирм-производителей баз данных. Способен ли новый интерфейс ODBC, выполненный в виде шлюзов, поддерживать производительность на прежнем уровне? Мы отвечаем: "Да", поскольку все достижения производителей в области оптимизации стандартных драйверов ODBC теперь автоматически переносятся и на их "серверный вариант".

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

Два варианта сервера ODBC

Установка сервера OpenChannel прошла достаточно просто, однако определенные сложности возникли у нас при его конфигурировании. Большая часть затруднений связана с реализацией доступа к данным через стандартные драйверы ODBC, поэтому необходимо конфигурировать имена источников данных DSN (Data Source Name) не только на клиенте, но и на сервере. Это приводит к двойной работе по установке драйвера ODBC. Хотя OpenChannel выполняется как сервис под управлением Windows NT, необходимо убедиться, что имя DSN доступно регистрационному входу, в котором выполняется данный сервис.

В свою очередь, в пакете OpenLink можно использовать и собственные интерфейсы CLI поставщиков серверов БД, что не требует одновременного конфигурирования имен DSN и на сервере, и на клиенте. Информация о конфигурации записывается в файл WINDOWS.INI. В пакете OpenLink для каждого отдельного сервера СУБД запускается собственный исполняемый модуль.

Установка обоих продуктов со стороны клиента относительно проста и ничем не отличается от установки обычного драйвера ODBC. (Кстати, оба продукта поддерживают все основные клиентские платформы.) Все, что необходимо для конфигурирования, - это описать имена DSN, которые указывают на сервер ODBC. Тщательно спланируйте, на каких клиентских машинах установить 16-разрядные, а на каких - 32-разрядные версии драйвера, иначе процесс установки приложений превратится в бесконечный источник проблем. Например, если вы предварительно установили 16-разрядное приложение ODBC на машине с ОС Windows NT, то в память может быть загружен 16-разрядный управляющий модуль ODBC, который не позволит вам установить 32-разрядные драйверы.

Надо заметить, что серверы ODBC не облегчают бремя конфигурирования имен DSN на клиентских машинах. Конечно, было бы гораздо лучше, если бы клиенты сами могли запрашивать набор имен DSN у сервера и автоматически производить все необходимые настройки.

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

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

Поскольку технология ODBC серверов во многом обеспечивает функции связующего ПО, то пакеты OpenChannel и OpenLink предоставляют для связи с базами данных свой собственный специализированный протокол типа клиент-сервер. Оба пакета используют сетевой стек TCP/IP, хотя OpenLink поддерживает и IPX/SPX. Специализированный протокол устанавливается и конфигурируется автоматически (при условии, что на вашей машине установлен TCP/IP).

Наконец, слабым местом интерфейса ODBC всегда была безопасность: кроме процедуры аутентификации, он не предлагает никаких дополнительных средств обеспечения безопасности, особенно для шифрования самих передаваемых данных (end-to-end encryption). Обычно если реализация такой защиты в пакете ODBC не предусмотрена, что всегда зависит от конкретного производителя этого пакета, то конфиденциальные данные передаются через ODBC в открытом виде. С помощью OpenLink мы установили защищенный канал, просто включив флаг шифрования в файлах конфигурации клиента и сервера. Программные продукты, которые обеспечивают безопасность для OpenChannel, могут быть приобретены в дополнение к основному пакету.

Итоги первого опыта

Легко сказать, что Microsoft следовало бы разработать спецификацию ODBC-архитектуры этого типа с самого начала. Позицию Microsoft можно понять, если учесть то "разрозненное" состояние отдельных реализаций связующего ПО, которое было характерно для того времени. Microsoft не была заинтересована в разработке протокола сетевого уровня, а он составляет весомую долю в продуктах этого типа. Единственная цель той разработки - создание стандартного интерфейса API.

Простота администрирования, предлагаемая серверами ODBC, очевидна. Однако при использовании этих продуктов возникают некоторые вопросы, и самый главный из них - это поставка производителем комплексного решения в виде источников данных ODBC и сетевого протокола доступа к ним (как в случае с OpenLink). Еще один момент, связанный с применением серверов ODBC, - их стоимость. Например, OpenChannel фирмы Visigenic продается из расчета 500 долл. на одного пользователя, а это слишком большая цена за легкость администрирования.


распечатать статью




  
2 '1997
СОДЕРЖАНИЕ

колонка редактора

• Наш хит-парад

локальные сети

• Концентраторы Ethernet для рабочих групп (обзор российского рынка)

• Выбор аппаратной платформы для Windows NT

• Основы построения структурированной кабельной системы. Часть III

корпоративные сети

• АТМ в России: первые успехи

• Принимая решение о создании сети АТМ

услуги сетей связи

• Лазерная связь — новый экономичный способ беспроводной связи

• Беспроводные сетевые технологии

• Проблемы передачи данных по телефонным линиям

• Перспективные системы и стандарты транкинговой связи

• Измерительное звено системной интеграции

интернет и интрасети

• Как настроить браузер WWW

• Microsoft и Netscape — победители в "войне" браузеров

• Моментальная интрасеть

• Интеграция Windows и Unix с помощью файловых сервисов на базе SMB

• Отображение имен NetBIOS в сетях TCP/IP

• Шлюзы IPX—IP: ваши переводчики в стране Интернет

защита данных

• Обеспечение безопасности Web-сервера

новые продукты

• StorPoint — новое средство доступа к CD-ROM; Администрирование DNS станет легче

только на сервере

• Серверы ODBS: новое слово в технологии БД



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх