\voffset-10mm
\hoffset5mm

\documentstyle[a4wide,12pt,ite,polski]{article}
\pagestyle{empty}
\textwidth=16.5cm\textheight=24.5cm
%\date{14--04--95}
\date{}
\title {\bf X.500 --- us`luga katalogowa w sieci Internet}
%\author{{Maja G`orecka \hspace{2cm}Tomasz Wolniewicz{2cm} Jerzy `Xenkiewicz}}
\author{{Maja G`orecka} \\ {\normalsize mgorecka@cc.uni.torun.pl} \and 
{Tomasz Wolniewicz} \\ {\normalsize twoln@mat.uni.torun.pl} \and {Jerzy `Xenkiewicz}
 \\ {\normalsize jezenk@cc.uni.torun.pl}}
%\input dzieki

\begin {document}
\maketitle
\vspace{-5mm}
\centerline{\large Uniwersytet Miko`laja Kopernika w Toruniu}
\vspace{5mm}
%\section{X.500 od strony us`lugowej i `"White pages"}
\section{X.500 --- standard i jego realizacja}.

Zgodnie z za`lo`xeniami, standard X.500 zosta`l opracowany dla cel`ow szeroko
rozumianej informacji katalogowej wspieraj`acej procesy warstwy aplikacji
OSI, jak te`x procesy zarz`a\-dza\-j`a\-ce sieciami zgodnymi z OSI. 
Jednocze`snie chciano wyj`s`c naprzeciw rosn`acemu zapotrzebowaniu 
na dost`ep do `swiatowej ksi`a`xki telefoniczno-adresowej --- `"White Pages".

Dwie organizacje: CCITT (obecnie ITU-T) oraz ISO r`ownolegle prowadzi`ly
od roku 1984 prace standaryzacyjne. CCITT definiowa`lo us`lug`e 
informacji adresowej, a ISO opracowywa`lo zasady nazewnictwa zasob`ow
i us`lug komputerowych. W 1986 roku nast`api`lo po`l`aczenie obu grup.
Efektem dzia`la`n by`lo opublikowanie niezale`xnych standard`ow  CCITT
\cite{CCITT} i ISO/IEC 9594 \cite{ISO}, zwanych standardem X.500 '88.
Prace nad rozwojem X.500 trwaj`a, tym bardziej, `xe implementacje us`lugi
wed`lug standardu '88 ujawni`ly wiele s`labo`sci i niedoci`agni`e`c protoko`lu.
Ostatnio zosta`la oficjalnie opublikowana kolejna wersja, oznaczona jako 
X.500 '93.
Jej obszerne fragmenty s`a ju`x od roku og`olnie znane i dyskutowane, 
rozpocze`ly si`e 
te`x prace nad wdro`xeniem nowych cech standardu do program`ow.

\thispagestyle{empty}
Najbardziej popularnym oprogramowaniem realizuj`acym funkcje X.500
Directory jest QUIPU. Pakiet ten zosta`l zaimplementowany przez
grup`e zwi`azan`a z University College London w celu utworzenia 
narz`edzia badawczego, demonstruj`acego mo`xliwo`sci dzia`lania rozproszonej
bazy X.500 w sieciach rozleg`lych. Pocz`atkowo oprogramowanie
QUIPU by`lo dost`epne og`olnie, od 1993 roku
jest ono w gestii organizacji ISODE Consortium, kt`ora udziela
nieodp`latnej licencji o`srodkom akademickim.
Jednocze`snie powsta`ly i s`a nadal tworzone inne implementacje, m.in.
NEXOR QUIPU, DEC, UCOM, Siemens.

Rozw`oj us`lugi X.500 wi`a`xe si`e z uruchomieniem serwisu pracuj`acego na wybranym
oprogramowaniu i za`ladowa`c dane.
 Pierwsze lata dzia`lania X.500 by`ly w zdecydowanej wi`ekszo`sci
oparte na entuzjastycznych dzia`laniach i dobrej woli zainteresowanych
grup. W 1989 roku wystartowa`ly dwa programy pilotowe: europejski,
koordynowany przez Uniwersytet Lon\-dy`n\-ski oraz ameryka`nski, sponsorowany
przez US DARPA. Nast`epnie w ramach Europy zainicjowano projekt 
PARADISE, kt`orego celem by`la mi`edzynarodowa koordynacja rozwoju X.500
oraz po`l`aczenie pilot`ow europejskich i ameryka`nskich.
W kwietniu 1994 zosta`l zako`nczony projekt PARADISE
i opiek`e nad us`lug`a X.500 przej`e`la organizacja DANTE z zamiarem
dostarczania na podstawie dotychczasowego pilota niezawodnego, samofinansuj`acego si`e
serwisu. Aktualnie w ramach X.500 oferuje swoje dane 35 kraj`ow 
a `laczn`a ilo`s`c hase`l ocenia si`e na ponad 1.5 mln.

