Techniki tworzenia aplikacji internetowych dla bazy danych Oracle

Transkrypt

1 Rozdział 38 Techniki tworzenia aplikacji internetowych dla bazy danych Oracle Streszczenie. Twórcy bazodanych aplikacji internetowych mają do dyspozycji wiele technik ich tworzenia. Wybór najwłaściwszej z nich do realizacji konkretnego projektu musi być poprzedzony głęboką analizą wszelkich ich wad oraz zalet. W rozdziale skupiono się na omówieniu technik możliwych do zastosowania dla baz danych Oracle. Są wśród nich rozwiązania dedykowane wyłącznie dla tej bazy, jak również bardziej uniwersalne, które mają jednak bardzo silne wsparcie ze strony systemu Oracle. W rozdziale omawiane są takie techniki jak: PL/SQL, PSP, rozwiązania dla Javy (w ramach specyfikacji J2EE, głównie: serwlety, strony JSP, JavaBeans, Enterprise JavaBeans, Web Services), pakiet Oracle Developer Suite, pakiet HTML DB, Platforma.NET, język PHP, skrypty CGI. Rozdział kończy się zbiorczą tabelą podsumowującą wady i zalety wszystkich omawianych technik. 1 Wstęp Statyczne strony WWW (tworzone w czystym HTML-u) zaczynają coraz bardziej tracić na znaczeniu na rzecz stron generowanych dynamicznie. Mówiąc o generowaniu dynamicznym, mamy zwykle na myśli tworzenie stron WWW w taki sposób, że pewna część pojawiających się na nich informacji jest zawsze statyczna i niezmienna (np. nagłówek strony, menu itp.) a część jest zmienna i zależy od różnych czynników. Typowym przykładem są tutaj wszelkiego rodzaju sklepy internetowe, gdzie dużo (jeśli nie większość) pojawiających się na stronie WWW informacji pochodzi z zasobów przechowywanych w bazach danych (zwykle relacyjnych), które to zasoby mają z oczywistych względów bardzo zmienny charakter (oferta produktów nieustannie zmienia się). Chcąc więc tworzyć wspomniane wyżej dynamiczne strony WWW, musimy zapewnić możliwość skomunikowania się serwera HTTP z właściwą bazą danych. Firma Oracle od dawna udostępnia takie możliwości, równocześnie ciągle wzbogacając i udoskonalając swoją ofertę. W rozdziale skupiono się na przedstawieniu, siłą rzeczy bardzo skrótowym, wszystkich najważniejszych technik tworzenia aplikacji internetowych możliwych do zastosowania dla baz danych Oracle [1]. Podstawową platformą uruchomieniową jest w tym przypadku serwer aplikacyjny Oracle Application Server (AS) [3], [4], [5], [24], którego najważniejszym komponentem jest Oracle HTTP Server bazujący na technologii Apache [6], [20]. AS to Artur Gramacki, Jarosław Gramacki: Uniwersytet Zielonogórski, Instytut Informatyki i Elektroniki, ul. Podgórna 50, , Zielona Góra, Polska {a.gramacki, j.gramacki}@iie.uz.zgora.pl

