Hlavní oblasti zkoumání a dalšího vývoje

LDAP a často se měnící data

Pro realizaci některých funkcí informační infrastruktury, zejména v oblasti přístupu k informacím o aktuálním stavu služeb (Metacomputing, DEN apod.) je nezbytné měnit hodnoty některých položek velmi často a(nebo) zajistit rychlou reakci na změnu stavu reality jíž položka odpovídá. Zde vyvstává rozpor mezi návrhem LDAPu (LDAP není určen pro uchovávání takovýchto dat) a výše uvedenými potřebami, které jsou důsledkem relativní vhodnosti LDAPu pro řešení uvedené množiny problémů (především z hlediska hledání vhodného standardního rozhraní).

Jednotlivá možná řešení:

1. Synchronní update

   

   Periodické provádění měření sledovaných hodnot (source) se zápisem změn do LDAP serveru. Mezi výhody tohoto řešení patří jednoduchost, mezi nevýhody velká režie. Další poznámky:

   • Režie z hlediska adresářového serveru může být redukována, pokud se na místě měření může sledovat, zda došlo oproti poslednímu měření ke změně hodnoty a pouze v takovém případě je update skutečně proveden.
   • Změna dat v adresářovém serveru může být realizována přes LDAP API (běžné rozhraní) nebo lze uvažovat o realizaci rozšíření funkce LDAP serveru pro provádění dávkových změn skupiny položek.
   • Tato metoda může být výhodná v případě, že je potřeba udržovat historii měření.
   • Referencí pro tuto metodu je informační infrastruktura projektu Globus (MDS Meta Directory Services) [10, , ].
2. Asynchronní update

   

   Update položky v adresářovém serveru je proveden při změně hodnoty měřené informace. Tento mechanismus je možno realizovat pouze v případě, že lze na místě měření získat asynchronní informaci o nastalé změně.

   Z hlediska režie a zpoždění v promítnutí změny je tato varianta zřejmě nejlepší, nicméně obvykle ji nelze realizovat.

   Použití tohoto mechanismu by bylo s výhodou možné například pokud by zdrojem informací byl nějaký modulární (SNMP) management systém, jako je HP OV.

3. Virtuální backend
   Pro zajištění přístupu k nějakému souboru dat, která pocházejí z vnějšího zdroje, je možno uvažovat o vytvoření specializovaného backendu adresářového serveru, který namísto běžné funkce backendu zprostředkovává propojení se zdrojem dat. Takový backend pak pro jistý podstrom adresářového stromu zajišťuje přečtení aktuální hodnoty měřené veličiny pro každou LDAP operaci, která se týká položky jež odpovídá této veličině. Více o významu pojmu backend a možnostech úpravy chování adresářového serveru viz informace zabývající se výběrem a strukturou adresářového serveru.

   Jedná se o poměrně komplexní řešení specializované pro konkrétní účel. Požadovaná informace je vždy zjištěna v okamžiku požadavku na její čtení, což může v některých případech mít neblahý vliv na výkonnost serveru. Na druhou stranu však toto řešení eliminuje režii vzniklou periodickým snímáním hodnot (bez ohledu na to, zda je někdo potřebuje).

   Tento způsob je vhodný pro realizaci bran do některých systémů, například pro informace, které jsou k dispozici přes AFSstats rozhraní nebo LSF API.

4. Řízený update
   Získávání dat je řízeno ze strany LDAP serveru na základě požadavků na čtení. To znamená, že data jsou uložena standardně v LDAP serveru, ale LDAP server je upraven (opatřen plug-inem) tak, že je schopen vyvolat asynchronně proces získání aktuální hodnoty položky v okamžiku, kdy je tato hodnota požadována.

   Poznámky:

   • Realizace např. pre-operation plug-inem, který monitoruje operace čtení a v případě požadavku na čtení položky, jež odpovídá měřené veličině, získá aktuální hodnotu (provede měření), tuto zapíše standardní cestou do položky a předá řízení dále obvyklou cestou.
   • Řízení a konfigurace tohoto chování může být provedeno stanovením speciálních atributů u příslušných položek adresářového serveru. Například zde mohou být atributy určující minimální dovolený čas mezi měřeními téže hodnoty (tj. jsou-li požadavky na čtení častější, není nutno pro každý z nich provádět měření, postačí vydat hodnotu z adresářového serveru (funguje jako cache)) nebo maximální dovolené stáří hodnoty (naopak kdy už je měření nutno učinit).

     Stejně tak může být (modulárně) navržena vlastní funkce plug-inu který realizuje toto chování, například tak, že položky v adresářovém stromu mohou mít speciální atribut, který říká, že odpovídají reálné hodnotě, kterou je potřeba změřit a jak se měření provádí. Tím by se směřovalo k vytvoření obecnějšího, modulárního mechanismsu, který dovoluje relativně snadnou modifikaci.

     Je pravděpodobně nutné, aby položky reprezentující naměřené hodnoty byly obohaceny ještě o další servisní atributy, jako například čas posledního provedeného měření.

   • Jednou z vlastností tohoto řešení může být i možnost, že lze dle konfigurace příslušné položky a na základě jejího stáří, v okamžiku požadavku na hodnotu této položky pouze spustit (naplánovat) provedení nového měření a hodnotu vrátit z adresářového serveru (cache). To může být výhodné v případě, že získání aktuální hodnoty je časově náročná operace.
   • Výše nastíněný mechanismus by mohl zřejmě hrát důležitou roli i v řešení problému vazby adresářový server - relační databáze. Funkce navrženého systému se totiž nemusí omezit na definování a provádění specifických operací souvisejících se získáváním rychle se měnících hodnot, ale může být zobecněna. Například tak, že je možno definovat některé akce rozšiřující sémantiku operací nad položkami adresářového serveru (obecné akce spouštěné při dané LDAP operaci) sloužící například k definici integritních omezení nad daty v adresářovém serveru. Přičemž takový mechanismus je mnohem pružnější než mechanismus modulů typu plug-in zajišťujících funkcionalitu integritních omezení.

     Rozšíříme-li dále tento model tak, že jako jeho (v podstatě) vnitřní mechanismus použijeme relační databázi, nebo spíše vazbu na svět relačních databází (SQL, odkazy na vnořené procedury v relační databázi apod.) můžeme dostat prostředek řešící mnohé otevřené otázky relativně modulární a přehlednou cestou.

     Mechanismus definice operací nad operacemi LDAPu za účelem vytvoření prostředku pro řešení potřeb vznikajících kolem rychle se měnících dat a potřeby zavádět integritní omezení nad daty se složitějšími vazbami řeší obdobným způsobem projekt LTAP (Lightweight Trigger Access Process) [13, 14].