Pod nazw`a `"White Pages" rozumiemy obecnie mi`edzynarodowy
program rozwoju us`lugi
 (po`l`acznienie europejskiego programu PARADISE i ameryka`nskiego
`"White Pages"). Jednocze`snie dzia`la kilka program`ow zamkni`etych,
inicjowanych  mi`edzy innymi przez dostawc`ow us`lug telefonicznych. 
Programy takie stosuj`a zwykle  X.500 w zaw`e`xonym zakresie,
np.\ umieszczaj`ac w bazach danych wy`l`acznie dane dotycz`ace numer`ow
telefon`ow, miejsca zatrudnienia lub zamieszkania.
Ta tendencja powoduje, `xe og`olno`swiatowa rozproszona baza informacyjna
X.500,  zbudowana zgodnie ze  standardem jako struktura hierarchiczna
i sk`ladaj`aca si`e, jak dotychczas, z jednego drzewa danych (DIT),
b`edzie musia`la uwzgl`edni`c mo`xliwo`s`c istnienia wielu niezale`xnych
drzew informacyjnych, tworzonych przez odr`ebne domeny administracyjne.


Jak ju`x wspomniano, w swoim za`lo`xeniu X.500 mia`lo by`c stosowane 
jako us`luga `"White Pages" (informacja
adresowa), przeznaczona zar`owno dla cel`ow og`olnych, jak przesy`lania poczty
elektronicznej w standardzie X.400. `"White Pages" ma za zadanie
wyszukiwanie os`ob ze wzgl`edu  na dane osobowe, miejsce pracy lub
zamieszkania. W odr`o`xnieniu od `"Yellow Pages" nie zak`lada si`e rozleg`lego
wyszukiwania wed`lug specjalno`sci zawodowej, zainteresowa`n, czy innych
cech charakterystycznych.

Internet zaadoptowa`l standard X.500 jako podstaw`e us`lugi katalogowej,
mimo `xe wi`ek\-szo`s`c `srodowiska by`la zdecydowanie przeciwna protoko`lom
CCITT/OSI. 
Nie by`lo jednak `xadnej rozs`adnej alternatywy, a
X.500 mo`xe by`c eksploatowane na bazie r`o`xnych infrastruktur
sieciowych.
Tempo rozwoju zasob`ow bazy obs`lugiwanej przez X.500 nie nad`a`xa
 za dynamik`a Internetu. 
Jednym z powod`ow takiej sytuacji by`la dominacja aspektu protoko`lu
w pracach aktywist`ow X.500, cz`esto prowadz`aca do oderwania od 
zadania docelowego --- zbudowania niezawodnego serwisu.
Internet stosuje metod`e
tworzenia aplikacji poprzez szybk`a realizacj`e w jak najprostszy
spos`ob zamierzonego celu, `srodowisko OSI najpierw przygotowuje
jednoznacznie zdefiniowan`a i wszechstronn`a infractruktur`e, a dopiero na jej 
podstawie aplikacje u`xytkowe.

Obecnie X.500 posiada konkurent`ow w postaci innych technologii.
Coraz szerzej m`owi si`e o niezb`edno`sci realizacji w ramach us`lug
katalogowych indeksacji zasob`ow
sieciowych. Planowany protok`o`l wspieraj`acy t`e funkcj`e nosi nazwe WHOIS\raisebox{1.5pt}{\small ++} i
jest dok`ladniej opisany poni`xej.

Jednocze`snie jednak X.500 pozostaje funkcjonalnym, elastycznym
i wieloplatformowym standardem.
Jego nowa wersja '93 pozwala przypuszcza`c, `xe kolejne implementacje
b`ed`a efektywniejsze, a dodanie protoko`lu replikacji daje prosty mechanizm
wbudowania serwer`ow indeksowych w model strukturalny X.500.

\vspace{5mm}
\section{Mo`xliwo`sci wykorzystania X.500}

Standard X.500 przewiduje w swoim za`lo`xeniu mo`xliwo`s`c zupe`lnie dowolnego 
rozszerzania rodzaju
przechowywanych w bazie obiekt`ow, co pozwala umieszcza`c w niej
r`o`xnego typu informacje. Opieraj`ac si`e na architekturze X.500 mo`xna
utworzy`c baz`e gromadz`ac`a np.\ zbiory biblioteczne, dokumenty itp.

Ogromn`a zalet`a bazy X.500 jest jej rozproszony charakter. 
Zarz`adzanie du`x`a, centraln`a baz`a danych prowadzi na og`o`l do znacznego
pogorszenia jako`sci utrzymywanych w niej informacji.
W X.500 uprawnienia do modyfikacji zasob`ow ma ka`xdy
administrator domeny (tzw. {\it naming context}). 
Poprzez powi`azanie z danymi odpowiedniej autoryzacji dost`epu do nich
mo`xna zgodnie z potrzeb`a rozszerzy`c zezwolenie na modyfikacje danych, albo
oddelegowa`c zarz`adzanie fragmentem drzewa informacji  wybranemu
administratorowi w ramach organizacji czy instytutu.

Autoryzacja dost`epu pozwala r`ownie`x wskaza`c w`la`sciwych odbiorc`ow danych.
Dopuszcza si`e ograniczanie uprawnie`n do odczytu
niekt`orych hase`l, przeszukiwania czy listowania fragment`ow drzewa informacyjnego. 

Autoryzacja jest mo`xliwa w oparciu o 
konieczno`s`c po`swiadczania to`xsamo`sci przy `l`aczeniu si`e z baz`a X.500,
dopuszcza si`e wprowadzanie r`o`xnych poziom`ow identyfikacji zg`la\-sza\-j`a\-ce\-go
({\it simple}, {\it strong}).
%modyfikacji oparty jest o jednoznaczne identyfikatory i w ten spos`ob
%uniemo`xliwia b`l`edn`a interpretacj`e informacji przez u`xytkownik`ow spoza
%kr`egu, dla kt`orych jest ona przeznaczona.

Standard X.500, pomimo swojego rozproszonego charakteru, 
u`xywany bywa r`ownie`x jako
scentralizowana baza danych, tam gdzie jej hierarchiczna specyfika
szczeg`olnie dobrze nadaje sie do wiernego odwzorowywania struktury 
organizacji instytucji. 
Wspomiana modyfikowalno`s`c rodzaju przechowywanych zasob`ow jest
tu du`xym atutem, poniewa`x zapewnia prost`a skalowalno`s`c aplikacji.

