Warstwa pośrednia:Oracle9i AS czy aplikacje linuksowe?

Ewa Palarczyk
ewa.palarczyk@mp.pl

Na podstawie dokumentacji technicznej i wiadomości znalezionych w Internecie

Model funkcjonowania e-biznesu obejmuje trzy warstwy – warstwę
baz danych, warstwę aplikacji użytkownika końcowego i warstwę pośrednią.
Jakie technologie internetowe stosować w warstwie środkowej mając system
operacyjny Linux? O ile kwestia funkcjonowania bazy danych na Linuksie została
przeze mnie omówiona (Oracle’owe PLOUG’tki nr 23 i 24), niezwykle
ciekawie wygląda tworzenie tutaj warstwy pośredniej. Warstwa aplikacji operuje
przede wszystkim na technologiach typu Java (J2EE, J2ME), XML, a w przypadku
Linuksa, charakterystyczną technologią jest również PHP. Tworzenie
oprogramowania warstwy pośredniej może być realizowane dwojako – po pierwsze,
przy pomocy aplikacji „linuksowych” – czyli programów tworzonych z
myślą o Linuksie, z przeznaczeniem na ten system operacyjny. Drugą opcją
jest wykorzystanie serwera aplikacji dostarczanego przez Oracle – chodzi oczywiście
o Oracle9i AS. W pierwszym przypadku wiąże się to z wykorzystaniem wielu
aplikacji i modułów pełniących określone funkcje. W drugim – wszystkie
zadania realizowane w warstwie pośredniej wykonywane są jedynie przez serwer
aplikacji.

Trudno jednoznacznie określić, jak wyglądałaby warstwa pośrednia
w modelu wykorzystującym oddzielne aplikacje, jako że mnogość tych programów
skutkuje wieloma możliwymi konfiguracjami, a co za tym idzie funkcjami
realizowanymi przez warstwę. Na pewno wariant ten wymaga szerszej wiedzy
administratora, nie tylko bardzo dobrej znajomości systemu operacyjnego Linux,
zwłaszcza w zakresie kompilacji i konfiguracji aplikacji ze źródeł, ale również
znajomości wielu programów i ich poszczególnych modułów, wykorzystywanych
do realizacji określonych zadań. Takie rozwiązanie na pewno jest niezwykle
czasochłonne i złożone, umożliwia natomiast optymalne skonfigurowanie
warstwy pośredniej. Tu ujawnia się wielka zaleta Linuksa i oprogramowania open
source
– nawet jeżeli okaże się, że nie ma na rynku programu czy modułu,
który pracowałby w określony sposób, zawsze mamy dostęp do źródła i możliwość
takiej modyfikacji aplikacji, aby się zachowywała dokładnie tak, jak tego
oczekujemy. Co więcej, mając problemy z aplikacją, nie mogąc znaleźć
przyczyny jej nieprawidłowego działania, zawsze można przestudiować kod,
znaleźć prawdziwe źródło problemu i dokonać ewentualnych poprawek.

W przypadku serwera aplikacji Oracle9i działającego pod
Linuksem, nasze pole manewru jest do pewnego stopnia ograniczone (to samo ma
miejsce np. w przypadku baz Oracle ) – nadmierna ingerencja administratora w źródła
aplikacji (np. serwera Apache) lub Linuksa (przykładowo rekompilacja jądra) –
powoduje, że tracimy „gwarancję” ze strony Oracle. W tej sytuacji
należy dokładnie czytać zasady użytkowania oprogramowania Oracle, żeby dokładnie
wiedzieć co i do jakiego stopnia możemy modyfikować. Generalnie standardowa
konfiguracja serwera Apache związanego z Oracle9i AS odcina nam drogę od
korzystania z PHP jako modułu serwera, czyli najpowszechniej stosowanej
konfiguracji.

Rozwiązanie I: Apache i co do niego…

Oczywiście niemożliwością jest omówienie wszelkich możliwych
konfiguracji aplikacji warstwy pośredniej. Postaram się zaprezentować
konfigurację wykorzystującą serwer WWW, środowisko PHP (można zaryzykować
stwierdzenie – nierozerwalnie związane z Linuksem, tu wykorzystywane między
innymi jako parser XML), oczywiście XML i technologie J2EE.

