\voffset-10mm
\hoffset-13mm
%wersja 5
\input epsf
\tolerance 500
\documentstyle[a4wide,11pt,polski,odstepy]{article}
%\documentstyle[a4wide,11pt,polski]{article}
\textwidth=16.5cm\textheight=24.5cm
\title{{\bf X.500 --- STANDARD I US`LUGI KATALOGOWE}\thanks{Prace wykonano w ramach dzia`lalno`sci statutowej NASK.}}

%\author{{\bf Maja G`orecka}\\[12pt]{\sl Og`olnouczelniany O`srodek Obliczeniowy}\\
%{\sl UMK Toru`n} \and {\bf Tomasz Wolniewicz}%
\author{{\bf Maja G`orecka \hspace{2cm}Tomasz Wolniewicz}%
\thanks{Adresy autor`ow: M.~G`orecka: Og`olnouczelniany O`srodek Obliczeniowy,
 UMK Toru`n, T.~Wolniewicz: Wydzia`l Matematyki i Informatyki, UMK Toru`n}
\\[5mm]{\sl Naukowa i Akademicka Sie`c Komputerowa}\\{\sl Bartycka 18, 00--716 Warszawa}%
\thanks{Autorzy pragn`a w tym miejscu podzi`ekowa`c 
 mgr.~in`x.~Jerzemu `Xenkiewiczowi, kt`ory z ramienia NASK koordynuje
prace w zakresie X.500, za kilkuletni`a wsp`o`lprac`e i wsparcie naszych
dzia`la`n. Panom prof.~Jerzemu Brzezi`nskiemu i dr~Tomaszowi Koszlajdzie
dziekujemy za pomoc w zakresie teorii baz danych i usp`ojnienie naszej
wiedzy.
Poparcie NASK  umo`xliwia`lo nam prowadzenie prac oraz branie udzia`lu  w
europejskich spotkaniach koordynacyjnych X.500}}

\date{}
\begin{document}
\maketitle
\section{Wst`ep}


Dynamicznie rosn`aca popularno`s`c sieci Internet poci`aga za sob`a
konie\-czno\-`s`c rozwoju nowych aplikacji w celu elastycznej adaptacji
oferowanych us`lug do potrzeb przeci`etnego u`xytkownika.

Masowa ilo`s`c informacji potencjalnie dost`epnej
w Internecie powinna by`c w spos`ob niezawodny dostarczana do 
u`xytkownika, niezale`xnie od miejsca jej rezydencji. 
Niezmiernie istotne jest wi`ec funkcjonowanie sieci rozproszonych
baz danych, kt`ore uproszcz`a odzyskanie
po`x`adanej informacji. W tym celu m.in.\ zosta`l zaimplementowany standard OSI ---
protok`o`l X.500, definuj`acy dost`ep do rozproszonej  bazy danych
(X.500 Directory).

Celem niniejszego artyku`lu jest przybli`xenie tematyki zwi`azanej z poj`eciem
X.500 Directory. Pomimo, `xe termin X.500 zaczyna si`e coraz
cz`e`sciej pojawia`c w opracowaniach zwi`azanych z Internetem, wielu
specjalist`ow zajmuj`acych si`e us`lugami sieciowymi ma jedynie pobie`xn`a wiedz`e
na ten temat. Prace prowadzone ostatnio w zakresie WHOIS++ mog`a by`c
odbierane jako atak na X.500, nie brakuje te`x g`los`ow krytyki pod adresem
samego standardu. Postaramy si`e poni`xej pokaza`c czym jest X.500, na ile
mo`xe by`c u`xyteczne, jaki jest jego zwi`azek z innymi us`lugami sieciowymi.

Przedstawiamy r`ownie`x w skr`ocie prace prowadzone w zakresie polskiego
pilotowego projektu X.500.

Na  zako`nczenie czytelnik znajdzie kr`otk`a
 informacje na temat rozszerze`n standardu
zawartych w jego nowej (nieopublikowanej jeszcze) wersji.

Du`xym problemem przy pisaniu o X.500 jest brak ustalonego s`lownictwa.
Pierwszym powa`xnym k`lopotem jest przet`lumaczenie samego s`lowa {\em Directory},
czy okre`slenia {\em Directory Services}. W wielu przypadkach terminu
{\em Directory} w og`ole nie t`lumaczymy, w innych stosujemy okre`slenia {\em
katalog}, czy {\em us`lugi katalogowe}.


\section{X.500 jako standard CCITT/ISO} % zmienic nazwe CCITT i dac odnosnik
Standard CCITT~X.500/ISO~9594 z 1988 roku definiuje rozproszon`a baz`e danych
prze\-zna\-czo\-n`a przede wszystkim dla cel`ow szeroko rozumianej informacji
adresowej. Na pierwszej stronie oficjalnego tekstu \cite{X.500}
czytamy: {\em Directory
udost`epnia us`lugi katalogowe wymagane przez aplikacje OSI, procesy
zarz`adzania standardu OSI, elementy innych warstw OSI oraz us`lugi
telekomunikacyjne. [\ldots] Directory nie jest pomy`slane jako baza
danych og`olnego przeznaczenia,
pomimo `xe mo`xe by`c tworzona w oparciu o takie systemy.
Na przyk`lad, zak`lada si`e, `xe podobnie jak dla katalog`ow
komunikacyjnych, cz`estotliwo`s`c `"zapyta`n" jest wyra`znie wy`xsza od cz`esto`sci
poprawek.} 


Standard opisuje:
\begin{itemize}
\item {\bf Model Bazy} (Directory Model), a w jego zakresie:
\begin{itemize}
\item {\bf Model funkcjonalny} --- okre`slenie zasad dzia`lania bazy --- sposobu
dost`epu, komunikacji mi`edzy klientem i serwerem oraz samymi serwerami,
\item {\bf Model organizacyjny} --- okre`slenie zasad zarz`adzania baz`a podzielon`a na
tzw.\ {\em Domeny Zarz`adzania} (Directory Management Domain --- DMD),
\end{itemize}
\item {\bf Model informacyjny} (Information Model)
--- okre`slenie odwzorowania opisywanej rzeczywisto`sci
na elementy bazy danych,
\item {\bf Model bezpiecze`nstwa} (Security Model) --- 
za`lo`xenia systemu autoryzacji dost`epu,
\item Okre`slenie protoko`l`ow komunikacji.
\end{itemize}

W dodatkach, nie b`ed`acych formalnie sk`ladow`a samego standardu, opisuje si`e
przy\-k`la\-do\-wy zestaw atrybut`ow i typ`ow obiekt`ow przechowywanych w X.500.
Ustalenia zawarte w dodatkach mia`ly na celu u`latwienie budowy 
sp`ojnych i wzajemnie kompatybilnych implementacji
w oparciu o jednolity schemat wymiany danych.

W ramach modelu informacyjnego okre`sla si`e, `xe rzeczywisto`s`c, przedstawiana
jako zbi`or obiekt`ow opisywanych atrybutami i nazywanych
Directory Information Base  (DIB), 
odwzorowywana
jest na drzewiast`a struktur`e o nazwie Directory Information Tree (DIT).
Podstawowymi elementami DIT s`a obiekty takie jak kraj, instytucja, jednostka
organizacyjna, jednostka geograficzna, osoba, ale mo`xe to by`c r`ownie`x
dokument, us`luga komputerowa itp.

Przyk`ladowy wycinek DIT mo`xe wygl`ada`c nast`epuj`aco:

\centerline{\epsfbox{dit.eps}}

Podstawowymi elementami modelu funkcjonalnego s`a {\bf serwery}
({\bf DSA} --- Directory System Agent) oraz oprogramowanie klienckie
({\bf DUA} --- Directory User Agent). Ka`xdy DSA `"panuje" nad pewnym wycinkiem
drzewa informacji. Sp`ojne fragmenty drzewa informacji nazywane s`a
kontekstami (Naming Context), w typowej sytuacji DSA za\-rz`a\-dza pojedynczym
kontekstem. Przyk`lady kontekst`ow pokazane s`a na rysunku poni`xej.

\centerline{\epsfbox{kontekst.eps}}


Ka`xdy DSA, z wyj`atkiem DSA najwy`xszego poziomu, musi zna`c metod`e dost`epu do
DSA zarz`adzaj`acego kontekstem bezpo`srednio powy`xej, jak r`ownie`x do DSA
za\-rz`a\-dza\-j`a\-cych kontekstami bezpo`srednio poni`xszymi. Taka organizacja bazy
pozwala na dost`ep do dowolnego fragmentu drzewa za pomoc`a jednej z dw`och
metod: {\bf odes`lania} (referral) --- przekazania informacji o kolejnym
DSA, kt`ory mo`xe by`c `"bli`xszy" poszukiwanej informacji, lub {\bf
tworzenia `la`ncuch`ow} (chaining) --- wykonania po`l`aczenia w imieniu pytaj`acego i
przekazania gotowej informacji. To, kt`ory wariant zostanie wybrany zale`xy
od paremetr`ow konfiguracyjnych, opcji zapytania, jak r`ownie`x mo`xliwo`sci
dokonania bezpo`sredniego po`l`aczenia przez pytaj`acego (w pewnych sytuacjach
DSA po`srednie mo`xe pe`lni`c rol`e pomostu pomi`edzy sieciami).

Ka`xdy obiekt wyst`epuj`acy w DIT jest jednoznacznie charakteryzowany przez
swoj`a {\bf Nazw`e Wyr`o`xnion`a} (Distinguished Name) sk`ladaj`ac`a si`e z ci`agu
nazw w`ez`l`ow ga`l`ezi drzewa DIT prowadz`acej do opisywanego obiektu.
Ostatni cz`lon DN nazywany jest {\bf Rela\-tyw\-n`a Nazw`a Wyr`o`xnion`a} (Relative
Distinguished Name), DN jest zatem ci`agiem RDN. Przy\-k`la\-do\-wo DN mo`xe
wygl`ada`c: 

\begin{verbatim}
         c=PL@o=Uniwersytet Mikolaja Kopernika@ou=Wladze@cn=Rektor
\end{verbatim}

Znak {\tt @} jest u`xywany do oddzielania RDN w ramach DN.

Obiekty bazy X.500 musz`a by`c okre`slonych typ`ow nazywanych po angielsku {\bf
Object Class}. Typ zawiera opis atrybut`ow, kt`ore dany obiekt musi posiada`c,
jak r`ownie`x tych, kt`ore s`a opcjonalne. Z atrybutami zwi`azane s`a ich typy.
W trakcie komunikacji pomi`edzy DSA zachodzi konieczno`s`c przekazywania
typ`ow obiekt`ow i warto`sci atrybut`ow. Atrybuty przekazywane s`a
jako pary  {\tt (nazwa atrybutu, warto`s`c atrybutu)}. Zar`owno typy obiekt`ow
jak i nazwy atrybut`ow oznaczane s`a jednoznacznymi identyfikatorami i te, a
nie nazwy, s`a w istocie przesy`lane w sieci
(wykorzystuje si`e w tym celu standard ASN.1 i zwiazanie z nim metody
kodowania BER). W przypadku zdefiniowania
lokalnych typ`ow, czy atrybut`ow, przyporz`adkowuje si`e im nowe
identyfikatory. W konsekwencji `"obce" DSA i DUA nie s`a w stanie tych
element`ow interpretowa`c. Przy zachowaniu zasady, `xe ka`xdy obiekt posiada
pewne atrybuty standardowe nie zachodzi obawa, `xe nie zostanie on w og`ole
odczytany, a r`ownocze`snie jednoznaczno`s`c identyfikator`ow gwarantuje, `xe
nieznane identyfikatory nigdy nie zostan`a zinterpretowane b`l`ednie.
Ta mo`xliwo`s`c rozszerzania jest wykorzystywana mi`edzy innymi przy
dostosowywaniu bazy do lokalnego j`ezyka, o czym piszemy w cz`e`sci
\ref{inter}.