Wa`xn`a dziedzin`a zastosowania X.500 jest poczta elektroniczna. 
Istniej`a ju`x pierwsze pr`oby integracji program`ow obs`lugi e-mail
z dost`epem do X.500. Baza X.500 jest naturalnym miejscem przechowywania
kluczy publicznych dla cel`ow `"bezpiecznej"
 poczty prywatnej (PEM). Technologia
PEM opiera si`e  na koncepcji certyfikat`ow kluczy publicznych wed`lug
rekomendacji X.509, dotycz`acej aspektu po`swiadczania w ramach X.500.


W RFC~1491 \cite{rfc1491} mo`xna znale`z`c list`e ro`xnorodnych zaawansowanych
zastosowa`n X.500.


\section{X.500 na tle innych us`lug przechowywania i  wyszukiwania
informacji}

M`owi`ac o X.500, bardzo cz`esto identyfikuje si`e ten termin z
us`lug`a `"White Pages". Krytyka, kt`ora wielokrotnie kierowana jest 
pod adresem X.500
dotyczy w zasadzie samej s`lu`xby katalogowej.

Naszym zdaniem, kilka powod`ow decyduje o tym, `xe `"White Pages" jest us`lug`a, 
kt`or`a nale`xy
traktowa`c odmiennie od innych serwis`ow:
\begin{itemize}
\item {\bf Typ u`xytkownika} --- u`xytkownik us`lugi katalogowej bardzo rzadko jest
typem szperacza. Wymaga us`lugi sprawnej i szybkiej i co najwa`xniejsze
niezawodnej. Zawodno`s`c us`lugi mo`xe by`c spowodowana np.\ niedost`epno`sci`a
okre`slonego serwera, nie\-komp\-let\-no\-`sci`a informacji, czy faktem, `xe pewne
instytucje nie wprowadzi`ly swoich danych, albo `xe format danych 
jest niejednorodny.

\item {\bf Niezb`edno`s`c us`lugi} --- pomimo, `xe us`luga katalogowa jest jedn`a z
najbardziej po\-`x`a\-da\-nych, wiekszo`s`c u`xytkownik`ow zak`lada, `xe jest ona po
prostu niemo`xliwa do realizacji i, co za tym idzie, nie wymaga jej
zainstalowania. Ka`xdy oczekuje sprawnie dzia`laj`acej poczty elektronicznej,
FTP, telneta,  a wi`ec niezawodnego serwisu DNS. 
Administrowanie DNS jest
przykr`a konieczno`sci`a, przed kt`or`a nie uchyla si`e `xaden administrator ---
bez tego nic nie dzia`la. X.500 nie ma jeszcze charakteru us`lugi koniecznej.

\item {\bf Koordynacja} --- us`luga katalogowa musi by`c cz`e`sciowo scentralizowana,
aby zapewni`c mi\-ni\-mal\-n`a przynajmniej sp`ojno`s`c danych. 
Chodzi tu o koordynacj`e na szczeblu krajowym oraz dostosowywanie si`e do
wzorc`ow `swiatowych. Potrzeba ta jest
kosztowna, wymaga spotka`n administrator`ow na szczeblach mi`edzynarodowych  i
krajowych. 
W ramach kierowania programem krajowym X.500 konieczne jest rozpoznanie
zapotrzebowa`n u`xytkownik`ow na us`lug`e i d`a`xenie do udost`epniania
danych, kt`ore s`a po`x`adane, dotyczy to zar`owno rodzaju,
czy jako`sci informacji, jak i jej rozleg`lo`sci.
Niezb`edne jest prowadzenie dzia`lalno`sci popularyzacyjnej i zach`ecanie
`srodowisk do wsp`o`ltworzenia serwisu.

\item {\bf Administrowanie} --- `"White Pages" musi zawiera`c aktualne i pe`lne
informacje. Ze wzgl`edu na dynamik`e zmian danych gromadzonych 
w X.500 Directory oznacza to, `xe administrowanie
jest w zasadzie zadaniem ci`ag`lym, uci`a`xliwym i kosztownym.
Specyfika postaci danych w X.500 wymaga przygotowania odpowiednich
narz`edzi programowych, zapewniaj`acych w miar`e automatyczne dokonywanie
 konwersji danych do w`la`sciwej postaci, a tak`xe sprawdzanie poprawno`sci 
danych. Z drugiej strony uruchomienie
uniwersalnych metod `ladowania bazy mo`xe w znacznym stopniu poprawi`c
jako`s`c X.500 i wp`lyn`a`c na zwi`ekszanie zasob`ow.

\item {\bf `Latwo`s`c instalacji} --- utarta opinia g`losi, `xe X.500 jest trudne w
instalacji i administrowaniu. Wydaje si`e nam, ze opinia ta nie jest s`luszna
i przy odpowiednio dostosowanych narz`edziach X.500 mo`xe uruchomi`c ka`xdy
kompetentny administrator UNIXa.  
R`ownie`x utrzymanie podstawowego serwisu nie nastr`ecza na og`o`l problem`ow.
Trudno`sci pojawiaj`a si`e cz`esto przy
eksploatowaniu rozbudowanej bazy, kiedy trzeba podejmowa`c decyzje
wp`lywaj`ace na efektywno`s`c dzia`lania systemu i gdy bardzo przydatna jest
znajomo`s`c szczeg`o`l`ow. 
Tego typu sytuacje powinny by`c regulowane poprzez dzia`lania odpowiednich
s`lu`xb typu {\it HelpDesk}.
Administrowanie szczeblem krajowym jest pod tym 
wzgl`edem mocno wyr`o`xnione.