Punktem wyjścia konstruowania warstwy pośredniej w oparciu
o aplikacje „linuksowe” jest oczywiście Apache. Większości użytkowników
nazwa Apache kojarzy się jednoznacznie z serwerem HTTP. Tymczasem w ramach
projektu Apache tworzone są aplikacje oparte na Java, serwletach, XML, Tcl,
Perl. Pozwolę sobie wymienić najważniejsze projekty realizowane w ramach
grupy Apache, spośród których będziemy wybierać elementy do naszej układanki:

  • serwer HTTP, czyli punkt wyjścia wszelkich działań.
  • Jakarta – grupa projektów opartych o technologie Java, z
    najbardziej znaną aplikacją – maszyną serwletów Tomcat.
  • Cocoon – środowisko prezentacji XML w aplikacjach po
    stronie serwera, wykorzystujące technologie XSLT. Przetwarzanie odbywa się
    poprzez SAX. Cocoon umożliwia odseparowanie zawartości (treści) od logiki
    i stylu.
  • Apache XML – zajmuje się rozwijaniem aplikacji XML, w
    tym tych pozostających w związku z innymi projektami Apache.
  • Apache Web Services – rozwijane technologie związane z
    Web Services; przede wszystkim: SOAP, XML-RPC, UDDI, WSDL.
  • PHP – język skryptowy przeznaczony do tworzenia z założenia
    prostszych (niż Java) aplikacji internetowych. Język od początku swego
    powstania związany z Uniksem/Linuksem. Bardzo lubiany i powszechnie
    stosowany w środowisku linuksowym, można zaryzykować twierdzenie, że
    cieszy się tu większym powodzeniem od technologii Java.
  • James – czyli Java Apache Mail Enterprise Server, jest w
    stu procentach napisanym w Javie serwerem pocztowym (protokoły SMTP i POP3)
    i serwerem newsów (protokół NNTP). Zaprojektowany został w ten sposób,
    aby pełnić rolę kompletnego i przenośnego silnika poczty do rozwiązań
    biznesowych, wspierającego otwarte protokoły.
  • Avalon – ramowy zestaw komponentów Java,
    wykorzystywanych później w różnorakich aplikacjach.
  • Apache DB – jak sama nazwa wskazuje, w tej grupie
    znajdziemy aplikacje do obsługi baz danych.
  • Apache Ant – narzędzie oparte na Javie, odpowiadające
    linuksowemu programowi make.

Oczywiście, w ramach każdego projektu znajdziemy całą masę
aplikacji, nad którą dana grupa pracuje. Z punktu widzenia aplikacji
e-biznesowych chciałabym zwrócić uwagę na kilka z nich, jako że mogą być
bardzo przydatne przy konstruowaniu własnego zestawienia aplikacji warstwy pośredniej.
Zacząć należy oczywiście od maszyny serwletów i Java Server Pages (JSP),
czyli aplikacji Tomcat. Interesującym projektem jest Slide – system zarządzający
treścią (content), implementujący protokół WebDAV. Wymieniając
dalej: Jetspeed – wygodny dla użytkownika system portalowy, czy Cactus,
przeznaczony do testowania kodu Java po stronie serwera (między innymi serwlety,
EJB, biblioteki, filtry).

Kolejną ważną grupą aplikacji stanowią projekty związane
z XML. W ramach tej grupy najważniejszymi z naszego punktu widzenia aplikacjami
na pewno są Xerces zawierający parsery XML w Javie i C++, z powiązaniami do
Perla i COM; Xalan, czyli procesory arkuszy XSLT (w Javie i C++). Dalej wymienić
należy Cocoon – środowisko publikacji XML w Javie (o tym nieco więcej w
dalszej części artykułu) i jego odpowiednik w mod_perl, czyli AxKit.
Wymieniając dalej: FOP – obiekty formatujące XML w Javie, Xang – moduł do
rozbudowy dynamicznych stron po stronie serwera (w Javie), SOAP (Simple Object
Access Protocol, implementacja protokołu), Crimson – alternatywny parser XML w
Javie. Znajdziemy tu nawet bazę danych w XML – Xindice.