2 A. Gramacki, J. Gramacki potężne narzędzie (również w sensie wymagań hardware-owych oraz ceny!) i w prostszych zadaniach jego zastosowanie może nie być uzasadnione ekonomicznie. Możliwe jest jednak użycie oryginalnego (darmowego) serwera Apache z odpowiednimi modułami towarzyszącymi (również darmowymi). 2 PL/SQL oraz strony PSP (PL/SQL Server Pages) Aplikacje internetowe w języku PL/SQL [9] działają na zasadzie wywoływania z poziomu przeglądarki internetowej procedur i funkcji PL/SQL zeskładowanych w bazie danych. Kluczową rolę pełni tutaj moduł serwera HTTP o nazwie mod_plsql [10], [20]. Za pomocą odpowiednich pakietów (podstawowe znaczenie mają tutaj procedury htp.print i htp.prn) możliwe jest wysyłanie do przeglądarki poleceń HTML przekazanych im jako argument. W ten sposób można w łatwy sposób generować dynamiczne strony HTML. Ponadto wewnątrz kodu PL/SQL można osadzać kod SQL co zapewnia nam pełną kontrolę nad zgromadzonymi danymi. Aplikacje internetowe pisane w języku PL/SQL w żaden sposób nie oddzielają kodów HTML od logiki aplikacji tworzonej w języku PL/SQL i SQL. Dlatego też firma Oracle zaproponowała rozwiązanie o nazwie PSP (ang. PL/SQL Server Pages) nieco podobne do stron JSP oraz ASP (rozwiązanie firmy Microsoft). Dzięki temu mamy możliwość osadzania w plikach HTML (za pomocą odpowiednich znaczników) fragmentów kodów w PL/SQL. Programista tworzy dokumenty PSP, które następnie muszą być załadowane do bazy danych za pomocą narzędzia o nazwie loadpsp. Narzędzie to w swej istocie tłumaczy dokument PSP na równoważny mu kod PL/SQL i składuje go w bazie danych na zwykłych zasadach. Nie występują tu więc żadne różnice w wydajności czy stabilności aplikacji. 3 Platforma J2EE Firma Oracle bardzo intensywnie wspiera specyfikację J2EE [4], [18], która stanowi swego rodzaju ogólną platformę tworzenia oraz uruchamiania modułowych aplikacji w rozproszonym środowisku internetowym. W przypadku bazy danych Oracle podstawową platformą uruchomieniową jest serwer aplikacyjny Oracle Application Server. Serwer ten został przez Oracle wyposażony w wiele modułów rozszerzających jego funkcjonalność. Jednym z takich modułów jest mod_oc4j [10] implementujący specyfikację J2EE. Nosi on nazwę Oracle Containers for J2EE (OC4J). W najnowszej wersji (w chwili pisania tekstu numer ) kontener OC4J jest zgodny ze specyfikacją J2EE w wersji 1.3. Wspiera on wiele różnych technik (szczegóły patrz [4], [5], [12]), z których najważniejsze to: serwlety, wersja 2.3, strony JSP, wersja 1.2, Enterprise JavaBeans, wersja 2.0, Web Services, wersja 1.2, JDBC, wersja 2.0 (Oracle JDBC-OCI driver type 2 oraz Oracle JDBC driver type 4). 318

3 3.1 Serwlety oraz strony JSP (Java Server Pages) Techniki tworzenia aplikacji internetowych dla bazy danych Oracle Serwlety oraz JSP [11] to aplikacje napisane w języku Java, które uruchamiane są po stronie serwera WWW a ich zadaniem jest generowanie dynamicznych stron HTML odsyłanych następnie do przeglądarki internetowej. Dostęp do baz danych, podobnie jak w przypadku innych aplikacji w języku Java, odbywa się w oparciu o standardy JDBC oraz SQLJ. Różnica pomiędzy serwletami a JSP jest istotna w zasadzie tylko dla programisty, gdyż z punktu widzenia serwera WWW jest to jedno i to samo. Mianowicie przy pierwszym odwołaniu do pliku JSP jest on automatycznie tłumaczony do postaci równoważnego serwletu i każde kolejne odwołanie do dokumentu JSP powoduje uruchomienie tego właśnie serwletu. Z punktu widzenia programisty istnieją pewne różnice w stylu programowania. Nie wnikając w tej chwili w szczegóły można powiedzieć tylko tyle, że kod JSP jest bardziej zwarty niż odpowiadający mu kod w postaci serwletu. Tworząc serwlet zanurzamy w kodzie Javy kod HTML, natomiast w przypadku dokumentów JSP jest dokładnie odwrotnie: wewnątrz statycznych stron HTML umieszczamy odpowiednie wstawki języka Java (używając tzw. biblioteki znaczników ang. tag library można tworzyć dokumenty JSP nie zawierające żadnych fragmentów kodu w języku Java). 3.2 Enterprise JavaBeans Specyfikacja Enterprise JavaBeans (EJB) wywodzi się bezpośrednio ze specyfikacji Java- Beans (JB, dosł. ziarna Javy ) [18], [11]. Są to klasy Javy, mające postać komponentów nadających się do wielokrotnego użycia w aplikacjach Java. Poszczególne komponenty (ziarna stąd nazwa) można łatwo łączyć ze sobą w celu stworzenia złożonej aplikacji. Z racji swojej jednolitej budowy poszczególne komponenty mogą być tworzone niezależnie przez różnych programistów a następnie mogą ze sobą bez problemów współpracować. Każde ziarno posiada pewne właściwości, które mogą być odczytywane bądź ustawiane. Kiedy właściwość ulega zmianie, ziarno może wyzwolić pewne zdarzenie i poinformować o tym otoczenie (np. inne ziarno). EJB są swego rodzaju rozwinięciem idei JB. O ile jednak JB są dedykowane dla aplikacji działających po stronie użytkownika, o tyle EJB definiują sposób tworzenia rozproszonych aplikacji sieciowych działających po stronie serwera aplikacji. Jest to standard Javy służący do tworzenia aplikacji w architekturze trójwarstwowej. Projektant czy też programista może skoncentrować się ściśle na tworzeniu logiki aplikacji. Natomiast o takie detale jak np. obsługa transakcji, obsługa sesji, sposób składowania, wyszukiwania i modyfikowania danych dba sam EJB. 3.3 Web Services Usługa sieciowa Web Services [17], [18] to pewien użyteczny program (najczęściej jest to klasa Javy), do którego uprawnieni użytkownicy mają zdalny dostęp za pośrednictwem Internetu. Usługa sieciowa wykonuje pewne działanie i zwraca wyniki do wywołującego ją programu. Praca odbywa się w trybie RPC (ang. Remote Procedure Call). Usługi sieciowe mogą pełnić rolę zdalnych bibliotek wspomagających i/lub rozszerzających funkcjonalność innych programów (zwykle tworzonych też w języku Java, choć nie jest to wymóg konieczny). 319