Z drugiej strony wystartowanie us`lugi X.500 nie jest zadaniem tak prostym
jak uruchomienie {\it gophera}, czy {\it WWW}.
Wymaga kompilacji ca`lego, rozbudowanego oprogramowania, a nast`epnie  
odpowiedniej konfiguracji. Udost`epnienie
danych w ramach X.500 nie mo`xe by`c r`ownie`x por`ownywane z DNS, czy gopherem, nie tylko
ze wzgl`edu na ilo`s`c danych, ale przede wszystkim dlatego, `xe trzeba,
przynajmniej pobie`xnie  zna`c dopuszczaln`a struktur`e bazy (typy
obiekt`ow, atrybuty opisuj`ace obiekt), by w`la`sciwie za`ladowa`c informacje.

\item {\bf Dost`epno`s`c informacji} --- baza danych jest zawsze postrzegana jako
potencjalne `zr`od`lo dochod`ow, jak r`ownie`x zagro`xenie dla prywatno`sci.
Z fakt`ow tych wynika, `xe zdarzaj`a si`e problemy zar`owno z pozyskiwaniem
danych jak i ich publicznym udo\-st`e\-pnia\-niem. Docelowo zatem, baza musi by`c
wyposa`xona w mechanizmy identyfikacyjne, ograniczenia dost`epu itp.
Przyk`ladowym zabezpieczeniem mo`xe by`c zezwolenie na odczytywanie
poszczeg`olnych obiekt`ow bazy z r`ownoczesn`a blokad`a operacji
przeszukiwania. 

\item {\bf Modyfikowanie informacji} --- typowe s`lu`xby informacyjne,
funkcjonuj`ace w Internecie s`a albo bardzo ograniczone odno`snie mo`xliwo`sci
przechowywania rozbudowanej informacji (np.\ DNS), albo daj`a ca`lkowit`a
dowolno`s`c co do organizacji i zawarto`sci. 
Skrajnym przyk`ladem jest WWW, kt`ore
przy swoim lawinowym rozwoju doprowadza do totalnego zam`etu i
nie\-mo\-`xli\-wo\-`sci oddzielenia u`xytecznej informacji od szumu. 
Us`luga `"White
Pages" nie mo`xe zezwala`c na tego typu dowolno`s`c, musi zawiera`c 
informacj`e bogat`a, o odpowiedniej jako`sci, zwart`a, tak by
np.\ mog`la by`c wykorzystana do automatycznego tworzenia wyci`ag`ow drukowanych.
 Jednocze`snie nale`xy implementowa`c metody wp`lywania