LDAP a relační databáze

Základní idea

Adresářové služby (speciálně LDAP) poskytují standardizovanou a dobře obecně přijímanou metodu pro přístup k datům (hlavně standardizované API). Zřejmě by se daly s výhodou využít jako jednotné rozhraní pro přístup k datům. Jejich filozofie ale i úspěšnost vychází mimo jiné z jednoduchosti. Pro mnoho skutečných aplikací je však potřeba poněkud komplexnější sada funkcí. Na druhé straně existuje sice velmi propracovaná (z mnoha stránek) technologie relačních databází, ale na tomto poli neexistuje žádné vhodné standardizované rozhraní. Daly by se tyto technologie spojit, tj. podpořit rozhraní LDAPu zkušenostmi a technickými možnostmi databázových technologií?

Možné metody řešení

1. LDAP jako nástroj pro publikaci dat (pouze pro čtení)

   

   Relativně jednoduchým způsobem lze využít LDAP jako rozhraní k datové bázi uložené v relačním modelu, smíříme-li se s tím, že toto rozhraní slouží pouze pro čtení.

   Poznámky:

   • Využití pouze silných a propracovaných stránek jednotlivých technologií, z mnoha pohledů dostatečně účelné. Neposkytuje však jednotné rozhraní, neboť LDAP slouží jen pro čistě čtecí aktivity a ostatní aplikace musí používat jiné (nestandardní, zato však vyzkoušené a pro tyto účely optimalizované) rozhraní.
   • Pro aplikace s uživatelským rozhraním přes WEB lze dosáhnout stavu, kdy uživatel nepozná která část aplikace je databázová, tj. komunikuje přímo s databází (změny dat) a která komunikuje s LDAPem (čtení, hledání, atd.). Pro uživatele je pak pohled na takovou aplikaci zcela konzistentní.
   • Aplikace pro změnu dat lze realizovat existujícími technologiemi relačních databází (vývojové nástroje, CASE).
   • Vazba mezi databází a adresářovými službami je relativně jednoduchá. Kód update logic zajišťuje jednosměrnou transformaci relačního modelu dat do datových struktur adresářových služeb. Lze snadno zajistit update v pseudoreálném čase.
   • Referenčním projektem pro tento model je Directory Services Project na Stanford University [15].
2. LDAP jako univerzální rozhraní pro data

   

   Jednotné rozhraní pro data je velmi lákavým cílem. Na poli databázových systémů dosud neexistuje žádný otevřený a obecně uznávaný standard. Vyvine se z LDAPu nový standard zasahující i do těchto oblastí (komplexnější data a operace nad nimi)?

   Možné přístupy k realizaci vazby databáze - adresářové služby:

   • Virtuální backend realizující přístup do relační databáze.
     Specializovaný backend adresářového serveru realizující obousměrnou transformaci relačního modelu dat na reprezentaci těchto dat v adresářovém serveru.
   • LDAP - SQL backend - obecný prostředek pro vazbu do SQL.
     Obecný prostředek pro realizaci vazby SQL - LDAP.
   • Obecnější backend realizující rámec pro řešení vazeb (nejen do SQL).
     Návrh a realizace modelu pro rozšíření funkcionality LDAP serveru o možnost provádění dalších akcí ve spojitosti s LDAP operacemi, definování itegritních omezení a vazeb na vnější zdroje dat. Samozřejmě s důrazem na využití relační databáze.

   V každém případě je nutno uvažovat o rozšířeních komunikačního modelu pro zajištění podpory složitějších operací (transakcí). Protokol LDAP (tím i LDAP API) je pro takové rozšíření připraven.