ОЦЕНКА СЕТИ
Именно сейчас, когда весь сетевой мир охватило повальное увлечение новым промышленным стандартом доступа к каталогам, самое время трезво оценить, что же с практической точки зрения означает поддержка LDAP для конечного потребителя.
Никто не спорит, что упрощенный протокол доступа к каталогам (LDAP) обеспечил разработчикам стандартный фундамент для построения совместимых служб каталогов, и это дало значительный прогресс. Однако в существующей (второй) версии спецификаций отсутствуют многие необходимые пользователям функции. Правда, в этом направлении ведется несколько параллельных разработок. Основные усилия сосредоточены на создании единой схемы каталога.
В базе данных схема каталога определяет, какие объекты и атрибуты могут содержаться в каталоге. Когда два каталога обращаются друг к другу или когда приложение обращается к каталогу, то от того, какую схему принимает за основу каждый участник процесса, в большой степени зависит, насколько совместимыми окажутся эти каталоги и приложения. Рассмотрим такой пример: в каталоге “A” адрес пользователя электронной почты хранится как атрибут объекта “Electronic Mail Address”, тогда как в каталоге “B” он хранится как атрибут объекта
“E-mail Address”. Каталоги должны иметь какой-то механизм, помогающий им выяснить, что эти два объекта отражают одно и то же.
На сегодня простая поддержка LDAP 2 такую проблему не решает. Поскольку вторая версия не позволяет каталогу публиковать данные о своей схеме, любые другие каталоги или приложения должны априори “понимать” эту схему, и только тогда возможно какое-либо взаимодействие между ними. И пока нет “стандартной схемы”, простое соблюдение стандарта LDAP 2 вовсе не означает, что приложение способно автоматически обращаться к любому каталогу, соответствующему этому стандарту. Разработчики вынуждены писать код для той конкретной реализации LDAP, с которой должны работать их приложения.
Очерченную проблему пытаются решить двумя способами. Во-первых, ведутся работы по созданию основной стандартной схемы для объекта-пользователя. Например, рабочий комитет по интегрированным службам каталога (Integrated Directory Services, IDS), входящий в целевую группу инженерной поддержки Internet (IETF), опубликовал предварительные спецификации, подробно описывающие схему каталога “белых страниц” Internet (Internet White Pages Schema, IWPS). Консорциум по сетевым приложениям (Network Applications Consortium, NAC) совместно с группой фирм-производителей разрабатывает описание схемы LIPS (Lightweight Internet Person Schema), которая является составной частью LDAP, и намеревается согласовать ее с IETF. Кроме того, несколько компаний разрабатывают стандарт vCard, первоначально принятый фирмой Verity в качестве формата электронной бизнес-карты. Не прекращаются попытки объединить все разработки и создать единую базовую схему, которой могли бы руководствоваться разработчики приложений и каталогов.
Однако следует заметить, что эта схема никогда не станет статичной: разработчики постоянно будут расширять ее, обеспечивая новые функции, поэтому им как воздух нужны средства распознавания. Эти потребности будут учтены в третьей версии стандарта LDAP, в которой появится механизм публикации схемы каталога в самом каталоге. Новый механизм описывает процедуру “рукопожатия” (handshake) каталогов, позволяя двум каталогам взаимодействовать друг с другом и узнавать реализацию схемы “в рабочем порядке”.
Работа в этих двух направлениях очень важна для практического использования LDAP в качестве стандарта совместимости каталогов. Оценивая целесообразность внедрения LDAP, постарайтесь умерить свои восторги, помня одну простую истину: до тех пор, пока новые разработки не будут сначала провозглашены стандартами,
а затем реализованы в продуктах, обещанной полной совместимости каталогов достичь не удастся.
Джейми Льюис
Джейми Льюис - президент The Burton Group, компании, специализирующейся на исследовании новых сетевых технологий. К нему можно обратиться по адресу: jlewis@tbg.com.