\section{X.500 jako us`luga sieciowa}
%Projekt PARADISE/White pages
Sprawdzenie funkcjonalno`sci modelu opisanego w standardzie X.500 by`lo
niemo`xliwe bez uruchomienia pilotowej bazy danych o znacznym stopniu
rozproszenia i zauwa`xalnej zawarto`sci. W zwi`azku z tym w roku 1990
uruchomiono dwa r`ownoleg`le i wzajemnie skoordynowane projekty: White Pages w
USA i PARADISE w Europie Zachodniej. W ramach projekt`ow utworzono pilotowe
bazy danych w zakresie `srodowiska akademickiego. Finansowanie centralne
pozwala`lo na utrzymywanie serwera koordynuj`acego informacj`e o pierwszym
poziomie drzewa, stanowiska pomocy dla administrator`ow krajowych,
organizacj`e spotka`n administrator`ow. Udzia`l w projekcie by`l dobrowolny i
wolny od op`lat. Pod`l`aczanie kolejnych kraj`ow nast`epowa`lo po uruchomieniu w
danym kraju pierwszego serwera pe`lni`acego rol`e koordynuj`ac`a. Funkcjonowanie
bazy oparte by`lo niemal w ca`lo`sci o oprogramowanie ISODE/QUIPU
rozpowszechniane nieodp`latnie. 

Rozw`oj projektu by`l bardzo r`o`xny w r`o`xnych krajach.
W niekt`orych utworzono stosunkowo kompletne bazy o du`xym stopniu u`xyteczno`sci
(np.\ w Holandii doprowadzono do sytuacji, w kt`orej ka`xda
instytucja pod`l`aczona do
akademickiej sieci SurfNet prowadzi w`lasny serwis X.500). Niekt`ore
instytucje uruchomi`ly niezawodny serwis X.500 wykorzystywany bardzo
intensywnie do cel`ow lokalnych. W wielu krajach napotkano jednak na znaczne
k`lopoty (bardzo cz`esto natury formalnej) i tam X.500 jest bardzo ubogie.

Obecnie koordynacja projektu PARADISE zosta`la przej`eta przez DANTE i
prowadzona jest na niedok`ladnie jeszcze okre`slonych zasadach odp`latno`sci
kraj`ow cz`lonkowskich. DANTE stawia sobie za cel doprowadzenie do bardziej
sp`ojnego obrazu informacji w DIT i dostarczenie niezawodnego serwisu.

Koordynacja us`lugi takiej jak X.500 jest dosy`c specyficzna, sprawne
dzia`lanie bazy opiera si`e na wielu ustaleniach administracyjnych,
niekiedy pozastandardowych,
 i w zwi`a\-z\-ku z tym niezb`edne s`a, na przyk`lad, stosunkowo
cz`este zebrania koordynacyjne administrator`ow krajowych. Dzia`lalno`s`c ta
wzmaga si`e zw`laszcza obecnie, w obliczu przygotowa`n do wprowadzania nowego
standardu X.500. Fakt ten, jak r`ownie`x to, `xe implementacje X.500 s`a dosy`c
wymagaj`ace sprz`etowo oznacza, `xe X.500 jest stosunkowo drogie w eksploatacji. Do
wspomnianych koszt`ow dochodz`a te`x koszty utrzymania samej bazy danych, o
trudno`sciach z tym zwi`azanych piszemy w cz`e`sci \ref{admin}.
%Inne projekty (PTT)

Poza projektem PARADISE/White Pages spore znaczenie mo`xe mie`c plan kilku
europejskich PTT tworz`aczych program Eurascom.
Projekt ten ma zbada`c skuteczno`s`c X.500 jako
 bazy adresowo-telefonicznej dla cel`ow tych instytucji.   Za`lo`xenia i
funkcjonowanie projektu jest jednak utrzymywane w tajemnicy.


\subsection{Udzia`l Polski w programie PARADISE}
%pocz`atek
Polska przyst`api`la do projektu PARADISE w lecie 1992 roku uruchamiaj`ac
pierwszy serwer na UMK w Toruniu. Kr`otko potem patronat nad
polskim X.500 przej`a`l NASK. Dzia`lania pocz`atkowo ogranicza`ly si`e do
wprowadzenia niewielkiej ilo`sci danych, z czasem UMK umie\-`sci\-`lo sw`oj pe`lny
sk`lad osobowy.

W roku 1994 KBN przyzna`l dofinansowanie na uruchomienie pilotowej bazy
danych w wybranych o`srodkach w Polsce. W rezultacie mamy obecnie pi`e`c
aktywnych region`ow: Krak`ow, Pozna`n, Toru`n, Warszawa i Wroc`law. W ka`xdym z
nich dzia`la serwer regionalny utrzymuj`acy kompletn`a baz`e danych o
przynajmniej jednej reprezentatywnej uczelni regionu. Dodatkowo w ramach
wspomnianego dofinansowania pozyskano dane z MEN oraz O`srodka
Przetwarzania Informacji w Warszawie. Dane te pozwoli`ly na umieszczenie
informacji o znacznej cz`e`sci kadry naukowej ze stopniem naukowym doktora,
jak r`ownie`x o strukturze organizacyjnej polskich uczelni. W chwili obecnej
baza liczy ponad 50000 hase`l. Mamy nadziej`e, `xe mo`xliwe b`edzie zdobycie finansowania
pozwalaj`acego na utrzymanie  obecnych zasob`ow oraz obj`ecie zasi`egiem
projektu znacznie wi`ekszej liczby o`srodk`ow.

Od 1994 prowadzimy w ramach NASK prace badawczo-rozwojowe
dotycz`ace X.500. Obejmuj`a one ocen`e efektywno`sci rozproszonej bazy danych
oraz stosowanie znak`ow diakrytycznych w systemach baz danych X.500 Directory.


\subsection{Implementacje X.500}
X.500 okre`sla standard, wed`lug kt`orego producenci powinni tworzy`c swoje
oprogramowanie. Implementacji jest stosunkowo niewiele, ale zaczynaj`a si`e
pojawia`c w coraz wi`ekszej liczbie. Od dawna dost`epna by`la implementacja o
nazwie QUIPU stanowi`aca fragment pakietu ISODE. Oprogramowanie to by`lo
przez wiele lat oferowane bez `xadnych ogranicze`n. Obecnie na bazie ISODE
rozpowszechnia si`e dwa najwa`xniejsze produkty X.500 (wersja firmy NEXOR i
wersja ISODE Consortium). Od wielu lat dost`epny jest te`x produkt francuski
o nazwie Pizarro, w oparciu o kt`ory funkcjonuje francuski pilot.

So`sr`od innych  produkt`ow mo`xna wymieni`c: UCOM~X.500, DEC~X.500, DIR.X
itd. Pe`ln`a list`e mo`xna znale`z`c w RFC1632 \cite{rfc1632}.  


\section{X.500 w praktyce}
\subsection{Zalety i wady}
X.500 jako baza danych, w praktycznym zastosowaniu ma zar`owno zalety jak i
pewne wady. Nie ulega w`atpliwo`sci, `xe jedn`a z najwi`ekszych zalet X.500 jest
dostosowanie modelu informacyjnego do przechowywania struktury
organizacyjnej instytucji. Odwzorowanie jest ca`lkowicie naturalne i nie
wymaga od administratora `xadnego specjalnego modelowania.

Kolejn`a zalet`a jest `latwo`s`c lokalnego, dynamicznego modelowania struktury
przechowywanej informacji przy jednoczesnym zachowaniu sp`ojno`sci bazy w
zakresie mi`e\-dzy\-na\-ro\-do\-wym. Jest to mo`xliwe dzi`eki zastosowaniu drzewiastej
struktury identyfikator`ow, kt`ore przy\-po\-rz`a\-dko\-wy\-wa\-ne s`a wszelkim elementom
sk`ladowym konstrukcji bazy. Jak ju`x wspominali`smy elementami takimi s`a typy
przechowywanych obiekt`ow, nazwy atrybut`ow itp. Admninistratorzy lokalni mog`a
wzbogaca`c struktur`e na sw`oj w`lasny spos`ob; poza obszarem lokalnym ich
modyfikacje nie b`ed`a po prostu rozpoznawane, informacja o charakterze
uniwersalnym b`edzie jednak nadal skuteczna. Zasada, z kt`or`a si`e tutaj
spotykamy jest identyczna do stosowanej przy konstrukcji MIB dla SNMP (w
istocie w obu przypadkach stosuje si`e takie same identyfikatory).

Po stronie wad na og`o`l przytacza si`e powolny wzrost obj`eto`sci bazy,
por`ownuje si`e rozw`oj X.500 z lawinowym rozwojem {\it gophera} czy {\it WWW},
jak r`ownie`x z szybkim i niezawodnym dzia`lniem DNS. Bardzo interesuj`ace
pogl`ady na ten temat mo`xna znale`z`c w referacie \cite{Waugh2}, s`a one zgodne
z naszymi w`lasnymi do`swiadczeniami z pracy przy administrowaniu X.500.
 Zanim zacznie si`e na
powa`xnie rozwa`xa`c wspomniane por`ownania trzeba sobie zda`c spraw`e z kilku fakt`ow:
\begin{enumerate}
\item X.500 funkcjonuje przede wszystkim
 jako baza danych o osobach, oznacza to, 
`xe zbieranie danych musi by`c obarczone trudno`sciami prawnymi i
organizacyjnymi. Trudno`sci te napotka ka`xdy system, kt`ory b`edzie pr`obowa`l
zebra`c podobne dane.
\item {\it gopher} i {\it WWW} nie s`a bazami danych w sensie teorii takich system`ow,
s`a jedynie zbiorowiskiem
informacji, kt`or`a mo`xna przegl`ada`c, ale w ramach kt`orej bardzo trudno jest
cokolwiek wyszuka`c. S`lu`xby indeksuj`ace s`a bardzo niepe`lne. Informacja nie
ma `xadnej okre`slonej struktury.
\item DNS jest sprawnie funkcjonuj`acym systemem odwzorowywania nazw i
adres`ow na siebie. Ilo`s`c informacji, kt`or`a przechowuje jest stosunkowo
niewielka, nie zawiera `xadnych mechanizm`ow wyszukiwania i bardzo
ograniczone mechanizmy `"listingu". DNS jest ponadto absolutnie niezb`edny
do transportu poczty elektronicznej i z tego powodu ka`xdy administrator dba
o aktualno`s`c podstawowych danych. W przeciwie`nstwie do tego X.500 jest
us`lug`a dla `swiata zewn`etrznego i je`xeli u`xytkownicy nie zaczn`a domaga`c sie
sprawnego systemu informacji adresowej, przeci`etni administratorzy
system`ow komputerowych nie b`ed`a widzieli potrzeby utrzymywania tej bazy
jako jednego z priorytetowych zada`n.
\item Wielokrotnie podkre`slana z`lo`xono`s`c X.500 (zar`owno samego standardu
jak i pro\-to\-ko\-`lu) bierze si`e st`ad, `xe  u`xytkownicy maj`a bardzo
r`o`xnorodne wymagania dotycz`ace rodzaju wprowadzanych danych, stosowanych
zabezpiecze`n przed dost`epem, sposobu odwzorowywania struktury
organizacyjnej opisywanego `swiata na struktur`e bazy.
\item Tw`orcy WHOIS++, maj`a
do dyspozycji ogrom do`swiadcze`n zebranych przy implementacji X.500.
Do`swiadczenia takie pozwalaj`a stwierdzi`c jaki jest najbardziej typowy spos`ob
dost`epu do danych (na przyk`lad typowe s`a pr`oby wyszukowania pojedynczych
os`ob z poziomu kraju), jakiego typu narz`edzia nale`xy dostarcza`c tw`orcom
oprogramowania, aby u`latwi`c im tworzenie nowych produkt`ow w kr`otkim czasie,
jakie s`a najbardziej podstawowe trudno`sci w funkcjonowaniu takiego
rozproszonego systemu itp. Trzeba podkre`sli`c przy tym, `xe prace nad
tworzeniem WHOIS++ prowadzone s`a przy wsp`o`ludziale os`ob zajmuj`acych si`e
X.500.
\item X.500 (podobnie jak X.400) od pocz`atku tworzone by`lo z my`sl`a o
`swiecie komercyjnym, a nie akademickim. Firmy komercyjne maj`a zupe`lnie inne
podej`scie do us`lug sieciowych, wymagaj`a standard`ow, gwarancji,
zabezpiecze`n. Usuni`ecie takich ogranicze`n znacznie u`latwia szybkie
tworzenie produkt`ow, ale znacznie zmniejsza ich potencjalny zasi`eg.
\end{enumerate}

Grupy zaanga`xowane w prace zwi`azane z X.500 zdaj`a sobie spraw`e z faktu, `xe
technologia ta, mimo `xe rozwija`la si`e w spos`ob ci`ag`ly, nie nad`a`xa`la
za lawinowym wzrostem Internetu. W konsekwencji powsta`lo szereg
produkt`ow konkurencyjnych stanowi`acych podbudow`e dla {\it directory
service}, abstrahuj`acych od protoko`l`ow CCITT/OSI, cz`esto ba\-zu\-j`a\-cych
na kilku podstawowych technologiach w celu dostarczenia docelowej
us`lugi katalogowej.
G`l`owne powody stosunkowo ma`lej popularno`sci X.500 i jego
relatywnie wolnego rozwoju, to skomplikowana technologia, niska efektywno`s`c
implementacji dost`epnych nieodp`latnie, trudno`sci instalacyjne,
konfiguracyjne i eksploatacyjne, a tak`xe problemy zwi`azane z prywatno`sci`a
danych umieszczanych w bazie X.500. R`ownie istotn`a przyczyn`a wydaje
si`e by`c dominowanie spraw dotycz`acych protoko`l`ow i ignorowanie przez
d`lugi czas
efektu docelowego, kt`oremu X.500 ma s`lu`xy`c --- dostarczenia niezawodnej
us`lugi katalogowej.

Z drugiej strony, X.500 jest jedyn`a sp`ojn`a, jednolit`a, wielop`laszczyznow`a
technologi`a oferowan`a dla potrzeb {\it directory service} i jako taka,
szczeg`olnie w swoim nowym standardzie i po uwzgl`ednieniu dotychczasowych
do`swiadcze`n eksploatacji pilotowej,
wydaje si`e by`c znakomit`a podstaw`a do tworzenia uniwersalnej us`lugi,
dost`epnej  w r`o`xnorodnym `srodowisku sieciowym.
Wszystkie pozosta`le produkty X.500 zosta`ly rozwini`ete {\it ad hoc},
jako odzew na potrzeb`e szybkiego dostarczenia docelowej us`lugi.

Eksploatacja X.500 wskazuje, `xe jednym z podstawowych wymog`ow stawianym
bazie adresowej jest istnienie mo`xliwo`sci szybkiego wyszukiwania
os`ob poprzez podanie nazwiska, bez dok`ladnego okre`slenia organizacji.
Tego typu zapytania, przy obecnej infrastrukturze
rozproszonych serwer`ow X.500
wymagaj`a przegl`adania wielu poddrzew informacji, co jest
bardzo nieefektywne.
W celu zwi`ekszenia funkcjonalno`sci X.500 zamierza si`e wprowadzi`c
koncepcj`e serwer`ow indeksuj`acych, kt`ore b`ed`a pe`lni`c podobn`a rol`e
jak {\it archie} dla us`lugi FTP, czy {\it Veronica} dla przestrzeni
informacyjnej {\it gophera}. Serwery takie b`ed`a gromadzi`ly nazwy
hase`l okre`slonych DSA, mog`a to by`c oczywi`scie has`la dotycz`ace
obiekt`ow umiejscowionych w r`o`xnych, odseparowanych od siebie miejscach
drzewa danych X.500. Przewiduje si`e, `xe konieczne b`ed`a pewne
modyfikacje w sposobie przechowywania informacji o odwo`laniach do
poszczeg`olnych obszar`ow, tak, by mo`xna okre`sli`c zakres
przeszukiwania. Indeksowe DSA maj`a istnie`c w ramach drzewa DIT, ale
nie b`ed`a jawnie widoczne. Szczeg`o`lowo proponowan`a koncepcj`e 
om`owiono w \cite{IndexDSA}.

Konieczno`s`c wprowadzenia indeksowych DSA jest niezaprzeczalna.
Jednocze`snie narzuca si`e pytanie dlaczego dopiero teraz.
Dla WHOIS++ technologia serwer`ow indeksowych by`la fundamentem
samego projektu.
Aby zrozumie`c przyczyny takiej sytuacji nale`xy u`swiadomi`c sobie, `xe
w standardzie '88 nie zdefiniowano zasad replikacji. Przybli`xony
protok`o`l tego typu operacji zosta`l okre`slony dla potrzeb
Internetu w RFC1276 \cite{rfc1276}, jednak brakuje w nim element`ow dotycz`acych
replikacji poddrzew oraz mo`xliwo`sci tzw.\ stopniowej aktualizacji
({\it incremental update}), a poza tym nie zosta`l on powszechnie
zaimplementowany. Standard '93 zawiera definicj`e operacji replikacji,
co rozwi`azuje wiele technicznych problem`ow przy tworzeniu indeksowych
DSA.

\subsection{Administrowanie}\label{admin}

Kilka lat pracy przy rozwoju X.500 pozwoli`lo na zebranie do`swiadcze`n
zwi`azanych z obs`lug`a samych danych.

Na pocz`atek nale`xy podkre`sli`c, `xe rozr`o`xnienia wymaga administrowanie samym
systemem od administrowania danymi. Oba zadania s`a niezmiernie wa`xne, ale
dosy`c r`o`xne w zakresie obowi`azk`ow. W pocz`atkowej fazie implementowania bazy
zadania te s`a szczeg`olnie blisko zwi`azane ze sob`a, jako `xe naturalnym
elementem administrowania systemem jest tworzenie narz`edzi programowych, a
przy przetwarzaniu danych z najr`o`xnorodniejszych `zrode`l takiej pracy jest
du`xo. Po utworzeniu systemu narz`edzi i uruchomieniu stabilnego systemu
zbierania informacji, do wykonania pozostaje regularne aktualizowanie
danych, co jest czynno`sci`a stosunkowo ma`lo interesuj`ac`a. Trzeba zwraca`c na
to uwag`e, aby nie zatrudnia`c do takich zada`n os`ob zbyt wysoko
wykwalifikowanych. 

Kolejn`a spraw`a jest fakt, `xe pozornie ilo`sciowa jedynie r`o`xnica pomi`edzy
administrowaniem baz`a eksperymentaln`a i `"produkcyjn`a", jest w istocie
r`o`xnic`a jako`sciow`a. To, co w ma`lej bazie jest do wykonania metodami
ingerencji w ka`xde has`lo, przy bazie du`xej wymaga narz`edzi. Du`xa baza
przedstawia informacje dotycz`ace wielu jednostek, kt`orym nie jest oboj`etnie
jak te informacje s`a przedstawione. Dobrym przyk`ladem takich problem`ow mo`xe
by`c przetwarzanie danych uzyskanych z O`srodka Przetwarzania Informacji
(OPI). Na poz`or sprawa powinna by`c zupe`lnie prosta, dokonano zrzutu
informacji w postaci po`sredniej, wystarczy zatem przetworzy`c j`a do formatu
X.500; w praktyce napotkali`smy na szereg problem`ow zwi`azanych z
niekompatybilno`scia format`ow --- nazwy instytucji s`a zbyt d`lugie, telefony
podawane s`a w lu`znym formacie tekstowym, a nie sformalizowanym jak w X.500,
d`lugo`sci nazw polskich ulic przekraczaj`a przyj`ete przez tw`orc`ow X.500
ograniczenie. To jedynie kilka z napotkanych problem`ow, kt`ore s`a bardzo
trudne do rozwi`azania, jako `xe wymaga`lyby w zasadzie ingerencji
administratora w pojedyncze has`la, a w pewnych przypadkach nawet
konsultacji z tymi, kt`orych dane dotycz`a.


\subsection{Efektywno`s`c}
W trakcie prac nad uruchamianiem bazy X.500 przeprowadzili`smy nieco bada`n
efekty\-wno\-`s\-cio\-wych. Teoretycznym rozwa`xaniom nad elementami wp`lywaj`acymi na
sprawno`s`c rozproszonej bazy danych po`swi`ecili`smy raport \cite{efekt}.

QUIPU, kt`ore by`lo badanym przez nas produktem jest dosy`c specyficzne, jako
`xe przechowuje ca`lo`s`c danych (za wyj`atkiem specyficznych atrybut`ow jak
obraz, czy d`zwi`ek) w pami`eci operacyjnej komputera. Fakt ten ma bardzo
istotny wp`lyw na sprawno`s`c samej bazy --- dzia`lanie jest bardzo szybkie w
sytuacji, gdy baza faktycznie rezyduje w pami`eci, z drugiej strony obs`luga
pami`eci  wirtualnej mo`xe dzia`lanie bazy bardzo spowalnia`c. W tym zakresie
obserwuje si`e dwa efekty:
\begin{enumerate}
\item Baza mieszcz`aca si`e w ca`lo`sci w pami`eci
operacyjnej dzia`la szybko, pod warunkiem, `xe w okresie bezczynno`sci nie
zostanie `"wymieciona" przez system na dysk. Je`xeli to nast`api, to pierwszy po
przerwie dost`ep do bazy b`edzie op`o`zniony, nast`epne s`a ju`x szybkie.

\item Baza nie mieszcz`aca si`e w ca`lo`sci w pami`eci wymaga obs`lugi
poprzez stronicowanie pami`eci i jest nadzwyczaj nieefektywna.
Obserwowali`smy rezultaty, kiedy odszukanie pojedynczego has`la, w ramach
jednego serwera, zabiera`lo ok.\ 90~sekund, powi`ekszenie pami`eci na tej
samej maszynie obni`xy`lo ten czas do poni`xej sekundy.
\end{enumerate}

Z obserwacji tych wynika wniosek, `xe nale`xy by`c ostro`xnym przy podejmowaniu
decyzji o rozpraszaniu danych. Rozproszenie ma dwa negatywne skutki:
op`o`znienia sieciowe oraz rzadszy dost`ep do serwer`ow (i  w konsekwencji
cz`estsze efekty `"wymiatania" procesu na dysk), z drugiej strony baza nie
mo`xe przekracza`c rozs`adnych wymiar`ow, tak aby bez k`lopotu mie`sci`la si`e w
pami`eci operacyjnj komputera.

Nasze do`swiadczenia wykaza`ly, `xe przy typowych rozmiarach baz indeksowanie
nie wydaje si`e mie`c pierwszorz`ednego znaczenia. Wyniki te mog`a jednak
zosta`c zweryfikowane po wykonaniu pr`ob opartych o mocno rozbudowane
zapytania.

Gdy rozwa`xa si`e zagadnienia efektywno`sciowe bazy, z regu`ly my`sli si`e
wy`l`acznie o funkcjonowaniu samego serwera, tymczasem czasami pozornie s`labe
efekty mog`a by`c win`a samego oprogramowania dost`epowego (klienta).
Stwierdzili`smy, `xe pewne interfejsy rozpowszechniane w ramach pakietu ISODE
stosuj`a wyj`atkowo `zle zaprojektowane algorytmy sortowania otrzymanej listy
wynik`ow, nie stosuj`a te`x buforowania otrzymanych raz danych. Zmiana
algorytmu sortowania pozwoli`la na przyspieszenie dzia`lania klienta o ponad
50 razy.

Kolejna grupa problem`ow zwi`azana jest z opisywan`a w kolejnej cz`e`sci
inter\-na\-cjo\-na\-li\-za\-cj`a. Stosowanie dodatkowych atrybut`ow przechowuj`acych
poprawnie napisane nazwy wydaje si`e by`c na pierwszy rzut oka prostym
rozwi`azaniem, po chwili zastanowienia okazuje si`e jednak, `xe w wyniku
przeszukania poddrzewa zwracane s`a wynikowe nazwy wyr`o`xnione; sk`ladnikami
tych nazw s`a oczywi`scie relatywne nazwy wyr`o`xnione, a nie specjalne
atrybuty przechowuj`ace poprawne nazwy. W wyniku tego, dla wy`swietlenia
ca`lej nazwy wyr`o`xnionej, w poprawnej pisowni, konieczne jest dokonanie
operacji czytania dla ka`xdego obiektu wyst`epuj`acego w ga`l`ezi prowadz`acej do
otrzymanego wyniku. Wp`lyw takiego dzia`lania na efektywno`s`c mo`xe by`c
katastrofalny, zw`laszcza przy d`lugich listach wynikowych.


\subsection{Internacjonalizacja}\label{inter}
Istotnym problemem przy popularyzacji bazy danych o zasi`egu
mi`edzynarodowym jest zapewnienie jej uniwersalno`sci.
Podstawowe atrybuty opisuj`ace has`la zgromadzone w X.500 musz`a by`c
zapisane w taki spos`ob, by mog`ly by`c odczytane przez dowolne
interfejsy u`xytkowe. Oznacza to, w przypadku Polski, `xe wszystkie
nazwy s`a okrojone z polskich znak`ow diakrytycznych.
Taka prezentacja danych nie mo`xe zadowoli`c polskiego u`xytkownika, gdy`x
bardzo cz`esto powoduje utrat`e istotnej informacji.

Model informacyjny X.500 zapewnia rozszerzalno`s`c bazy poprzez
tworzenie nowych atrybut`ow, kt`ore nie s`a interpretowane
przez zewn`etrzne systemy,
nie poinformowane o wprowadzeniu nowych identyfikator`ow obiekt`ow.
Niestety, eksploatowane w ramach polskiego programu pilotowego
oprogramowanie QUIPU dopuszcza wy`l`acznie interpretacj`e znak`ow
tabeli ASCII i Latin-1 (ISO8859-1). Wewn`etrznie X.500 stosuje standard
telekomunikacyjny T.61 do kodowania znak`ow dodatkowych.
Wbudowane w QUIPU mechanizmy obs`lugi `la`ncuch`ow T.61 i
prezentacji znak`ow Latin-1 s`a bardzo ubogie i, jak si`e
okazuje,  posiadaj`a wiele b`l`ed`ow implementacyjnych.

W ramach grantu KBN autorzy przeprowadzili wst`epne prace \looseness=-1
maj`ace na celu dostosowanie oprogramowania QUIPU
oraz struktury baz X.500 do obs`lugi polskich znak`ow diakrytycznych.
Opracowane zosta`ly zasady niezb`ednych rozszerze`n tablic atrybut`ow
i klas obiekt`ow, dzi`eki temu zapewniona jest mo`xliwo`s`c umieszczania
polskich nazw jako oddzielnych atrybut`ow opisuj`acych has`la.
Dokonano analizy oprogramowania w celu umiejscowienia 
modu`l`ow odpowiedzialnych za obs`lug`e translacji kod`ow, a nast`epnie
zosta`ly zmodyfikowane odpowiednie funkcje biblioteczne. 
W ten spos`ob zrealizowano obs`lug`e znak`ow z zakresu tabeli
Latin-2 (ISO8859-2), czyli w`la`sciwe przekodowanie w przypadku, gdy
program u`xytkowy korzystaj`acy z DSA zg`losi`l si`e jako interfejs
interpretuj`acy taki kod (jest to parametr ustawiany konfiguracyjnie).
Jednocze`snie konieczne by`ly zmiany w ramach samych program`ow
u`xytkowych takich jak {\it Pod}, {\it dish}, {\it de}. Ten ostatni
zosta`l przebudowany w do`s`c szerokim zakresie, z my`sl`a dostarczania
go jako typowego polskiego interfejsu u`xytkowego X.500. Rozwa`xaniom 
na temat problem`ow zwi`azanych z obs`lug`a znak`ow narodowych w systemach typu
X.500 Directory po`swi`econy jest raport autor`ow \cite{pol}.

Sporo pracy wymaga`lo dostosowanie oprogramowania do obs`lugi
przeszukiwania bazy X.500 po podaniu polskiego wzorca danych, gdy`x
niestety, r`ownie`x w tym zakresie produkt nie dzia`la`l prawidlowo.
Obecnie, poprawione funkcje biblioteczne oraz program obs`lugi DSA
prawid`lowo realizuj`a tego typu wyszukania. Nale`xy jednak pami`eta`c,
`xe w tym celu niezb`edna jest eksploatacja zmodyfikowanego oprogramowania
serwera QUIPU oraz DUA skompilowanych na bazie poprawionych bibliotek.

Dzia`lania dotycz`ace internacjonalizacji X.500 s`a prowadzone nadal.
Uwa`xamy, `xe jest to priorytetowe zadanie polskiego programu X.500.
Zamierzamy kontynuowa`c prac`e nad dostosowaniem r`o`xnych DUA do obs`lugi 
polskich znak`ow, jak r`ownie`x prowadzi`c dzia`lania na forum mi`edzynarodowym
zmierzaj`ace do uwypuklenia problemu stosowania lokalnego nazewnictwa.

Nowy standard '93 przewiduje istnienie tzw.\ `la`ncuch`ow BMP (Base Modular
Plan), repre\-zen\-tu\-j`a\-cych znaki wed`lug standardu ISO 10646.
By`c mo`xe nowe implementacje X.500 upro\-sz\-cz`a dzi`eki temu wprowadzanie
lokalnych nazw do bazy danych.

Grupa rozwijaj`aca europejski projekt X.500  rozwa`xa r`ownie`x mo`xliwo`s`c 
pe`lnej internacjonalizacji
poprzez wbudowanie w DSA odpowiednich mechanizm`ow t`lumacz`acych
wed`lug odpowiednich s`lownik`ow. 
Abstrahuj`ac od sensowno`sci takiego rozbudowywania DSA, wydaje si`e, 
`xe wobec nawa`lu
prac zwi`azanych z nowym standardem perspektywy urzeczywistnienia
tego typu plan`ow s`a znikome.
Brakuje niestety odpowiedniego forum forsuj`acego problematyk`e 
znak`ow mi`edzynarodowych w bazach danych,
w efekcie administratorzy krajowi s`a zmuszani do indywidualnych prac,
cz`esto dubluj`acych ju`x wykonane.




\vspace*{-2mm}
\section{Powi`azania X.500 z innymi standardami i systemami}
\vspace*{-1mm}

W `srodowisku Internetu trwaj`a dyskusje na temat modelu us`lugi katalogowej
({\it Directory Service}). Istnieje grupa przeciwnik`ow X.500, kt`ora zarzuca
standardowi nieefektywno`s`c, brak jednoznacznej definicji niekt`orych element`ow
protoko`lu i, co za tym idzie, niemo`xliwo`s`c sp`ojnej implementacji oraz
du`xy ci`e`xar protoko`lu obarczonego obs`lug`a modelu sieciowego OSI.

Nowy standard X.500 '93 zawiera szereg poprawek i rozszerze`n
(patrz cz`e`s`c \ref{93}),
wydaje si`e `xe jego pe`lna implementacja pozwoli`laby unikn`a`c wiele
problem`ow, z kt`orymi produkty wersji '88 pr`obuj`a upora`c si`e w r`o`xny,
nie zawsze wzajemnie kompatybilny spos`ob. 
Wiod`acy producenci oprogramowania X.500: ISODE Consortium, NEXOR, DEC,
 ju`x przyst`apili do prac maj`acych na celu wdro`xenie nowego
standardu, jednak ze wzgl`edu na rozleg`lo`s`c zmian nie jest mo`xliwa
szybka modyfikacja istniej`acego oprogramowania.

Tymczasem istniej`a grupy, w kt`orych trwaj`a prace nad 
definicj`a i imple\-men\-ta\-cj`a uproszczonych protoko`l`ow realizuj`acych 
analogiczn`a us`lug`e dost`epu do baz informacyjnych typu `"ksi`a`xka 
adresowa" ({\it White Pages}).

\subsection {WHOIS++}

Jednym z g`l`ownych konkurent`ow jest protok`o`l WHOIS++, rozwijaj`acy
si`e na bazie zdefiniowanego w 1982 roku NICNAME/WHOIS (\cite{whois}). 
Patronowana przez Network Information Center (NIC) us`luga WHOIS mia`la
na celu dostarczenie w sieci Internet danych o u`xy\-tko\-wni\-kach, organizacjach,
zasobach sprz`etowych i programowych. W pierwotnym zamierzeniu baza 
ta by`la pomy\-`sla\-na jako wielodost`epna, rezyduj`aca na okre`slonym
serwerze i udost`epniaj`aca w prostym formacie dane o obiektach
zarejestrowanych w NIC. Podstawowa us`luga szybko rozszerzy`la si`e i
gwa`ltownie wzros`la liczba niezale`xnych komputer`ow oferuj`acych tego 
typu dane.
Model informacyjny protoko`lu WHOIS ogranicza`l skal`e zastosowania,
tymczasem popularno`s`c us`lugi `swiadczy`la o niezb`edno`sci jej
udoskonalenia i wdro`xenia.
Spowodowa`lo to rozw`oj kolejnej wersji, znanej jako WHOIS++, 
o rozbudowanym modelu danych, wzbogaconym mechanizmie formu`lowania zapyta`n
i przeszukiwania.

Architektura us`lugi katalogowej WHOIS++ jest rozdzielona pomi`edzy
dwa komponenty: serwer poziomu podstawowego oraz indeksuj`acy.
Standard WHOIS++ opisuj`a dokumenty Internet--Draft \cite{whois-arch}
i \cite{whois-index}.
W praktyce jeden serwer fizyczny mo`xe spe`lnia`c obie funkcje,
czyli gromadzi`c dane wed`lug ustalonego schematu oraz utrzymywa`c
indeks, zawieraj`acy wskazania do innych serwer`ow.

Stosowana zasada indeksowania polega na tworzeniu na podstawie
informacji zawartej w ramach serwer`ow, odwzorowania
postaci tzw.\ {\it centroid}, b`ed`acych has`lami, kt`ore
dla ka`xdego typu atrybutu gromadz`a jego warto`sci. 
Dane te s`a zarz`adzane przez serwery indeksuj`ace, zbieraj`ace
`"centroidy" w`lasne oraz wybranych serwer`ow indeksuj`acych.
WHOIS++ uwzgl`ednia r`ownie`x rozproszone zarz`adzanie baz`a danych.

Autorzy protoko`lu WHOIS++ twierdz`a, `xe w wielu przypadkach jego zwi`ez`lo`s`c
i prostota mo`xe zadecydowa`c o wyborze tej technologii w celu
implementacji {\it directory services}. Podkre`sla si`e efektywno`s`c
wybranej metody indeksacji, zarzucaj`ac standardowi X.500 brak 
mechanizmu pozwalaj`acego w spos`ob optymalny przekazywa`c zapytania
do kolejnych serwer`ow.


\subsection {SOLO}

SOLO (Simple Object Look-up Protocol) to kolejna pr`oba specyfikacji
us`lugi zwanej {\it directory service} (\cite{Solo}). Protok`o`l ten jest rozwijany
we Francji (INRIA), jego autorzy bazuj`a na do`swiadczeniach zwi`azanych
z X.500, wykorzystuj`a zainicjowane w ramach X.500 `"przy\-ja\-zne" nazewnictwo
obiekt`ow ({\it user friendly naming}) oraz koncepcje indeksowania
({\it centroids}) sto\-so\-wa\-n`a w WHOIS++.
Podstawowym motywem przy defincji tego standardu by`lo powstanie
systemu dostarczaj`acego z jednej strony mechanizmy prostego
dost`epu do serwer`ow pracuj`acych wed`lug innych protoko`l`ow ---
WHOIS czy X.500, a jednocze`snie daj`acego mo`xliwo`s`c tworzenia
oprogramowania po`srednicz`acego pomi`edzy tymi protoko`lami
(typu {\it gateway}).

SOLO to prosty  protok`o`l tekstowy, pracuj`acy 
na platformie po`l`acze`n TCP/IP, kt`ory opiera si`e na dw`och 
podstawowych operacjach: 

\begin {itemize}
\item przeszukiwania --- w celu odzyskania informacji o okre`s\-lo\-nym 
obiekcie,
\item transferu strefy --- operacji wykonywanej dla aktualizacji 
indeks`ow w ramach serwera; indeksowanie odbywa si`e analogicznie
jak w protokole WHOIS++ poprzez tworzenie tzw.\ {\it centroid}, czyli
jednego ogromnego has`la ({\it entry}), zawieraj`acego 
warto`sci atrybut`ow dla wszystkich indeksowanych typ`ow atrybut`ow 
opisuj`acych obiekty.
\end {itemize}

\subsection {X.500 a inne systemy informacyjne}

Zasoby sieci Internet oferowane s`a poprzez r`o`xnego
typu systemy realizuj`ace funkcje naprowadzania i udost`epniana informacji
na bazie wielopoziomowych menu. Jednym z nich jest opracowany
w 1991 w University of Minnesota {\it gopher}.
Obecnie wszystko wskazuje na to, `xe nast`epc`a {\it gophera} zostanie system
{\it World Wide Web --- WWW}, kt`ory spowodowa`l prawdziw`a rewolucj`e 
w dziedzinie prezentacji danych w sieci Internet.

Baza X.500 Directory jest dost`epna z tych popularnych system`ow
dzi`eki istnieniu specjalnych program`ow transluj`acych odpowiednie
protoko`ly (oprogramowanie typu {\it gateway}). Na og`o`l mo`xliwo`sci
te s`a realizowane na bazie protoko`l`ow LDAP czy SOLO
jako po`srednicz`acych w kontakcie z X.500, co wskazuje, `xe 
tw`orcy program`ow u`xytkowych dla X.500 preferuj`a 
specyfikacje mniej rozbudowane.

Bardzo istotnym czynnikiem, jakie wni`os`l rozw`oj WWW jest jednorodne
nazewnictwo zasob`ow komputerowych za pomoc`a tzw.\ Universal 
Resource Locators (URL). Nazwa taka zawiera rodzaj i lokalizacj`e zasobu,
`l`acznie z form`a dost`epu do niego.

X.500 Directory uwzgl`enia obecnie mo`xliwo`s`c podawania umiejscowienia
obiektu za pomoc`a URL, zasady okre`s`la opublikowany dokument serii
 serii Internet Draft \cite{url}.

Przy okazji warto wspomnie`c o funkcjonowaniu wyspecjalizowanych system`ow
katalogowych, np.\ skupiaj`acych dane o osobach okre`slonej specjalno`sci.
Wydaje si`e, `xe d`a`xenie do utrzymywania jednej tylko globalnej dazy danych,
kt`ora udost`epnia`laby okre`slone podzbiory danych w formie projekcji, jest
nierealne. Baza utrzymywana w formie rozproszonej i obej\-mu\-j`a\-ca swoim
zasi`egiem ogromne ilo`sci informacji, nie mo`xe by`c tak jednorodna oraz dawa`c
gwarancj`e, `xe przedstawia obraz pe`lny i bez przek`lama`n. Nie  oznacza to
bynajmniej, `xe nie nale`xy my`sle`c o stosowaniu X.500 do us`lug typu {\em
Yellow Pages}, twierdzimy tylko, `xe X.500 nie b`edzie w stanie wyprze`c
niewielkich i silnie specjalizowanych baz danych.

\subsection {Wykorzystanie X.500 dla potrzeb poczty elektronicznej}

G`l`ownym motywem rozwoju X.500 by`la potrzeba odwzorowania
skomplikowanych adres`ow poczty elektronicznej X.400 na identyfikatory
u`xytkownik`ow. W miar`e rozwoju, zakres zastosowania 
X.500 rozbudowa`l si`e i cz`esto technologia ta jest stosowana
jako spos`ob reprezentacji ksi`a`xki telefonicznej, czy adresowej.

Ju`x obecnie istniej`a produkty, kt`ore integruj`a us`lug`e X.500
z poczt`a elektroniczn`a, do\-star\-cza\-j`ac u`xytkownikom Internetu
wygodn`a metod`e wyszukiwania adres`ow e-mail z baz X.500 Directory.
Programy takie pracuj`a na r`o`xnych platformach systemowych (Unix,
DOS, Macintosh OS). Rosn`aca popularyzacja poczty elektronicznej, kt`ora
staje si`e obecnie podstawow`a form`a wymiany informacji poci`aga za
sob`a konieczno`s`c szerszego rozpowszechniania X.500 jako
infrastruktury e-mail.

Programy pilotowe poczty X.400, dzia`laj`ace w wielu `srodowiskach
akademickich Europy (Anglia, Holandia, Niemcy) wykorzystuj`a
X.500 jako miejsce przechowywania informacji o sposobie przekazywania
komunikat`ow ({\it routing}) pomi`edzy kolejnymi MTA ({\it Message
Transfer Agent}), w celu dostarczenia poczty od adresata do odbiorcy,
czy do okre`slenia mo`xliwo`sci program`ow u`xytkowych ({\it User Agent}),
co jest szczeg`olnie istotne w przypadku poczty multimedialnej (MIME).
 

X.500 mo`xe by`c r`ownie`x stosowane do przechowywania adres`ow
cz`lonk`ow list dystrybucyjnych, co dzi`eki rozproszonemu zarz`adzaniu
X.500 pozwala na zmian`e adresu e-mail osoby bez konieczno`sci 
informowania  administratora listy.

Obecnie rozwija si`e wykorzystanie X.500 w poczcie prywatnej --- PEM
(Privacy Enhanced Mail). PEM stosuje machanizm kluczy publicznych 
do bezpiecznej wymiany komunikat`ow, wysy`lana poczta mo`xe zosta`c
zaszyfrowana kluczem publicznym odbiorcy, kt`ory jest jedyn`a osob`a
maj`ac`a prawo do odkodowania informacji poprzez podanie klucza
prywatnego. U`xywanie PEM wymaga zapewnienia dost`epu do kluczy
publicznych wszystkich potencjalnych adresat`ow. X.500 pozwala
przechowywa`c tego typu dane w ramach swoich rozproszonych baz danych.
Nale`xy podkre`sli`c, `xe architektura zarz`adzania kluczami 
szyfruj`acymi stosowana w PEM 
(\cite{rfc1421}, \cite{rfc1422}) bazuje na koncepcji certyfikat`ow kluczy
publicznych zdefiniowanej w  serii X.509, b`ed`acej zaleceniami
CCITT dotycz`acymi metod po`swiadczania w ramach X.500 Directory.
Ponadto, certyfikaty wykorzystuj`a okre`s\-lo\-n`a w X.500 posta`c
reprezentacji nazw ({\it Distinguished Names}). Organizacje
posiadaj`ace uprawnienia do przydzielania kluczy publicznych
--- {\it Certification Authorities}, maj`a w ramach drzewa X.500
przydzielone odpowiednie has`la.


%\vskip 1cm

Analiza nowej wersji standardu X.500 pozwala odeprze`c wiele zarzut`ow
do\-ty\-cz`a\-cych mo\-`xli\-wo\-`sci oferowanych w ramach samego protoko`lu.
Nie spos`ob jednocze`snie zaprzeczy`c, `xe X.500 jest protoko`lem rozleg`lym,
wymagaj`acym ogromnego wysi`lku implementacyjnego. 
Jednak w przypadku konstruowania aplikacji sieciowych, 
kt`ore maj`a zadawala`c szerok`a rzesz`e u`xytkownik`ow i spe`lnia`c
r`o`xnorodne wymagania, konieczny staje sie wyb`or
pomi`edzy nie\-zb`e\-dny\-mi nak`ladami pracy a oczekiwanymi efektami, jakie
ma da`c gotowy system. Najistotniejszym celem powinno by`c powstanie
systemu, na bazie kt`orego b`edzie mo`xna w przysz`lo`sci szybko
i tanio budowa`c oprogramowanie typu u`xytkowego, `"klienckiego".

 

\section{Rozw`oj standardu (X.500 '93)}\label{93}

Nowa wersja standardu zosta`la ogromnie rozbudowana w stosunku do swojej
pierwszej wersji. Autorzy starali si`e usun`a`c zauwa`xone niejasno`sci, jak
r`ownie`x doda`c elementy, kt`orych do tej pory ewidentnie brakowa`lo. 
Najbardzej odczuwalny by`l brak:
\begin{itemize}
\item replikacji danych,
\item kontrolowania dost`epu do danych,
\item rozdzia`lu atrybut`ow na u`xytkowe i operacyjne, tj.\ 
przechowyj`acych informacje potrzebne potencjalnemu odbiorcy i te potrzebne
dla poprawnego funkcjonowania bazy,
\item wprowadzenie atrybut`ow zbiorowych, wsp`olnych dla ca`lej grupy
obiekt`ow. 
\end{itemize}

Dwa pierwsze punkty zamiplementowano w QUIPU jako rozszerzenia standardu '88,
uwa`xaj`ac, `xe
s`a niezb`edne do uruchomienia sprawnie dzia`laj`acej us`lugi.
Standard '93 podchodzi do tych spraw inaczej ni`x okre`slono to w
rozszerzeniach stosowanych w QUIPU, co
poci`aga za sob`a niekompatybilno`s`c produkt`ow.

Odno`snie replikacji administratorzy b`ed`a mieli znacznie szersze
mo`xliwo`sci ni`x dawa`lo im QUIPU, b`ed`a mogli replikowa`c ca`le wybrane
fragmenty drzewa, a nie jak do tej pory tylko pojedynczy poziom, replikacji
b`eda mog`ly podlega`c tylko wybrane grupy atrybut`ow, wywo`lanie protoko`lu
replikacji b`edzie mog`lo nast`epowa`c z inicjatywy dowolnej ze stron.
W zwi`azku z tym konieczne by`lo wzbogacenie protoko`lu zapyta`n o opcje
steruj`ace tym, czy pytaj`acy zadowala si`e informacj`a zreplikowan`a, by`c mo`xe
niekompletn`a, czy te`x niezb`edny jest orygina`l.

Kontrolowanie dost`epu b`edzie zapewnia`lo du`xy stopie`n bezpiecze`nstwa
(standardowo stosowane obecnie w QUIPU zabezpieczenia, s`a proste do
z`lamania), rozbudowany jest tak`xe mechanizm zabezpiecze`n daj`ac
wielostopniowy system ochrony (np.\ ochrona przed wy`swietlaniem listy,
przeszukiwaniem, wy`swietlaniem warto`sci, informowaniem o istnieniu itp.).

Rozdzia`l atrybut`ow b`edzie mia`l pozytywny wp`lyw na u`xytkowanie bazy, kiedy
osoba pobie\-ra\-j`a\-ca informacj`e nie b`edzie ju`x dostawa`la ca`lkowicie zb`ednych
atrybut`ow administracyjnych.

Wprowadzenie atrybut`ow grupowych stanowi konieczne uzupe`lnienie
poprzedniego standardu. QUIPU stosowa`lo atrybuty dziedziczone, atrybuty
zbiorowe b`ed`a rozszerza`ly ich funkcjonalno`s`c.


R`o`xnice mi`edzy obiema wersjami standardu s`a bardzo znaczne, ale szczeg`olowe
ich wy\-ja\-`s\-nie\-nie wykracza znacznie poza zakres niniejszego artyku`lu.
Zainteresowanych czytelnik`ow odsy`lamy do opracowania \cite{Waugh1}.

\section{Literatura uzupe`lniaj`aca}

Poni`xej zamieszczamy wykaz pozycji, kt`orych 
lektur`e zalecamy czytelnikowi
zainteresownemu szczeg`o`lowo problematyk`a X.500.

\begin{itemize}
\item C.J. Robbins, S.E. Kille (1992) {\it The ISO Development Environment:
User's Manual, Volume 5: QUIPU}
\item Marshall T. Rose (1992) {\it The Little Black Book: Mail
Bounding with OSI Directory Services}
\item D. Chadwick (1994) {\it Understanding X.500 The Directory}

\end{itemize}

%\newpage
\begin{thebibliography}{99}
%\setlength{\labelwidth}{15mm}
%\setlength{\itemindent}{5mm}
%\def\makelabel#1{\hbox to \labelwidth{[#1]\hfill}}
\bibitem{X.500}Data Communication Networks: Directory, Recommendations X500-X.521,
CCITT, Fascile VIII.8 of Blue Book.
\bibitem{rfc1276} 
S. E. Hardcastle-Kille (1991) 
{\it Replication and distributed operation 
extentions to provide an Internet Directory using X.500, 
Request for Comments RFC1276}\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc1276.txt$>$}

\bibitem{rfc1632} A. Getchell, {\it A Revised Catalog of 
Available X.500 Implementations},
Request for Comments RFC1632\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc1632.txt$>$}


\bibitem{rfc1421} J. Linn (1993) {\it Privacy Enhancement for Internet Electronic 
Mail:  Part I: Message Encryption and Authentication Procedures}
Request for Comments RFC1421\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc1421.txt$>$}

\bibitem{rfc1422} S. Kent (1993) {\it Privacy Enhancement for Internet Electronic
Mail:  Part I: Certificate-Based Key Management} 
Request for Comments RFC1422\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc1422.txt$>$}

\bibitem{whois} E. Finler, K. Harrenstien, M. Stahl (1985) {\it NICNAME/WHOIS},
Request for Comments RFC954\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc954.txt$>$}

\bibitem{whois-arch} P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider (1995)
{\it Architecture of the WHOIS++ service}, Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/drafts-ietf-wnils-whois-arch-02.txt$>$}

