\documentstyle[12pt,a4wide,polski]{article}
\textwidth=14cm
\tolerance=1000
\author{Maria G`orecka\\Tomasz M.\ Wolniewicz}
\title{Efektywno`s`c rozproszonych baz danych na podstawie implementacji
X.500 Directory\\[2cm]
\Large
Stan obecny\\[2cm]}
\begin{document}
\maketitle
\section{Wst`ep}
Podstawowym zagadnieniem w zakresie konstrukcji baz danych jest problem
efektywno`sci wytworzonego produktu. Ostateczny efekt dzia`lania
projektant`ow jest mo`xliwy do oceny
dopiero przy badaniu konkretnej aplikacji, jako `xe zale`xy od ogromnej
ilo`sci czynnikow, cz`esto wzajemnie si`e wykluczaj`acych, a optymalne dzia`lanie
osi`aga si`e jako kompromis pomi`edzy r`o`xnymi mo`xliwymi wariantami.

Celem niniejszego raportu jest przygotowanie gruntu do badania efektywno`sci
systemu X.500 Directory jako przyk`ladowej rozproszonej bazy danych.
Przedstawiamy w nim problematyk`e i zwracamy uwage na najistotniejsze,
naszym zdaniem, elementy systemu maj`ace wp`lyw na jego sprawno`s`c.
Ten przygotowawczy charakter raportu powoduje, ze zdecydowali`smy si`e
wprowadzi`c dosy`c obszerne fragmenty opisuj`ace specyfik`e rozproszonej bazy
danych X.500, wydaj`a si`e one by`c niezb`edne w celu w`la`sciwego zrozumienia
opisywanego zagadnienia.

Jako kontunuacj`e niniejszej pracy planujemy przedstawienie wynik`ow
rozwa`xa`n i test`ow przeprowadzonych na konkretnej implementacji,
w postaci zalece`n dla administrator`ow systemu X.500 w Polsce.

\section {Informacje og`olne o X.500 Directory}

\subsection{X.500 jako termin}
Terminem X.500 okre`sla si`e potocznie funkcjonuj`ac`a jako us`luga sieci
Internet, rozproszon`a baz`e danych, zawieraj`ac`a informacje 
o instytucjach i ich pracownikach.
Faktycznie X.500 jest standardem OSI, a funkcjonuj`aca us`luga jedynie jego
implementacj`a. Terminu X.500 b`edziemy u`xywa`c zar`owno w potocznym jak i w
formalnym znaczeniu, z kontekstu b`edzie wynika`c, o jakie znaczenie chodzi.


\subsection{Standard X.500}

Seria zalece`n X.500--X.521, zebrana w [X500], jest standardem
OSI\footnote{Open Systems Interconnection}
definiuje obiektow`a, rozproszon`a baz`e danych opart`a na modelu 
sieciowym (Directory). Zalecenia te zosta`ly opublikowane przez
CCITT\footnote{The International Telegraph and Telephone Consultative
Committee} i
obejmuj`a opis koncepcji i modelu 
bazy X.500, zasady ochrony i bezpiecze`nstwa danych, definicj`e us`lug, 
spos`ob realizacji zdalnych operacji i specyfikacj`e protoko`lu.

R`ownolegle do serii
X.500 opracowano standard ISO-9594 b`ed`acy {\em oficjalnym} miedzynarodowym
dokumentem definiuj`acym Directory. [X500] zawiera, poza definicj`a samego
standardu r`ownie`x szereg dodatk`ow okre`slaj`acych podstawowe typy atrybut`ow
i klas obiekt`ow, jak r`ownie`x wskazania co do mo`xliwych sposob`ow
implementacji Directory.  

U`xytkowy opis standardu X.500 i przyk`lady zastosowania mo`xna znale`z`c
w [ROSE].

Definicja standardu bazuje na notacji ASN.1 (Abstract Syntax Notation
One), utworzonej dla potrzeb reprezentacji z`lo`xonych struktur danych,
wyst`epuj`acych w warstwie aplikacji modelu sieciowego OSI, 
a docelowo rozwini`etej dla szerokich zastosowa`n zwi`azanych z opisem 
protoko`l`ow OSI. Notacja ta umo`xliwia definicj`e skomplikowanych
struktur danych, abstrahuj`ac`a od `srodowiska implementacji oraz opis
protoko`l`ow i operacji. Dodatkowo, dla tak opisanych struktur, okre`slono
spos`ob transmisji sieciowej, poprzez kodowanie wed`lug zasad przyj`etych
w standardzie BER (Basic Encoding Rules).
Formalny j`ezyk ASN.1 zosta`l zdefiniowany w roku 1987, jego wyczerpuj`acy
opis zawarty jest w [ASN1].


Pomimo, `xe podstawowym za`lo`xeniem przy`swiecaj`acym tw`orcom 
standardu by`lo opracowanie `swiatowej `"ksi`a`xki adresowej", 
X.500 dopuszcza przechowywanie w bazie danych najzupe`lniej dowolnych typ`ow, 
np.\ zbior`ow dokument`ow, publikacji, zdj`e`c, czy informacji o zasobach 
programowych i sprz`etowych.


Standard X.500 zosta`l opublikowany w 1988 roku, a pod koniec roku 1994
oczekiwana jest publikacja nowej jego edycji. Zmieniony standard (nazywany
X.500 --- wersja 1993) znacznie rozszerza definicj`e z roku 1988, mi`edzy
innymi o elementy maj`ace bardzo istotny wp`lyw na efektywno`s`c dzia`lania
bazy. Standard 1993 zosta`l formalnie opisany za pomoc`a nowej edycji j`ezyka
ASN.1, opublikowanej w 1993 roku.