Nie można sobie wyobrazić struktury aplikacji e-biznesowych
nie zawierającej serwera HTTP. A jeśli Linux, to oczywiści Apache! Serwer
HTTP Apache jest nie tylko najbardziej powszechnym serwerem stron jeśli chodzi
o Linuksa, ale również globalnie ma największy udział w rynku- szacuje się,
że ponad 60% serwerów HTTP na świecie to różne wersje serwera Apache. Również
Oracle9i AS bazuje na serwerze Apache. W oparciu o Apache 1.3.27 chciałabym
zaproponować, wydaje mi się ciekawą, konfigurację obejmującą PHP z
wbudowanym parserem XML i Cocoon jako środowisko publikacji parsowanego
dokumentu XML (do którego potrzebny nam będzie Tomcat i wirtualna maszyna Javy).

Instalację serwera możemy przeprowadzić z pakietu,
powiedzmy RPM (dla większości dystrybucji linuksowych, np. Red Hat). Taka
instalacja, pomimo iż łatwiejsza, jest tym samym znacznie ograniczona, dlatego
polecam instalację serwera ze źródeł, gdzie już w procesie instalacji mamy
możliwość podania określonych parametrów Apache’a i tym samym
zbudowania go zgodnie z naszymi potrzebami. PHP będzie wkompilowane do serwera
jako moduł dynamiczny (DSO – Dynamic Shared Object), dzięki czemu uzyskamy większą
elastyczność pracy serwera, możliwość dodawania bądź odejmowania
wybranych modułów „w locie”, w trakcie pracy serwera.

Instalacja i kompilacja serwera Apache wersja 1.3.27 (w
przypadku wersji 2.0.x opcje konfiguracji nieco się różnią) przebiega następująco:

  1. Dekompresja źródeł serwera z pakietu
    apache_1.3.24.tar.gz poleceniem tar -xvzf apache_1.3.24.tar.gz
  2. Przejście do katalogu z rozpakowanymi źródłami –
    apache_1.3.24 i uruchomienie skryptu ./configure z opcją –prefix=/usr/local/apache,
    wskazującą na katalog domowy serwera.
  3. Zbudowanie Apache: polecenia make a następnie make
    install.
  4. Sprawdzenie czy serwer działa poprzez uruchomienie
    skryptu apachetl z opcją start w /usr/local/apache/bin.
  5. Ponieważ Apache ma obsługiwać dynamicznie moduły (obsługa
    DSO), po upewnieniu się, że serwer działa prawidłowo, należy zatrzymać
    go i wrócić do katalogu ze źródłami, a następnie wydać polecenia
    tworzące te moduły. Przykładowo, chcąc dodać maksymalną liczbę modułów,
    można zastosować poniższe opcje, zamiast wymieniać sporą liczbę modułów
    (potem te, z których nie będziemy chcieli korzystać, możemy w dowolnej
    chwili wyłączyć):
    ./configure -prefix=/usr/local/apache -enable-shared= max -enable-module=most

    Następnie należy wydać polecenie make i make install. Dwa moduły nie mogą
    zostać w ten sposób utworzone, o czym poinformuje kompilator. Moduły te
    zostaną dodane do pliku konfiguracyjnego httpd.conf.default. Należy zmienić
    temu plikowi nazwę na httpd.conf, nadpisując aktualny httpd.conf (dla
    bezpieczeństwa warto zrobić kopię). Moduły obsługiwane dynamicznie mają
    rozszerzenie so. W pliku konfiguracyjnym są włączane poprzez dyrektywę
    LoadModule np. LoadModule rewrite_module libexec/mod_rewrite.so.
    Moduły powinny znajdować się jako pliki wykonywalne w katalogu /usr/local/apache/libexec.
    Dodatkowo w pliku httpd.conf poniżej dyrektywy LoadModule, dany moduł musi
    być wpisany przy dyrektywie AddModule (odpowiednio AddModule mod_rewrite.c).
    W razie problemów, należy sprawdzić czy jest uruchomiony moduł mod_so,
    który powinien być dodany automatycznie przy kompilacji. Jeżeli nie został
    skompilowany, należy w katalogu ze źródłami Apache wydać polecenie ./configure
    -enable-module=so , a następnie zbudować pakiet. Przy kompilacji
    pakietu z przeznaczeniem do pracy z Oracle należy pamiętać o bibliotece
    pthread.

  6. Następnie możemy ponownie uruchomić serwer Apache. Aby
    sprawdzić, czy Apache działa poprawnie, wystarczy w dowolnej przeglądarce
    go wywołać np. lynx 127.0.0.1 lub lynx localhost. Przeglądarka powinna wyświetlić
    stronę domową Apache. W tym celu musi być uruchomiona usługa /etc/rc.d/init.d/network.