\bibitem{whois-index} C. Weider, J. Fullton, S. Spero (1994)
{\it Architecture of the WHOIS++ Index Service}, Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/drafts-ietf-wnils-whois-03.txt$>$}

\bibitem{Solo} C. Huitema, P-A. Pays, A. Zahm, A. Woermann (1994)
{\it Simple Object Look-up protocol (SOLO)}, Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/drafts-huitema-solo-01.txt$>$}

\bibitem{url}Mark Smith (1995) {\it Definition of an X.500 Attribute Type and Object Class to
Hold Uniform Resource Identifiers (URIs)} Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/draft-ietf-asid-x500-url-01.txt$>$}
\bibitem{Waugh1} A. Waugh (1994) {\it X.500 and the 1993 Standard}
\bibitem{Waugh2} A. Waugh (1994) {\it Where are the Network Applications?},
Australian Networkshop '93, Melbourne\\
{\small URL=$<$ftp://ftp.unimelb.edu.au/pub/networkshop93/infores/waugh.txt$>$}

\bibitem{IndexDSA} P. Barker (1995) {\it X.500 Index DSAs}
\bibitem{pol}M. G`orecka, T. Wolniewicz (1994) {\it Ocena efektywno`sci rozproszonej 
bazy danych na podstawie X.500 Directory}, Raport NASK
\bibitem{efekt} M. G`orecka, T. Wolniewicz (1994) {\it Stosowanie znak`ow diakrytycznych 
w systemach baz danych X.500}, Raport NASK
\end{thebibliography}
\end{document}