W niniejszym raporcie bazujemy na wersji X.500 z roku 1988 oraz jej 
rozszerzeniach wprowadzonych przez eksploatowan`a w Polsce implementacj`e 
tego standardu zwan`a QUIPU, b`ed`ac`a cz`e`sci`a pakietu ISODE\footnote{Patrz
cze`s`c \ref{ISODE}}. 
Nale`xy oczekiwa`c, `xe jeszcze przez d`lu`xszy czas dominowa`c b`ed`a 
implementacje tej w`la`snie wersji standardu. 
Przewidujemy, `xe po ukazaniu si`e nowej wersji niezb`edna 
b`edzie konfrontacja naszych przemy`sle`n i wynik`ow bada`n
z nowymi ustaleniami.

X.500 jest baz`a `"obiektow`a".
Obiekty (entries) przechowywane w bazie X.500 definiowane s`a w oparciu o
poj`ecie klasy. Definiuje si`e klasy podstawowe, a nast`epnie ich podklasy.
Podklasy dziedzicz`a konieczne i opcjonalne atrybuty swojej nadklasy,
wprowadzaj`ac przy tym w`lasne rozszerzenia, specyficzne dla opisywanej
grupy obiekt`ow. Bardzo cz`esto stosowane jest
tworzenie nowej podklasy w postaci  przekroju kilku klas
wyj`sciowych. W ten spos`ob klasa obiekt`ow identyfikuje rodzin`e obiekt`ow
o wsp`olnej charakterystyce, a ka`xdy obiekt bazy X.500 musi nale`xe`c
co najmniej do jednej klasy. Opis konkretnego obiektu dokonywany jest
poprzez okre`slenie odpowiednich atrybut`ow. Atrybut sk`lada si`e z typu,
identyfikuj`acego obiekt (OID --- object identifier) i zbioru warto`sci.
Atrybuty obiekt`ow musz`a zachowywa`c okre`slone regu`ly
syntaktyczne, kt`ore s`a przetwarzane zgodnie ze zdefiniowanymi dla nich
metodami. Obiekty rozr`o`xniane s`a poprzez swoje jednoznaczne nazwy
(Distinguished Names), zaleca si`e takie dobieranie nazw, by dotarcie
do szukanej informacji by`lo proste i samonarzucaj`ace si`e. 
Wi`ekszo`s`c typ`ow atrybut`ow dopuszcza nadawanie kilku warto`sci, sprzyja
to opisywaniu obiektu na wiele sposob`ow, satysfakcjonuj`ac r`o`xnych
odbiorc`ow. 



Ta obiektowo`s`c bazy X.500 w po`l`aczeniu z sieciowym modelem przypomina bardzo
model funkcyjny Bunemana-Frankela opisany w [M-R]. Struktura sieciowa
X.500  jest
w zasadzie `sci`sle hierarchiczna (drzewiasta), dopuszcza jednak odsy`lacze
(aliasy) komplikuj`ace struktur`e i maj`ace istotny wp`lyw na efektywno`s`c
systemu. 

Podstawowym za`lo`xeniem X.500 jest rozproszenie systemu i ogromny docelowy
rozmiar bazy. W pe`lni u`xyteczny system oparty o X.500 powinien posiada`c
tysi`ace w`ez`l`ow w ka`xdym kraju i w skali `swiata miliardy obiekt`ow. 

\subsection{Specyfika bazy X.500}
Jak wspomnieli`smy powy`xej, X.500 zdefinowano przede wszystkim dla cel`ow
szeroko rozumianej informacji adresowej. Zosta`la ona zaprojektowana z my`sl`a
o aplikacjach i procesach zarz`adzania OSI oraz dla potrzeb us`lug
telekomunikacyjnych. Nie by`lo zamiarem tw`orc`ow standardu X.500 utworzenie
modelu bazy uniwersalnej, og`olnego u`xytku, w pe`lni niezawodnej i sp`ojnej.
Fakt ten ma istotny wp`lyw zar`owno
na sam standard, jego implementacje jak i funkcjonuj`ace systemy.
Podstawowe implikacje takiego podej`scia to:
\begin{itemize}
\item Konieczno`s`c przechowywania danych w spos`ob u`xyteczny, zar`owno przy
dost`epie wewn`atrz jednego kraju jak i z zewn`atrz; istotn`a cech`a bazy X.500
jest `"przyjazne" nazewnictwo obiekt`ow, maj`ace na celu uproszczenie wyszukiwania
konkretnych danych.

\item Mo`xliwo`s`c stosowania lokalnych rozszerze`n klas obiekt`ow, zar`owno na
poziomie kraju jak i instytucji w celu dodefiniowania cech obiekt`ow.

\item Tworzenie drzewa informacji zgodnego z naturaln`a struktur`a
admi\-nis\-tra\-cyjn`a `swiata.

\item Odporno`s`c na wsp`o`lprac`e r`o`xnorodnych implementacji standardu 
oraz na lokalne ustalenia co do sposobu administrowania baz`a.

\item Za`lo`xenie znacznej przewagi operacji odczytu nad operacjami
modyfikacji bazy i dopuszczenie do czasowych niekonsystencji pomi`edzy
kolejnymi replikacjami fragment`ow rozproszonej bazy danych.
\end{itemize}

\subsection{Implementacja ISODE}\label{ISODE}
ISODE (ISO Development Environment) jest zespo`lem bibliotek i program`ow
jezyka C implementuj`acych hierarchiczny model protoko`l`ow komunikacyjnych 
OSI. Pakiet ten dostarcza niezb`ednych narz`edzi do budowania aplikacji OSI,
bazuj`acych zar`owno na typowych sieciach OSI, jak i na sieciach Internetowych
--- TCP/IP. Pocz`atkowo oprogramowanie to rozwijane by`lo w celach badawczych,
zmierzaj`acych do testowego tworzenia aplikacji OSI, docelowo obejmuje 
implementacje podstawowych us`lug sieciowych, eksploatowanych w wielu
mi`edzynarodowych programach pilotowych.
QUIPU jest implementacj`a standardu X.500 (1988) w ramach ISODE.
Poza tym ISODE zawiera
implementacj`e us`lugi poczty elektronicznej (MHS --- Message Handling
System), wirtualnego terminala (VT --- Virtual Terminal), transferu plik`ow 
(FTAM --- File Transfer Access and Management), a tak`xe us`lugi zarz`adzania
sieciami (SNMP --- Simple Network Management Protocol --- to zastosowanie
nie bazuje na protokole OSI).
Oprogramowanie QUIPU sta`lo si`e podstaw`a dla uruchomienia w `srodowiskach
akademickich pilotowych projekt`ow us`lugi X.500 (PARADISE w Europie i White
Pages w Ameryce P`o`lnocnej). Ten funkcjonuj`acy system X.500 Directory,
obejmuj`acy r`ownie`x Polsk`e, jest aren`a do`swiadczaln`a dla standardu i 
by`l podstaw`a dla rozwoju jego nowej wersji. 
Nasze do`swiadczenia z X.500 pochodz`a z udzia`lu w projekcie PARADISE, w 
kt`orym uczestniczymy od po`lowy 1992 roku.

\subsection{Por`ownanie z DNS}
X.500 jako us`luga sieciowa jest z regu`ly por`ownywana z DNS (Domain Name
Service) --- systemem zarz`adzaj`acym baz`a informacji o adresach sieciowych,
opisanym w [DNS].
Tendencja do takiego por`ownania jest naturalna, jako `xe DNS jest podstaw`a
systemu 
dostarczania poczty elektronicznej w Internecie, a X.500 ma sta`c si`e jego
odpowiednikiem dla systemu poczty X.400. DNS, tak jak X.500, jest
rozproszon`a baz`a danych o strukturze hierarchicznej, podobnie jak w
przypadku X.500 dopuszcza si`e czasowe niekonsystencje danych. 
W tym miejscu ko`ncz`a si`e jednak podobie`nstwa. 
Podstawowymi r`o`xnicami w zakresie za`lo`xe`n funkcjonalnych s`a:
\begin{enumerate}
\item Spos`ob przechowywania danych.

\item Obiektowo`s`c i rozszerzalno`s`c X.500 w por`ownaniu ze `sci`sle narzucon`a
struktur`a rekord`ow DNS.

\item Oparcie X.500 o standard w przeciwie`nstwie do tworzenia DNS {\em de
facto} na bazie jednej aplikacji (BIND --- Berkeley Internet Name Domain
system). 

