Говард Чу - главный архитектор проекта OpenLDAP (http://www.openldap.org) и его основного корпоративного спонсора Symas Corporation. OpenLDAP - это свободная (и с открытым исходным кодом) реализация протокола LDAP, обеспечивающего общие адресные книги, единую аутентификацию, автоматическое подключение домашних каталогов и совместный доступ к файлам для клиентов, работающих под управлением ОС Linux, Unix, Mac и Windows.
Вопрос: Не могли бы вы немного рассказать о своей работе, проекте OpenLDAP и его отношениях с Symas?
Ответ: Что же, как главный архитектор проекта OpenLDAP я принимаю решения о том, что следует включать в код, а что - нет. По большей части разработчики сообщества OpenLDAP работают над тем, что выберут сами.
Я внес свой первый вклад в OpenLDAP в 1998 году и вскоре после этого был приглашен в основную команду разработчиков. Под руководством Курта Зейленга (Kurt Zeilenga) бОльшая часть ранней разработки OpenLDAP была сфокусирована на устранении проблем, связанных с переносимостью и реализации LDAPv3.
Более радикальная эволюция кода со времен работы, проделанной над ним в Мичиганском университете была моей инициативой и это по большей части мой код. Я был полностью занят в работе над проектом, начиная с 1999 года как основатель Symas, решивший инвестировать средства в проект путем финансирования моего участия в нем.
Вопрос: Как вы сравниваете OpenLDAP с проприетарными службами каталогов, такими как Active Directory или SunOne?
Ответ: Active Directory настолько неправильно реализована, что едва заслуживает упоминания. Она попросту несовместима со спецификациями LDAP, что ухудшает возможности взаимодействия. А дизайн ее базы данных настолько плох, что сам по себе может вывести эту службу каталогов из строя.
Наша недавняя оценка работы Active Directory и Active Directory Application Mode (ADAM) в качестве LDAP-серверов и тесты производительности, показавшие, что AD и ADAM работают в 3-5 раз медленнее (по сравнению с OpenLDAP - прим. пер.), убедили нас в том, что корпоративные стратегии опирающиеся на эти службы каталогов ведут к неприятностям.
SunOne в течение нескольких лет была, пожалуй, ведущим образцом технологии службы каталогов. Тем не менее, первоначальные разработчики уже давно отошли от работы с кодовой базой и теперь она показывает свой возраст и многочисленные хорошо документированные проблемы со стабильностью и удобством сопровождения.
OpenLDAP сегодня занимает лидирующие позиции в области производительности, масштабируемости и надежности.
К сожалению, мы не можем опубликовать результаты сравнения OpenLDAP и SunOne из-за лицензионных ограничений.
SunOne ныне заменяется на OpenDS, проект каталога с открытым исходным кодом, написанный на Java, но это ничего не значит.
OpenLDAP не имеет себе равных среди других служб каталогов, проприетарных или с открытым исходным кодом. И проприетарные службы среди прочих - это лишь попытка спрятать грязное белье и пустая трата времени и денег.
Вопрос: Мы наблюдаем возникновение большого количества ПО с открытым исходным кодом, которое прекрасно работает в корпоративной среде. Какое место в этом множестве вы отводите OpenLDAP?
Ответ: Я думаю, что лучший ответ на этот вопрос вы получите, обратившись к Open Source Investment Portfolio и Open Source Middleware Stack компании Hewlett-Packard. В качестве службы каталогов они выбрали OpenLDAP (а Symas - в качестве партнера для техподдержки).
Несколько меньших независимых поставщиков ПО также выбрали OpenLDAP (наиболее заметными среди них являются Ventyx и Zimbra) и мы ожидаем, что их количество будет расти.
Вопрос: Похоже, что у каждого Open Source проекта есть своя собственная схема LDAP. Как решаете проблемы, связанные с множеством схем, а также вытекающие отсюда проблемы несовместимости и сложности?
Ответ: Множественность схем в каталогах LDAP на самом деле вполне поддается управлению. Главное - убедить разработчиков публиковать спецификации их схем для облегчения адаптации. Например, мы работаем с разработчиками Samba и группой разработчиков Kerberos из IETF над созданием стандартной схемы LDAP для центра распределения ключей Kerberos.
Мы создаем рациональное надмножество схем, в настоящее время использующихся в Heimdal и MIT, которые затем могут быть использованы в Samba и других приложениях, которым нужны Kerberos и LDAP. Все очень просто: люди должны взаимодействовать для того, чтобы могли взаимодействовать создаваемые ими программы.
Меня слегка удивляет, что эти проблемы вообще относят на счет LDAP. Вы крайне редко сможете столкнуться с настоящей несовместимостью в определениях схемы. Обычно вы всего лишь обнаруживаете, что опубликованная стандартная схема является неполной или неподходящей для какого-то определенного приложения.
Этого и следует ожидать, поскольку большинство опубликованных схем - это стартовые варианты и подразумевается, что они будут расширяться и дорабатываться для совместимости с другими схемами. Для сравнения: управление схемами в реляционных базах данных - по-настоящему трудная проблема.
В мире SQL нет общих определений, как в X.500/LDAP. Фактически нет даже общего SQL - есть множество несовместимых между собой диалектов. Даже такие фундаментальные вещи, как элементарные типы данных (целое, 64-битное целое и т. д.) не имеют стандартного определения в разных реализациях SQL.
Конечно, нам приходится сталкиваться с ситуациями, когда необходимо обучение. Мы проводим много официальных и неофициальных консультаций для организаций, переходящих на OpenLDAP. Время от времени возникают проблемы совместимости, но они легко устраняются по мере того, как технические специалисты начинают проходить подготовку в "университете LDAP" компании Symas.
Вопрос: Каким образом сообществу Open Source следует пропагандировать использование OpenLDAP организациями?
Ответ: Во-первых, о выборе LDAP в качестве службы каталогов. Мы видим организации и Open Source-проекты, реализующие хранилища данных с использованием других технологий и их масштабируемость, производительность или управляемость крайне редко оказываются адекватными для развертывания в масштабах предприятия. LDAP предоставляет превосходную и легкодоступную базу для хранения данных каталога.
Во-вторых, потратьте некоторое время на то, чтобы дать оценку вашему использованию OpenLDAP. После принятия решения о вложении денег в LDAP вам следует провести сравнение технологий LDAP, наиболее соответствующих стандартам и предложить вашим пользователям возможность легкого развертывания OpenLDAP.
В-третьих, следует протестировать производительность службы каталогов с открытым исходным кодом с использованием предложенной схемы, репрезентативных образцов данных, нагрузок и количества записей, соответствующих нуждам организации.
URL: http://www.computerworlduk.com/community/blogs/index.cfm?ent...
Новость: http://www.opennet.ru/opennews/art.shtml?num=14723