Mając działający serwer HTTP, można rozpocząć instalację
PHP, przykładowo php-4.2.1, które posiada w sobie mechanizmy obsługi XML (między
innymi parser XML). PHP zostanie skompilowany (ze źródeł, chociaż dostępny
jest również w postaci pakietów RPM) jako dynamiczny moduł serwera Apache.
Należy to przeprowadzić w następujący sposób:

Po dekompresji i przejściu do utworzonego katalogu php-4.2.1
należy uruchomić skrypt konfiguracyjny

./configure -with-apxs=/usr/local/apache/bin/apxs

Aby korzystać z połączeń z bazą Oracle należy dodać również
opcję -enable-sigchild

  1. wydanie poleceń make i make install
  2. Po zbudowaniu pakietu należy skopiować z bieżącego
    katalogu plik php.ini.dist do /usr/local/apache/lib/php.ini
  3. Kolejnym krokiem jest sprawdzenie czy w httpd.conf zostały
    dodane linie: LoadModule php4_module libexec/libphp4.so i dalej AddModule
    mod_php4.c
  4. Należy również pamiętać o wpisaniu w pliku
    konfiguracyjnym Apache dyrektywy AddType application/x-httpd-php .php, aby
    Apache rozpoznawał pliki z rozszerzeniem .php
  5. Po uruchomieniu Apache powinniśmy sprawdzić, czy PHP
    działa prawidłowo poprzez utworzenie pliku test.php o zawartości <?phpinfo()?>
    i otworzenie go w przeglądarce: lynx localhost/test.php. Efektem takiej
    funkcji powinno być otworzenie strony domowej PHP w oknie przeglądarki.
  6. Aby móc wykorzystywać PHP jako parser XML należy pamiętać
    o kompilacji, mającej na celu dodanie biblioteki expat do serwera Apache:
    ./configure -with-xml, dalej oczywiście make i make install. Krok ten
    można wykonać w dowolnym miejscu wcześniej.

Powyższe rozwiązanie w zupełności wystarczy do mniej
zaawansowanych rozwiązań. Możemy z tego poziomu parsować dokumenty XML,
komunikować się z bazą danych za pomocą PHP (rozszerzenia do obsługi baz
Oracle, wymagające bibliotek klienta Oracle), wykonywać skrypty PHP. W
momencie, gdy zechcemy korzystać z technologii JSP, serwletów, czy też chociażby
publikować parsowany dokument XML, konieczne jest dodanie nowych elementów do
naszej warstwy pośredniej. Tymi nowymi elementami będą maszyna serwletów i
JSP Tomcat i środowisko publikacji ZML – Cocoon.

Serwer Tomcat działa na dowolnej maszynie wirtualnej Javy
(od wersji 1.1). Pracuje jako niezależny proces, komunikujący się z serwerem
HTTP z wykorzystaniem specjalnego protokołu AJP (Apache JServ Protocol). Po
stronie serwera Apache konieczna jest instalacja modułu przekierowującego żądania
klientów do odpowiedniego serwera aplikacji. Taka architektura umożliwia
skalowanie całego systemu – moduł w serwerze HTTP może równoważyć obciążenie
wielu serwerów aplikacji, działających na oddzielnych maszynach. Obydwa
pakiety są wielowątkowe, zaś w serwerze Tomcat zaimplementowano dość
zaawansowane mechanizmy zarządzania wątkami (pula wątków). Dostępne są
mechanizmy autoryzacji połączenia – przesyłane dane mogą być opatrywane
sygnaturą MD5. Serwlety mogą być uruchamiane samodzielnie lub obsługiwać
wybrane rodzaje plików (można je przypisywać plikom odpowiednich typów),
rozszerzając w bezpieczny sposób funkcjonalność serwera – odpowiednie
skojarzenia definiujemy w pliku konfiguracyjnym serwera HTTP.