\item Ograniczenie funkcjonalno`sci DNS do operacji odczytu ---
{\bf read} i {\bf list}, bez mo`xliwo`sci przeszukiwania --- {\bf search}.

\item Brak wbudowanych w system mechanizm`ow aktualizacji danych.

\end{enumerate}
W zakresie funkcjonuj`acych s`lu`xb r`o`xnica polega na tym, `xe DNS stanowi
pe`ln`a baz`e danych, umo`xliwiaj`ac`a przesy`lanie poczty elektronicznej,
podczas gdy istniej`aca baza X.500 jast dalece niekompletna. Nale`xy przy
tym jednak zauwa`xy`c, ze DNS pozwala na realizacj`e `l`aczno`sci komputerowej
pod warunkiem, `xe nadawca wiadomo`sci zna dok`ladne dane adresata, podczas
gdy X.500 pozwala odszuka`c konkretne dane na podstawie przybli`xonych.
Podobie`nstwa DNS i X.500 w zakresie technologii oraz zastosowania sk`laniaj`a
do po`l`aczenia obu us`lug. Poniewa`x dane DNS mo`xna bez trudu uczyni`c 
podzbiorem informacji
zawartych w X.500, podejmowane s`a prace zmierzaj`ace do powi`azania obu 
system`ow ([HK91a]). Punktem wyj`sciowym do tego typu dzia`la`n jest 
adaptacja bazy X.500 do przyjmowania danych pochodz`acych z DNS.
W tym celu zdefiniowano rozszerzenia standardu X.500, umo\-`xli\-wia\-j`a\-ce 
wprowadzanie danych specyficznych dla DNS: m.in. przypisanie
odpowiednim obiektom atrybut`ow okre`slaj`acych nazw`e domeny adresowej
i zawarto`s`c typowego rekordu DNS. 



\section{Elementy maj`ace wp`lyw na efektywno`s`c rozproszonej bazy danych}
Efektywno`s`c dzia`lania bazy danych zale`xy od wielu sk`ladnik`ow, 
w przypadku baz rozproszonych ich ilo`s`c  wyra`znie
wzrasta ze wzgl`edu na r`o`xnorodne i na og`o`l bardzo rozleg`le `srodowisko
eksploatacji. 

Podstaw`a zrozumienia dzia`lania bazy rozproszonej i czynnik`ow mog`acych
wp`lywa`c na jej dzia`lanie jest poj`ecie {\em modelu funkcjonalnego}.
W jego zakresie okre`sla si`e spos`ob wsp`o`ldzia`lania element`ow systemu.

Rozproszona baza danych to fizycznie zas`ob informacji, sk`ladaj`acej si`e 
ze zbior`ow rezyduj`acych na wielu komputerach, bed`acy, z logicznego punktu
widzenia, sp`ojn`a ca`lo`sci`a. W pe`lni funkcjonalna baza 
rozproszona zapewnia niezawodny dost`ep do informacji z dowolnego miejsca. 
W przypadku, gdy istnieje konieczno`s`c dzielenia zasob`ow danych,
najkorzystniejszym rozwi`azaniem jest model rozproszony, wielou`xytkowy.
Charakteryzuje si`e on tym, `xe dane i aplikacje rezyduj`a na wielu
serwerach.
%Dodatkowo ka`xdy serwer posiada umiej`etno`s`c dost`epu do
%dzielonych danych poprzez tzw.\ zarz`adc`e transakcjami (TM --- transaction
%manager), kt`ory analizuje zlecenia i jest odpowiedzialny za ich wykonanie.
Kluczowym zagadnieniem w takim modelu funkcjonalnym jest zapewnienie
szybkiego i niezawodnego dost`epu do danych, co wi`a`xe si`e z 
nast`epuj`acymi wymogami:

\begin {itemize}
\item konieczno`scia utrzymywania w ramach serwer`ow aktualnej informacji 
o rozmieszczeniu poszczeg`olnych komponent`ow danych --- s`lu`x`a do tego
specjalne systemowe katalogi --- spos`ob ich realizacji i aktualno`s`c danych
decyduj`a w du`xej mierze o efektywno`sci systemu;

\item w`la`sciw`a synchronizacj`a przep`lywu danych pomi`edzy serwerami,
czyli prawi\-d`lo\-w`a obs`lug`a wszelkich operacji rozproszonych, dzi`eki
czemu eliminowane s`a sytuacje, w kt`orych realizacja poszczeg`olnych
operacji ko`nczy si`e niepowodzeniem, czy prowadzi do zap`etlenia systemu.
\end {itemize}

Opis modelu funkcjonalnego bazy X.500 zamieszczamy w cz`e`sci \ref{efekt}.


Poni`xej przedstawiamy podstawowe czynniki, kt`ore uznali`smy za 
najistotniejsze z punktu widzenia bada`n jako`sci operacyjnej 
rozproszonych baz danych.


\begin{enumerate}

\item {\bf Stopie`n rozproszenia. }  
\begin{enumerate}
\item Op`o`znienia sieciowe. W rozleg`lym systemie sieciowym
rozproszenie bazy wprowadza oczywiste op`o`znienia wynikajace z
niedoskona`lo`sci po`l`acze`n. 

\item Czas reakcji serwera.
Innym, zauwa`xalnym efektem jest r`ownie`x czas
pierwszej reakcji pojedynczego serwera --- im wieksze rozproszenie, tym
wieksze prawdopodobie`nstwo odwo`lywania si`e do serwer`ow pozostaj`acych w
stanie u`spienia. 
Oczywiste jest, `xe rozproszenie bazy zmniejsza obj`eto`s`c danych w 
pojedynczych serwerach, a wi`ec mamy tu do czynienia z dwoma przeciwnie
pracuj`acyni czynnikami.

\item Wp`lyw obci`a`xenia na czas reakcji serwera. W pewnym zakresie wzrost
obcia`xenia mo`xe mie`c dodatni wp`lyw na `sredni czas reakcji serwera
(zmniejszenie ilo`sci okres`ow u`spienia), nadmierne obcia`xenie wp`lywa
natomiast niekorzystnie na efektywno`s`c. 
\end{enumerate}

