Zastosowanie Oracle Designer/2000 do projektowania i implementacji aplikacji WWW

Transkrypt

1 V Konferencja PLOUG Zakopane Październik 1999 Zastosowanie Oracle Designer/2000 do projektowania i implementacji aplikacji WWW Grzegorz Bliźniuk gbliz@isi.wat.waw.pl. Roman Wantoch-Rekowski rekowski@isi.wat.waw.pl. Marek Nowak mnowak@isi.wat.waw.pl. Wojskowa Akademia Techniczna, Instytut Systemów Informatycznych STERSZCZENIE Referat przedstawia przykład tworzenia aplikacji zarządzającej danymi poprzez sieć Internet. Jako narzędzie wspomagające proces wytwarzania został zastosowany Oracle Designer/2000. Zasoby dostępne przez tę sieć mogą stanowić podstawę działania wielu aplikacji. Przykładem takiej aplikacji może być system przetwarzania danych oparty o serwery rozproszone. Jako przykład środowiska realizacji aplikacji WWW przedstawiono Oracle Application Server (OAS 3.0 z bazami danych Oracle 7.3 oraz Oracle 8). Aplikacja osadzona w tym środowisku jest przykładem 3-warstwowego modelu klient-serwer. Omówiono elementy OAS, w którego skład wchodzą: serwer WWW, Web Request Broker (WRB) oraz kartrydże. W prezentowanym rozwiązaniu działanie stworzonych aplikacji bazuje na wykorzystaniu tradycyjnej przeglądarki WWW.

2 1. WSTĘP Funkcjonowanie aplikacji z wykorzystaniem Oracle Application Server (OAS) 1 stanowi przykład praktycznego zastosowania 3-warstwowego modelu klient-serwer [4, 5]. OAS niezależnie od wersji składa się z 3 podstawowych elementów: serwer WWW, Web Request Broker (WRB), kartrydże. Wszystkie wymienione elementy funkcjonują w warstwie pośredniej i stanowią część składową systemu w nomenklaturze Oracle określanej mianem serwera aplikacji. Do podstawowych założeń należy obsługa użytkownika przez wykorzystanie przeglądarki WWW. W warstwie trzeciej (najbardziej oddalonej od użytkownika) są umieszczone serwery baz danych. Schemat środowiska pracy przedstawiono na rysunku WARSTWA POŚREDNIA OAS Podstawowe znaczenie dla 3-warstwowego środowiska klient-serwer ma warstwa pośrednia serwer aplikacji OAS (patrz: rys.1). Zadaniem tej warstwy jest kompleksowa obsługa przychodzących żądań użytkowników 2. Pierwszy etap obsługi dowolnego żądania polega na rozpoznaniu jego typu (statyczna strona WWW, strona WWW z dynamiczną zawartością). Elementem składowym OAS odpowiedzialnym za ten etap obsługi jest serwer WWW. Nadejście żądania dostarczenia do klienta strony WWW z dynamiczną zawartością należy rozumieć jako zapotrzebowanie na stronę WWW, która zawiera dane pochodzące z bazy danych pobierane w trybie on-line. Tego typu strony są przechowywane w serwerze bazy danych w postaci szablonów określających sposób pozyskania danych. W technologii zaproponowanej przez Oracle oznacza to, że należy wykonać procedurę przechowywaną w bazie danych, której realizacja będzie nadzorowana przez jeden z dostępnych kartrydży OAS (np. dla procedur PL/SQL kartrydż PL/SQL). Problem wybrania odpowiedniej instancji kartrydża należy do modułu rozdzielającego serwera WWW, który w tym celu wykorzystuje usługi WRB. Parametrem wejściowym jest adres URL zawierający specyfikację poszukiwanego zasobu. Efektem pracy modułu rozdzielającego jest uruchomienie określonej procedury w oparciu o wyspecyfikowany kartrydż. 1 Autorzy artykułu przeprowadzili testy działania OAS 3.0 z bazą danych Oracle Warstwa pośrednia przyjmuje żądania użytkowników, wykonuje odpowiednie zapytania do serwera danych oraz formatuje dane pozyskane z serwera bazy danych do postaci akceptowanej przez przeglądarki WWW. 2