4 A. Gramacki, J. Gramacki Do komunikacji wykorzystywany jest protokół SOAP (ang. Service-Oriented Access Protocol). Jest to protokół ogólnego przeznaczenia zaprojektowany do przesyłania poprzez sieć Internet komunikatów XML. Komunikaty te zwykle są opakowywane w protokół HTML i w tej postaci łatwo transportowane). W praktyce do zarządzania tzw. repozytorium usług sieciowych obok protokołu SOAP korzysta się też z protokółów WSDL (ang. web services description language, mówi do czego służy dany serwis, gdzie się znajduje, jak go wywołać) oraz UDDI (ang. universal discovery, description and intergration, rejestr dostępnych usług Web Services). Przykładem usługi sieciowej Web Services może być aplikacja udostępniająca zdalnym klientom kursy walut. Jeżeli usługa taka będzie świadczona np. przez bank centralny danego kraju, to mogą z niej korzystać pozostałe banki. Nie ma wówczas potrzeby dobudowywania do istniejących systemów informatycznych tych banków indywidualnych rozwiązań zapewniających otrzymywanie aktualnych kursów walut. W zamian za to można skorzystać ze wspólnego, ujednoliconego rozwiązania. Poniższy rysunek ilustruje zasadę Web Services. SOAP Request Program klienta HTML Komunikat XML (np.: pobierz kurs PLN / EUR) HTML Komunikat XML (np.: odeślij kurs PLN / EUR) Web Services (np.: przelicznik kursów walut) SOAP Response Rys. 1. Zasada działania Web Services 3.4 Środowisko projektowe Oracle JDeveloper Oracle JDeveloper [22] to zintegrowane środowisko programistyczne do tworzenia, debugowania oraz udostępniania w sieci Internet (ang. deploying) aplikacji Java (np. aplikacji typu Web Services). Środowisko to zawiera wiele zintegrowanych ze sobą narzędzi do przeprowadzenie wszystkich etapów tworzenia rozproszonych aplikacji w środowisku internetowym. Wspiera on specyfikację J2EE, w szczególności w zakresie tworzenia appletów, serwletów, JavaBeans, Enterprise JavaBeans oraz Web Services. JDeveloper zawiera również wbudowany serwer OC4J (patrz kolejny rozdział), który pozwala łatwo testować tworzone aplikacje J2EE przed ich ostatecznym umieszczeniem w warstwie serwera aplikacyjnego. Pracę z bazą danych Oracle zapewniają dołączone do środowiska JDeveloper sterowniki JDBC. 4 Pakiet Oracle Developer Suite Pakiet Oracle Developer Suite (DS) [23] to zintegrowane środowisko programistyczne typu RAD (ang. Rapid Application Development) umożliwiające tworzenie aplikacji interneto- 320

5 Techniki tworzenia aplikacji internetowych dla bazy danych Oracle wych. Ponieważ aplikacje kodowane są w języku PL/SQL, który jest bardzo silnie powiązany z systemem Oracle, dlatego też tworzone w pakiecie DS programy są w zasadzie nieprzenoszalne do innych systemów bazodanowych (można natomiast wewnątrz aplikacji DS umieszczać kody napisane w języku Java, co pozwala nieco zmniejszyć hermetyczność środowiska DS). Mówiąc o aplikacjach DS mamy na myśli formularze (tzw. formatki ekranowe) do wprowadzania i edycji danych oraz raporty do prezentacji wyników. Pierwsze tworzone są w module o nazwie Forms, drugie natomiast w module Reports. Na rysunkach 2 oraz 3 pokazano przykłady odpowiednio formularza oraz raportu utworzonego z wykorzystaniem pakietu DS. Rys. 2. Przykład formularza do wprowadzania i edycji danych utworzony w module Forms pakietu Developer Suite Rys. 3. Przykład raportu utworzonego w module Reports pakietu Developer Suite 321