\item {\bf Zgodno`s`c systemu serwer`ow z logik`a uk`ladu bazy. }
Nasz`a analiz`e ograniczamy do przyk`ladu bazy hierarchicznej, jako `xe 
z tak`a struktur`a mamy do czynienia w systemie X.500.
Baza hierarchiczna odwzorowuje przedstawian`a rzeczywisto`s`c w postaci drzewa.
To jakie fragmenty drzewa b`ed`a przechowywane w ramach pojedynczych
serwer`ow ma istotny wp`lyw na czas reakcji systemu. Przy projektowaniu
systemu serwer`ow trzeba bra`c pod uwag`e najbardziej prawdopodobne zapytania
i tak dobiera`c rozproszenie danych, aby minimalizowa`c ilo`s`c niezb`ednych 
po`l`acze`n sieciowych. 

\item{\bf Stosowanie odsy`laczy (alias`ow). }Odsy`lacze pozwalaj`a na
wielokrotne wy\-st`e\-po\-wa\-nie tego samego obiektu w r`o`xnych miejscach hierarchii
lub pod r`o`xnymi nazwami. System taki zapewnia konsystencj`e bazy i
jest absolutnie niezb`edny, wymaga jednak niezawodnego algorytmu
realizuj`acego odwzorowanie aliasu na w`la`sciw`a nazw`e obiektu.


\item{\bf Replikacja danych. }Nadzwyczaj wa`xnym elementem, z punktu widzenia
sprawno`sci, jest stosowanie replikacji danych, tj.\ kopiowanie
fragment`ow zasob`ow informacji i przechowywanie ich na wielu serwerach.
Mo`xe to ogranicza`c ilo`s`c niezb`ednych po`l`acze`n sieciowych, 
jak i podwy`xsza`c niezawodno`s`c dzia`lania bazy (w przypadku niesprawno`sci 
pojedynczych serwer`ow). 


\item {\bf Sprawno`s`c poszczeg`olnych serwer`ow. }Czynnik ten jest oczywisty
i musi by`c brany pod uwag`e w wielu sytuacjach --- niecelowe jest na
przyk`lad replikowanie znacznych zbior`ow danych z serwer`ow szybkich na wolne,
gdy`x doprowadzi to do generalnego spowolnienia dzia`lania serwera oraz do
prowadzenia przeszuka`n na wolnym  serwerze replikuj`acym, zamiast na
szybkim podstawowym.  Replikacja taka mo`xe by`c jednak uzasadniona, gdy
po`l`aczenie z serwerem podstawowym jest czasoch`lonne lub zawodne. 

\item {\bf Algorytmy generowania po`l`acze`n. }W przypadku, gdy potrzebna
informacja jest niedost`epna na bie`x`acym serwerze, konieczne jest wykonanie
po`l`aczenia sieciowego z serwerem, kt`ory informacj`e tak`a posiada. System
zarz`adzaj`acy baz`a danych musi w`owczas zrealizowa`c po`l`aczenie
mo`xliwie optymalne, wybieraj`ac serwer o najwy`xszej jako`sci
operacyjnej.  Generowanie niew`la`sciwych po`l`acze`n mo`xe doprowadzi`c
baz`e do niemal ca`lkowitego zastoju. 


\item {\bf Stosowanie standardowych zapyta`n. }Kontakt z typow`a baz`a danych
realizowany jest zawsze za pomoc`a interfejsu u`xytkownika. 
Projektant takiego interfejsu musi zna`c specyfik`e bazy i przewidywa`c,
w jaki spos`ob b`edzie wykorzystywana. Poniewa`x tego typu zbiory informacji
s`a w zdecydowanej wi`ekszo`sci nastawione na operacje przeszukiwania,
nale`xy zdawa`c sobie spraw`e z tego, jakiego typu zapytania s`a
optymalne i tylko takie oferowa`c u`xytkownikowi. 


\item {\bf Dok`ladno`s`c dopasowywania do wzorc`ow. }Jedn`a z wa`xnych cech
bazy danych jest mo`xliwo`s`c wyszukiwania w sytuacji, kiedy dane 
wej`sciowe s`a niedok`ladne. 
W takim przypadku baza powinna wygenerowa`c list`e
przybli`xonych trafie`n. Dob`or algorytmu dopasowywania przybli`xonego jest
nadzwyczaj istotny, jako ze mo`xe wydatnie wp`lyn`a`c na czas dost`epu do
danych, a jednocze`snie decyduje o wielko`sci odbieranej listy przybli`xe`n. 
Zbyt lu`zno, lub b`l`ednie funkcjonuj`ace przybli`xenia wprowadzaj`a do 
wynik`ow znaczny szum informacyjny, utrudniaj`ac i przed`lu`xaj`ac czas 
pracy z baz`a.

\item {\bf Indeksowanie. }Indeksowanie bazy wp`lywa pozytywnie na czas
przeszukiwa`n, ale r`ownocze`snie znacznie powi`eksza obszar pami`eci potrzebny
do przechowania danych istotne jest zatem aby stosowa`c ten mechanizm w
spos`ob optymalny.

\end{enumerate}


\section{Czynniki efektywno`sciowe w bazie X.500 i mo`xliwo`s`c
sterowania jako`sci`a operacyjn`a}\label{efekt}


Po okre`sleniu element`ow, kt`ore, naszym zdaniem, maj`a najistotniejszy
wp`lyw na ostateczn`a jako`s`c us`lug dost`epu do bazy rozproszonej,
poni`xej, odwo`luj`ac si`e do wymienionych czynnik`ow, analizujemy ich
specyfik`e w bazie X.500 Directory. Jednocze`snie przedstawiamy
elementy sterowania baz`a QUIPU udost`epnione obecnie ka`xdemu administratorowi.
Pomimo, `xe dokumentacja oprogramowania ([QUIPU]) opisuje rol`e poszczeg`olnych
czynnik`ow, nie przedstawia `xadnych ilo`sciowych zestawie`n
dotycz`acych wp`lywu rodzaju ustawie`n na efektywno`s`c operacyjn`a systemu.
Szczeg`o`lowe przetestowanie, a nast`epnie
stworzenie raportu przed\-sta\-wia\-j`a\-ce\-go optymalne ustawienia b`edzie
ostatecznym celem prowadzonych przez nas prac.

Baza X.500 sk`lada si`e z szeregu serwer`ow wsp`o`lpracuj`acych ze sob`a za 
pomoc`a ustalonych protoko`l`ow. Ka`xdy serwer jest jednak w znacznym stopniu
autonomiczny co do sposobu obs`lugi danych, generowania zapyta`n, replikacji
danych itp.
Jak ju`x wspomniano, standard 1988 nie precyzuje zupe`lnie dzia`lania bazy 
w tym zakresie, implementacja QUIPU posiada szereg pozastandardowych metod
sterowania. Nowy standard 1993 zosta`l rozbudowany o wiele element`ow
wp`lywaj`acych na wsp`o`ldzia`lanie serwer`ow, ale jak na razie nie jest
on opublikowany w wersji ko`ncowej i z pewno`sci`a, ze wzgl`edu na spor`a
ilo`s`c modyfikacji, nie zostanie szybko w pe`lni zaimplementowany. 


Na wst`epie naszkicujemy podstawy modelu funkcjonalnego  X.500 Directory. 

Informacja przechowywana w bazie uporz`adkowana jest w struktur`e drzewa
(DIT --- Directory Information Tree)
i jest podzielona na fragmenty, tzw. `"poddrzewa", zarz`adzane przez 
serwery zwane DSA (Directory System Agent), wsp`o`lpracuj`ace ze sob`a
w celu wymiany informacji.
Dost`ep do bazy danych nast`epuje poprzez wybrany interfejs u`xytkowy, zwany
DUA (Directory User Agent), kt`ory w imieniu u`xytkownika komunikuje
si`e z DSA. Interakcja mi`edzy DUA i DSA odbywa si`e wed`lug prostej
zasady pytanie--odpowied`z. Poniewa`x dane wewn`atrz DIT s`a rozproszone,
na og`o`l pojedynczy serwer nie posiada informacji niezb`ednej do odpowiedzi
na zadane 
przez DUA zapytanie, musi natomiast potrafi`c  zidentyfikowa`c inne DSA,
zdolne, jego zdaniem, do wykonania zlecenia. 
Model funkcjonalny definiuje, w ramach interakcji pomi`edzy serwerami DSA,
operacje typu odes`lanie (referral) oraz `la`ncuchowanie (chaining).

Operacja odes`lania polega na wskazaniu adresu innego DSA, 
do kt`orego zaleca si`e przekazanie zapytania,
w gestii DUA pozostaje kontynuacja realizacji zlecenia.

Operacja `la`ncuchowania, to przekazanie otrzymanego zlecenia
innemu serwerowi DSA, kt`ory, w przypadku niemo`xliwo`sci odpowiedzi, 
b`edzie kontynuowa`c prac`e poprzez wykonanie operacji odes`lania lub
`la`ncuchowania. 
W takiej sytuacji DUA nie jest `swiadome tego, jak`a drog`e przebywa zlecenie.
W ramach `la`ncuchowania wyodr`ebniona jest operacja
rozg`laszania (multicasting), w tym przypadku DSA `l`aczy si`e jednocze`snie
z wieloma innymi serwerami i zadaje im to samo zapytanie, oczekuj`ac 
na pozytywn`a odpowied`z.

Opisany model funkcjonalny implikuje nast`epuj`ace wymagania, dotycz`ace
serwer`ow DSA:
\begin{itemize} 
\item mo`xliwo`s`c sprawdzenia, czy realizacja zlecenia mo`xe nast`api`c
w oparciu o lokalny zas`ob danych, 
\item je`xeli nie mo`xna zlecenia wykona`c lokalnie, 
umiej`etno`s`c identyfikacji DSA, kt`o\-re\-mu nale`xy je przekaza`c
i wyb`or optymalnego sposobu wsp`o`lpracy z innymi serwerami
(`la`ncuchowanie lub odes`lanie).
\end {itemize}

Wymienione elementy maj`a zasadniczy wp`lyw na efektywno`s`c dzia`lania
X.500 Directory. Wynika z nich, `xe zarz`adzaj`acy poddrzewem bazy X.500
serwer musi w ramach swoich danych posiada`c prawid`lowo skonstruowany
zas`ob bazy informacyjnej (knowledge) o innych DSA,
jest to realizowane przez umieszczenie odpowiednich odsy`laczy --- adres`ow
serwer`ow.
W sytuacji, gdy zlecenie nie mo`xe by`c zrealizowane lokalnie, a r`ownocze`snie
istnieje kilka serwer`ow zdolnych do wykonania zadania niezb`edny jest
dobrze funkcjonuj`acy system optymalnego wyboru serwera, do kt`orego
zostanie wys`lane zapytanie.

Przewidujemy przeprowadzenie szeregu test`ow i wyspecyfikowanie optymalnych
ustawie`n parametr`ow wp`lywaj`acych na spos`ob realizacji po`lacze`n
z innymi serwerami.

Patrz`ac na model funkcjonalny X.500 Directory nale`xy pami`eta`c, `xe 
jest to przyk`lad bazy, w
kt`orej operacje typu przeszukanie i odczyt maj`a wyra`znie wi`ekszy
priorytet od innych (jak np.\ modyfikacja). Spowodowane jest to
funkcjonowaniem aplikacji w konkretnej sytuacji, kiedy modyfikacje
dokonywane s`a stosunkowo rzadko, a dynamika zmian jest g`l`ownie uzale`xniona
od mobilno`sci w ramach organizacji zbieraj`acych dane, nie od dynamiki
sieci. Czas niezb`edny do aktualizacji w bazie nie by`l w za`lo`xeniach
tw`orc`ow standardu, elementem krytycznym. 

Por`ownajmy teraz przedstawione wcze`sniej elementy efektywno`sciowe ze
specyfik`a bazy QUIPU X.500.

\begin{enumerate}
\item {\bf Stopie`n rozproszenia. }Pomimo, `xe wydaje si`e 
oczywisty teoretyczny wp`lyw rozproszenia na dzia`lanie bazy,
konieczne jest przeprowadzenie szczeg`o`lowych test`ow na znacznych zbiorach
danych, aby okre`sli`c optymalny model rozproszenia. W tym celu przewidujemy
utworzenie szeregu przyk`ladowych konfiguracji serwer`ow, pracuj`acych 
na r`o`xnych poziomach drzewa informacji. 
Czas reakcji u`spionego serwera zale`xy od wielu czynnik`ow,
miedzy innymi od wielko`sci przechowywanej bazy.
Serwer w implementacji QUIPU przechowuje dane w pami`eci operacyjnej,
st`ad konieczno`s`c przeprowadzenia analizy wp`lywu wielko`sci bazy 
na szybko`s`c powrotu ze stanu u`spienia.
Problem rozproszenia w naturalny spos`ob `laczy si`e z realizacj`a
replikacji danych.
Decyzj`e co do replikacji okre`slonego fragmentu
drzewa podejmuje administrator serwera biorcy w porozumieniu z
administratorem serwera dawcy. Brakuje opisu algorytm`ow poruszania si`e po
zreplikowanym drzewie X.500, a co za tym idzie administratorzy
pozostawieni s`a samym sobie i mog`a podejmowa`c b`l`edne decyzje dotycz`ace
replikacji. Takie b`l`edy mog`a powodowa`c znaczne spowolnienie dost`epu do
fragment`ow drzewa informacji.


Narzucaj`ace si`e rozproszenie
danych b`edzie dawa`lo efekt pozytywny pod warunkiem, `xe nie  dojdzie do
d`lugich op`o`znie`n w sieci i wspomnianych powy`xej okres`ow u`spienia.

\item {\bf Zgodno`s`c systemu serwer`ow z logik`a uk`ladu bazy. }Fragmenty
drzewa informacji DIT rezyduj`ace na serwerach X.500 odzwierciedlaj`a
rzeczywisty podzia`l organizacyjny `swiata. Projektuj`ac podzia`l danych
nale`xy wyj`s`c naprzeciw najbardziej popularnym sposobom przeszukiwa`n
bazy i da`xy`c do realizowania wy`l`acznie niezb`enej ilo`sci po`l`acze`n
sieciowych. 
Istniej`a mi`edzynarodowe og`olne zalecenia dla administrator`ow DSA,
dotycz`ace tworzenia poddrzew bazy X.500 ([BKL]).
G`l`ownie k`ladzie si`e nacisk na minimalizowanie g`l`eboko`sci poddrzewa
(wielopoziomowe poddrzewo implikuje d`lugie nazwy obiekt`ow, kt`ore
staj`a si`e mniej naturalne, a przede wszystkim zmniejszaj`a
efektywno`s`c, w przypadku cz`estych operacji przeszukiwania).
Je`xeli w poddrzewie dominuje operacja odczytu, ilo`s`c poziom`ow nie
ma znacz`acego wp`lywu na jako`s`c us`lugi.
Jednocze`snie dane powinny zosta`c tak rozmieszczone, by upro`sci`c
wykonywanie bardzo cz`estej operacji przeszukiwania jednopoziomowego
(single--level search). Poniewa`x obiekty podporz`adkowanego bie`x`acemu,
kolejnego poziomu mog`a by`c zlokalizowane w r`o`xnych DSA, 
operacja ta wi`a`xe si`e na og`ol z konieczno`sci`a
kontaktu z wieloma serwerami. Aby temu zapobiec nale`xy stosowa`c 
odpowiedni`a replikacj`e danych. 