3 Przeglądarka WWW HTTP Oracle Application Server SQL *NET Oracle Workgroup Server 1 warstwa 2 warstwa 3 warstwa Rys. 1. OAS jako warstwa pośrednia w 3-warstwowym modelu klient-serwer Wykorzystanie kartrydży jako elementów przetwarzających w stosunku do tradycyjnej technologii skryptów CGI posiada wiele zalet. Główne z nich to: pojedyncza instancja kartrydża może obsłużyć wiele żądań użytkowników, instancje kartrydży mogą być rozproszone na wielu węzłach sieci, co umożliwia wdrożenie mechanizmów równoważenia obciążenia, kartrydże mogą korzystać z wbudowanych usług WRB (np. autoryzacja, dziennik, sesje), których odpowiedniki w skryptach CGI trzeba organizować samodzielnie. W pakiecie OAS 3.0 są dostępne następujące standardowe kartrydże: PL/SQL, Java, Perl, LiveHTML, ODBC. Ponadto istnieje możliwość nabycia kartrydży dedykowanych (np.: Internet Commerce Server, Payment Server, OLAP). OAS jest środowiskiem otwartym umożliwiającym tworzenie własnych kartrydży zgodnych z architekturą przetwarzania sieciowego NCA (ang. Network Computing Architecture). Zastosowanie w warstwie bezpośrednio obsługującej użytkownika przeglądarek WWW umożliwia uniezależnienie klienta od systemu operacyjnego, zapewnia jednolity interfejs systemu praktycznie niezależny od rodzaju przeglądarki, a także miejsca dostępu. Jedynym warunkiem koniecznym poprawnej obsługi klienta jest generowanie wyników pracy serwera aplikacji OAS w formie ustalonej dla przeglądarek WWW. Wytwarzanie aplikacji dla trójwarstwowej architektury klient-serwer jest skutecznie wspomagane przez Oracle Designer/ Rysunek 2 przedstawia logikę zaproponowanej przez Oracle metody wspomagania wytwarzania bazy danych i aplikacji. Podobnie jak w przypadku wytwarzania aplikacji nie działających w standardzie HTML prace analityczne mogą być wspierane w dwóch płaszczyznach: w zakresie wytwarzania bazy danych, w zakresie wytwarzania aplikacji. 3 Przedstawione rezultaty zostały uzyskane w wersji tego narzędzia. 3

4 Na rysunku 2 został przedstawiony schemat wytwarzania aplikacji WWW w Oracle Designer/2000, który umożliwia pracę zgodnie z metodyką CASE*Method SM [1, 2, 3]. W zakresie wytwarzania bazy danych tradycyjnie można skorzystać z modelu informacyjnego przedstawionego w postaci diagramów encji z narzędzia Entity Relationship. Przejście z modelu informacyjnego na schemat bazy danych jest wspomagany narzędziem przetwarzającym diagram encji w logiczny model danych. W kolejnym kroku możliwe jest wygenerowanie skryptów SQL osadzających fizyczną bazę danych na serwerze. Działająca instancja bazy z osadzonymi w niej obiektami przechowującymi dane stanowi podstawę informacyjną dla funkcjonowania wygenerowanej aplikacji WWW. Ścieżka wytwarzania tej aplikacji przebiega zgodnie z dolną strzałką z rysunku 2. Można diagram encji logiczny model danych generacja bazy danych wytwarzanie bazy danych wytwarzanie aplikacji Oracle Workgroup Server diagram funkcji logiczny model aplikacji generacja pakietów typu WebServer Rys.2. Schemat wytwarzania aplikacji w Designer/2000 skorzystać z hierarchii funkcji (narzędzie Function Hierarchy). Następnie przy wspomaganiu CASE generowane są tzw. moduły kandydujące. Spośród tych modułów tworzony jest zestaw modułów przeznaczonych do dalszych prac projektowo-implementacyjnych w wyniku czego powstaje działająca aplikacja. W przypadku aplikacji WWW nie są generowane oddzielne pliki tak, jak ma to miejsce w przypadku formularzy czy raportów. Generuje się pakiety PL/SQL, które są osadzane bezpośrednio na grupowym serwerze danych, które stanowią podstawę do dalszej pracy dla serwera aplikacji. 2. TWORZENIE MODUŁÓW WYKONYWALNYCH Schemat postępowania przy tworzeniu modułów wykonywalnych jest analogiczny ze ścieżką postępowania dla narzędzia Oracle Forms lub Oracle Reports. Pierwszym elementem, o którym należy pamiętać podczas definiowania modułu Web Server jest określenie Type jako Screen oraz Language jako Oracle Web Server. W kolejnym kroku określa się użycia tabel. Po wyspecyfikowaniu użyć tabel można przystąpić do określenia ich parametrów. W pierwszej kolejności należy zdecydować jakie operacje są możliwe w ramach modułu (grupa Allow zakładki Table Details: Insert, Update, Delete, Query), co ma istotny wpływ na funkcjonalność dostarczaną użytkownikowi. W korelacji z grupą parametrów typu 4