Cocoon napisany jest w postaci serwletu Java, pozwalającego
na publikowanie dokumentów XML, dynamicznie przekształcanych do HTML. Trójwarstwowy
model publikowania przy pomocy Cocoona obejmuje: treść (dokumenty XML),
prezentację (arkusze XSL) oraz logikę publikacji. Cocoon nadaje się do
dynamicznego generowania HTML na podstawie źródeł w XML i arkuszy stylów.
Proces generowania dokumentu rozpoczyna się od utworzenia pliku lub strumienia
XML. Projektanci zajmujący się tworzeniem treści strony mają do dyspozycji
kilka mechanizmów. Jednym z nich jest język XML rozszerzony o elementy DCP,
umożliwiające wywoływanie metod lub pobieranie wartości zmiennych ze skryptów
napisanych w JavaScript lub klas Java. Logika może więc powstawać całkowicie
niezależnie od treści stron. Inna możliwość, to tworzenie dokumentów XML
zawierających odwołania do systemów baz danych i zapytania SQL. Można też
po prostu czytać pliki XML bezpośrednio z dysku. Zaawansowani programiści
Cocoon mogą tworzyć własne mechanizmy generujące XML. Treść dokumentu jest
następnie przesyłana do mechanizmu formatującego, gdzie na podstawie
wybranego stylu XSL powstaje ostateczna wersja dokumentu. System potrafi wykryć,
z jakiego oprogramowania korzysta klient i wygenerować dokument przy użyciu
odpowiedniego stylu (np. WML, czy różne odmiany HTML). Cocoon obsługuje zarówno
XSLT jak i XSLFO. Przetwarzanie odbywa się potokowo, a informacje przepływają
w postaci zdarzeń SAX. Na koniec zdarzenia te są serializowane w postaci XML/HTML
lub dowolnego innego formatu danych.

Aby zainstalować Cocoon, należy wcześniej mieć w systemie
wirtualną maszynę Javy i maszynę serwletów w wersji 2.2 do obsługi operacji
serwletów i obsługi dynamicznych żądań.

Instalacja maszyny serwletów Tomcat i środowiska
prezentacji Cocoon przebiega następująco:

  1. Na początku należy ustawić zmienną środowiskową
    JAVA_HOME, aby odnosiła się do odpowiedniego katalogu JDK:
    JAVA_HOME=/usr/local/lib/java
  2. Po dekompresji źródeł Tomcata, należy ustawić
    CATALINA_HOME na katalog, który powstał po dekompresji.
  3. Uruchomienie Tomcata odbywa się poprzez wywołanie
    skryptu:
    $CATALINA_HOME/bin/startup.sh
  4. Mając zainstalowany poprawnie serwer Tomcat, można
    przejść do instalacji środowiska publikacji Cocoon. Na początku należy
    oczywiście zdekompresować źródła.
  5. Kolejnym krokiem, jaki trzeba wykonać, jest skopiowanie
    pliku cocoon*/cocoon.war do $CATALINA_HOME/webapps
  6. Następnie należy zrestartować Tomcata przy pomocy
    skryptów:
    $CATALINA_HOME/bin/shutdown.sh
    $CATALINA_HOME/bin/startup.sh
  7. W tej chwili powinniśmy mieć utworzony podkatalog
    $CATALINA_HOME/webapps/cocoon

Oczywiście, w powyższym przykładzie przedstawiłam jedynie
najważniejsze i niezbędne aplikacje, natomiast – zależnie od potrzeb –możemy
daną konfigurację wzbogacić o dodatkowe moduły, które mogą znacznie
rozszerzyć funkcjonalność tego modelu. Jak widać, takie skonfigurowanie
aplikacji warstwy pośredniej jest dość czasochłonne i skomplikowane, ale
obok możliwości konfiguracji odpowiadającej całkowicie naszym potrzebom, ma
jeszcze jedną bardzo istotną zaletę – jest całkowicie darmowe! Istotną wadą
jest jednak to, iż nie możemy liczyć na wsparcie producenta, aczkolwiek mamy
do dyspozycji całe grupy developerów pracujących nad open source.
Jednocześnie, takie rozwiązanie pociąga za sobą konieczność znajomości
wielu różnych technologii realizujących zadania warstwy pośredniej,
firmowanych przez różnych producentów, podczas gdy wykorzystując Oracle9i AS
mamy do czynienia z jednym produktem integrującym wielorakie funkcje.