Jako przyk`lad wp`lywu rzeczywistego podzia`lu administracyjnego
na logik`e uk`ladu bazy mo`xna rozwa`xy`c system serwer`ow regionalnych
X.500. System taki przewiduje w zasadzie, `xe serwery regionalne
przechowuj`a dane o lokalnych instytucjach. W takiej sytuacji przeszukanie w
zakresie jednej instytucji odbywa`loby si`e na pojedynczym serwerze i by`loby
najbardziej efektywne. Jednocze`snie lokalni administratorzy bazy danych
maj`a najlepszy dost`ep do informacji. System taki nie uwzgl`ednia jednak`xe
istnienia du`xych instytucji o oddzia`lach rozproszonych w wielu regionach
kraju. W`l`aczenie takich instytucji do 
systemu serwer`ow regionalnych wymaga rozwa`xenia, czy bardziej typowe b`ed`a
przeszukania w ramach danej (rozproszonej) instytucji, czy te`x w ramach
konkretnego regionu.  W zale`xno`sci od odpowiedzi na to pytanie informacje
o instytucji nale`xy lokalizowa`c lub rozprasza`c. Do rozwa`xenia pozostaje
r`ownie`x odpowiedni  dla takiej sytuacji system replikacji danych.


\item{\bf Stosowanie odsy`laczy (alias`ow). }Aliasy 
pozwalaj`a na odwo`lywanie si`e do tego samego obiektu w r`o`xnych
miejscach bazy X.500, dzi`eki temu te same obiekty nie musz`a by`c
definiowane wielokrotnie, a drzewo informacji jest sp`ojne. 
Niestety, w implementacji QUIPU stosowanie odsy`laczy ma negatywny wp`lyw 
na sprawno`s`c algorytmu rozstrzygania nazwy obiektu (name resolution) oraz
znacz`aco obni`xa efektywno`s`c algorytmu przeszukania, 
zw`laszcza w sytuacji, gdy konieczne jest generowanie wielokrotnych 
po`l`acze`n sieciowych, czyli, gdy obiekt jest zdefiniowany
w  innym serwerze.

Administratorzy musz`a mie`c klarowne informacje o
tym jak aliasowanie wp`lywa na sprawno`s`c bazy, tak aby mogli podejmowa`c
trafne decyzje w momencie definiowania struktury swojego wycinka drzewa.

\item{\bf Replikacja danych. }Mechanizm replikacji 
nie zosta`l okre`slony w standardzie X.500 z 
roku 1988. Jego wprowadzenie jest jednak niezb`edne w celu uzyskania 
niezawodno`sci i efektywno`sci serwisu, na co wskazano w [HK91b].
Rozszerzenia standardu dotycz`ace replikacji i s`lu`xacych do tego
celu dodatkowych rozproszonych operacji zdefiniowane s`a w [HK91c]. 
Sta`ly si`e one podstaw`a do implementacji replikacji w oprogramowaniu QUIPU.

QUIPU dopuszcza trzy techniki replikacji:
\begin{itemize}

\item Pobieranie kopii wybranego fragmentu drzewa (shadowing) --- technika
ta jest stosowana w celu lokalnego przechowywania tych cz`e`sci bazy
X.500, do kt`orych przewiduje si`e cz`este odwo`lywanie poprzez
operacje przeszukiwania lub odczytu. Polega na `l`aczeniu si`e
serwera biorcy z serwerem dawc`a i wykonaniu
operacji transmisji bloku danych.

\item Automatyczn`a aktualizacj`e danych dotycz`acych wybranych,
specjalnych obiekt`ow bazy (spot-shadowing).
Podstawowa informacja (master copy) o takich obiektach jest 
wprawdzie trzymana w ramach opiekuj`acego si`e tym  fragmentem
poddrzewa serwera, jednak {\em de facto} danymi tymi zarz`adza inny DSA.
W celu aktualizacji serwer `l`aczy si`e z odpowiednim DSA
i dokonuje odczytu danych dotycz`acych konkretnego obiektu.
Przyk`ladem obiekt`ow podlegaj`acych tego typu replikacji
jest klasa {\tt quipuDSA}, definiuj`aca serwery X.500 w implementacji
QUIPU.

