CC BY
60
mgr inz. Adam KRASUSKI
prof. dr hab. Tadeusz MACIAK
Szkola Glowna Sluzby Pozarniczej
ARCHITEKTURA ORAZ MOZLIWOSCI FUNKCJONALNE KATALOGOWYCH BAZ DANYCH
Streszczenie
Artykul zawiera opis technologii katalogowych baz danych. Omowiony zostal sposob zapisu informacji oraz podstawowe funkcjonalnosci katalogowych baz danych. Zawarto rowniez rozwazania odnosnie mozliwosci wykorzystania tej technologii jako rozproszonej bazy danych do gromadzenie dokumentacji generowanej w Panstwowej Strazy Pozarnej.
Summary
This article describes Directory Service technology. Data allocation and main functionality has reviewed. It also contains analyzes regarding possibilities of implementation of this technology as Distributed Database for documentation generated in Fire Service.
1. Wprowadzenie
Roznorodnosc interwencji Panstwowej Strazy Pozarnej (PSP) jest bardzo duza. Bl^dnie podj^ta decyzja dotycz^ca likwidacji zagrozenia moze miec konsekwencje w narazeniu zdrowia i zycia ludzkiego. W wi^kszosci przypadkow rozwoj zagrozenia jest bardzo gwaltowny, przez co czas na podj^cie decyzji bardzo krotki. Calosc sprawia, iz podejmowanie trafnych decyzji w takich warunkach jest bardzo trudne. Dlatego tez na calym swiecie prowadzi si? badania nad systemami wspomagaj ^cymi podejmowanie decyzji w warunkach ekstremalnych [1,2]. Podstaw^. ich dzialania musz^. byc rozlegle bazy wiedzy (ang. knowledge database). W sytuacji sluzb ratowniczych wiedza ta powinna byc czerpana z doswiadczenia strazakow. Poziom doswiadczenia jest rozny w zaleznosci od Jednostki Ratowniczo-Gasniczej a nawet od poszczegolnych funkcjonariuszy.
Dana jednostka poprzez nabyte doswiadczenia posiada umiej?tnosc zwalczania danego typu
zagrozenia, podczas gdy inna takich doswiadczen nie ma. Podstaw^ skutecznego systemu wspomagania decyzji jest budowa bazy wiedzy wykorzystuj^cej doswiadczenie wszystkich funkcjonariuszy.
W zwi^zku ze struktur^. PSP zasadna wydaje sie budowa bazy wiedzy w architekturze rozproszonej. Wykorzystanie modelu relacyjnego do budowy systemu niesie ze sob^ szereg funkcjonalnosci. Jednakze transakcje, mozliwosc przywracania bazy do dowolnego stanu z przeszlosci nie s^. najwazniejszymi kryteriami koniecznymi do budowy systemu wspomagania decyzji. Wazniejsza natomiast jest szybkosc odpowiedzi oraz latwosc integracji struktur rozproszonych. Problemy te zostaly lepiej rozwi^zane w katalogowych bazach danych.
Dane przechowywane w bazie wiedzy mog^. miec rozn^ forme. Mog^. to byc analizy zdarzen, zdjecia z akcji, filmy oraz wiele innych. Aby ujednolicic system wyszukania, koniczne jest zastosowanie pewnej abstrakcji ich opisu. Zamienic fizyczne obiekty przechowywane w bazie na podstawowe jednostki wiedzy lub doswiadczenia. Pozwoliloby to na dowoln^. ich prezentacje uzytkownikom np. w formie wykresow, komend dzwiekowych lub tekstu.
Mozliwosc definiowania nowych struktur danych nie jest dornen^, systemow relacyjnych. Bardziej do tego nadaj^ sie obiektowe bazy danych. Szczegolnym przypadkiem obiektowej bazy danych jest baza katalogowa. Sposob jej dzialania oraz posiadane wlasciwosci kaz^. rozwazyc jej przydatnosc do budowy rozproszonej bazy danych jako podstawy systemu wspomagania decyzji.
Ponizszy artykul zawiera opis technologii katalogowych baz danych. Jego celem jest prezentacja tej technologii jako potencjalnego narzedzia do budowy podstaw systemu wspomagania decyzji dla celow PSP.
2. Usluga katalogowa
Usluga katalogowa DS (ang. Directory Service) jest zbiorem oprogramowania, sprzetu, procesow, polityki oraz procedur, odpowiedzialnych za organizacj e danych w katalogi, oraz udostepnienie ich uzytkownikom [3,4,5,6]. W polskim rozumieniu nazwa katalog powinna byc traktowana jako kartoteka, nie zas katalog z plikami.
DS jest baz^. danych wyspecjalizowan^. i optymalizowan^. pod k^tem wyszukiwania, przegl^dania oraz odczytywania informacji. Jej struktura zostala zaprojektowana w celu
przechowywania danych charakteryzowanych przez atrybuty. W przeciwienstwie do systemow zarz^dzania baz^. danych, nie jest wyposazona w narzçdzia do zarz^dzania transakcjami czy przywracania zawartosci bazy [4]. Mechanizmy do modyfikacji zawartosci katalogow s^. proste i nie umozliwiaj^. przeprowadzania aktualizacji, wybranych w wyrafinowany sposob grup danych. Jest przeciwienstwem dla DBMS ktore posiadaj^ narzçdzia do przeprowadzania duzej ilosci jednoczesnych modyfikacji.
Istnieje wiele modeli uslugi katalogowej, pozwalaj^. one na przechowywanie roznego typu informacji. Zaimplementowane mechanizmy decyduj^. o tym w jaki sposob dane s^. przechowywane, udostçpniane, modyfikowane czy zabezpieczone przed niepowolanym dostçpem. Istnieje katalogi lokalne przechowuj3.ce w^sk^. dziedzinç informacji dla lokalnych serwisow, jak rowniez globalne przechowuj ^ce dodatkowo informacje o szerokim kontekscie, dostçpne z kazdej lokalizacji. Przechowywanie danych moze byc scentralizowane lub tez rozproszone w zaleznosci od wykorzystania serwisu [7].
2.1. LDAP
LDAP (ang. Lightweight Directory Access Protocol) - tlumacz^c z jçzyka angielskiego - jest to „lekki" protokol dostçpu do katalogow [4,8,9]. Umozliwia on dostçp do zawartosci katalogowej bazy danych. LDAP w swoim dzialaniu wykorzystuje protokol komunikacyjny TCP/IP. LDAP jako standard definiuje metody l^czenia do katalogow, przeszukiwania ich zawartosci oraz modyfikacji bazy. W przeciwienstwie do poprzednich protokolow dostçpu do katalogow, LDAP nie wymaga l^cza szerokopasmowego, ani tez duzych zasobow systemowych [7,10].
Z technicznego punktu widzenia LDAP jest jedynie protokolem dostçpu do katalogowej bazy danych, zazwyczaj bazuj^cej na standardzie X.500 [4,7,11]. Pocz^tkowo protokol byl przeznaczony do komunikacji z bramkami dostçpu do uslugi katalogowej standardu X.500. Bramka byla posrednikiem miçdzy klientem a uslugi katalogow^.. Komunikacja bramki z katalogiem X.500 odbywala siç z wykorzystaniem protokolu DAP (ang. Directory Access Protocol) [12]. DAP jest protokolem wykorzystuj^cym caly stos protokolu OSI i do dzialania wymaga duzych zasobow systemowych. LDAP pracuje ponad protokolem TCP/IP i do swojego dzialania nie wymaga duzych zasobow systemowych.
Chociaz LDAP jest nadal wykorzystywany jako narzçdzie dostçpu do baz danych bazuj^cych na standardzie X.500 to obecnie najczçsciej wykorzystywany jest jako kompleksowe narzçdzie wbudowane w serwer uslug katalogowych (ang. DSA Directory System Agent) o zwyczajowej nazwie LDAP. Na rysunku 1 przedstawiono dwie metody wykorzystania LDAP.
a) b)
Ryc. 1.: Wykorzystanie LDAP: a) historyczna b)obecna. Zrôdlo: opracowanie wlasne
Usluga katalogowa LDAP bazuje na modelu klient-serwer [7,11]. Jeden lub kilka serwerôw LDAP przechowuje dane. Klient l^czy siç do serwera i wysyla z^danie. Serwer opracowuje z^danie i wysyla do klienta jego wyniki lub tez wskaznik do innego zródla danych, przewaznie serwera LDAP.
2.2. Historia LDAP
Na pocz^tku lat osiemdziesi^tych zauwazono, iz komputery bardzo dobrze sprawdzajq, siç w zmudnych czynnosciach powtarzanych wielokrotnie. Rozpoczçto wiçc prace maj^ce na celu wprowadzenie komputerowych kartotek, lub tez elektronicznych katalogów. Spodziewano siç, iz przeniesienie danych na komputer w znacznym stopniu przyspieszy i ulatwi ich przetwarzanie. Zaczçto wiçc opracowywac narzçdzia, które mogq, posluzyc jako katalogowe bazy danych. Systemy te mialy spelnic wymagania ludzi jako uzytkowników oraz byc konstruowane w ten sposób aby wykorzystac atuty komputerów.
W roku 1984 swoj3 dzialalnosc rozpoczçly trzy organizacjç maj^ce na celu wyznaczenie standardow w dziedzinie elektronicznych katalogowych baz danych. Pierwsza z nich o nazwie CCITT (fr. Comité consultatif international téléphonique et télégraphique) postawila sobie za cel opracowanie serwisu zawieraj^cego i udostçpniaj^cego adresy pocztowe i numery telefonow obywateli francuskich [3,13]. Celem pozostalych dwoch - ISO (ang. International Standard Organization) oraz ECMA
(ang. European Computer Manufacturers Association) - bylo opracowanie uslugi ktora zamienialaby nazwy serwerow dostçpnych w sieci na adresy wykorzystywane do komunikacji.
W 1986 roku dwa rozne projekty pol^czyly siç tworz^c grupç robocz^ o nazwie ISO/CCITT zajmuj^c^. siç opracowaniem standardow w dziedzinie katalogowych baz danych [13].
W pazdzierniku 1988 roku pol^czone organizacje, opublikowaly standard dotycz^cy uslug katalogowych pod nazw^ X.500 [3,13].
Przed rozpoczçciem prac postawiono za cel opracowanie systemu o zasiçgu globalnym, mog^cego przechowywac informacje dotycz^ce adresow i numerow telefonicznych, oraz narzçdzi, ktory umozliwily by szybkie wyszukiwanie informacji w takiej bazie. Jednakze osi^gniçto znacznie wiçcej. Udalo siç zbudowac system, ktory potrafil przechowywac rowniez dane multimedialne w postaci zdjçc paszportowych ludzi, logo firm, a takze roznego rodzaju mapy lokalizuj^ce polozenie firmy. Mozliwe bylo rowniez przechowywani e dzwi çku [13].
Standard ogloszony w 1988 roku dotyczyl systemu, o zasiçgu lokalnym. Jednakze nikt z uczestnicz^cych w tworzeniu standardu nie wiedzial jak stworzyc z tych podstaw system o zasiçgu globalnym. W celu budowy takiego systemu uruchomiono dwa programy pilotazowe. Pierwszy w Stanach Zjednoczonych o nazwie Ksi^zka Adresowa (ang. White Pages) mial na celu pol^czenie katalogow 15 organizacji. W ich sklad wchodzily uniwersytety oraz firmy komercyjne glownie ze Wschodniego Wybrzeza. W ci^gu trzech lat rozbudowy systemu udalo siç pol^czyc ponad 100 organizacji i zbudowac bazç przechowuj informacje o ponad milionie obiektow [14].
Rownolegle z programem amerykanskim wystartowal program europejski. W Wielkiej Brytanii powstal zespol o nazwie JNTUFC (ang. Joint Network Team of the
University Founding Council) zajmuj^cy siç integraj sieci, w celu pol^czenia uniwersytetow posiadaj^cych komputery firmy Sun oraz oprogramowanie QUIPU. QUIPU bylo darmow^. implementaj standardu X.500 dla systemow UNIX [13].
W zwi^zku z darmowym oprogramowaniem do projektu europejskiego przyst^pila ponad polowa z Brytyjskich Uniwersytetow, a w 1993 roku w projekcie uczestniczylo juz 59 organizacji.
Krotko po tym jak wystartowal projekt brytyjski Wspolnota Europejska wyasygnowala srodki na projekt o nazwie Paradise, maj^cy na celu utworzenie miçdzynarodowej bazy katalogowej poprzez pol^czenie projektu brytyjskiego,amerykanskiego oraz wl^czenie innych panstw. W 1993 roku okolo 20 panstw uczestniczylo w projekcie Paradise, miçdzy innymi Polska.
Projekt Paradise umozliwial publiczny dostçp do zasobow baz, przy wykorzystaniu specjalnego interfejsu, dostçpnego przez modem oraz protokol Telnet lub PSS (ang. Personal Search Syndication) [13].
Projekt Paradise odniosl sukces w zakresie integracji danych. Posiadal tez zasoby, ktore mozna bylo liczyc w milionach wpisow. Jednakze jego funkcjonalnosc ograniczona byla w duzym stopniu przez problemy techniczne. Dostçp do bazy oraz wyszukiwanie danych trwalo bardzo dlugo. Ponadto interfejs uzytkownika mial bardzo nisk^ funkcjonalnosc [13].
Dostçp do katalogow odbywal siç za posrednictwem protokolu DAP. Protokol dzialal ponad stosem modelu OSI i wymagal od komputerow klienckich duzych zasobow systemowych. W zwi^zku z tym ograniczeniem w 1992 roku na uniwersytecie w Michigan powstal projekt stworzenia protokolu dostçpu do baz X.500 ktory w przeciwienstwie do DAP odznaczalby siç lekkosci^.. W 1993 roku T. Howes, S. Kille oraz W. Yeong stworzyli prototyp tego protokolu o nazwie LDBP (ang. Lightweight Directory Browsing Protocol) a nastçpnie przekazali jego dokumentacjç do IETF (ang. Internet Engineering Task Force), ktora zajçla siç dalszym jego rozwojem [11]. Nazwa LDBP wynikala z tego, iz pocz^tkowo protokol ten przewidywal jedynie przegl^danie zasobow bazy. Z czasem jednak utrzymuj^c „lekkosc" zostal rozbudowany o dodatkowe funkcje zwi^zane z dostçpem do katalogowej bazy danych i uzyskal nazwç LDAP [15,16].
W wyniku sukcesu jaki odniosl LDAP zaczçto z czasem budowac go jako samodzielny serwer uslug katalogowych, rowniez o nazwie LDAP. Powoduje to obecnie
niescisiosci zwi^zane z nazwq, LDAP. Uzywana jest ona zaröwno do okreslenia protokoiu dostçpu do bazy katalogowej, jak röwniez samodzielnego serwera usiug katalogowych wykorzystuj^cego protoköi LDAP.
3. Opis standardu LDAP
Podstawowq, jednostkq, informacji przechowywanq, w katalogu LDAP jest wpis (ang. entry) [4,6,17]. W odniesieniu do relacyjnych baz danych wpis jest odpowiednikiem krotki lub rekordu w systemach sieciowych. Wpisy zawierajq, grupç informacji reprezentuj^c^ obiekty swiata rzeczywistego. Mogq, byc zatem reprezentaj dla osöb, urz^dzen, pliköw, itp. [6].
Podobnie do krotek, wpis w katalogach definiowany jest przez atrybuty lub wiasciwosci[4,8]. Przykiadowy wpis reprezentuj^cy osoby moze byc charakteryzowany przez atrybuty typu imiç, nazwisko, piec. Kazdy z atrybutöw skiada siç z pary elementöw - typu atrybutu oraz jego wartosci. Przykiadowym atrybutem moze byc cn=Jan Kowalski, gdzie cn (ang. common name) rozumiane jest jako typ atrybutu, natomiast Jan Kowalski jako jego wartosc. Na rysunku 2 przedstawiono struktur? wpisu oraz jego przykiad.
Ryc. 2: Struktura oraz przykiadowy wpis. Zrödio: opracowanie wiasne
Typ atrybutu okresla dziedzinç informacji jakie mogq, byc dowi^zane do wpisu. Wartosc natomiast stanowi szczegölnie wyst^pienie tej dziedziny. W niektörych przypadkach atrybuty mogq, miec kilka wartosci, co jest szczegölnq, cechq, istotnq, dla katalogowych baz danych [4,6,8]. Zapewnia ona duzo wiçkszq, elastycznosc w konstruowaniu struktury bazy. Jest to cecha, ktöra odröznia LDAP od innych baz danych np. relacyjnych.
Atrybuty powi^zane z wpisem dzielq, siç na obowi^zkowe lub tez opcjonalne [8]. Zdefiniowanie atrybutöw obowi^zkowych jest wymagane dla utworzenia wpisu w katalogu.
Liczba atrybutow obowi^zkowych jest rozna w zaleznosci od rodzaju obiektu, ktorego reprezentacj ц jest wpis. Jednakze zawsze okreslony musi byc co najmniej jeden atrybut o nazwie objectclass. Atrybut ten okresla dziedzinç, a scislej klasç do jakiej bçdzie zaliczal siç wpis. Objectclass jest odnosnikiem do definicji klasy [4,6,8]. Klasç mozna rozumiec jako szablon z ktorego odbijane s^. obiekty. Zatem wpisy wystçpuj^ce w bazie danych s^. kolejnymi wyst^pieniami danej klasy. Definicja klasy okresla wszystkie atrybuty jakie mog^. byc dowi^zane do wpisu, ich typ oraz kategoriç. Objectclass definiuje tez zasady gdzie w strukturze katalogu, obiekt danej klasy moze byc umiejscowiony [8].
Wsrod klas istnieje specjalny ich rodzaj o nazwie kontener (ang. container) [4,6]. Kontener pomaga w organizowaniu grupy wpisow w struktur^ hierarchiczn^ o zaleznosciach rodzic-dziecko. Powszechnie uzywan^. klas^. kontenera jest ou (ang. organizational unit). Kontener ten umozliwia na przyklad umieszczenie wszystkich obiektow klasy osoba pracuj^cych w danym dziale firmy. Hierarchiczna organizacja struktury bazy ulatwia nawigacjç oraz przyspiesza wyszukiwanie danych.
Kontenery mog^. rowniez przechowywac inne kontenery jako „dzieci". Jednakze musz^ byc one organizowane w struktur^ hierarchiczn^. Oznacza to, iz dany kontener moze miec tylko jednego rodzica. Natomiast kontener rodzic moze miec kilka kontenerow dzieci.
3.1. Przestrzen nazw
Przestrzen nazw (ang. namespace) jest zbiorem zasad, uzywanych do tego, aby identyfikowac obiekty wystçpuj^ce w danym srodowisku. W przypadku LDAP przestrzen nazw wykorzystywana jest do dwoch celow.
Po pierwsze do przyporz^dkowywania obiektom unikalnych nazw w katalogu, po drugie, aby zorganizowac je w okreslony struktur^ [8,18]. Poprzez organizacjç struktury nalezy rozumiec definiowanie jej modelu oraz okreslanie zaleznosci pomiçdzy wpisami.
W LDAP, jednym mozliwym modelem struktury jest model hierarchiczny. Jak juz wspomniano jest to realizowane za pomoc^. obiektow typu kontener. Wpisy umieszczane wewn^trz danego kontenera nazywane s^. dziecmi (ang. child) lub tez wpisem podporz^dkowanym (ang. subordinate entry) do danego kontenera. Kontenery nadrzçdne
nazywane s^ natomiast rodzicami (ang. parents).
Struktura hierarchiczna bazy musi byc scisle przestrzegana. Jeden wpis rodzic moze miec kilka wpisow dzieci. Jednakze wpis dziecko moze miec tylko jednego rodzica[4,6,8,18]. Struktury innych postaci s^ niedozwolone. Hierarchiczna struktura bazy przypomina drzewo. St^d tez czçsto wykorzystywana jest inna nazwa dla przestrzeni nazw - Drzewo Informacji Katalogowej DIT (ang. Directory Information Tree) [8,18].
Struktura hierarchiczna moze byc tworzona nie tylko przy uzyciu obiektow typu kontener. W zasadzie kazdy obiekt mozne pelnic funkcjç kontenera jezeli tylko dowi^ze siç do niego wpisy podporz^dkowane. W niektorych implementacjach LDAP istniejq, jednak ograniczenia dotycz^ce tej reguly. Uzycie danego wpisu jest mozliwe tylko w okreslonych miejscach struktury [4]. Regulowane jest to poprzez odpowiednio zdefiniowane prawa struktury (ang. structure rules). Ograniczenia te nie wynikaj^ ze standardu LDAP, jednakze stosowane s^ przez wielu producentow oprogramowania LDAP. Prawa struktury nie dotycz^ wyl^cznie obiektow typu kontener. W wiçkszosci implementacji ograniczenia nalozone s^ na wszystkie obiekty w przestrzeni nazw. Kazdy z nich ma okreslone zasady gdzie moze byc umieszczony w strukturze katalogu. Jako przyklad moze posluzyc klasa ou (ang. organizational unit). W wielu przypadkach wymagane jest aby obiekty tej klasy umieszczane byly wewn^trz klasy o nazwie o (ang. organization). Podobne prawa dotycz^. innych klas.
Kazda struktura hierarchiczna wymaga zdefiniowania swego pocz^tkowego obiektu, zwanego korzeniem (ang. root) [4,6,18]. W przypadku LDAP korzen nie jest obiektem zadnej klasy zdefiniowanej w przestrzeni nazw. Istnieje on jako specjalny typ wpisu dla danego serwera o nazwie root DSE (ang. DSA specific entry). Jego zadaniem jest przechowywanie listy wszystkich wpisow znajduj^cych bezposrednio ponizej niego. Kontenery, ktore umieszczone s^ bezposrednio pod wpisem root DSE otrzymaly nazwç kontekstu nazw. Kontenery te maj^ specjalne przeznaczenie, wyznaczaj^ przyrostek dla galçzi wpisow znajduj^cych siç ponizej.
3.1.1. Unikalnosc nazw
Obiekt znajduj^cy siç w strukturze katalogow musi posiadac unikaln^ nazwç. Jest to konieczne do jego jednoznacznej identyfikacji. Istnieje dwa poziomy unikalnosci
nazw. Pierwszy to unikalna nazwa w obrçbie kontenera, w ktorym siç znajduje, drugi to unikalnosc w calej katalogu [18]. Unikalnosc w obrçbie kontenera zapewnia specjalny atrybut wpisu o nazwie relatywnej zroznicowanej nazwy RDN (ang. Relative Distinguished Name). Standard LDAP nie definiuje jaki typ atrybutu danej klasy ma reprezentowac RDN. Jednakze wiçkszosc producentow sama okresla jaki atrybut danej klasy ma byc wykorzystywany na RDN. Przykladowo dla klasy osoba takim atrybutem jest cn.
Drugi poziom, unikalnosc w obrçbie calego katalogu jest realizowana za pomoc^ tzw. zroznicowanych nazw DN (ang. Distinguish Name). Oprocz zapewnienia unikalnosci, DN dodatkowo determinuje lokalizacjç wpisu. Zgodnie ze specyfikaj LDAP, DN nie jest atrybutem wpisu, przez co nie jest zapisany jako jego wartosc. DN nie jest rowniez zapisany w indeksie katalogu i wykorzystywany do wyszukiwania wpisu. DN jest konstruowany jako pol^czenie relatywnej zroznicowanej nazwy wpisu, oraz RDN kontenerow pomiçdzy wpisem a korzeniem DIT. Na rysunku 3 przedstawiono graficzn^. konstrukcjç DN.
Ryc. 3: Tworzenie unikalnych nazw. Zrôdlo: opracowanie wlasne
Dla obiektu „Jan Kowalski" przedstawionego na rysunku, RDN zdefiniowany jest przez cn=JanKowalski, natomiast jego unikaln^. nazw^. jest cn =Jan Kowalski, ou=SGSP, o =PSP.
RDN: cn=Jan Kowalski;
DN: cn=Jan Kowalski,ou=SGSP,o=PSP.
Uzycie DN pocz^tkowo moze okazywac sie trudne, poniewaz uzyskanie dost^pu do wpisu umieszczonego w dowolnym kontenerze, wymaga od uzytkownika znajomosci nazw, oraz kolejnosci wszystkich kontenerow umieszczonych na sciezce do obiektu.
3.2. Operacje klient-serwer.
Typ architektury LDAP to klient-serwer. Oznacza to, iz dzialanie aplikacji bazuje si? na tym, iz uzytkownik za pomocq programu klienckiego konstruuje zqdanie do serwera. Serwer opracowuje zqdanie i wysyla wyniki. Protokolem komunikacyjnym lqcznia si? do serwera LDAP jest TCP/IP [8,9].
Katalogowa baza danych optymalizowana jest pod kqtem wyszukiwania informacji, zatem najcz?sciej wykonywanq operacje jest wyszukiwanie. Na przykladzie wyszukiwania omöwiony zostanie proces interakcji pomi?dzy klientem i serwerem.
Pierwszym krokiem wykonywanym przez aplikacj? klienckq jest ustanowienie podlqczenia do serwera LDAP (ang. bind operation) [8,9]. W trakcie lqcznia wykonywane jest uwierzytelnianie klienta. Klient wysyla login, haslo oraz kontekst przestrzeni nazw do ktörego zamierza si? podlqczyc. Jezeli parametry autoryzacji zostanq zatwierdzone przez serwer nast?puje podlqczenie do katalogu. W dalszej kolejnosci klient wysyla zqdanie wykonania operacji wyszukiwania zgodnie z podanymi parametrami. Serwer opracowuje zqdanie i wysyla wyniki. W trakcie podlqczenia do bazy klient moze wykonac kilka operacji wyszukiwania. Jezeli wyniki wyszukiwania sq wystarczajqce dla klienta wysyla on zqdanie odlqczenia od serwera. Serwer wysyla do klienta wynik operacji odlqczenia i zamyka polqczenie. Na rysunku 4 przedstawiono sekwencj? operacji wykonywanych pomi?dzy klientem a serwerem.
Klient
[ Pol^czenie do serwera,
I wyslanie z^dania pod^cznia
Wys+anie z^dania wyszukiwania lub innej operacji
^ Wystanie zqdania odfocznia
Ryc. 4: Kolejne sekwencje interakcji klient-serwer. Zrödlo: wedlug [3]
Operacja wyszukiwania (ang. search) jest najczçsciej wykonywano operacjo z dostçpnych na serwerze LDAP. Dodatkowo poprzez ilosc parametrow jest tez, najbardziej zlozona. W zwiozku z tym wymaga ona szerszego omowienia.
3.2.1. Wyszukiwanie informacji w katalogach
Operacja wyszukiwania posiada kilka parametrow, ktore informujo serwer o sposobie jej wykonania. Niektore z tych parametrow so obowiozkowe aby serwer mogl przeprowadzic operacjç wyszukiwania, czçsc natomiast jest opcjonalnych. Do parametrow obowiozkowych zaliczyc mozna [19]:
- poczotek wyszukiwania (ang. base DN) - parametr ten okresla od jakiego miejsca serwer LDAP ma rozpoczoc wyszukiwanie informacji. Ze wzglçdu na hierarchiczno struktur^ jest to cecha bardzo uzyteczna. Mozna okreslic kontener, od ktorego rozpoczçte bçdzie przeszukiwanie bazy. Jezeli struktura bazy nie jest znana zawsze mozna rozpoczoc szukanie od korzenia struktury.
- zasiçg (ang. scope) - parametr okresla jak glçboko w dol struktury serwer ma siçgac w poszukiwaniu wpisow. Do parametru mogo byc przyporzodkowane trzy opcje:
* base zawçza wyszukiwania tylko wewnotrz zdefiniowanego kontenera,
* one wyszukuje wszystkie wpisy, ktore so na takim samym poziomie struktury, takze w innych kontenerach,
* subtree - przeszukuje wszystkie wpisy umieszczone ponizej zdefiniowanego kontenera, niezaleznie od poziomu.
- filtr - jest to parametr zlozony. Sklada siç on z typu atrybutu, operatora porownania oraz wartosci atrybutu. Wszystkie wymienione komponenty ujçte so w nawiasach. Przykladowo (objectclass=person) jest filtrem, ktory wyszukuje obiekty nalezoce do klasy osoba. Filtr moze skladac siç z jednego lub wiçcej regul tego typu, poloczonych operatorami logicznymi.
Przykladowo skladnio zapytania kierowanego do bazy moze byc wyrazenie:
o=PSP(scope=subtree((cn="Jan Kowalski") Jak wspomniano mozliwe jest loczenie filtrow za pomoco operatorow logicznych. Mozna w ten sposob dokladnie sprecyzowac parametry wyszukiwania. Istniejo trzy operatory logiczne wykorzystywane do loczenia parametrow filtra[19]:
- & iloczyn logiczny - AND;
- | suma logiczna - OR;
- ! zaprzeczenie - NOT;
Przykladowo filtr typu (|(cn="Jan Kowalski") (cn="Jan Nowak") wyszuka wszystkie osoby, ktorych parametr cn jest rowny „Jan Kowalski" lub „Jan Nowak". Natomiast filtr typu (&(cn="Jan Kowalski") (telephone=998)) wyszuka wszystkie osoby, ktorych nazwa jest rowna „Jan Kowalski" i telefon jest rowny 998.
Oprocz rownosci, jako znak porownania mogo sluzyc operatory:
- <= mniejszy rowny, co dla porownan tekstu, oznacza, iz znalezione zostano wszystkie wartosci alfabetycznie nizsze niz podany wzorzec wyszukiwania;
- >= wiçkszy rowny, dla tekstu wartosci alfabetycznie wyzsze niz wzorzec;
- ~= przyblizenie, rodzaj wyszukiwania informacji tekstowy zalezy od producenta oprogramowania;
Mozliwe jest rowniez podawanie w filtrze jako wartosc parametru znakow wieloznacznych (ang. wildcard) [4,6]. Znak „*" zastçpuje zero lub wiçcej znakow w danym lancuchu znakow. Przykladowo filtr (cn=Jan*) wyszuka wszystkie wartosci parametru cn zaczynajoce siç od wyrazu „Jan".
Oprocz parametrow obowiozkowych istniejo tez opcjonalne, ktore w przypadku pominiçcia w konstrukcji zapytania przyjmujo wartosci domyslne.
3.2.2. Inne operacje klient-serwer LDAP
LDAP posiada ograniczono zaledwie do 10 liczbç operacji, jakie mogo byc wykonywane na katalogach. Dzielo siç one na grupy [4,8]:
- sesji - bind, unbind oraz abandon,
- pozyskiwania danych - search, compare,
- modyfikacji - dodawania add, modyfikacji modify, modyfikacji RDN modifyRDN oraz usuwania delete,
- rozszerzone - extended.
Operacje sesji bind oraz unbind zostaly juz omowione wczesniej w punkcie 3.2. Operacja abandon umozliwia porzucenie wykonywania ostatniej operacji, ktoro klient wyslal do serwera.
Szczegolowo w punkcie 3.2.1 zostala omowiona rowniez operacja wyszukiwania, znajduj^ca siç w grupie pozyskiwania danych.
Operacja compare umozliwia porownanie czy informacja przeslana przez klienta zgadza siç z t^. zapisan^. w bazie. Operacja porownania rozni siç od wyszukiwania zwracaniem wynikow zapytania. W przypadku proby porownania jednego z atrybutow wpisu, ktory nie istnieje zwracany jest specjalny kod blçdu. Natomiast w przypadku operacji wyszukiwania kod blçdu nie jest zwracany, tylko informacja, iz nie ma wpisu z danym atrybutem [8].
Operacja dodawania umozliwia wprowadzenie do bazy nowego wpisu. Aby przebiegla prawidlowo, wymagane jest zdefiniowanie kilku parametrow w postaci, klasy jak^. reprezentuje obiekt, atrybutow, ktore s^. obligatoryjne oraz podanie wlasciwego DN. Zanim wpis zostanie dodany do bazy, na serwerze uruchamiany jest proces, ktory sprawdza wyzej wymienione zaleznosci. Dodatkowo kontener do ktorego chcemy dodac wpis musi byc wczesniej zdefiniowany [4].
Usuwanie wpisu polega na podaniu DN wpisu ktory ma byc usuniçty. Warunkiem poprawnosci operacji jest istnienie danego wpisu oraz aby usuwany wpis nie byl kontenerem z wpisami dziecmi.
Operacja modyfikacji umozliwia zmianç wartosci atrybutow danego wpisu, dodania nowego atrybutu lub usuniçcie istniej^cych. W przypadku jednoczesnej modyfikacji wielu atrybutow, niepowodzenie modyfikacji jednego zatrzymuje modyfikacjç pozostalych. Operacja modyfikacji potrzebuje spelnienia dwoch warunkow do prawidlowego dzialania: podanie DN oraz zbioru modyfikowanych atrybutow [4,6,9].
Modyfikacja RDN umozliwia zmianç unikalnej nazwy danego wpisu. Jako parametry operacji wymagane s^.: DN wpisu, nowy RDN oraz flaga okreslaj^ca czy stary RDN ma zostac usuniçty czy pozostawiony. Jako opcjonalny jest parametr, ktory okresla DN nowego kontenera. Wykorzystanie ostatniego parametru umozliwia przeniesienie wpisu do innego kontenera w strukturze bazy. Przenosic mozna rowniez kontener, ktory ma wpisy dzieci. Wowczas przeniesione zostan^. wszystkie wpisy, umieszczone w tym kontenerze [4].
Operacje rozszerzone, umozliwiaj^. rozbudowç podstawowych operacji wykonywanych przez LDAP. Jest to pojemnik na operacje zdefiniowane przez
uzytkownikow. Jednakze podlegajo one okreslonym zasadom odnosnie skladni, zgodnie, z ktoro mogo byc budowane. Jako przyklad operacji rozszerzonej moze byc operacja szyfrowania poloczen, ktora jest implementowana w wielu aplikacjach LDAP [20,21].
4. Schemat LDAP
Schematem nazywamy definicjç wszystkich klas ktorych obiekty aktualnie przechowywane so w bazie, oraz zasady relacji pomiçdzy obiektami. Definicja obejmuje rodzaj klasy oraz typy atrybutow skojarzonych z dano klaso.
Schemat katalogu (ang. directory schema) jest zbiorem zasad okreslajocych sposoby wspolpracy (interakcji) pomiçdzy klientami a uslugo katalogowo [4,8]. Schemat definiuje rowniez jakie elementy mogo byc przechowywane w bazie. Odbywa siç to poprzez definiowanie odpowiednich klas, reprezentacjo ktorych so wpisy. Klasa schematu definiowana jest poprzez [4]:
a. zasady doboru atrybutow (ang. content rules),
b. zasady okreslajoce rozmieszczenie klasy w strukturze katalogu (ang. structure rules), rodzaj atrybutow wykorzystanych do identyfikacji wpisow (ang. name form).
Ad. a. Zasady doboru atrybutow definiujo rodzaje informacji powiozanych z wpisem. Na przyklad mozna zdefiniowac aby pracownik opisany byl w bazie przez atrybuty takie jak: imiç, nazwisko, stanowisko, pobory. Definiowanie atrybutow polega na okresleniu skladni oraz zasad odwzorowania. Skladnia okresla typ danych jakie mogo byc przypisane do danego atrybutu. Na przyklad do atrybutu pobory mozna jedynie przypisac liczby. Zasady odwzorowania definiujo natomiast sposob porownywania atrybutow w trakcie np. operacji wyszukiwania.
Ad. b. Zasady okreslajoce rozmieszczenie klas w strukturze katalogu definiujo gdzie dana klasa moze wystçpowac w przestrzeni nazw. Na przyklad w ktorym kontenerze moze byc skladowana.
Ad. c. Klasa moze posiadac wiele atrybutow jednakze nie wszystkie nadajo siç do identyfikacji danego wpisu. Dlatego tez konieczne jest wyznaczenie atrybutu (atrybutow), ktory bçdzie wykorzystywany do jednoznacznej identyfikacji obiektu w przestrzeni nazw -RDN.
Schemat struktury katalogu przedstawiono w pogl^dowy sposób na rysunku 5.
^SCHEMAT K^TALOGuj
Ryc. S: Struktura schematu katalogu. Zródio: opracowanie wiasne
Schemat moze bye rozbudowany przez uzytkowników, jednakze przyjçto zasadç, iz musi on bye zgodny ze schematem LDAP wywodz^cym siç ze standardu X.SGG opisanym w pracach [4,22]. Schemat standardowy definiuje podstawowq, grupç klas oraz zasady ich rozmieszczania w bazie. Wychodz^c z tego standardu mozna go rozbudowae o dodatkowe klasy lub tez dodae nowe atrybuty do klas juz istniej^cych. Funkcjonalnose ta zapewnia duz^ elastycznose w tworzeniu struktury katalogowej bazy danych oraz definiowaniu obiektów, które mogq, bye w niej skiadowane.
Schemat standardowy definiuje równiez sposób kodowania danych umieszczonych w bazie. Ma to na celu zapewnienie mozliwosci wspóipracy stworzonej bazy z innymi aplikacjami.
Wykorzystanie schematu standardowego w duzym stopniu nie jest obowi^zkowe, jednakze zawiera on róznego rodzaju rekomendacje odnosnie definiowania nowych klas i atrybutów ich opisuj^cych [4,8].
4.1. Klasy schematu
Kazdy wpis przechowywany w katalogu musi miec zdefiniowany atrybut typu objectclass. Jego wartosc okresla przynaleznosc do danej klasy zdefiniowanej w schemacie katalogu. Klasy dzielo siç na trzy kategorie [4]:
- strukturalne (ang. structural),
- abstrakcyjne (ang. abstract),
- pomocnicze (ang. auxiliary).
Kazdy wpis przechowywany w katalogu musi nalezec od co najmniej jednej klasy strukturalnej i jednej abstrakcyjnej.
Klasy tworzone so poprzez odpowiednie zdefiniowanie pol kluczowych. Definicja tych pol stanowi podstawç przy pozniejszym tworzeniu wpisow danej klasy oraz okresla cechy jakie dany wpis bçdzie posiadac.
Ponizsze pola kluczowe stanowio definicjç klasy [4,8]:
- OID - unikalny identyfikator klasy,
- nazwa - nadawana klasie w celu pozniej szej identyfikacji,
- opis - krotki opis stanowi ocy o tym jaki fragment rzeczywistosci dana klasa reprezentuje, status bezczynnosci (ang. inactive status) - wskazuje na uzycie danej klasy,
- klasy nadrzçdne - lista klas na ktorych dana klasa bazuje,
- kategoria klasy - okresla kategoriç klasy: strukturalna, abstrakcyjna, pomocnicza,
- atrybuty obowiozkowe - lista atrybutow ktore nie mogo miec pustej wartosci przy definiowaniu obiektu tej klasy,
- atrybuty opcjonalne - lista dodatkowych atrybutow dozwolonych w danej klasie.
Ponizszy przyklad przedstawia definicjç klasy o nazwie osoba (ang. person):
person OBJECT-CLASS ::= { SUBCLASS OF { top } MUST CONTAIN { commonName,surname} MAY CONTAIN {
description,seeAlso,telephoneNumber,userPasswor d}ID 2.5.20.1 }
Definicja klas zazwyczaj przechowywana jest w plikach tekstowych.
Umozliwia to szybkie tworzenie nowych klas lub modyfikacj? istniej^cych.
Pomi?dzy poszczegolnymi klasami mogq, wyst?powac roznego rodzaju zaleznosci. Kazda z klas moze rozszerzyc innq, lub tez zapozyczac z definicji niektorych atrybutow. Najpowszechniejszq, metodq, rozszerzania klas jest dziedziczenie [4,6,8].
Nowq, klas? mozna utworzyc jako rozszerzenie juz istniej^cej. Mowi si? wowczas, ze nowa klasa jest podklasq, klasy nadrz?dnej lub superklasy i dziedziczy jej cechy. Klasa podrz?dna moze zatem dziedziczyc, umiejscowienie w przestrzeni nazw oraz atrybuty. Szersze omo wienie dziedziczenia zostalo omowione w [23]. Na rysunku 6 zaprezentowano schematycznie zasad? dziedziczenia klas.
Ryc. 6: Przyklad dziedziczenia klas. Zrodlo: wedlug [4]
Jezeli teraz zostanie utworzony obiekt klasy intOrgPerson, konieczne b?dzie zdefiniowanie obowi^zkowych atrybutow klasy inetOrgPerson, ale takze klas OrganizationalPerson oraz Person. Jednakze w obiekcie tym b?dzie mozliwosc wykorzystania atrybutow wyst?puj^cych we wszystkich klasach struktury.
Innym sposobem na wykorzystanie atrybutow z roznych klas jest uzycie klas pomocniczych [4]. Klasy pomocnicze, mog^ rozszerzac atrybuty innych klas jednakze nie nalezq, do zadnego lancucha dziedziczenia. L^cznie atrybutow wielu klas odbywa si? poprzez odpowiedniq, definicj? wpisu, podaj^c, iz jest on obiektem dwoch klas. Wykorzystanie klas
pomocniczych jest alternatywq, dla dziedziczenia. Nie mozna jednak môwic o przewadze jednej z metod. Wszystko zalezy od zadania jakie trzeba zrealizowac. Omôwienie wykorzystania klas pomocniczych zostanie przeprowadzone na przykiadzie.
Zaiôzmy, ze w katalogu przechowywane sq, wpisy nalezqce do klas komputer oraz drukarka. Zaiôzmy rôwniez, ze obie klasy nalezy do rôznych gaiçzi dziedziczenia. Dla kazdej z tych klas chcielibysmy dodac atrybut o nazwie dzialid, ktôry bçdzie okreslai, w tôrym dziale firmy wykorzystywane jest dane urzqdzenie. Majqc do dyspozycji wyiqcznie dziedziczenie nalezaioby zdefiniowac dwie klasy, jednq, rozszerzajqcq, klasç komputer, drugq, drukarka. W przypadku uzycia klas pomocniczych nalezy zdefiniowac jednq, klasç dzial z atrybutem dzial id a nastçpnie tworzqc nowe wpisy okreslic, iz obiekt nalezy do klasy komputer oraz dziai. Ideç klas pomocniczych ilustruje rysunek 7.
Ryc. 7: Zasada wykorzystania klas pomocniczych. Zrôdio: wediug [4]
Klasy skiadaj^ siç z atrybutôw, przy definicji ktôrych uzywa siç podobnej notacji do las [4,8,24]. W celu utworzenia atrybutu nalezy zdefiniowac kilka pôl kluczowych. Najwazniejsze z nich to pola odpowiedzialne za skiadniç, oraz sposôb odwzorowania. Jak wspomniano wczesniej skiadnia okresla rodzaj oraz format przechowywanych danych.
Do definiowania skiadni uzywany jest specjalny system notacji o nazwie ASN.1
(ang. Abstract Syntax Notation One) [25,26]. ASN.1 jest standardem sluz^cym do opisu struktur przeznaczonych do reprezentacji, kodowania, transmisji i dekodowania danych. Dostarcza zbior formalnych zasad pozwalaj^cych na opis struktur obiektow w sposob niezalezny od konkretnych rozwi^zan sprzçtowych. ASN.1 jest bardzo uniwersalnym systemem, ktory moze bye uzywany do definiowania roznego rodzaju typow danych. Pocz^wszy od prostych typu liczba, czy tekst a skonczywszy na skomplikowanych pol^czeniach roznych typow danych. Wiçcej na temat ASN.1 mozna przeczytae w [25,26]. Dokument RFC [22] definiuje 55 gotowych skladni przeznaczonych do tworzenia klas w standardzie LDAP. Istnieje takze mozliwose definiowana nowych, wlasnych skladni. Przykladow^ deflnicjç atrybutu zaprezentowano ponizej.
attributetype ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
Przedstawione definicje zapisane s^ w schemacie katalogu. Nie jest to jednak wystarczaj^ce aby zachowae spojnose katalogu. Musi dodatkowo istniee mechanizm odpowiedzialny za sprawdzanie czy wprowadzone dane zgodne s^ ze schematem. Mechanizm ten powinien wykonywae nastçpuj^ce funkcje:
• sprawdzae wartosci atrybutow zgodnie ze skladni^. zdefiniowan^. w schemacie,
• kontrolowae przypisywanie wartosci do atrybutow obowi^zkowych,
• sprawdzae unikalnose nazw a takze ich zgodnose ze struktur^. DIT.
Mechanizm sprawdzania poprawnosci nie jest zdefiniowany przez zaden ze standardow LDAP. Dlatego tez jego realizacja oraz sposob jego dzialania zalezy od poszczegolnych producentow.
5. Rozproszona architektura katalogowych baz danych.
Jak opisano w poprzednim artykule alokacja zasobow bazy moze bye realizowana na cztery sposoby [27] :
• centralnie na jednym serwerze,
• replikowana calkowicie w kazdym wçzle,
• replikowana selektywnie,
• podzielona na fragmenty i rozproszona.
Katalogowe bazy danych mogq rôwniez realizowac kazdq z wymienionych architektur [4,6,9].
Replikacja caikowita lub selektywna polega na utworzeniu kopii caiego katalogu lub jego fragmentu na innych serwerach. Sposôb realizacji replikacji nie jest obecnie regulowany przez standard LDAP, w zwiqzku z tym nie jest wymagany. Jednak umieszczenie wszystkich informacji na serwerze bez rezerwy jest potencjalnym siabym punktem systemu. Dlatego wiçkszosc producentôw dodaje mozliwosc replikacji w swoich produktach. Sposôb realizacji tej funkcjonalnosci zalezy od producentôw, ale prowadzone sq rôwniez prace przez IETF nad opracowaniem modelu oraz protokoiu replikacji [4].
Replikacja katalogowej bazy danych moze byc realizowana w modelu nadrzçdnym (ang. single-master model) lub rôwnorzçdnym (ang. mutlimaster model)[4,27]. W modelu nadrzçdnym istnieje tylko jeden autorytatywny serwer. Na tym serwerze przeprowadza siç wszelkie modyfikacje bazy. Pozostaie serwery siuzq jedynie do odczytu informacji.
W modelu rôwnorzçdnym istnieje wiele serwerôw autorytatywnych, na ktôrych mozna przeprowadzac modyfikacje. Model ten jest jednak bardziej skomplikowany i wymaga zastosowania wielofazowych protokoiôw wypeiniania, omôwionych w poprzednim artykule.
Mozliwosc fragmentacji katalogowej bazy danych pojawiia siç wraz z wersjq 3 protokoiu LDAP. Byia odpowiedziq na ograniczenia funkcjonalnosci systemôw scentralizowanych. Fragmentacja struktury katalogôw jest realizowana za pomocq specjalnych obiektôw klasy odnosnik (ang. referral) [8,28].
Odnosnik jest typem komunikatôw odpowiedzi generowanych przez serwer. Zwrôcony do klienta LDAP jest instrukcjq kontynuacji wyszukiwania danych na innym serwerze LDAP. Po otrzymaniu tej instrukcji klient automatycznie wysyia zqdanie do serwera wskazanego w odpowiedzi [28].
Zazwyczaj uzycie odnosnikôw ograniczone jest do operacji wyszukiwania. Jednakze w niektôrych implementacjach mogq rôwniez siuzyc do modyfikacji, usuwania lub dodawania informacji. Proces przeiqczania siç na serwer wskazany w odnosniku nazywa siç podqzaniem za odnosnikiem (ang. chasing the referral) [4,8,28].
Wprowadzenie odnosnikow w wersji 3 standardu LDAP wymagalo modyfikacji aplikacji klienckich. Poniewaz funkcja pod^zania za odnosnikiem zaimplementowana jest w oprogramowaniu klienckim. W przypadku serwera, wystarczylo jedynie utworzenie nowego typu klas, przechowuj^cych adres URL do innych serwerow LDAP nalez^cych do struktury katalogow[28]. Wprowadzenie odnosnikow spowodowalo wydluzenie czasu realizacji zapytania. Klient dodatkowo musi uzyskac pol^czenia z wi^kszq, liczbq, serwerow. Jednakze poprawilo w duzym stopniu elastycznosc w tworzeniu struktur rozproszonych.
Przy pomocy odnosnikow mozliwe jest utworzenie spojnej bazy danych rozproszonej na wielu w^zlach. Konstrukcja odnosnika przedstawiona jest ponizej[29].
ldap://ldap.cnbop.pl/ou=cnbop,o=PSP?? sub?cn=Jan*
Rysunek 8 ilustruje dzialanie odnosnikow.
Ryc. 8: Zasada dziaiania odnosnikow. Zrodio: opracowanie wiasne
Na rysunku nr 8 przedstawiono fragment struktury organizacyjnej PSP. Root DSE oraz informacje kontekstu ou=SGSP przechowuje serwer nr 1. Dodatkowo przechowuje on odnosnik do serwera nr 2, na ktorym skiadowane s^, dane kontekstu ou=CNBOP.
Wyszukiwanie wszystkich osôb zatrudnionych w PSP przebiegac bçdzie nastçpujqco [4,8,28]:
1. Klient wysyia zapytanie do serwera nr 1, w ktôrym zqda wyszukania wszystkich wpisôw, ktôrych parametr cn zaczyna siç na „Jan".
2. Serwer nr 1 wysyia odpowiedz do klienta, w ktôrym zawarty jest wpis „Jan Kowalski" oraz odnosnik do serwera nr 2. W odnosniku tym zawarty jest adres URL serwera nr 2 oraz jego DN.
3. Klient tworzy nowe zqdanie, w ktôrym zastçpuje oryginalny adres URL oraz DN na te wskazane w odnosniku.
4. Serwer nr 2 przysyia odpowiedz do klienta z wpisem „Jan Nowak".
Jak pokazano na rysunku, zadaniem klienta po otrzymaniu odnosnika jest modyfikacja oryginalnego zapytania i ponowne wysianie zqdania. Parametry zwrôcone przez serwer nadpisujq te z oryginalnego zqdania. Modyfikowanymi parametrami mogq byc: adres lub port serwera, podstawa wyszukiwania oraz zastosowane filtry [4,28]. Zamiana parametrôw wyszukiwania nastçpuje tylko wtedy gdy parametr zdefiniowany w odnosniku jest inny niz w zapytaniu oryginalnym. Jezeli dany parametr nie wystçpuje, wyszukiwanie jest kontynuowane z uzyciem oryginalnych parametrôw. Giôwnym zadaniem klienta jest zatem odpowiednie poiqczenie obu zapytan i kontynuacja wyszukiwania zgodnie ze zmodyfikowanymi parametrami.
Istniejq trzy kategorie odnosnikôw [4,28]:
• hierarchii - wskazujq serwery, ktôre stanowiq rozszerzenie tego samego drzewa informacji katalogowej. W zaleznosci czy wskazujq na obiekty wyzsze czy nizsze w hierarchii, mogq byc nadrzçdne (ang. superior referrals) lub podrzçdne (ang.subordinate referrals).
• Zewnçtrzne (ang. external referrals) - wskazujq na serwery, ktôre przechowujq inne drzewo informacji katalogowej.
• Domyslne (ang. default referrals) - wykorzystywane sq do wskazywania serwerôw za kazdym razem gdy zapytanie dotyczy obiektôw niebçdqcych w strukturze katalogôw danego serwera.
Na rysunku 9 zaprezentowano 3 kategorie odnosnikôw.
С)
Ryc. 9: Rodzaje odnosników. a) hierarchii, b) zewnçtrzny c) domyslny. Zródlo: opracowanie wlasne
Funkcja pod^zania za odnosnikiem jest standardowo implementowana we wszystkich klientach. Jednakze czçsc z nich ma mozliwosc wyl^czenia tej opcji.
5.1. Aliasy
Jak zaznaczono w rozdziale 2.3 struktura katalogowej bazy danych moze byc wyl^cznie hierarchiczna. Jezeli teraz konieczne jest odwzorowanie w bazie innej struktury staje siç to problematyczne. Przykladowo osoba, która pelni kilka funkcji w danej firmie i nalezy do jej róznych dzialów zaklóca model hierarchiczny. Aby unikn^c dublowania
wpisôw i zwiqzanych z tym komplikacji wprowadzono specjalne obiekty klasy alias (ang. alias) [4,6,8]. Aliasy mozna traktowac jako puste wpisy, posiadajqce jednak mechanizm przekierowujqcy do wiasciwego wpisu w tym samym katalogu.
Zasadq dziaiania, aliasy mogq przypominac odnosniki. W przeciwienstwie jednak do odnosnika alias moze jedynie wskazywac na inny wpis w tym samych katalogu. Odnosnik moze natomiast wskazywac caiy kontener takze poza strukturq DIT. Poza tym aliasy rôzniq siç przeznaczeniem. Podstawowym zadaniem aliasôw jest rozmieszczanie tego samego wpisu w rôznych miejscach struktury katalogu. Odnosniki natomiast wykorzystywane sq do iqczenia struktury katalogu rozmieszczonej na rôznych wçziach. Za pomocq aliasôw mozna utworzyc strukture katalogu przypominajqcq siec. Jednakze polqczenie pomiçdzy aliasem a wpisem wiasciwym nie jest widoczne dla uzytkownika, przez co nie zakiôca to struktury hierarchicznej.
Alias moze posiadac innq nazwç RDN niz oryginalny wpis. Dziçki temu wydaje siç caikowicie innym obiektem. Jednak modyfikacja parametrôw oryginalnego wpisu, powoduje modyfikacjç parametrôw aliasu. Przez co spôjnosc bazy zostaje zachowana [4].
Wykorzystanie aliasôw ogranicza siç jedynie do operacji wyszukiwania. Modyfikacja lub usuniçcie dotyczy natomiast aliasu.
6. Podsumowanie
Systemy rozproszone wykorzystujqce model relacyjny omôwione w [30], wyposazone sq w narzçdzia kontrolujqce transakcje, umozliwiajqce odtworzenie bazy do dowolnej chwili z przesziosci oraz wiele innych funkcjonalnosci. Zapewniajq one bardzo duze mozliwosci budowy systemôw baz danych jednakze jednoczesnie obarczone sq wiçkszq komplikacjq. W przypadku budowy bazy danych bçdqcej podstawq systemu wspomagania decyzji w PSP zaawansowane funkcjonalnosci dostçpne w relacyjnych bazach danych nie sq potrzebne. Komplikacja systemu moze przyczynic siç do zmniejszenia jego niezawodnosci, co jest niedopuszczalne w systemach wspomagania decyzji.
Wykorzystanie serwerôw LDAP pozwala na ujednolicenie i logiczne scentralizowanie informacji przechowywanych w strukturach rozproszonych. Katalogi LDAP pozwalajq przechowac miliony rekordôw i obsiugiwac do kilkuset zapytan w ciqgu sekundy. LDAP pozwala tez na przekierowywanie zapytan do innego serwera co gwarantuje
skalowalnosc do poziomu najwiçkszych organizacji. Uslugi katalogowe LDAP cechuje tez mozliwosc realizacji replikacji bazy danych na wielu serwerach wewn^trz organizacji. Replikacja zmniejsza ruch w sieci, zmniejsza czas odpowiedzi na zapytanie, zmniejsza ryzyko awarii oraz ulatwia pracç lokalnym administratorom. Dziçki tym zaletom w dobie powszechnej globalizacji usluga LDAP znajduje coraz wiçksze zainteresowanie.
Katalogowa baza danych posiada wlasnosci, odpowiednie do budowy rozproszonej bazy danych do systemu wspomagania decyzji w PSP. Zaliczyc do nich mozna:
• Uslugi katalogowe s^ optymalizowane pod k^tem przeszukiwania oraz odczytu informacji, co daje bardzo krotki czas odpowiedzi na zapytanie;
• Dane przechowywane s^ w logicznej strukturze drzewa, odpowiadaj^cej strukturze PSP;
• Dowolnosc w definiowaniu nowych typow obiektow;
• Relatywnie prosta przez co niezawodna implementacja.
Wlasciwosci katalogowych baz danych sprawiaj^, iz nalezy rozwazyc mozliwosc ich wykorzystania jako warstwy danych przechowuj^cej dokumenty generowane w PSP jak rowniez bazç wiedzy dla systemu wspomagania decyzji.
7. Literatura
1. Lewis A.: RIMSAT DSS Project: Integrating Model-Based and Case-Based Reasoning.
[online]. DSSResources.COM. [dostçp: 20.03.2007] Dostçpne w Internecie: <http://dssresources.com/papers/features/lewis/lewis04052004.html>.
2. Fressmann A. i inni: Advanced Multi-modal Intelligence for Remote Assistance. W: Report on Applied Research Findings - Final. [online]. University of Trier. [dostçp: 23.04.2007] Dostçpne w Internecie: <http://www.amira. no/modules.php ?op =modload&name =PagEd&file=index&theme =E xtraLite&p_deliver=media&m_id=259>.
3. ISO/IEC 9594-1:1998: Information technology -- Open Systems Interconnection -
The Directory: Overview of concepts, models and services.
4. Arkills B.: LDAP Directories Explained. An Introduction and Analysis.
Reading. Addison Wesley 2004.
5. Andersen E.: The X.500 Directory The mother of all directories. [online]. Andersen E.
[dostçp: 12.02.2006] Dostçpne w Internecie: <http://home20.inet.tele.dk/era/x500/x500-technol ogy. htm>.
6. Johner H. i inni: LDAP Implementation Cookbook. Austin. IBM RedBooks 1999.
7. Janikowski A.: LDAP co nowego?. NetWorld Styczen 2000. nr 1.
8. Wahl M., Howes, T., Kille S.: Lightweight Directory Access Protocol (v3). W: RFC 2251.
Reston. The Internet Society 1997.
9. Tuttle S., Ehlenberger A., Gorthi R.: Understanding LDAP - Design and Implementation.
Austin. IBM RedBooks 2004.
10. Praca zbiorowa.: LDAP lekkiprzejrzysty protokôl. NetWorld. Grudzien 2000. nr 12.
11. Mueller S.: Rozbudowa i naprawa sieci. Gliwice. Helion 2004.
12. ISO/IEC 9594-3:2001: Information technology - Open Systems Interconnection -The Directory: Abstract service definition.
13. Chadwick D. W.: Understanding X.500 - The Directory. Tampa. International Thompson Publishing 1996.
14. Andrianopoulos A., Chadwick D. W.: Simulating the global directory service with opnet. W: Proceedings of the IEEE. 26th Annual Simulation Symposium. Washington. IEEE Computer Society Press 1993. s. 162-172.
15. Howes T. A.: The Lightweight Directory Access Protocol: X.500 Lite. W: Technical. report TR-95-8, Michigan. University of Michigan 1995. .
16. Yeong W., Howes T., Kille S.: X.500 Lightweight Directory Access Protocol. W: RFC1487 Reston. The Internet Society 1993.
17. Pfliegl K.: Ustugi Katalogowe - zasada dzialania. Sieci. Wydanie specjalne PC World Komputer. Sierpien 2003. nr 1.
18. Kille S., Wahl, M., Howes T.: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. W: RFC 2253. Reston.
The Internet Society 1997.
19. Howes T.: The StringReprezentation of LDAP Search Filters. W: RFC 2254. Reston. The Internet Society 1997.
20. Zeilenga K.: LDAP Password Modify Extended Operation. W: RFC 3062 Reston.
The Internet Society 2001.
21. Wahl M., Hodges J., Morgan R.: Authentication Methods for LDAP. W: RFC 2829. Reston. The Internet Society 2000.
22. Kille S., Wahl, M., Howes T.: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. W: RFC 2252. Reston. The Internet Society 1997.
23. Eckel B.: Thinking in Java. Wydanie 2. Gliwice. Helion 2003.
24. Wahl M.: A Summary of the X.500(96) User Schema for use with LDAPv3. W: RFC 2256. Reston. The Internet Society 1997.
25. Dubuisson O.: ASN.1 - Communication Between Heterogeneous Systems. San Francisco. Morgan Kaufmann 2000.
26. Larmouth J.: ASN.1 Complete. San Francisco. Morgan Kaufmann 2006.
27. Connolly T., Begg C.: Systemy Baz Danych - projektowanie, wdrazanie i zarzqdzanie w praktyce. Warszawa. RM 2004.
28. Zeilenga K.: Named Subordinate References in LDAP Directories. W: RFC 3296. Reston. The Internet Society 2002.
29. Howes T., Smith M.: The LDAP URL Format. W: RFC 2255 Reston. The Internet Society 1997.
30. Özsu M. T.: Distributed Database Systems. W: Hossein B.: Encyclopedia of Information Systems. Boston. Academic Press 2003.