5 Allow pozostaje grupa Layout, która umożliwia określenie stylu prezentacji modułu (dostępne style to: List, Form, Frames). Po ustawieniu podstawowych parametrów modułu można już przystąpić do generacji modułów GENERACJA MODUŁÓW DLA PRZEGLĄDARKI WWW Ostatnią fazą tworzenia aplikacji z dostępem do bazy danych Oracle z wykorzystaniem serwisu WWW sieci Internet jest generacja modułów wykonywalnych. Na wejściu do tego etapu znajduje się wcześniej przygotowany projekt modułu. Uruchomienie operacji generowania modułu powoduje pojawienie się okna Generate WebServer. Kroki postępowania są uzależnione od wcześniej ustalonych parametrów grupy Allow na etapie definicji modułu. Jeżeli podczas definiowania parametrów użyć tabel dla chociaż jednej wybrano Insert, to właściwe generowanie modułu należy poprzedzić operacją generowania serwera API (zakładka Generate Server API). Następnie przystępuje się już do generowania modułu. Po poprawnym zakończeniu ww. czynności należy zainstalować wygenerowany moduł w bazie danych. Algorytm postępowania podczas pracy przy generacji modułów został przedstawiony na rysunku KONFIGURACJA ORACLE APPLICATION SERVER W sytuacji, kiedy został wygenerowany moduł z przeznaczeniem do pracy w ramach środowiska OAS należy dokonać instalacji aplikacji w kartrydżu. Polega ona na ustawieniu ścieżek wirtualnych wskazujących na aplikację. W tym celu należy wykorzystać narzędzie administratora OAS. Zainstalowanie aplikacji w kartrydżu jest możliwe po wcześniejszym skonfigurowaniu dwóch podstawowych parametrów kartrydża: DataBase Access Descriptor (DAD) definiujący parametry dostępu do bazy danych, definicję agenta (np. dla kartrydża PL/SQL). Po wykonaniu powyższych czynności administracyjnych można przystąpić do uruchomienia aplikacji. Do tego celu należy użyć dowolnej przeglądarki WWW i wprowadzić poprawny adres URL w następującym formacie (przykład dla kartrydża PL/SQL): wa_pakietu.nazwa_procedury. 5

6 START Wybór modułu do generowania grupa Allow zawiera operację Insert TAK Generacja serwera API NIE Właściwa generacja modułu Instalacja modułu w bazie danych KONIEC Rys. 3. Algorytm generacji modułów PODSUMOWANIE Zastosowanie pakietu Oracle Application Server podobnie do innych tej klasy produktów umożliwia jednoczesną obsługę bardzo dużej liczby użytkowników, zmniejszenie kosztów utrzymania systemu oraz wykorzystanie już istniejących komponentów systemu w innych aplikacjach. Należy oczekiwać, że ten kierunek rozwoju systemów informatycznych stanie się wiodący w najbliższej przyszłości. Świadczy o tym stale rosnący popyt na tę formę obsługi klienta, charakteryzujący się dużą uniwersalnością i otwartością. Obserwacja trendów na innych rynkach informatycznych pozwala przypuszczać, że w najbliższym czasie także Polska stanie się (o ile już nie jest) krajem o dużym zapotrzebowaniu na systemy informatyczne pracujące w otoczeniu 3-warstwowego modelu przetwarzania klient-serwer. 6

7 LITERATURA [1] BARKER R., LONGMAN C., CASE*Method SM. Modelowanie funkcji i procesów, WNT, Warszawa, [2] BARKER R., LONGMAN C., CASE*Method SM. Modelowanie związków encji, WNT, Warszawa, [3] BLIŹNIUK G., GAWRYCH D., KOZŁOWSKI K., Sposób prowadzenia projektu oprogramowania systemu informatycznego przy pomocy Oracle Designer/2000 TM, materiały konferencyjne Systemy Czasu Rzeczywistego 97, str , Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław [4] EDWARDS J., DEBORAH DV., 3-Tier Client/Server At Work, John Wiley&Sons Inc., New York, [5] ORFALI R., HARKEY D., EDWARD J., The Essential Client/Srver Survival Guide. Second Edition, New York,