\item Czasowe utrzymywanie odebranych z innych serwer`ow danych
w `"pami`eci pod\-r`e\-cz\-nej" (caching). Nale`xy zwr`oci`c uwag`e na 
fakt, `xe ta technika replikacji danych jest stosowana zar`owno po
stronie serwera DSA, jak i po stronie interfejsu u`xytkowego DUA.
Z punktu widzenia serwera mo`xliwo`s`c korzystania z wcze`sniej
odebranych informacji implikuje konieczno`s`c dezaktualizacji
kopii danych po okre`slonym czasie, a tak`xe decydowania czy kopia
danych mo`xe zosta`c u`xyta do odpowiedzi na pytanie postawione
przez inny interfejs u`xytkowy.

\end {itemize}
Replikacja ma oczywiste czynniki uboczne:
\begin{itemize}
\item doprowadza do mo`xliwych czasowych niekonsystencji w bazie,
\item powieksza ilo`s`c danych przechowywanych na poszczeg`olnych serwerach.
\end{itemize}
Efektywno`s`c replikacji zale`xy zatem od doboru powielanej informacji tak,
aby dopasowa`c j`a do najbardziej prawdopodobnego stylu zapyta`n, nie
generuj`ac jednocze`snie nadmiernych ilo`sci danych.

Poniewa`x dane
replikowane niekoniecznie musz`a by`c pewne, w sytuacjach, gdy znalezienie
poprawnej odpowiedzi jest krytyczne, trzeba korzysta`c z danych
podstawowych, a nie kopii. W sytuacjach, gdy przewiduje si`e niezb`edno`s`c
pracy na danych pewnych, replikacja jest bezcelowa. 
Nale`xy podkre`sli`c, `xe korzystanie z danych niepewnych jest 
w wielu zastosowaniach dopuszczalne i nie prowadzi do utraty prawdziwej 
informacji.
Je`xeli mo`xliwa jest
p`o`zniejsza weryfikacja poprawno`sci odpowiedzi, nie jest przeciwwskazane 
podanie (jako pierwszego przybli`xenia) informacji niepe`lnej lub nawet b`l`ednej.
Np.\ informacja o routingu poczty otrzymana w celu dostarczenia konkretnego
listu zostanie zweryfikowana przez system nadawczy. B`l`ad przy
dostarczeniu listu wygeneruje odpowiedni`a informacj`e i b`edzie sygna`lem, `xe
konieczne jest odwo`lanie si`e do danych pewnych. W przypadkach baz rzadko
modyfikowanych, sytuacje takie s`a sporadyczne i jak najbardziej uzasadnione
jest godzenie si`e na takie pojedyncze `"awarie" systemu.


\item {\bf Sprawno`s`c poszczeg`olnych serwer`ow. }Czynnik ten jest 
de\-cy\-du\-j`a\-cy, gdy mamy do czynienia z baz`a rozproszon`a ---
korzystanie z us`lug serwer`ow zawodnych doprowadza do znacznego
spowolnienia pracy systemu.
Standard 1988 nie zawiera ustale`n odno`snie jako`sci operacyjnej serwer`ow
(QOS --- Quality of Service).
Atrybuty niezb`edne do wprowadzania takich informacji do bazy X.500
zosta`ly zdefiniowane w [BK91],
zalecan`a form`e zastosowania rozszerze`n standardu w implementacjach
X.500 opisano w [HK91d].

W celu kontrolowania jako`sci operacyjnej partner`ow obiekt re\-pre\-zen\-tu\-j`acy
w DIT serwer DSA mo`xe dodatkowo zosta`c opisany poprzez atrybut {\tt
DSAQuality}, w kt`orym okre`sla si`e stopie`n `swiadczonych us`lug
(eksperymentalny, us`luga pilotowa, pe`lny serwis).
Zosta`la r`ownie`x dodana mo`xliwo`s`c wyspecyfikowania jako`sci danych
umieszczonych w okre`slonym fragmencie drzewa, zar`owno z punktu widzenia
ich ilo`sci jak i jako`sci konkretnych atrybut`ow opisuj`acych obiekt.

Istniej`a ju`x pierwsze interfejsy u`xytkowe analizuj`ace jako`s`c serwisu.
W trakcie bada`n wydajno`sciowych X.500 zamierzamy przeprowadzi`c 
odpowiednie testy, g`l`ownie w celu sporz`adzenia wytycznych co do
ustawie`n atrybut`ow dla administrator`ow serwer`ow, ale tak`xe
by zebra`c do`swiadczenia niezb`edne do tworzenia interfejs`ow u`xytkowych
w pe`lni wykorzystuj`acych kontrol`e jako`sci serwisu.



 

\item {\bf Algorytmy generowania po`l`acze`n. }Dla uzyskania pe`lnej
funkcjonalno`sci bazy X.500 nale`xy prawid`lowo 
dobra`c algorytm wyboru serwera, predysponowanego do wykonania zadania,
kt`ore nie mo`xe zosta`c zrealizowane lokalnie.
Algorytm taki opiera si`e w implementacji QUIPU na utrzymywanej w ramach DSA 
informacji o jako`sci operacyjnej partner`ow oraz na odpowiednim doborze 
parametr`ow administracyjnych, daj`acych mo`xliwo`s`c okre`slenia sposobu 
interakcji pomi`edzy DSA i adres`ow preferowanych serwer`ow.
Czynnik ten ma r`ownie`x istotny wp`lyw na mechanizm replikacji danych.
Przewidujemy potrzeb`e analizy skuteczno`sci zrealizowanego algorytmu
i ewentualnej jego weryfikacji do lokalnych potrzeb.

\item {\bf Stosowanie standardowych zapyta`n. }W przypadku  X.500 specyfika bazy daje mo`xliwo`s`c przewidywania
najbardziej typowych zapyta`n i dostosowywania do nich uk`ladu samej bazy,
indeksowania itp. Istniej`a mo`xliwo`sci blokowania zapyta`n bardzo
czasoch`lonnych, np.\ z regu`ly zabrania sie standardowego przeszukiwania
drzewa w zakresie ca`lego kraju, jako `xe na og`o`l nios`loby to za sob`a
konieczno`s`c kolejnego uruchamiania wielu serwer`ow i, w konsekwencji,
d`lugiego czasu reakcji. 
Samo zabezpieczenie administracyjne bazy przed obci`a`xaj`acymi system
przeszukiwaniami nie jest wystarczaj`ace. 
Bardzo istotn`a rol`e odgrywa tu tw`orca interfejsu u`xytkownika,
kt`ory musi uwzgl`edni`c jakiego typu zapytania s`a obs`lugiwane szybko, 
a jakie wolno i stara`c si`e realizowa`c obs`lug`e optymalnie.


\item {\bf Dok`ladno`s`c dopasowywania do wzorc`ow. }Jest to bardzo istotna
cecha systemu, poprawnie skonstruowany algorytm 
dopasowywania przybli`xonego znacznie podnosi wydajno`s`c. 
R`o`xnorodne testy, na podstawie analizy informacji o przebiegu realizacji
operacji konkretnych przeszuka`n (zapisy typu {\tt log})
dadz`a obraz dzia`lania algorytmu w konkretnej implementacji QUIPU.
Wydaje si`e r`ownie`x niezb`edne zrozumienie zasady dzia`lania odpowiednich
algorytm`ow. G`l`ownie  uwagi wymaga algorytm SOUNDEX, 
odpowiedzialny za wyszukiwanie przybli`xone, realizowane w QUIPU dla potrzeb 
j`ezyka angielskiego i daj`ace w polskich warunkach niespodziewane 
rezultaty.