6 A. Gramacki, J. Gramacki Wcześniejsze wersje pakietu (do wersji 6 włącznie) umożliwiały tworzenie wyłącznie aplikacji klienckich w klasycznej architekturze dwuwarstwowej. Do ich uruchamiania wymagane było wcześniejsze zainstalowanie na komputerach użytkowników tzw. runtime-u, czyli niewielkiego objętościowo oprogramowania, umożliwiającego uruchomienie utworzonej w pakiecie DS aplikacji. Wersja 6i miała już możliwość pracy w środowisku internetowym, lecz było to środowisko raczej mało popularne. W praktyce zdecydowana większość deweloperów używała wersji 6i do budowy wyłącznie klasycznych aplikacji w architekturze dwuwarstwowej. Najnowsze wersje 10g (a wcześniej 9i, obie wersje różnią się minimalnie) wprowadzają bardzo istotną zmianę. Nie jest już możliwe tworzenie samodzielnych aplikacji typu runtme (za wyjątkiem pewnych szczególnych przypadków dotyczących modułu raportowego). W zamian za to można je uruchamiać wyłącznie w przeglądarkach internetowych. Aplikacje Forms uruchamiane są jako (bardzo rozbudowane) aplety, natomiast aplikacje Reports jako serwlety lub strony JSP [13], [14]. Należy również podkreślić, że samo środowisko programistyczne zmieniło się bardzo nieznacznie i w praktyce migracja do wersji 9i/10g nie nastręcza dla programisty większych problemów (czego nie można niestety powiedzieć o przenoszeniu gotowych aplikacji z wersji 6/6i do wersji 9i/10g tu problemy są czasem dużo większe). Ogólnie należy uznać DS za udany produkt umożliwiający tworzenie stabilnych i szybko działających aplikacji. Jego opanowanie jednak wymaga sporo czasu. Pewnym mankamentem mogą być nieco odstające od obecnych standardów możliwości łatwego tworzenia złożonych formatek korzystających z GUI. Brak jest przykładowo obiektów typu grid, który de facto stał się standardem w aplikacjach bazodanowych i pochodnych. Aplikacje DS mogą być uruchamiane w środowisku WWW (ang. deployment) w dwóch trybach. Pierwszy nie wymaga instalacji pełnej wersji serwera aplikacyjnego. Mamy wówczas do czynienia z tzw. środowiskiem standalone. Drugi tryb wymaga posiadanie serwera aplikacyjnego wraz z odpowiednimi modułami do uruchamiania formularzy i raportów. Mówimy wówczas o tzw. trybie enterprise. Zawracamy w tym miejscu uwagę, że różnice, o których tu mówimy dotyczą wyłącznie sposobu uruchamiania gotowych już aplikacji DS. Środowisko projektowe jest tylko jedno i nie zmienia się wraz ze zmianą trybu uruchamiania. Tryb standalone wykorzystuje dostarczany przez firme Oracle mały dedykowany serwer (tzw. kontener) o nazwie OC4J (ang. Oracle Containers for J2EE) [12]. Jest to w istocie niewielki serwer HTTP/HTTPS obsługujący serwlety, strony JSP, moduły EJB oraz inne technologie definiowane w specyfikacji J2EE. Jego niewątpliwą zaletą są małe rozmiary i niewielkie zapotrzebowanie na zasoby sprzętowe. Wadą (zwłaszcza w środowisku produkcyjnym) jest niewielka wydajność i konieczność ręcznej edycji dość złożonych plików konfiguracyjnych. Z kolei tryb enterprise wymaga pełnej instalacji serwera aplikacyjnego, który jest bardzo zasobożerny i trudny w administrowaniu. Daje on jednak zdecydowanie większe możliwości konfiguracji, zarządzania i skalowalności. Podobnie jak w wersji standalone wykorzystywany jest tutaj też kontener OC4J, jednak tym razem nie działa on jako samodzielny serwer HTTP/HTTPS tylko jest pośrednikiem pomiędzy serwerem WWW (Apache) a aplikacją Java. Należy w tym miejscu również wspomnieć o pakiecie Oracle AS Forms and Reports Services 10g [23]. Jest to okrojona wersja pełnego serwera aplikacyjnego, przygotowana dla tych użytkowników, którzy zamierzają uruchamiać głównie aplikacje Forms oraz Reports i nie maja potrzeby wykorzystywania pełnych możliwości serwera aplikacyjnego. Wymagania sprzętowe tej wersji są jednak również znaczne, zbliżone w zasadzie do pełnej wersji serwera aplikacyjnego. 322