Rozwiązanie II: Oracle9i AS

Drugie rozwiązanie wykorzystuje prawdziwy
„kombajn”, jakim jest serwer aplikacji Oracle9i. Zaletą tego rozwiązania
jest przede wszystkim to, iż od razu otrzymujemy wszystkie potrzebne nam
aplikacje, nie musimy tym samym szukać, planować, dostrajać różnych programów
do poprawnej współpracy. Serwer aplikacji Oracle9i jest niezwykle ważnym
produktem rozwijanym na linuksowym systemie operacyjnym. Przypominając w kilku
słowach funkcjonalność i zadania realizowane przez Oracle9i AS, należy
powiedzieć, iż jest on oparty na technologii umożliwiającej przedsiębiorstwom
zawężenie warstwy pośredniej do jednego punktu integracji. Integracja ta
oznacza, że poprzez serwer aplikacji rozdzielane będą aplikacje nie tylko
firmowane przez Oracle, ale również innych producentów. Tym samym rola
serwera aplikacji jest nie do przecenienia w internetowych systemach biznesowych
typu B2B, ERP czy CRM. W styczniu bieżącego roku ukazała się nowa wersja
serwera – Oracle9i AS R2 9.0.4, mająca jeszcze bardziej zredukować złożoność
i zawęzić przepływy biznesowe.

Serwer aplikacji Oracle9i jest zintegrowaną platformą J2EE,
przeznaczoną do rozwiązań biznesowych, łączącą technologie do tworzenia i
dystrybucji portali e-biznesowych, aplikacje do obsługi transakcji i Web
services
. 9i AS wspiera najważniejsze technologie internetowe takie, jak
Java, XML, Web Services. Podstawą serwera aplikacji Oracle9i jest
maszyna J2EE stworzona przy pomocy czystej Javy, dzięki czemu jest ona całkowicie
niezależna sprzętowo i systemowo. iAS jest również oparty na serwerze HTTP
Apache, przy czy mamy tu bardzo ograniczone możliwości wprowadzenia własnych
zmian, czy dodania modułów. Przykładowo dodanie modułu PHP, chociaż jest
ono z technicznego punktu widzenia możliwe, oznacza utratę wsparcia ze strony
Oracle dla takiej konfiguracji. Wszystkim zainteresowanym przypominam, że
serwer aplikacji Oracle9i był omawiany na łamach Oracle’owych
PLOUG’tek w numerach 18, 19 i 20.

Podsumowanie

Proces dostosowania Linuksa dla potrzeb biznesu na szeroką
skalę trwa nadal. Małe, średnie i duże przedsiębiorstwa, oraz sektor
publiczny na całym świecie (niestety w Polsce na tym rynku rządzi
niepodzielnie Microsoft i nic nie zapowiada jakichkolwiek zmian) wykazują stale
rosnące zainteresowanie tego typu rozwiązaniem. Z jednej strony przyciągani są
wyższą stopą zwrotu na inwestycji, niższym całkowitym kosztem użytkowania
(TCO), a w przypadku jednostek państwowych, główną determinantą jest
poparcie dla rozwoju konkurencyjności i innowacji systemów, dzięki pracy społeczności
open source. Oracle – w porę dostrzegając ten kierunek rozwoju rynku IT
– wprowadził, a raczej udoskonalił pod kątem pracy na Linuksie, nie tylko
bazy, ale również inne swoje produkty na rynek linuksowy, zapewniając im
intensywne wsparcie ze swojej strony.

Trudno jednoznacznie powiedzieć, które rozwiązanie – tworzenie własnej
konfiguracji warstwy pośredniej, czy zastosowanie przeznaczonego do tego celu
serwera aplikacji Oracle9i – jest korzystniejsze. Wybór zależy na pewno od
indywidualnych preferencji, a także od takich czynników jak przyzwyczajenia,
wygoda czy środki finansowe. Należy podkreślić, że możliwości obu rozwiązań
są do siebie zbliżone, różnią się natomiast sposoby i narzędzia umożliwiające
realizację określonych zadań.