\item {\bf Indeksowanie. }Implementacja QUIPU dopuszcza mo`xliwo`s`c 
indeksowania wskazanego poddrzewa (subtree) lub jednego poziomu drzewa
(siblings) oraz optymalizowania przeszukiwa`n struktur danych w pami`eci 
wed`lug podanego klucza --- typu atrybutu.

Nale`xy pami`eta`c, `xe indeksowanie ponad miar`e mo`xe doprowadzi`c do
efektu odwrotnego ni`x zamierzony. Na celowo`s`c korzystania z indeksu wp`lywa
te`x to, jak wsp`o`lpracuje z nim konkretna aplikacja, istniej`a przypadki, w
kt`orych uszcze\-g`o\-`lo\-wie\-nie pytania mo`xe spowodowa`c, `xe zamiast korzytania z
indeksu baza przeprowadzi standardowe przeszukanie. 
Oznacza to, `xe
administrator bazy musi by`c w stanie przewiedzie`c, jakie zapytania s`a 
standardowo generowane i do nich dobra`c spos`ob indeksowania.
Decyzj`e o indeksowaniu bazy danych nale`xy podejmowa`c
na podstawie analizy cz`estotliwo`sci stosowania r`o`xnego rodzaju
przeszukiwa`n bazy (jednopoziomowe lub ca`lego poddrzewa) oraz typ`ow
atrybut`ow, wed`lug kt`orych przeszukiwania wyst`epuj`a.
Jak ju`x wspominali`smy nieodpowiednie indeksowanie
nie przyspiesza dzia`lania bazy, a nawet je spowalnia na skutek zwi`ekszenia
ilo`sci przechowywanych danych. R`ownie`x w tym zakresie potrzebne s`a
szczeg`o`lowe wytyczne co do optymalnych modeli.