7 Techniki tworzenia aplikacji internetowych dla bazy danych Oracle Na rysunku 4 pokazano schematycznie różnice pomiędzy uruchamianiem aplikacji w wersji standalone oraz enterprise. a) Web browser b) HTTP HTTPS OC4J Container OC4J Remote Method Invocation (ORMI) Klient JAVA Web browser HTTP HTTPS HTTP Server (Apache) mod_oc4j AJP 1.3 OC4J Container ORMI Klient JAVA Rys. 4. Środowisko uruchomieniowe aplikacji Developer Suite w wersji standalone (a) oraz enterprise (b). 5 Pakiet HTML DB HTML DB [2], [15], [16] to najnowsza propozycja firmy Oracle skierowana do twórców aplikacji internetowych. Pojawił się on wraz z nową bazą danych Oracle 10g. Jest to kompletne środowisko do budowy aplikacji internetowych. Narzędzie HTML DB obsługiwane jest wyłącznie z poziomu przeglądarki internetowej i tylko z tego poziomu użytkownik wykonuje wszelkie czynności konfiguracyjne, projektuje i implementuje aplikację i w końcu udostępnia ją użytkownikom końcowym. Aby efektywnie używać tego narzędzia nie jest konieczne zbyt wielkie doświadczenie programistyczne choć jego brak może skutecznie odstraszyć przyszłego użytkownika. Pakiet HTML DB nie jest wcale taki prosty, jak by to mogło się z pozoru wydawać. Należy więc wyraźnie doprecyzować o jakich twórców aplikacji tutaj chodzi. Na pewno nie są to doświadczeni developerzy, piszący swoje aplikacje w takich językach jak Java, PHP czy PL/SQL (lub inne języki programowania). Oni z pewnością będą postrzegali pakiet HTML DB jako niezbyt poważny produkt do mało ważnych i raczej prostych zastosowań. I tak jest w istocie. Twórcy pakietu HTML DB tworzyli go od samego początku dla osób, które muszą w miarę szybko (w ciągu kilku dni a nie tygodni, czy miesięcy) stworzyć dość ładnie wyglądającą aplikację o podstawowej funkcjonalności, nie posiadając przy tym wiedzy i doświadczenia w tworzeniu aplikacji internetowych. Aplikację w HTML DB tworzy się w zasadzie niemal całkowicie przy użyciu wielu, często bardzo rozbudowanych, kreatorów. Oznacza to, że twórca aplikacji nie musi (przynajmniej teoretycznie) znać żadnego normalnego języka programowania, aby poradzić sobie z budową aplikacji. Jeżeli dodatkowo zadowoli się predefiniowanymi szablonami graficznymi i nie będzie chciał zbytnio zmieniać założonego przez twórców HTML DB poziomu złożoności aplikacji, jest w stanie tworzyć je w iście ekspresowym tempie. Niestety, to co jest zaletą dla niewprawnego programisty, będzie z pewnością dużą wadą dla kogoś bardziej doświadczonego. Taka osoba z pewnością niezbyt chętnie sięgnie po to 323

