Trochę historii. Zaczęło się wszystko pod koniec lat 70 i na początku 80, kiedy to Sektor Normalizacji Telekomunikacji (ang. International Telecommunication Union, ITU) – ITU zaczął prace nad X.400, czyli zestawem definiującym standard obsługi wiadomości e-mail (http://pl.wikipedia.org/wiki/X.400). Wymagał on miedzy innymi katalogu nazw (oraz innych informacji), do których dostęp realizowany byłby poprzez sieć w sposób hierarchiczny, podobnie jak w DNSie.
To pociągnęło za sobą kolejne wymagania i tak powstał zbiór standardów X.500 (http://pl.wikipedia.org/wiki/X.500). Jednym z tych standardów jest X.519, który definiuje protokół dostępu do usług katalogowych (ang. Directory Access Protocol, DAP). Niestety standardy określone zarówno w/przez X.400, jak i X.500 wykorzystuja cały model/stos OSI, są dosyć ‘ciężkie’ i potrzebują dużo zasobów. Dlatego na początku lat 90-tych stowarzyszenie IETF (ang. Internet Engineering Task Force, http://pl.wikipedia.org/wiki/IETF) stwierdziło, że brakuje ‘lekkiego’ dostępu do uslug katalogowych. I tak powstał LDAP (http://pl.wikipedia.org/wiki/LDAP) – czyli Lightweight Directory Access Protocol, który jest lżejszym, alternatywnym protokołem dostępu do usług katalogowych X.500 – wykorzystującym protokół TCP/IP.
No dobrze. A czym właściwie jest LDAP?
LDAP jest tylko protokołem, który definiuje metody dostępu do usług katalogowych. Opisuje i określa w jaki sposób dane są przedstawiane w usłudze katalogowej (Data Model). Nie oznacza to, w jaki sposób dane powinny być przechowywane, a jedynie formę i charakter informacji. Możemy wyróżnić 4 modele, które opisuje LDAP – Information Model (Data Model), Naming Model, Functional Model oraz Security Model.
1. Data Model – definiuje typy danych oraz podstawowe jednostki informacji, które możemy przechowywać w katalogu. Podstawową jednostką informacji jest wpis (ang. entry), który jest zbiorem informacji o obiekcie, zestawem atrybutów opisujących obiekt. Każdy z tych atrybutów posiada swój typ i Wartość (jedną lub więcej)
2. Naming Model – definiuje organizację i odwołania w katalogu. Ten model określa, że wpisy są ułożone w odwróconej strukturze drzewa. Odwołujemy się do nich poprzez DN – Nazwę wyróżniającą (ang. Distinguished Name). Pierwszy element (od lewej) całego DN’a nazywa sie RDN – relative distinguished name.
3. Functional Model – definiuje metody uwierzytelniania (bind, unbind, abandon), zapisu i modyfikacji (add, modify, delete) oraz zapytań (search, compare)
4. Security Model – najprościej, definiuje kto, do których danych ma dostęp i co z tymi danymi może zrobic.
LDAP vs. RDB
Nie będę się rozpisywał o wadach czy zaletach. Napiszę tylko o różnicach. Relacyjne bazy danych posiadają dwie podstawowe cechy. Są homogeniczne (rekordy mają taką samą strukturę) i płaskie (rekordy są równorzędne). W LDAP baza jest heterogeniczna (każdy wpis może mieć inną strukturę) i hierarchiczna (drzewiasta).
LDAP jest bazą zorientowaną na odczyt (write-once-read-many-times). Jednak można przyjąć ze systemy relacyjnych baz danych są znacznie szybsze od implementacji LDAP. Dużo zależy od typu, ilości i indeksacji danych. O ile LDAP nie będzie się najlepiej nadawało do przechowywania informacji np. o fakturach czy transakcjach (bo te ze swojej natury często mogą być zmieniane), o tyle świetnie nadaje się do przechowywania informacji np. o pracownikach (konta użytkowników).
Mamy już garść suchych informacji na temat LDAP. Czas rozwinąć temat struktury drzewa, schematów, klas obiektów i atrybutów. Ale o tym kolejnym razem.