\end{enumerate}




\section{Narz`edzia badania niezawodno`sci systemu X.500}

Przeprowadzenie testowania wp`lywu wymienionych powy`xej element`ow
ste\-ru\-j`a\-cych wymaga`c b`edzie tworzenia przyk`ladowych instalacji, w kt`orych
uwypuklone zostan`a odpowiednie specyficzne sk`ladowe bazy.
W ten spos`ob b`edzie mo`xna r`ownie`x zasymulowa`c wsp`o`lprac`e wi`ekszej
ilo`sci serwer`ow, umieszczonych na r`o`xnych poziomach drzewa informacji
X.500.
Konieczne b`edzie r`ownocze`snie stworzenie narz`edzi do badania 
zachowania bazy. 
Narz`edzia takie potrzebne s`a w instalacjach testowych, ale nale`xy 
pami`eta`c, `xe pewne metody monitorowania pracy bazy potrzebne s`a 
r`ownie`x w codziennej, docelowej eksploatacji serwisu X.500.

Obecnie w projekcie PARADISE stosuje sie monitorowanie serwer`ow krajowych
sieci X.500, narz`edzie do tego s`lu`x`ace nie jest jednak powszechnie
dost`epne, a na dodatek mocno niedoskona`le, jako `xe generuje jedynie
informacje na temat zachowania si`e bazy w ca`lo`sci, nie analizuj`ac przy tym
powod`ow ewentualnych awarii. Nie s`a na przyk`lad prowadzone statystyki
uwzgl`edniaj`ace wp`lyw awarii samej sieci Internet na baz`e X.500.
Utworzenie dobrego zestawu narz`edzi monitoruj`acych b`edzie jednym z 
cel`ow przysz`lych prac. 

Podobnie w przypadku generowania statystyk korzystania z bazy ---
istnieje oprogramowanie sporz`adzaj`ace raporty dla poszczeg`olnych serwer`ow,
brakuje natomiast systemu gromadz`acego statystyki dotycz`ace wiekszych
wycink`ow drzewa i odpowiednio prze\-twa\-rza\-j`a\-ce\-go tego typu dane.


\newpage



\section*{Bibliografia}
\begin{itemize}
\setlength{\labelwidth}{15mm}
\setlength{\itemindent}{5mm}
\def\makelabel#1{\hbox to \labelwidth{[#1]\hfill}}
\item[ASN1] D. Steedman, ASN.1 The Tutorial and Reference, 1990.

\item[BK91]  P. Barker and S.E. Kille. The COSINE and Internet X.500 schema, 
RFC 1274, University College London, November 1991.

\item[BKL] P. Barker, S. E. Kille, T. Langgenhager: Naming and Structuring
Guidelines for X.500 Directory Pilots, May 1994.

\item[DNS] P.V. Mockapetris, Domain names --- Concept and Facilities, RFC 1034,
November 1987;

\item[HK91a] S. E. Hardcastle-Kille, X.500 and Domains, RFC 1279, November 1991.

\item[HK91b] S. E. Hardcastle-Kille, Replication Requirements, RFC 1275, November 1991.

\item[HK91c] S. E. Hardcastle-Kille, Replication and distributed operation 
extentions to provide an Internet Directory using X.500, RFC 1276, November 1991.


\item[HK91d] S. E. Hardcastle-Kille, Handling QOS (Quality of service) in the
Directory, March 1991.

\item[PVM] P.V. Mockapetris, Domain names --- Implementation and Specification,
RFC 1035, November 1987;

\item[QUIPU] C.J. Robbins and S.E. Kille, The ISO Development Environment:
User's Manual, Volume 5: QUIPU, July 1992.

\item[ROSE] Marshall T. Rose, The Little Black Book: Mail
Bounding with OSI Directory Services, Prentice Hall, 1992.

\item[X500] Data Communication Networks: Directory, Recommendations X500-X.521,
CCITT, Fascile VIII.8 of Blue Book.
\end{itemize}

\end{document}

