W zrost zainteresowania WWW jako platform ą aplikacyjną spow o
dował oczyw iste poszukiwania efektywnych środow isk program o
wania. Dziś, dzięki istniejącej ofercie technologicznej, programista i projektant mogą wybierać spośród wielu różnorodnych metod budo
wy oprogramowania, wykorzystującego zawartość bazy danych do dynam icznego generowania dokum entów HTM L prezentow anych przez przeglądarkę użytkownika. Od dokonanego wyboru bedą
jed-nak znacząco zależały: czas budowy, elastyczność i wydajność two
rzonych system ów.
W dalszej części artykułu dokonano analizy porównawczej czte
rech, wybranych jako najpopularniejsze, platform rozwoju bazo-da
nowych aplikacji internetowych (tabela 1). Trzy z nich wykorzystują system zarządzania bazą danych Oracle, a jeden - w celu odniesienia do pozostałej części rynku produktów WWW - Microsoft SQL S en er.
Wszystkie środowiska zostały krótko scharakteryzowane, a następ
nie porów nane pod kątem najczęściej form ułow anych kryteriów.
W celu uzyskania prezentowanych tutaj wniosków, dokonano ekspe
rymentalnej implementacji identycznego systemu internetowego (księ
garnia internetowa) na każdej z platform.
Charakterystyka platform rozwoju aplikacji internetowych
Or a c l e Ap p l ic a t io n Se r v e r iP L /SQ L Ca r t r id g e
Oracle Application Server (OAS), poprzednio nazywany Oracle Web Server, jest obecną od kilku lat na rynku silną platformą udostępnia
nia trójw arstw ow ych aplikacji internetow ych, w spółpracujących z bazą danych Oracle. OAS realizuje funkcjonalność nowoczesnego serw era HTTP, a dodatkowo je s t w yposażony w środow iska uru
chomieniowe (kartrydże), pozwalające na wykonywanie niewielkich aplikacji, dynamicznie generujących dokum enty HTML, przesyłane
do przeglądarki WWW użytkownika. Kartrydże OAS obsługują apli
kacje tworzone w języku PL/SQL, Java, C/C++, Perl, standard Li- veHTML (odpowiednik Server Side Includes), standard Oracle Worlds (automatyczne generowanie światów wirtualnych VRML). Programi
ście związanemu dotychczas z narzędziami Oracle, najbardziej atrak
cyjny wyda się kartrydż PL/SQL.
A rchitekturę funkcjonow ania oprogram ow ania internetow ego, opartego na kartrydżu PL/SQL i OAS, przedstawiono na rysunku 5.
Program ista przygotow uje aplikację generującą dokum ent HTML jako procedurę składowaną, zapisaną w bazie danych. Procedura taka
stawie skojarzenia nazwy katalogu wirtualnego z zapisami w plikach konfiguracyjnych naw iązyw ane je s t połączenie z serw erem bazy danych. W b azie danych u ru ch am ian a je s t w ów czas p ro ced u ra o nazwie podanej przez użytkownika jako przedostatni człon adresu URL. Z adresu tego m ogą być odczytane rów nież w ejścio w e param etry je j w yw ołania. W oparciu o zaw artość bazy danych, uruchom iona procedura generuje na standardowym wyjściu kody HTML, które są odbierane przez OAS, a następnie przesyłane do przeglądarki WWW, która zainicjowała cały proces.
Ap a c h e We b Se r y e r i Or a c l k Ca l l In t e r f a c e
Praktycznie każdy popularny serwer WWW (jak np.
Apache Web Seryer) dostarcza mechanizmów woła
nia z ew n ę trzn y c h p ro g ram ó w w y k o n y w aln y ch , które m ogą generow ać kod HTM L przesyłany do przeglądarki W W W użytkownika. Najpowszechniej
szym standardem komunikacji pomiędzy serwerem WWW a innym programem zewnętrznym jest Call Gateway Interfa
ce (CG1). Program y w ołane poprzez C C I (często nazyw ane „pro
gram am i C G T ') m o g ą być tw o rz o n e w d o w o ln y ch ję z y k a c h programowania: C/C++, Pascal, Perl, UNIX Shell, D O S Batch, itd.
Jeżeli wymagany jest dostęp programu CGI do bazy danych Oracle, w tedy program ista zmuszony jest do samodzielnego oprogram owa
nia kom unikacji z serw erem O racle - najw ydajniejszym , chociaż najbardziej skom plikow anym interfejsem kom unikacyjnym w śro
dowisku serwera Oracle je s t Oracle Call Interface (OCI).
Architekturę funkcjonowania oprogramowania opartego na CGI i O C I przedstawiono na rysunku 6. Program ista przygotowuje pro
gram w ykonyw alny, który przy pom ocy interfejsu O C I nawiązuje połączenie z bazą danych, wysyła do niej treść zapytania SQL, odbiera wyniki zapytania i na ich podstawie generuje kody HTML. W celu wykonania programu, użytkownik, korzystając z przeglądarki WWW, wysyła do serwera Apache żądanie w postaci adresu URL, zawierają
cego adres serwera, nazwę katalogu wirtualnego, nazwę programu i jego parametry wejściowe. Adres URL jest następnie analizowany przez Apache i na podstawie skojarzenia nazwy katalogu wirtualnego z zapi
sami w plikach konfiguracyjnych lokalizowany jest fizyczny katalog dyskowy, w którym znajduje się program o podanej nazwie. Przed uruchomieniem programu, w środowisku systemowym definiowany jest zbiór zmiennych CGI, pod które podstawiane są takie wartości.
Nazwa środowiska Serwer WWW Interfejs z bazą danych
Oracle Web Listener PL/SQL Cartridge dowolny serwer bazy danych
Apache+ CGI + OCI Apache OCI dowolny serwer WWW
Afxiche + Ja w +
SYSTEMY INFORMACYJNE
jak: adres 1P klienta, nazwa przeglądarki WWW klienta, wersja proto
kołu HTTP, itd. Jedną ze zm iennych je s t QUERY_STR1NG, pod którą podstaw iany jest tekst zaw ierający w szystkie param etry
wy-wolania programu CGI, wyłonione z adresu URL. Program CG1 od
czytuje potrzebne zmienne środowiskowe, komunikuje się z bazą da
nych i na swoim standardowym wyjściu (stdout) generuje kody HTML.
Kody te są odbierane przez serwer Apache i przesyłane do przeglądar
ki WWW użytkownika, który zainicjował proces.
A p a c h e W e b S e r v e r iJD B C
Od kilku lat systematycznie rośnie popularność nowego obiektowe
go języka programowania Java. Java umożliwia tworzenie interesu
jącego typu aplikacji, nazywanych appletami. Applet Java to niewielki program, znajdujący się w systemie plików serwera WWW, który na
żądanie u żytkow nika je s t przesyłany przez sieć i w ykonyw any w ewnątrz przeglądarki WWW. Ważną zaletą appletów Java jest ich przenaszalność i niezależność od platformy - ten sam applet może
być wykonyw any zarówno przez przeglądarkę N etscape Navigator w systemie Solaris, jak i przez przeglądarkę Microsoft Internet Explo
re r w sy stem ie W indow s N T. A p p lety m o g ą się kom u n ik o w ać
z serwerami baz danych - służy do tego celu uniwersalny standard i zarazem biblioteka Java Database Connectivity (JDBC).
A rchitekturę funkcjonow ania oprogram ow ania opartego na ap- pletach J a va i JD B C p rzed staw io n o na rysunku 7. Program ista przygotow uje i kom piluje kod appletu, który będzie naw iązyw ać połączenie z bazą danych poprzez JD B C oraz obsługiwać interfejs użytkow nika. D odatkow o, tw o rzo n y je s t d okum ent H T M L p e ł
niący rolę pojemnika, w którym osadzony jest applet. Po otrzym a
niu żądania przesianego przez przeglądarkę W W W użytkow nika, serw er W W W p rz esy ła b azo w y d o k u m en t H T M L , a n a stęp n ie
applet Ja va . A pplet urucham iany je s t p rzez przeglądarkę WWW i kom unikuje się z bazą danych w celu pobrania rekordów i ich zaprezentow ania na ekranie.
adres URL, np.:
h ttp ://serw er /k a ta l0 1 /p ro c0 1 ? x = 1 0 & y = 2 0 ..
klient WWW
dokument HTML, np.:
< H l> P ra co w n icy < /H l>
Kowalski<BR>
Nowak<BR>
Zieliński <BR>
Application Server
kartrydż P L /S Q L
w ywołanie procedury proc01(10,20)
htp.header('Pracownicy',l);
for rekord in (select name from emp) loop
htp.print( rekord.name);
htp.br;
end loop
katalOl = kartrydż PL/SQL, baza TEST, użytkownik SCOTT, hasto TIGER
pliki
konfiguracyjne
baza danych, np.:
baza TEST, użytkownik SCOTT, hasto TIGER
Rys. 5. A rc h ite k tu ra fu n k c jo n o w a n ia O ra c le A p p lic a tio n S e rv e r i P L /S Q L C a r tr id g e
adres URL, np.:
* ? h t t p : / / s e r w e r / k a t a l 0 1 / p r o g 0 : Ł 7 x g l 0 & y = 2 0 ^
klient WWW
dokument HTML, np.:
< H l> P ra co w n lcy < /H l>
Kowalskl<BR>
Nowak<BR>
Zieliński <BR>
wywołanie programu
progOl kody HTML
zmienne
środow iskow e -QUERY_STRING =
prog01?x=10& y=20
p ro g r a m EXE O ra c le C ali In te r fa c e
zapytania SQL
► rekordy wynikowe
Apache Web Server ■ H
...
- ... ... ...^
* katalOl = program CGI,
katalog C:\PROG pliki
konfiguracyjne
baza danych
Rys. 6. A rc h ite k tu ra fu n k c jo n o w a n ia A p a c h e W eb S e rv e r, C G I i O C I
informatyka 5/2000
27A pache W eb Server ad res URL, np.:
h ttp ://se r w e r /k a ta l0 1 /d o k u m e n t-h tm l
a p p let Java
JDBC
dok u m en t HTML + a p p let Java klient WWW
rekordy w yn ik ow e
zapytania SQL
d ok u m en t HTML z od w ołan iem do ap p letu
a p p let Java
Rys. 7. A rc h ite k tu ra fu n k c jo n o w a n ia a p p letó w J a v a i JD B C
Mic r o s o f t In t e r n e t Da t a b a se Co n n e c t o r iSQ L Se r v e r
SQ L Server jest flagowym bazo-danowym produktem Microsoftu.
Do publikowania jego zawartości w sieci Internet wykorzystywany jest Internet Database Connector (IDC), związany z Internet Infor
mation Serverem, wchodzącym z kolei w skład Windows N T Server.
Program ow anie prostych aplikacji internetow ych nie w ym aga od program isty znacznych umiejętności - sprow adzają się one do po
znania przez niego składni poleceń języka SQL oraz składni poleceń
ment przesyła do przeglądarki W W W użytkow nika, który zainicjo
w ał cały proces.
Porównanie środow isk rozwoju aplikacji internetowych
Ł atw ość i szybkość budow y aplikacji
Pod hasłem łatwości budowy aplikacji rozumiano m.in. liczbę linii kodu, jakie musi przygotować programista dla uzyskania podobnego
ID C, służących do formatowania dokum entu HTML zawierającego w yniki zapytań.
Architekturę funkcjonowania oprogramowania opartego na IDC i SQL Server przedstawiono na rysunku 8. Program ista przygoto
wuje dwa pliki tekstowe: plik o rozszerzeniu SQL, zawierający treść polecenia SQL pobierającego rekordy z bazy danych i plik o rozsze
rzeniu IDC, zawierający szkieletowy dokum ent HTM L, do którego włączone zostaną rekordy wynikowe. Żądanie przesłane przez prze
glądarkę W W W użytkow nika odw ołuje się do pliku IDC. Serwer W W W - Intern et Information Server - odczytuje pliki ID C i SOL (o takiej samej nazwie, jak IDC), wykonuje zapytanie z pliku SQL, rekordy w ynikow e włącza do szablonu HTM L i ostateczny
doku-efektu wynikowego. Rozmiar kodu w pływa pośrednio na szybkość jeg o tw orzenia i łatwość utrzymywania.
Zdecydowanie najm niejszy rozm iar ma kod źródłowy aplikacji dla IDC/SQL Server - z praktycznego punktu widzenia, poza zapy
taniem SQL nie istnieje tam nawet kod źródłowy. Podobnie niewielki rozm iar m ają aplikacje O AS/PL/SQ L Cartridge. Przeciętny doku
m ent HTM L m oże zostać w ygenerow any przy użyciu kilku-kilku- nastu wierszy kodu źródłowego w języku PL/SQL.
D użo pracy m usi w łożyć program ista w budow ę program ów w ykorzystujących O C I bądź J D B C do sam odzielnej kom unikacji z bazą danych. Najmniejsze aplikacje wykonane w takich technolo
giach to dziesiątki wierszy kodu. Ponadto, OCI i JD B C nic są
po-SYSTEMY INFORMACYJNE
pulamie wykorzystywane w innych zastosowaniach, w związku z czym konieczne będzie podniesienie kwalifikacji programisty.
E lastyczność a p lik a cji
Ta kategoria porównawcza reprezentuje swobodę programisty w zakre
sie wykorzystywania różnorodnych technik i rozwiązań programistycz
nych. Im większa jest elastyczność oferowana przez środowisko, tym większy jest zakres zastosowań przygotowanych w nim aplikacji.
Pełną sw obodę m a program ista w środow iskach CG I/Java - wynika ona z własności obiektowych języków programowania 3GL.
Możliwe jest wykorzystywanie dostępnych na rynku bibliotek pro
gram ow ych, złożone i wydajne przetw arzanie obliczeniow e oraz dostęp do wszelkich zasobów system owych.
E lastyczność P L/SQ L C artridge w yznaczona jes t przez w ła
sności języka PL/SQL. Składnia PL/SQL przypom ina Pascal/Ada, podobne są zatem możliwości konstrukcji program owych. Progra
mowanie jest nie-obiektowe, programista czuje się hermetycznie za
mknięty w ew nątrz bazy danych.
N atom iast ID C nie oferuje praktycznie żadnej elastyczności.
Programista formułuje zapytanie SQL i otacza jeg o wyniki kodem HTML. N ie istnieją możliwości algorytmicznego przetwarzania da
nych i w yników zapytań. Jest to cena, ja k ą należy zapłacić za ła
twość stosow ania.
K oszt śro d o w isk a
W niewielkich zastosowaniach W W W istotna jest cena, jak ą należy zapłacić za platformę, na której pracują aplikacje internetowe. Naj
droższym z rozważanych rozwiązań jest niewątpliwie OAS/PL/SQL Cartridge - cena instalacji sięga 20 tysięcy złotych. Prawie dwukrot
nie tańszy jest wariant Microsoft IDC. Ceny minimalne - od 8 tysię
cy złotych (w yłącznie koszt serw era O ra cle -C i Java są zw ykle dostępne bezpłatnie) oferow ane są przez środow iska w ykorzystu
jące JD BC i OCI.
W y m ag an ia system ow e i sp rzęto w e
W ym agania d efiniow ane p rzez producentów w ykorzystyw anych rozwiązań dotyczą głównie rozmiaru dostępnej pamięci operacyjnej serwera WWW. Dla uzyskania zadowalających w'ynikôw prowadzo
nych testów należało zapewnić:
O 96 MB RAM dla OAS (64 MB) i serwera bazy danych Oracle (32 MB),
O 32 MB RAM dla M icrosoft IDC/SQL Server,
O 32 MB RAM dla A pache (pom ijalne) i serw era bazy danych Oracle (32M B) (z CGI lub JDBC).
W ydajność
Wydajność pracy aplikacji internetowych wiąże się głównie ze spraw
ną obsługą dużej liczby równoczesnych, krótkich żądań. Wewnętrz
na złożoność obliczeniow a aplikacji wydaje się być pom ijalna, ze względu na prostotę przetwarzania (głównie obsługa we/wy).
Z tej kategorii porównawczej należy wyodrębnić aplikacje budo
w ane w form ie appletów Java, poniew aż, jak o w ykonyw ane po stronie klienta, nie generują one rozważanego obciążenia obliczenio
wego serwera. Skalow alność takiego rozw iązania je s t absolutna - teoretycznie każda liczba appletów Java może pracować równocze
śnie na nieograniczonej liczbie komputerów-klientów.
Natomiast pozostałe rozwiązania szeregują się według malejącej w ydajności w następujący sposób:
1. OAS - w yposażony w zaaw ansow ane m echanizm y buforow a
nia, równow ażenia obciążenia, przekierowywania połączeń, itd.
jes t środow iskiem najlepiej dostosow anym do obsługi bardzo dużych ilości połączeń,
2. M icrosoft ID C - brak szczególnych rozw iązań ukierunkow a
nych na optymalizację obsługi żądań,
3. CGI/OCI - najmniej wydajna platforma, głównie ze względu na technologię CGI. Dla obsługi każdego żądania musi być uruchomio
ny oddzielny proces w systemie operacyjnym. Narzuty systemo
we związane z każdorazowym powoływaniem do życia nowego procesu są ogromne w porównaniu z prostotą samego przetwarza
nia realizowanego przez programy wykonywane w ramach tych procesów.
Przeprow adzone porów nanie nie dostarcza prostej odpow iedzi na pytanie: „Jaka jes t najlepsza platform a rozwoju aplikacji interneto
wych ?”. Podstawą do jej udzielenia powinna być dokładna specyfi
kacja wymagań, dotyczących złożoności i skalowalności budowanych aplikacji, a także ograniczeń o charakterze sprzętowo-finansowym . Niew ątpliw ie najbardziej zaaw ansow anym technicznie jest Oracle Application Server - bardzo dobra jest jego wydajność, na wyróżnie
nie zasługuje elastyczność i łatwość budowy aplikacji. Najtańszymi i postulującymi najmniejsze wymagania zasobowe (finansowe i sprzę
towe) będą te, które korzystają z serwera Apache (bezpłatny) i m e
chanizmów CG1/Java. Z kolei jeżeli aspiracje przedsiębiorstw a nie są równoległe do kierunku rozwoju Internetu, a kilka prostych apli
kacji powinno powstać minimalnym nakładem sił - wtedy zdecydo
wanie godne polecenia jest „user-friendly" M icrosoft IDC.
L ite r a tu r a
[ 1 ] A na liza porów naw cza środow isk rozwoju aplikacji in terneto
wych, Raport techniczny. Instytut Informatyki, Politechnika Po
znańska, 1999.
[2 ] Niem eyer P., Peck J., E xploring Java, O ’Reilly & A ssociates, Inc., 1996.
[3 ] Berners- LeeT., FieldingR., Frystyk H „ Hypertext Transfer Pro
tocol — H TTP/1.0, Internet Draft.
[4] Naik D.C., In tern et Standards and Protocols, M icrosoft Press, 1998.
[ 5 ] A . van Hoff, Shaio S., Starbuck O ., Java. H e lio n , 19 9 6 . [6] P e r l s t e i n L , Java™ 2 Platform: Technology f o r th e Enterprise,
httn://iava.sun.com /.
[7] M icro so ft In ter n et D atabase C onnector, D okum entacja tech
niczna.
[8j Oracle A pplication Server, Dokumentacja techniczna.
[9] Oracle Call Interface, Dokumentacja techniczna.
[IO JRobinson D.R.T., The W W W C om m on Gateway Interface Ver
sion 1.1, Internet Draft.
M aciej Z a k rzew icz, prof. Z b y s z k o K róliko w ski Politechnika Poznańska, Instytut Informatyki E-mail: Zbvszko.Krolikowski@ cs.out.Doznan.pl.
m zakrz@ cs. put.poznan.pl