u`xytkownik`ow na zawarto`s`c bazy (np.\ korygowanie b`l`ed`ow).
Administrator domeny musi by`c odpowiedzialny
za jako`s`c  informacji w ramach zarz`adzanego przez
siebie poddrzewa. Bardzo istotne jest podejmowanie decyzji odno`snie
rozszerzania 
zezwole`n na modyfikacje danych w X.500. Istnienie wbudowanych metod
po`s\-wia\-d\-cza\-nia to`xsamo`sci cz`e`sciowo zabezpiecza baz`e. 
Dodatkowo jednak niezb`edne by`lyby odpowiednie interfejsy u`xytkowe,
umo`xliwiaj`ace wprowadzanie danych wed`lug odpowiedniego schematu,
tak aby nie zosta`la naruszona sp`ojno`s`c formatu (w ramach og`olnych
mechanizm`ow jest ona kontrolowana tylko na zasadzie sprawdzania
poprawno`sci sk`ladni).
U`xytkownik powinien m`oc decydowa`c o zawarto`sci swojego has`la 
w spos`ob po`sredni, np.\ poprzez przesy`lanie odpowiedniego formularza.

\end {itemize}
\vspace{5mm}
\section {Inne technologie realizuj`ace us`lug`e informacyjn`a}
%\subsection {WHOIS\raisebox{1.5pt}{\small ++}}
\subsection {WHOIS++}

Historia protoko`lu WHOIS\raisebox{1.5pt}{\small ++} wykazuje w jak szybkim tempie tworzone
s`a aplikacje internetowe. Prace zainicjowano w po`lowie 1992, 
po 15 miesi`acach istnia`ly ju`x trzy pracuj`ace implementacje {\it `"public domain"},
trzy kolejne by`ly przygotowywane, powsta`l r`ownie`x procesor czo`lowy
({\it gateway}), `l`acz`acy WHOIS\raisebox{1.5pt}{\small ++} i X.500.


Protok`o`l WHOIS\raisebox{1.5pt}{\small ++} rozwin`a`l si`e jako kontynuacja
zdefiniowanego w 1982 roku w ramach Network Information Center (NIC)
NICNAME/WHOIS 
(\cite{whois}). Us`luga WHOIS umo`xliwia dost`ep do danych o u`xytkownikach,
organizacjach, zasobach sprz`etowych i programowych w sieci Internet.
Jest ona oparta na scentralizowanej bazie danych, co w du`xym
stopniu utrudnia jej aktualizacj`e, a przy istniej`acym ogromnym
rozbudowaniu zasob`ow internetowych (sprz`etowych i `"osobowych")
utrzymanie centralnej bazy staje si`e wr`ecz niemo`xliwe.

WHOIS\raisebox{1.5pt}{\small ++} mia`l upora`c si`e z problemami hamuj`acymi
popularyzacj`e us`lugi `"White Pages", takimi jak:
\begin {ite}
\item utrudnione przeszukiwanie w szerokim zakresie poddrzewa danych,
\item brak og`olnie dost`epnych, `latwych w instalacji i zarz`adzaniu
implementacji,
\item du`xy balast, jaki niesie z sob`a pe`lna implementacja X.500,
obarczona konieczno`sci`a obs`lugi protoko`l`ow OSI,
\item nieadekwatno`s`c wielko`sci przedsi`ewzi`ecia zwi`azanego z instalacj`a
do potrzeb, w przypadku tworzenia katalog`ow informacyjnych ma`lych
organizacji.
\end {ite}

Model danych WHOIS jest bardzo prosty, baza sk`lada si`e z rekord`ow
o przypisanych jednoznacznych identyfikatorach (tzw.\ {\it handles}).
Rekordy mog`a zawiera`c dowolne dane. 


W modelu WHOIS\raisebox{1.5pt}{\small ++}, opisanym w dokumentach Internet--Draft \cite{whois-arch}
 i \cite{whois-index},  rekord jest nadal oznaczany poprzez {\it handle},
ale informacji
w bazie zosta`la nadana struktura. Ka`xdy rekord jest uporz`adkowanym
zbiorem element`ow b`ed`acych parami (atrybut,warto`s`c).
Poza tym wprowadzono poj`ecie typu rekordu, kt`ory specyfikuje posta`c
wy\-st`e\-pu\-j`a\-cych w nim element`ow danych.
 Zestaw dopuszczalnych typ`ow (zwanych {\it template}) okre`sla 
wszystkie akceptowane postaci danych umieszczanych w bazie.
Istnienie typ`ow rekord`ow uznano za niezb`edne w celu umo`xliwienia
prostego sposobu ograniczania zakresu przeszukiwa`n do okre`slonego
zbioru informacji (np.\ wy`l`acznie osoby, us`lugi czy dokumenty).
Mechanizm przeszukiwania bazy WHOIS\raisebox{1.5pt}{\small ++} opiera si`e na podanym
wzorcu oraz opcjonalnym zbiorze globalnych ogranicze`n, steruj`acych
wykonaniem operacji. We wzorcu mo`xe zosta`c wyspecyfikowany
typ rekordu ({\it template}), atrybut, warto`s`c lub identyfikator 
({\it handle}), dodatkowo dopuszcza si`e podanie metody wyszukania
(dok`ladne, pod`la`ncucha, wed`lug wyra`xenia regularnego itp.), 
sprawdzania zgodno`sci du`xe/ma`le litery, stosowanej tablicy kodowej itd.

WHOIS\raisebox{1.5pt}{\small ++} charakteryzuje si`e r`ownie`x prost`a architektur`a. Zosta`la on podzielona 
po\-mi`e\-dzy dwa komponenty: serwer poziomu podstawowego oraz indeksuj`acy.
W praktyce jeden serwer fizyczny mo`xe spe`lnia`c obie funkcje.

Serwer podstawowy gromadzi dane wed`lug ustalonego schematu. 
Serwer indeksowy utrzymuje informacje pomocne w wyborze w`la`sciwego
miejsca odbioru danych ({\it forward knowledge})
i zawiera wskazania do innych serwer`ow indeksowych i podstawowych.

Stosowana zasada indeksowania polega na tworzeniu na podstawie
informacji zawartej w ramach serwer`ow odwzorowania
w ogromne rekordy zwane {\it centroidami}, kt`ore
dla ka`xdego dozwolonego typu {\it template}
gromadz`a zestawy: (atrybut,wszystkie warto`sci w danej bazie). 
Informacje te s`a zarz`adzane przez serwery indeksuj`ace, zbieraj`ace
centroidy w`lasne oraz wybranych innych serwer`ow indeksuj`acych.

R`ownie nieskomplikowany jest model interakcji, czyli protok`o`l, 
wed`lug kt`orego WHOIS\raisebox{1.5pt}{\small ++} kontaktuje
si`e z innymi serwerami lub aplikacjami klienckimi.
Serwer WHOIS\raisebox{1.5pt}{\small ++} oczekuje na okre`slonym porcie na po`l`aczenia TCP, a
po nawi`azaniu `l`aczno`sci przetwarza otrzymane komendy i wysy`la
wyniki. Rozr`o`xnia si`e komendy systemowe, stosowane do cel`ow  
informacyjnych, b`ad`z sterowania prac`a oraz komend`e przeszukiwania,
kt`orej dodatkowe argumenty specyfikuj`a lokalne ograniczenia
odno`snie zakresu.


Trudno nie zauwa`xy`c, `xe podstawowa struktura danych WHOIS\raisebox{1.5pt}{\small ++} jest 
wzorowana na bazie X.500, znajdujemy w niej odpowiedniki klas obiekt`ow,
typ`ow i warto`sci atrybut`ow. Tw`orcy tego standardu w du`xej mierze korzystali
z do`swiadcze`n zebranych przy implementacji i eksploatacji X.500.
WHOIS\raisebox{1.5pt}{\small ++} uwzgl`ednia r`ownie`x rozproszone zarz`adzanie baz`a danych.
Jego architektura jest natomiast nastawiona na optymalizacj`e 
przeszukiwania rozproszonej bazy danych.

WHOIS\raisebox{1.5pt}{\small ++} jest dobrym rozwi`azaniem dla zapewnienia lokalnej us`lugi
katalogowej. Jego implementacje s`a ma`le, `latwe w instalacji, 
a interakcje pomi`edzy klientem i serwerem bardzo proste, co
nie stwarza problem`ow przy konstruowaniu interfejs`ow u`xytkowych.
Dodatkowo WHOIS\raisebox{1.5pt}{\small ++} mo`xe pracowa`c jako lokalny serwis zintegrowany
z globaln`a infrastruktur`a.

WHOIS\raisebox{1.5pt}{\small ++} nie jest, jak dotychczas, w pe`lni funkcjonaln`a
us`lug`a `"White Pages". Nie zapewnia w`la`sciwego poziomu ochrony
danach w ramach bazy, opcjonalnie dopuszcza bardzo prost`a identyfikacj`e
pytaj`acego poprzez has`lo. Nie zdefiniowano tak`xe istotnego elementu
obs`lugi baz rozproszonych --- zasad replikacji danych.
System oparty o WHOIS\raisebox{1.5pt}{\small ++} jest w zasadzie ma`lo elastyczny. Wymienione
wady s`a konsekwencj`a zamierzonego pod`a`xania do celu najprostsz`a 
drog`a. Tego typu implementacje daj`a szybki efekt, jednak na og`o`l
wkr`otce ujawniaj`a si`e wszelkie niedoci`agni`ecia i braki, szczeg`olnie
gdy nale`xy zadowoli`c zapotrzebowania i upodobania szerokiej rzeszy 
u`xytkownik`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\-`swia\-dcze\-niach zwi`azanych
z X.500, wykorzystuj`a zainicjowane w ramach X.500 `"przy\-ja\-zne" 
nazewnictwo obie\-kt`ow ({\it user friendly naming}) 
oraz koncepcje indeksowania ({\it centroidy}) sto\-so\-wa\-n`a w WHOIS\raisebox{1.5pt}{\small ++}.
Podstawowym motywem przy defincji tego standardu by`lo powstanie
systemu dostarczaj`acego z jednej strony mechanizmy prostego
tworzenia oprogramowania typu serwer-klient dla us`lugi katalogowej
oraz daj`acego dost`ep do serwer`ow pracuj`acych wed`lug innych 
protoko`l`ow ---
WHOIS czy X.500, tj.\ oprogramowania po`srednicz`acego pomi`edzy 
tymi protoko`lami (typu {\it gateway}).

SOLO oparte jest na prostym  protokole tekstowym, pracuj`acym
na platformie po`l`acze`n TCP/IP i sk`ladaj`acym si`e z dw`och 
podstawowych operacji: 

\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\raisebox{1.5pt}{\small ++} poprzez tworzenie tzw.\ {\it centroidu}, 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}

Implementacje protoko`lu SOLO s`a najpopularniejsze we Francji.
Uruchomiono tam r`o\-wnie`x wiele program`ow po`srednicz`acych pomi`edzy
serwerami wed`lug protoko`lu SOLO i X.500 a us`lug`a informacyjn`a World
Wide Web.

\subsection {DNS}

Domain Name Service to podstawowa us`luga informacyjna Internetu,
pozwalaj`aca identyfikowa`c najistotniejsze zasoby typu: domena
sieci, komputer, mailhost, adres IP, dla potrzeb niezawodnej pracy aplikacji
aplikacji sieciowych. 
Serwis DNS jest niezb`edny w ka`xdej wi`ekszej sieci komputerowej, jego
realizacja jest wbudowana w system operacyjny, a zarz`adzanie sprowadza
si`e do odpowiedniej konfiguracji tablic gromadz`acych dane w`lasnej
domeny.

\subsection { NETFIND}

Wielu u`xytkownik`ow traktuje serwis zwany Netfind 
jako internetow`a us`lug`e `"White Pages".

Netfind dzia`la w dw`och etapach. Najpierw zostaje wyszukane miejsce,
do kt`orego nale`xy skierowa`c `x`adanie, w tym celu wykorzystuje si`e 
bazy artyku`l`ow News, mapy UUCP, bazy NIC WHOIS oraz wskazania DNS.
Nast`epnie rozpoczyna si`e faza wysy`lania zapyta`n, realizowana poprzez
komend`e {\it finger}, zapytania Whois, komendy SMTP ({\it expns}, 
{\it vrfys}) oraz polecenia do serwisu DNS. 

Podstawow`a zalet`a us`lugi Netfind jest jej samotworzenie. Nie wymaga ona
uruchamiania specjalnych serwer`ow, administracji, `ladowania  danych,
aktualizacji itp. Bazuje na ist\-nie\-j`a\-cych zasobach informacyjnych.

Zasada dzia`lania Netfind, wi`a`x`aca efekt ko`ncowy z wynikami
po`srednimi pochodz`acymi z r`o`xnych `zr`ode`l, powoduje, `xe cz`esto
otrzymane rezultaty nie s`a zadawalaj`ace. 
W uzyskaniu prawid`lowego wyniku mo`xe przeszkodzi`c zawodna us`luga
DNS, niedost`epna komenda {\it finger}, zdezaktualizowana baza WHOIS.
Du`x`a przeszkod`a jest r`ownie`x fakt, `xe 
wiele o`srodk`ow internetowych instaluje w postaci  zabezpieczenia
zakazy zg`laszania si`e z okre`slonymi komendami.

Najpopularniejsz`a aktualnie form`a wykorzystania us`lugi Netfind jest
poszukiwanie u`xy\-tko\-wni\-k`ow sieci komputerowych. 
W istniej`acej postaci Netfind nie mo`xe zadowoli`c odbiorcy, 
uzyskana informacja jest uboga, pozbawiona okre`slonej struktury,
a serwis zawodny. 
Z drugiej strony
us`luga ta jest bardzo wygodna, gdy trzeba ustali`c umiejscowienie
domeny, aplikacji, serwera. Netfind mo`xe by`c w znakomity spos`ob
stosowany do wyszukiwania w`la`sciwego serwera us`lugi katalogowej
w danej domenie, czy organizacji.

Istniej`a  propozycje, aby Netfind do`l`aczy`l bazy X.500 
jako jedno z miejsc poszukiwania danych dotycz`acych organizacji
i os`ob. M`owi si`e r`ownie`x o mo`xliwo`sci pozyskiwania danych
do X.500 poprzez wysy`lanie odpowiednich zapyta`n typu Netfind.

Og`olnie, wydaje si`e, `xe Netfind nie jest ani alternatyw`a,
ani konkurentem X.500. Jego funkcjonalno`s`c jest bardzo ograniczona,
a rozw`oj na istniej`acej bazie, nie mo`xe spowodowa`c takiej poprawy,
by m`og`l by`c traktowany jako pe`lna us`luga katalogowa.



\subsection {Gopher i Veronica}
 Gopher to jeden z popularniejszych system`ow naprowadzania
i udost`epniania informacji na bazie wielopoziomowych menu.
Pozwala gromadzi`c r`o`xnego typu informacje oraz dociera`c do
danych oferowanych przez inne serwery.
R`ownie`x dane X.500 mog`a by`c widoczne z menu gophera, zapewnia
to odpowiednie oprogramowanie typu {\it gateway}.
Ilo`s`c informacji proponowana w ramach us`lugi  gopher jest
ogromna. Doprowadza to bardzo cz`esto do k`lopot`ow z dotarciem 
do poszukiwanego celu.

Systemem upraszczaj`acym zarz`adzanie dost`epem do informacji
zawartej w `swiatowych zasobach gophera jest  Veronica.
Veronica zawiera odes`lania do odpowiednich serwer`ow gopher, a
tak`xe innych serwer`ow informacyjnych, typu WWW, archiwa
Usenet itp. Tworzony indeks zasob`ow bazuje na s`lowach kluczowych
tytu`l`ow  zasob`ow informacyjnych.

W styczniu 1995 roku w indeks Veronica w`l`aczonych by`lo 5057
serwer`ow gopher i 5000 innych serwer`ow, a ilo`s`c element`ow
informacji udost`epnianej w ten spos`ob ocenia si`e na 15 milion`ow.

Z us`lugi Veronica mo`xna korzysta`c poprzez zwyk`ly kliencki interfejs
gophera. 



\subsection {WWW}

World Wide Web to w chwili obecnej najcz`e`sciej stosowana 
us`luga informacyjna Internetu. 
Oferuje prost`a w obs`ludze metod`e wyszukiwania danych, zgromadzonych
w bazach udost`epnianych przez r`o\-`x\-ne us`lugi informacyjne. 
WWW wprowadzi`l 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 mo`xe zosta`c zintegrowane z us`lug`a WWW poprzez stosowanie
odpowiedniego oprogramowania pe`lni`acego funkcj`e {\it gateway}
pomi`edzy serwerem X.500 a WWW. Baza X.500 dopuszcza umieszczanie
w niej danych typu URL, tak by mo`xna charakteryzuj`ac obiekty wskaza`c
po`lo`xenie dodatkowych opis`ow (np. zdj`e`c, d`zwi`eku) w przestrzeni
informacyjnej Internet.



\section {Proponowane usprawnienia wykorzystania X.500}

Przeciwnicy X.500 wymieniaj`a jako jeden z podstawowych zarzut`ow
zawodno`s`c oprogramowania zrealizowanego na podstawie standardu '88. 
Jest ono okre`slane jako rozbudowane, trudne w instalacji i modyfikacji,
a tworzenie nowych interfejs`ow u`xytkowych wymaga dok`ladnej znajomo`sci
szczeg`o`l`ow protoko`lu i zaimplementowanych funkcji bibliotecznych.
Dodatkowo, w ramach konkretnych pakiet`ow niezb`edne by`lo wprowadzenie
pozastandardowych rozszerze`n, by zapewnieni`c funkcjonalno`s`c systemu.
Oczywi`scie tego typu dzia`lania prowadz`a do wyst`epowania  niekompatybilno`sci
pomi`edzy implementacjami. M.in.\ w oprogramowaniu QUIPU zosta`la
dodana obs`luga operacji replikacji danych pomi`edzy serwerami (wg. RFC1276
\cite{rfc1276}).


Prace nad protoko`lem X.500 by`ly kontynuowane i 
zaowocowa`ly  nowym standardem,
zwanym X.500~'93.

Jego najistotniejsze cechy to:
\begin {itemize}
\item dodany protok`o`l replikacji informacji, tzw. {\it shadowing}
z mo`xliwo`sciami:
\begin {itemize}
\item utrzymywania kopii ca`lego poddrzewa lub jego fragment`ow,
\item wyboru atrybut`ow replikowanych,
\item wykonania replikacji na w`lasne `x`adanie lub z inicjatywy 
wysy`laj`acego kopi`e,
\item dokonywania pe`lnej kopii lub ograniczenie do fragment`ow,
kt`ore uleg`ly zmianie ({\it incremental}),
\end {itemize}
\item wbudowanie schematu danych w baz`e X.500:
\begin {itemize}
\item `"formularze" zawarto`sci hase`l, regu`ly nazewnictwa,
\item powi`azanie zasady dopasowywania z zawarto`sci`a has`la,
\item wyodr`ebnienie atrybut`ow operacyjnych --- dotychczas
wszystkie traktowano jako u`xy\-tko\-we,
\end {itemize}
\item zdefiniowanie zasad kontroli dost`epu ({\it access control}),
\item modyfikacja operacji protoko`lu mi`edzy DUA a DSA, m.in.\
wprowadzenie stronicowania wynik`ow operacji listowania i przeszukiwania.
\end {itemize}

Nowe implementacje wed`lug standardu '93 s`a w trakcie opracowywania,
przewiduje si`e stopniowe przej`scie do pe`lnej zgodno`sci.
Standard '93 otwiera mo`xliwo`sci zwi`ekszenia funkcjonalno`sci X.500,
przede wszystkim dzi`eki rozbudowanemu protoko`lowi replikacji.

Trwaj`aca ju`x 5 lat eksploatacja X.500 pokaza`la, jaki rodzaj 
informacji jest najcz`e`sciej poszukiwany poprzez `"White Pages" i w jaki
spos`ob u`xytkownicy generuj`a swoje zapytania.

Badania statystyczne najpopularniejszego interfejsu  X.500 ---
programu {\tt de}, wykazuj`a, `xe na og`o`l u`xytkownik w zapytaniu
nie podaje nazwy organizacji, w ramach kt`orej ma nast`api`c przeszukanie,
lub podaje niedok`ladn`a nazw`e. Poza tym cz`esto wykorzystywany jest
tryb {\tt de} zwany {\it power search}, w kt`orym nast`epuje r`ownoleg`le
wyszukiwanie w domenach administracyjnych wszystkich organizacji
danego kraju.

Hierarchiczno`s`c bazy X.500 pozwala `latwo dokonywa`c przeszukiwa`n
w obszarach poddrzew ({\it naming context}). 
Jeden z podstawowych wymog`ow funkcjonalnych --- operacje znalezienia
informacji w przypadku ma`lo precyzyjnego sformu`lowania miejsca poszukiwania
s`a w X.500 bardzo uci`a`xliwe lub niemo`xliwe.
Oznacza to w obecnej sytuacji konieczno`s`c prze\-gl`a\-da\-nia rozleg`lych obszar`ow,
a nawet ca`lego drzewa danych DIT i wymaga `laczenia  z du`x`a ilo`sci`a serwer`ow.
Jest to cz`esto niemo`xliwe 
(poprzez ustalenie administracyjnego zakazu), a przede wszystkim
niepraktyczne.

Tego typu problemy s`a charakterystyczne dla wszelkiego rodzaju
baz rozproszonych, zawsze te`x s`a rozwi`azywane jedn`a metod`a ---
poprzez stosowanie techniki indeksowania.
Podobne potrzeby spowodowa`ly utworzenie us`lugi archie
dla FTP, czy Veronica dla przestrzeni gopher.

Zosta`l ju`x sprecyzowany niezb`edny opis funkcjonalny serwer`ow 
indeksowych w ramach
X.500 (\cite{barker}). Serwery takie nastawione na gromadzenie 
hase`l pochodz`acych z r`o`xnych obszar`ow DIT i zawiera`lyby odsy`lacze do
miejsc zarz`adzania danym fragmentem poddrzewa, lub do serwer`ow dysponuj`acych
kopi`a po`x`adanej informacji.

Wprowadzenie indeksowych DSA jest z punktu widzenia u`xytkowego
rzecz`a naturaln`a, jednak realizacja tego przedsi`ewzi`ecia by`la
niemo`xliwa przy braku jednoznacznej definicji operacji replikacji
pomi`edzy serwerami X.500; standard '93 t`e barier`e prze`lamuje.

Indeksowe serwery X.500 mia`lyby docelowo zosta`c zintegrowane 
jako wskazania w us`ludze WWW, bierze si`e r`ownie`x pod uwag`e
konieczno`s`c umieszczania w ramach indeks`ow wskaza`n do serwer`ow
`"White Pages" pracuj`acych wed`lug innej technologii (WHOIS\raisebox{1.5pt}{\small ++}, SOLO).

Implementacje wed`lug standardu '93 s`a w stanie zapewni`c
szybszy dost`ep do danych nawet bez stosowania indeksowych DSA,
je`xeli zostanie w`la`sciwie wykorzystana technika replikacji danych. 
Administrator
serwera X.500 mo`xe w`owczas odpowiednio do potrzeb `srodowiska
skonfigurowa`c DSA tak, aby pobiera`c i utrzymywa`c lokalnie kopie
po`x`adanych informacji. 
 

Kolejnym problemem wymagaj`acym rozwi`azania w X.500 jest zapewnienie
mo`xliwo`sci za\-w`e\-`xo\-ne\-go przeszukiwania poddrzewa. Taka potrzeba
pojawia si`e, gdy poszukiwany jest obiekt o okre`slonym typie, np.
organizacja i wiadomo, `xe nie jest wymagane przegl`adanie hase`l
wy\-st`e\-pu\-j`a\-cych najni`xej w hierarchii drzewa ({\it leaf entries}).


\begin{thebibliography}{99}
\bibitem{CCITT}Data Communication Networks: Directory, Recommendations 
X500-X.521, CCITT, Fascile VIII.8 of Blue Book
\bibitem{ISO} The Directory --- Overview of Concepts, Models and Service,
 ISO/IEC 9594 
\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{rfc1491} C. Weider, R. Wright {\it A Survey of Advanced Usages of X.500}
Request for Comments RFC1491\\
{\small URL=$<$ftp://ds.internic.net/rfc/rfc1491.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\raisebox{1.5pt}{\small ++} service}, Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/drafts-ietf-wnils-whois-arc
h-03.txt$>$}
\bibitem{whois-index} C. Weider, J. Fullton, S. Spero (1994)
{\it Architecture of the WHOIS\raisebox{1.5pt}{\small ++} Index Service}, Internet Draft\\
{\small URL=$<$ftp://ds.internic.net/internet-drafts/drafts-ietf-wnils-whois-04.
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{barker} P. Barker (1995) {\it X.500 Index DSAs}

\end{thebibliography}

\end {document}