8 A. Gramacki, J. Gramacki narzędzie. Ilości okienek, które trzeba przejść, aby zbudować nawet najprostszą aplikację wystawia na ciężką próbę cierpliwość programisty. Wydaje się, że potencjalnymi użytkownikami pakietu HTML DB mogą być również administratorzy baz danych Oracle, gdyż jak pokazują przykłady wielu firm (czy tylko polskich?), administrator bardzo często zmuszony jest do tworzenia, mniej lub bardziej złożonych aplikacji bazodanowych. Zwykle tworzy je on niejako z doskoku, gdyż jego podstawowym obowiązkiem jest oczywiście dbanie o bezpieczną pracę serwerów bazodanowych. Można więc spodziewać się, że pakiet HTML DB zostanie w tej grupie użytkowników przyjęty jeżeli nie entuzjastycznie to na pewno z pewnego rodzaju przychylnym zainteresowaniem. Pakiet HTML DB z technicznego punktu widzenia stanowi bardzo rozbudowaną aplikację internetową napisaną z wykorzystaniem bramki sieciowej PL/SQL (patrz rozdział 2). Wymagany jest więc serwer WWW (Apache) z prawidłowo skonfigurowanym modułem mod_plsql. Serwer taki jest automatycznie instalowany i konfigurowany w czasie instalowania pakietu HTML DB. Na ryunku 5 pokazano przykładową aplikację demonstracyjna stworzoną w pakiecie HTML DB (jest ona instalowana domyślnie). Łatwo zauważyć, że jej szata graficzna jest utrzymana w konwencji innych oficjalnych aplikacji firmy Oracle (np. Enterprise Manager). Być może nie wszyscy zdają sobie sprawę z tego, że bardzo popularny w świecie serwis AskTom (asktom.oracle.com) zbudowany został z wykorzystaniem pakietu HTML DB. Pakiet ten wykorzystany został w tym serwisie do utworzenia warstwy prezentacyjnej. Logiką aplikacji zajmuje się z kolei pakiet Oracle Text. Rys. 5. Wygląd przykładowej aplikacji demonstracyjnej utworzonej w HTML DB 324

9 Techniki tworzenia aplikacji internetowych dla bazy danych Oracle 6 Inne techniki Mimo tego, że firma Oracle dostarcza dedykowane narzędzia i techniki tworzenia aplikacji internetowych, możliwe jest oczywiście wykorzystywanie rozwiązań bardziej uniwersalnych. Niektóre z nich ( jak np. omawiane poniżej skrypty CGI) nie są w praktyce zbyt często stosowane (wynika to głównie z ich znanych ograniczeń). Inne (np. język PHP) ze względu na lawinowo rosnącą popularność i łatwość użycia, coraz mocniej opanowują rynek aplikacji internetowych dla bazy danych Oracle. 6.1 CGI CGI (Common Gateway Interface) [21] jest specyfikacją interfejsu pomiędzy serwerem WWW a programami użytkownika. Jest to najstarsza i w sumie najbardziej uniwersalna technika tworzenia skryptów serwerowych. Innymi słowy CGI to rodzaj mechanizmu umożliwiający uruchamianie po stronie serwera WWW dowolnego programu, przy czym polecenie jego uruchomienia dociera do serwera za pośrednictwem przeglądarki internetowej użytkownika. W szczególności uruchamianym programem może być program komunikujący się z bazą danych i wykonujący na niej określone operacje. Technika CGI nie jest związana z żadnym konkretnym językiem programowania. Skryptem CGI może być dowolny plik wykonywalny, który czyta dane ze standardowego wejścia (zwykle klawiatura) i wypisuje dane na standardowe wyjście (zwykle jest to terminal). Gdy program uruchamiany jest jako skrypt CGI dane na standardowe wejście podawane są przez serwer HTTP, a standardowe wyjście przechwytywane jest przez ten serwer i wysyłane, po odpowiednim uzupełnieniu nagłówków, do przeglądarki klienta. Praktycznie każdy z istniejących obecnie na rynku serwerów HTTP wspiera tą technologię. W przypadku bazy Oracle technikę tą najrozsądniej stosować jest w połączeniu z językiem Perl lub C/C++. Nic nie stoi jednak na przeszkodzie, aby były to programy napisane np. w PHP. 6.2 Język skryptowy PHP Język PHP [19] od zawsze służył do tworzenia aplikacji internetowych. Stosunkowo późno został on dostrzeżony przez firmę Oracle, która do wersji 8i nie zapewniała dla niego wsparcia (co gorsza próba włączania na własną rękę modułu mod_php do serwera Apache, na którym bazuje Oracle HTTP Server, powodowała utratę wsparcia technicznego!). Wraz jednak z promowaniem przez firmę środowiska linuksowego, musiało wcześniej lub później dojść do otwarcia na PHP, gdyż język ten jest w tych środowiskach zdecydowanie na pierwszym miejscu popularności (nawet w porównaniu do Javy). Istota programowania w PHP polega na umiejętnym osadzaniu w kodzie HTML wstawek PHP, których zadaniem jest łączenie się z bazą Oracle, pobieranie z niej interesujących nas danych i przedstawianie ich na stronach WWW. PHP wspiera dwa różne interfejsy do łączenia z bazą Oracle: standardowy (oracle) oraz bardziej elastyczny i dający więcej możliwości (oci8 korzysta z bibliotek DLL Oracle, które muszą być dostępne na serwerze, gdzie zainstalowano PHP). Pewną niedogodnością języka PHP jest niewątpliwie to, że pracując z różnymi bazami danych korzystamy z osobnego zestawu funkcji. Na pewno nie ułatwia to przenaszalności aplikacji pomiędzy różnymi systemami bazodanowymi. Trzeba jednak zauważyć, że PHP rozwija intensywnie uniwersalny interfejs dbx, który ma zdecydowanie podnieść przenaszalność aplikacji bazodanowych pomiędzy różnymi systemami. 325

