Представление организации данных. Взаимодействие Lightweight Directory Access Protocol со службами каталогов. Операции аутентификации, поиска, добавления или удаления записей. Описание дерева и добавление данных. Определения правила соответствия.
Аннотация к работе
Работа протокола Lightweight Directory Access ProtocolЭта потребность в глобальном сетевом каталоге сподвигла ITU к разработке стандартов серии X.500 и, в частности X.519, которые определяют DAP (Directory Access Protocol), протокол для доступа к сетевой службе каталогов. IETF осознала необходимость доступа к глобальным службам каталогов (первоначально, во многом, по тем же самым причинам хранения адресов электронной почты, что и ITU), но не поднимая при этом всех этих ужасных перенагруженных протоколов (OSI), и начала работу над Lightweight Directory Access Protocol (LDAP). LDAP разрабатывался так, чтобы обеспечить почти столько же функциональности, что и оригинальный стандарт X.519, но с использованием стека протоколов TCP/IP, при этом оставляя возможность взаимодействия с каталогами, основанными на X.500.Lightweight Directory Access Protocol - "облегченный протокол доступа к каталогам") - протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегченный вариант разработанного ITU-T протокола DAP. Это всего лишь протокол, определяющий методы, посредством которых осуществляется доступ к данным каталога. Он также определяет и описывает, как данные представлены в службе каталогов. LDAP определяет четыре модели, которые мы перечислим и кратко обсудим, а затем Вы можете спокойно забыть о них, поскольку для понимания LDAP они мало что дают. Модель данных (или информационная модель) определяет, каким образом информация или данные представлены в системе LDAP.LDAP характеризуется как сервис "один раз записал - много раз прочитал".Где проходит грань разумного использования между LDAP и классическими, ориентированными на транзакции реляционными базами данных, к примеру, SQLITE, MYSQL, POSTGRESQL? Если обновление происходит при каждом втором доступе, будет ли разумно использовать в таком приложении LDAP, или нужно, чтобы обновления происходили раз в тысячу или в миллион обращений? Репликация LDAP генерирует несколько транзакций для каждого обновления, таким образом, желательно снизить практическую нагрузку, связанную с обновлениями (1000:1 или больше).Применяемые для доступа к каталогам LDAP примитивы используют модель данных, которая абстрагирована от ее физической организации.Реляционные и транзакционные базы данных идут на крайние меры для обеспечения целостности данных во время циклов записи/обновления, используя такие техники, как транзакции, блокировки, откаты и другие методы. Данная экстремальная форма синхронизации данных также действует при репликации данных на несколько хостов или серверов. Главный LDAP-сервер и подчиненные ему серверы используют простой асинхронный процесс репликации данных.Так в чем же преимущества LDAP, и почему каждый здравомыслящий человек будет их использовать? Прежде чем попытаться ответить на этот вопрос, давайте абстрагируемся от тактических соображений производительности. По мере разработки служб каталогов второго поколения - это положение меняется, и, хотя реляционные СУБД всегда будут оставаться быстрее LDAP, разрыв значительно сократился вплоть до точки, в которой различия становятся уже практически несущественными, если, конечно, Вы сравниваете подобное с подобным.Каталоги LDAP используют модель данных, которая представляет данные как иерархию объектов. Это не означает, что LDAP является объектно-ориентированной базой данных.В LDAP-системе данные представлены как иерархия объектов, каждый из которых называется записью. Полученная в результате древовидная структура называется Информационным деревом каталога (Directory Information Tree, DIT). Верхнюю часть данного дерева обычно называют корнем (root), (а также базой (base) или суффиксом (suffix)). Каждая запись состоит из одного или нескольких объектных классов (OBJECTCLASS). Объектные классы содержат ноль или более атрибутов (attribute).Каждый атрибут имеет имя и обычно содержит данные. Атрибуты всегда связаны с одним или несколькими объектными классами. Каждый атрибут определяет тип данных, которые он может содержать. Если атрибут описывает, скажем, адрес электронной почты, у него может быть одно, два или 500 значений - это один из ряда методов работы с почтовыми псевдонимами, применяемых при построении каталога. У атрибутов есть имена и, иногда, псевдонимы или аббревиатуры, например, COMMONNAME является членом объектного класса, называемого person, и имеет сокращенное имя cn.Существует огромное число предопределенных объектных классов, в каждом из которых полным-полно атрибутов для почти всех возможных применений каталогов LDAP. Объектный класс определяет, должен ли входящий в него атрибут присутствовать в записи (обязательный атрибут), или он может присутствовать (необязательный атрибут).Таким образом, родительская запись всегда должна быть добавлена перед тем, как пытаться добавить дочерние записи. Добавление записей может происходить разными путями, один из которых - использовать файлы формата LDAP Data Interchange Files (LDIF), который полностью описан в одной из посл