10 A. Gramacki, J. Gramacki 6.3 Platforma.NET Z chwilą pojawienia się na rynku platformy do tworzenia aplikacji w środowisku Windows o nazwie.net (czyt. dot NET) [26], firma Oracle rozpoczęła prace nad integracją bazy danych Oracle z tą platformą. Efektem tych prac jest rozwiązanie o nazwie Oracle Data Provider for.net (ODP.NET) [25]. W swej istocie jest to implementacja (rodzaj sterownika) specyfikacji o nazwie ADO.NET firmy Microsoft. Specyfikacja to z kolei to nic innego jak zbiór API dla platformy.net wspierający dostęp do baz danych. Firma Oracle swój sterownik ODP.NET zoptymalizowała pod kątem szybkości i wydajności oraz dodatkowo udostępniła funkcjonalność, która nie jest dostępna z poziomu oryginalnych sterowników ADO.NET firmy Microsoft. Mamy tu na myśli między innymi wsparcie dla XML, tzw. Ref Cousorów, zmiennych typu LOB (BLOB, CLOB, NCLOB), BFILE, Long, RAW itd. Możliwe jest również wykorzystywanie procedur i funkcji pisanych w języku PL/SQL, który jest powszechnie znany i wykorzystywany w bazach danych Oracle. Dzięki udostępnieniu ODP.NET możliwe stało się więc wykorzystywanie pełnych możliwości, jakie tkwią w środowisku Visual Studio.NET. Aplikacje można tworzyć w dowolnym wspieranym przez to środowisko języku programowania (C++, C#, Visual Basic). 7 Podsumowanie Poniżej w formie tabelarycznej zestawiono najważniejsze zdaniem autorów wady i zalety omawianych technologii. W kategoriach wad i zalet nie uwzględniano takich aspektów jak łatwość opanowania, wymagania sprzętowe, gdyż w kontekście pracy nie są to sprawy pierwszoplanowe i często zależą od subiektywnych odczuć i predyspozycji programisty. Tabela 1. Porównanie technik tworzenia aplikacji internetowych dla bazy danych Oracle Zalety Technika Skrypty CGI Prostota. Ogromna liczba wspieranych języków programowania. Działa na praktycznie każdym serwerze WWW. PL/SQL Technologia łatwa do opanowania dla znających języki SQL oraz PL/SQL. Duża szybkość i stabilność działania. Doskonała integracja z bazą Oracle. PSP Wady Nie zapewnia wystarczającej skalowalności. Przy dużej liczbie odwołań do skryptu CGI może dojść do zawieszenia całego serwera WWW. Technologia ograniczona tylko do baz danych Oracle. Pewne trudności w budowaniu aplikacji o bardzo złożonej logice i przewadze stron HTML o charakterze statycznym nad dynamicznymi. Technologia łatwa do opanowania dla znających języki SQL oraz PL/SQL oraz mających styczność W przeciwieństwie do PL/SQL wymaga przechowy- Technologia ograniczona tylko do baz danych Oracle. z językami opartymi o znaczniki, jak np. JSP, PHP. wania plików źródłowych poza bazą danych. Pozostałe zalety jak w PL/SQL. Poza tym łatwiej niż w PL/SQL oddzielić logikę aplikacji od jej warstwy prezentacji. 326

11 Techniki tworzenia aplikacji internetowych dla bazy danych Oracle Serwlety Oparte o język Java. Część technologii J2EE, która jest tworzona pod kątem możliwości budowania bardzo złożonych aplikacji biznesowych. Zdecydowanie lepsza skalowalność niż skrypty CGI. Oparte o język Java, Stosunkowo dobra separacja kodu Javy od statycznego kodu HTML. Gdy używany JavaBeans ta separacja jeszcze bardziej się poprawia. Oparte o język Java. Bardzo dobre rozwiązanie dla dużych projektów. Oparte o język Java. Bardzo dobre rozwiązanie dla dużych projektów. Prostota i wielka popularność języka. Bogactwo bibliotek. Technologia darmowa. Doskonała integracja z bazami Oracle. Względna prostota, umożliwiająca w miarę szybko otrzymanie działającej aplikacji internetowej o podstawowej funkcjonalności. Bardzo wygodne i efektywne środowisko graficzne do tworzenia aplikacji dla platformy Windows. Bardzo wygodne i efektywne środowisko graficzne do tworzenia aplikacji w języku Java. Wspiera J2EE oraz doskonale współpracuje z bazą Oracle. Rozwlekłość kodów źródłowych. Trudne czasami do opanowania przemieszanie kodów odpowiedzialnych za tworzenie części statycznych i dynamicznych stron HTML. JSP Rozwlekłość kodów źródłowych. Cecha w zasadzie typowa dla aplikacji tworzonych w Javie. Teoretycznie część statyczna oraz dynamiczna są rozdzielone, ale ten rozdział i tak jest mało praktyczny. Enterprise JavaBeans Rozwlekłość kodów źródłowych. Jeszcze większa niż serwlety i JSP. Technika bardzo złożona i trudna w utrzymaniu i konfiguracji. Web Services Rozwlekłość kodów źródłowych i plików konfiguracyjnych. Technika bardzo złożona i trudna w utrzymaniu i konfiguracji. Aplikacja klienta oraz usługa sieciowa muszą w pełni sobie ufać (w zastosowaniach biznesowych może to być dużym problemem). PHP Różny zestaw funkcji dla różnych baz danych. Zdaniem autorów składnia PHP jest mało czytelna (w stosunku do np. PL/SQL). Oracle Developer Suite Rozwiązanie tylko dla bazy Oracle, konieczność programowania w nieprzenoszalnym do innych systemów bazodanowych języku PL/SQL, nieco ubogie możliwości projektowania interfejsu użytkownika (np. brak bardzo popularnych obiektów typu grid). HTML DB Uciążliwa (choć dość prosta) obsługa. Wielka trudność w dopasowaniu aplikacji (wygląd, funkcjonalność) do specyficznych potrzeb klienta. Brak przenaszalności do innych systemów bazodanowych. Platforma.NET Autorzy spotkali się na różnych listach dyskusyjnych z uwagami dotyczącymi niestabilnej pracy aplikacji.net dla bazy Oracle. Nie przeprowadzili jednak na tyle intensywnych testów, aby to z całą pewnością potwierdzić. JDeveloper W zasadzie brak 327

12 A. Gramacki, J. Gramacki Literatura 1. Wojciechowski M., Zakrzewicz M.: Analiza porównawcza technologii tworzenia aplikacji internetowych dla baz danych Oracle. VIII Konferencja użytkowników i deweloperów ORACLE: Systemy informatyczne. Projektowanie, implementowanie, eksploatowanie. Zakopane 2002, s Gramacki A., Gramacki J.: Narzędzie HTML DB do szybkiego tworzenia aplikacji internetowych omówienie oraz ocena praktycznej przydatności. X Konferencja użytkowników i deweloperów ORACLE: Systemy informatyczne. Projektowanie, implementowanie, eksploatowanie. Zakopane 2004, s Dokumentacja systemowa produktów firmy Oracle. Do pobrania ze strony: 4. Dokumentacja systemowa: Oracle Application Server Concepts. 5. Dokumentacja systemowa: Oracle Application Server Administrator's Guide. 6. Dokumentacja systemowa: HTTP Server Administrator's Guide. 7. Dokumentacja systemowa: HTTP Server mod_plsql User's Guide. 8. Dokumentacja systemowa: Oracle Call Interface Programmer's Guide. 9. Dokumentacja systemowa: PL/SQL User's Guide and Reference. 10. Dokumentacja systemowa: PL/SQL Packages and Types Reference. 11. Dokumentacja systemowa: Java Developer's Guide. 12. Dokumentacja systemowa: Oracle Application Server Containers for J2EE User s Guide. 13. Dokumentacja systemowa: Oracle Application Server Forms Services. Deployment Guide 10g. 14. Dokumentacja systemowa: Oracle Application Server Reports Services. Publishing Reports to the Web 10g. 15. Dokumentacja systemowa: Oracle HTML DB User s Guide java.sun.com hoohoo.ncsa.uiuc.edu/cgi/interface.html