Nowe możliwości WWW (IV)

Połączenie serwera WWW z bazami danych ma podstawowe znaczenie przy budowie szerokiej gamy usług internetowych i intranetowych. Przykładów zastosowania takiej integracji można podać wiele: poczynając od archiwów umożliwiających wyszukiwanie tekstowe, przez systemy ogłoszeń, systemy śledzenia zamówień, aż po elektroniczne sklepy. Realizacja integracji WWW z bazami danych obejmuje takie zagadnienia, jak: architektura systemu, łatwość i intuicyjność wykorzystania, bezpieczeństwo danych i transakcji, wydajność, aspekty konfiguracji i administracji.

Połączenie serwera WWW z bazami danych ma podstawowe znaczenie przy budowie szerokiej gamy usług internetowych i intranetowych. Przykładów zastosowania takiej integracji można podać wiele: poczynając od archiwów umożliwiających wyszukiwanie tekstowe, przez systemy ogłoszeń, systemy śledzenia zamówień, aż po elektroniczne sklepy. Realizacja integracji WWW z bazami danych obejmuje takie zagadnienia, jak: architektura systemu, łatwość i intuicyjność wykorzystania, bezpieczeństwo danych i transakcji, wydajność, aspekty konfiguracji i administracji.

TECHNOLOGIA INTEGRACJI

Omawiany temat jest niezwykle obszerny. Przedstawić można całą gamę rozwiązań - od bardzo prostych, klasy deskłop, po integrację baz klasy legacy, eksploatowanych na komputerach mainframe. W każdym przypadku mamy jednak do czynienia z kilkoma podstawowymi komponentami:

• serwerem WWW

• oprogramowaniem pośredniczącym (często kilkupoziomo-

wym)

•serwisem bazodanowym.

Zasady projektowania interfejsu WWW do bazy danych są proste: język HTML umożliwia umieszczanie w dokumencie elementów aktywnych, takich jak: pola tekstowe,przyciski, listy wyboru, proste edytory tekstu itp. Dzięki nim użytkownik za pośrednictwem przeglądarki WWW może wprowadzić dane lub wykonać zapytanie. Z drugiej strony mechanizmy, takie jak dynamicznie generowane odnośniki i cookies, pozwalają na przekazanie do użytkownika informacji zwrotnej, która może zostać wykorzystana w następnym zapytaniu. Podstawowy mechanizm współpracy przeglądarka - serwer WWW - baza danych pokazano na rysunku.

Specyfika przedstawionego modelu współpracy jest z punktu widzenia projektanta systemu dość niekorzystna -nie istnieje trwałe połączenie pomiędzy przeglądarką a serwerem. W związku z powyższym nie ma bezpośredniej możliwości realizacji „sesji" z bazą danych, czyli połączenia, które istniałoby dłużej niż przez okres pomiędzy przesłaniem pojedynczego zlecenia i uzyskaniem odpowiedzi na nie. Rozważmy najprostszy przykład elektronicznego sklepu, w którym nasze zakupy są przechowywane w wirtualnym koszyku, aż do momentu realizacji płatności. W „normalnym" modelu klient-serwer koszyk zakupów odpowiadałby po prostu stałemu połączeniu pomiędzy klientem a serwerem, utrzymywanym aż do momentu realizacji płatności. W przypadku WWW rozwiązanie takie nie jest możliwe. Jak jest przechowywana w przypadku interfejsu WWW informacja o stanie „sesji" pomiędzy klientem (przeglądarką) a serwerem? Istnieje kilka mechanizmów: niezbędna informacja może być kodowana w dynamicznie generowanych odnośnikach (links), można też wykorzystać zmienne ukryte w formularzach (oczywiście, w takim przypadku formularz musi być generowany dynamicznie), dostępny jest mechanizm cookies -umożliwiający przekazywanie par zmienna-wartość pomiędzy przeglądarką a serwerem. Wszystkie te niskopoziomowe mechanizmy dość znacznie komplikują realizację nietrywialnych projektów internetowo/intarne-towych.

Krytycznym punktem systemu jest styk serwera WWW z bazą danych. Projektant systemu musi zdecydować, jak rozłożyć funkcje systemu pomiędzy serwer, oprogramowanie pośredniczące i sam system bazodanowy.

INTERFEJS CGI

W najprostszym przypadku każde zgłoszenie użytkownika powoduje uruchomienie przez serwer programu (wg standardu CGI), który z kolei połączy się z bazą danych, przekaże jej zapytanie, a uzyskane wyniki przetworzy na format HTML i odeśle do serwera. Rozwiązanie to jest najprostsze i jednocześnie obciążone największymi wadami. Wady rozwiązania CGI to niska wydajność oraz słaba integracja z ser-werem WWW. Niska wydajność CGI wynika z konieczności powoływania odrębnego procesu dla każdego zgłoszenia przychodzącego z sieci. Dla silnie obciążonego serwera rozwiązanie takie jest nie do przyjęcia. Fakt, że program CGI jest odrębnym procesem tworzonym dla każdego zlecenia klienta, powoduje, że ma on dość ograniczoną informację na temat stanu serwera oraz parametrów klienta. utrudnia to np. przechowywanie informacji o stanie „sesji" po stronie serwera. Dlatego też popularny interfejs CGI powinien być wykorzystywany w przypadku aplikacji, w których nie przewiduje się znacznego obciążenia serwera oraz w których nie są realizowane skomplikowane wieloetapowe transakcje.

WTYCZKI SERWEROWE

Alternatywą dla CGI są rozwiązania, w których „program" pośredniczący (interfejs bazodanowy) jest silnie zintegrowany z serwerem WWW. Typowym rozwiązaniem jest konstrukcja modułu pośredniczącego jako biblioteki dynamicznej. W takim przypadku nie występuje już problem narzutu czasowego na tworzenie procesu dla każdego zgłoszenia klienta. Biblioteka taka jest też ściśle zintegrowana z serwerem WWW. Oczywiście, podobnie jak dla CGI musi istnieć standard pozwalający tworzyć tego typu moduły. Obecnie istnieją dwa takie pseudostandardy: NSAPI (dla serwerów Netscape) i ISAPI dla serwerów Microsoft (IIS). Specyfikacje NSAPI i ISAPI pozwalają na tworzenie „wtyczek" do serwerów WWW (analogicznie do wtyczek do przeglądarek). Wtyczki takie obsługują odwołania do konkretnych zasobów serwera, niekoniecznie zresztą bazodanowych.

Interfejs wtyczek serwerowych jest specyfikacją nisko-poziomową stworzoną z reguły w języku C, a więc przeznaczoną dla programistów. Szereg producentów udostępnia gotowe wtyczki serwerowe przeznaczone do konkretnych celów, w tym interfejsy bazodanowe. Producenci baz danych dostarczają odpowiednie wtyczki zarówno do serwerów Microsofta, jak i Netscape. Tak jest zwłaszcza w przypadku mniejszych firm produkujących wyspecjalizowane systemy - głównie dotyczy to pełnotekstowych baz danych oraz baz multimedialnych. Dostępne są też opracowane bezpośrednio przez Microsoft i Netscape wtyczki zgodne ze standardem ODBC, co rozwiązuje kwestię współpracy z całym szeregiem relacyjnych baz danych na platformie PC/Intel. W przypadku głównych graczy rynku bazodanowego (Oracle, Informix, Sybase) mamy do czynienia z nieco inną sytuacją: producenci ci posiadają własne, kompletne rozwiązania dla Internetu i intranetu (w przypadku Oracle nawet własny serwer WWW).

W podejściu do integracji baz danych pochodzących od największych producentów widzimy pomiędzy Netscapem i Microsoftem wyraźną różnicę: zarówno techniczną, jak i marketingową. Netscape, prócz wtyczki ODBC, dostarcza też wtyczki dostosowane do systemów RBD: Oracle, Infor-mix i Sybase. Microsoft głęboko integruje IIS z własnym serwerem bazodanowym (Microsoft Server), proponując obsługę baz danych innych producentów poprzez interfejs ODBC. Oba podejścia dość jasno wynikają ze strategii firm: Netscape uważa, że generyczne interfejsy pracują wydajniej i unikają ograniczeń - ODBC, z czym zresztą trudno się nie zgodzić. Microsoft stara się zachęcić klientów do korzystania •z własnego serwera. Obecnie zauważyć można nowy trend: Netscape przekonywać będzie do integracji systemów w standardzie IIOP/CORBA, Microsoft natomiast promować będzie swoje rozwiązanie DCOM.

Strona WWW z wbudowanym kodem JavaScript

Pomiędzy tagami <SERVER> i </SERVER> zawarty jest kod JavaScript, który jest wykonywany na serwerze WWW - przed przekazaniem dokumentu klientowi. Wynik wykonania programiku zostaje umieszczony w dokumencie. W tym konkretnym przypadku, zostanie wykonane polecenie SQL selekcji rekordów z tabeli 'types', wynik selekcji zostanie przedstawiony w postaci tabeli HTML.

&#60;TR&#62;

&#60;TD BGCOLOR="#cOaOaO"&#62; Typ ogłoszenia: &#60;/TD&#62;

&#60;TD&#62;

&#60;SELECT SIZE=" 1" NAME="typejd"&#62;

&#60;OPTION VALUE=O SELECTED&#62; Wszystkie

&#60;SERVER&#62;

cursor - database.cursorfSELECT * FROM types ORDER BY typejd");

while(cursor.next()) {

&#60;/SERVER&#62;

&#60;OPTION VALUE=~ cursor.type_id' &#62;

&#60;SERVER&#62; write(cursor.atype) &#60;/SERVER&#62;

&#60;SERVER&#62;

)

cursor.close(); &#60;/SERVER&#62; &#60;/SELECT&#62;

Posługiwanie się wtyczką serwerową jest prostsze niż pisanie „od zera" całego interfejsu bazodanowego dla konkretnej aplikacji. Rozwiązania różnych producentów są podobne koncepcyjnie, choć dość odmienne składniowo. Idea działania wtyczki serwerowej sprowadza się do umieszczenia w stronie HTML instrukcji odwołujących się do bazy danych. Takie rozwiązanie przyjął zarówno Netscape - w oprogramowaniu LiveWire (obecnie nie sprzedawanym już jako osobny pakiet, lecz zintegrowanym z serwerem WWW), jak i Microsoft - w ASP (Active Server Pages). W praktyce w strony WWW można wbudowywać programy napisane w mutacji JavaScript, poszerzonym o obiekty bazodanowe oraz obiekty umożliwiające zapamiętanie stanu klienta. Przygotowana strona WWW jest więc w rzeczywistości wzorcem strony, w którym przed wysłaniem do klienta zostaną umieszczone odpowiednio sformatowane dane pochodzące z systemu bazodanowego.

W tym miejscu nie można nie wspomnieć o rozwiązaniu zastosowanym w Universal Server Informixa. Jest ono podobne do opisanego wyżej, z jedną bardzo poważną różnicą: wtyczka znajduje się nie po stronie serwera WWW, lecz po stronie bazy danych (jest to wg terminologii Informixa „moduł Datablade").

Wtyczki serwerowe z rozszerzeniami językowymi umożliwiającymi szybkie sięgnięcie do bazy danych pozwalają na bardzo szybkie tworzenie aplikacji webowych, zarówno inter-, jak i intranetowych. Prócz podstawowych (otwieranie i zamykanie połączeń z bazą danych, wykonywanie zdań SQL, obsługa kursorów) dostępne są dość wyrafinowane mechanizmy umożliwiające wykorzystanie procedur wbudowanych (embeded SQL procedures) oraz „rozciągnięcie" transakcji bazodanowych na więcej niż jedno połączenie z danym klientem. Koncepcja wtyczki serwerowej interpretującej wzorce HTML ma jednak swoje ograniczenia. >Z mojego doświadczenia wyniesionego z realizacji dość dużych projektów intranetowych wynika, że po przekroczeniu pewnego poziomu skomplikowania przemieszanie kodu i instrukcji HTML w stronach-wzorcach staje się mało czytelne, a zarządzanie projektem znacznie się komplikuje. Podobnie jest w przypadku, gdy dane uzyskane z bazy wymagają daleko posuniętej obróbki przed zwróceniem wyników klientowi oraz w przypadku, gdy chcemy nie tylko odpytywać bazę danych, ale i modyfikować jej zawartość.

NARZĘDZIA WIZUALNE

Kolejną grupą produktów, stanowiącą niejako nadbudowę dla opisanych wyżej wtyczek serwerowych, są różnego rodzaju „narzędzia wizualne". Oprogramowanie to pozwala na graficzne (WYSYWIG) zaprojektowanie wyglądu formatek HTML, schematów baz danych oraz formatów raportów, na podstawie których generowany jest następnie odpowiedni kod dla serwera i klienta (Java lub JavaScript). Przykładem takiego narzędzia jest IntraBuilder Borlanda. Podobne pakiety dostarczają też producenci baz danych, np. Oracle i Progress. Dobre narzędzia tego typu potrafią obsługiwać automatycznie różne formaty danych (np. grafikę), radzą też sobie z bardziej złożonymi schematami danych (złączenia tabel itp.).

Przed zdecydowaniem się na zakup i wykorzystanie narzędzi wizualnych warto sprawdzić, z jakimi serwerami WWW oraz bazodanowymi dany pakiet współpracuje. W wielu przypadkach wykorzystanie wszystkich możliwości wygenerowanej aplikacji wymaga użycia dedykowanego serwera WWW dostarczonego razem z pakietem, wykorzystanie serwera WWW innych producentów powoduje zaś znaczne ograniczenie możliwości. Podobnie ma się rzecz z bazami danych. Typowo wykorzystywany jest standard ODBC, jednak - podobnie jak w przypadku serwera WWW - może się okazać, że pewne zaawansowane mechanizmy mogą być wykorzystane tylko przy współpracy z bazą danych producenta danego pakietu.

JAVA I JDBC

Warto zwrócić uwagę na możliwość zastosowania języka Java w łączeniu aplikacji webowych z bazami danych. W najprostszym przypadku aplet Javy znajduje się wyłącznie po stronie klienta (przeglądarki) i pełni rolę „inteligentnego formularza", dzięki czemu unika się żmudnego konstruowania dynamicznych formularzy HTML. Java jest też w tego typu zastosowaniach po prostu elastyczniejsza. W bardziej zaawansowanym systemie zarówno część kliencka, jak i ser-werowa są napisane w języku Java. Do komunikacji z bazą danych może być wykorzystany protokół JDBC, dzięki czemu aplikacja staje się w dużej mierze niezależna od platformy sprzętowej i systemowej. Do wielu baz danych powstały już natywne bramki JDBC, do innych dostępne są one od firm niezależnych.

INNE ROZWIĄZANIA

Wielu producentów różnego rodzaju baz danych, narzędzi czwartej generacji itp. przegapiło gwałtowny wzrost zainteresowania technologiami internetowymi. Obecnie starają się oni nadrobić zaległości, tworząc różnego rodzaju bramki i nakładki do swojego oprogramowania. Nierzadko rozwiązania te pozostawiają wiele do życzenia. Dość często można spotkać się z sytuacją, gdy produkt taki nie spełnia pokładanych w nim oczekiwań klientów. Do typowych grzechów produ-centów zaliczyłbym: dostarczanie własnego, dedykowanego serwera WWW lub wykorzystywanie wyłącznie standardu CGI przy współpracy z serwerami WWW innych producentów. Dedykowany serwer nie posiada z reguły mechanizmów autoryzacyjnych, kryptograficznych, dziennikowania i innych cech charakteryzujących profesjonalne. Interfejs CGI, całkowicie wystarczający dla wielu zastosowań, nie może być jednak wykorzystywany w serwisach silnie obciążonych.

W artykule pominąłem różnego rodzaju rozwiązania połowiczne, polegające na automatycznym lub półautomatycznym generowaniu stron WWW na podstawie bazy danych, a następnie publikowaniu ich na serwerze webowym. Tego typu rozwiązania sprawdzają się w niektórych zastosowaniach (np. w katalogu produktów), jednak nie mogą być uznane za pełnowartościowe, gdyż z zasady nie umożliwiają odpowiedzi na zadawane ad hoc pytania użytkowników. Pominąłem też różnego rodzaju rozwiązania udostępniające bazy danych przechowywanych na komputerach klasy mainframe - temat jest dość interesujący, jednak zbyt specyficzny, jak na artykuł przeglądowy.

WDROŻENIE INTERFEJSU WEB DO BAZY DANYCH

Na zakończenie warto prześledzić trzy najbardziej typowe scenariusze przeprowadzenia integracji WWW-baza danych. Projektant systemu może spotkać się z następującymi sytua-cjami:

1. Serwis jest tworzony od zera - należy wybrać i zgrać trzy podstawowe składniki systemu.

2. Istnieje serwis bazodanowy - chroniąc swoje dotychczasowe inwestycje, należy dokonać wyboru oprogramowa nia serwerowego WWW i oprogramowania pośredniczącego.

3. Istnieje zarówno serwis bazodanowy, jak i serwis WWW - należy dokonać ich integracji przez wdrożenie od powiedniego oprogramowania pośredniczącego.

Przypadek 1 stawia nas w sytuacji z jednej strony komfortowej - budując system od zera nie musimy męczyć się z dopasowaniem zastanych składników i technologii.

Z drugiej strony czeka nas strategiczna decyzja, a za popełnione błędy trzeba będzie w przyszłości zapłacić. Przed podjęciem decyzji należy umiejscowić punkt ciężkości budowanego systemu: czy leży on bliżej baz danych, a serwer WWW jest tylko dodatkiem, czy też budujemy serwis WWW z rozszerzeniami bazodanowymi? W pierwszym przypadku możemy zdać się na producentów baz danych i oferowane przez nich narzędzia dla weba, w drugim należy pomyśleć o zakupie profesjonalnego serwera WWW posiadającego wbudowane rozszerzenia bazodanowe (a często i wbudowany motor bazy danych). W przypadku, gdy planowany system będzie złożony, warto zbadać ofertę firm tworzących wyspecjalizowane oprogramowanie do integracji WWW z bazami danych oraz firm specjalizujących się w dostarczaniu gotowych rozwiązań tego typu.

Zasoby

Specyfikacja NSAPI:

http://home. netscape. com/newsref/std/server_api. html

Wtyczki serwerowy Netscape:

http://home.netscape.com/comprod/server_central/server_add_ons.html

Microsoft ISAPI i dbWeb:

http://www.microsoft.com/internet/

Serwery WWW:

Netscape: http;//home.netscape.com/comprod/server_central/

Microsoft:http://www.microsoft.com/internet/

Apache:http://www.apache.org/

Bazy danych (firmy posiadające własne, rozbudowane rozwiązania webowe):

lnformix:http://www.informix.com/

Oracle:http://www.oracle.com/

Progress:http://www.progress.com/

Sybase:http://www.sybase.com/

Niektóre firmy dostarczające uniwersalne interfejsy WWW do baz danych:

Bluestone:http://www.blustone.com/products/saphire/

Borland:http://www.borland.com/intrabuilder/intbreg.html

Netscape:http://home.netscape.com/comprod/sener_central/

Powersoft:http://www.powersoft.com/

Spider Technologies:http://www.w3spider.com/

Tekstowe i multimedialne bazy danych z interfejsem WWW:

http://www.atext.com/

http://www.excite.com/

http://icat.com/

http://www.opentext. com/

http://www.pls.com/

http://www.verity.com/

W przypadku 2 łatwo popełnić poważny błąd - zaufać producentowi eksploatowanej bazy danych i zdać się całkowicie na jego rozwiązania „internetowe". Z czasem może okazać się, że utknęliśmy w ślepej uliczce. Przy okazji udostępniania w Internecie lub intranecie istniejących baz danych warto zastanowić się, czy nie nadszedł czas na zmianę technologii - bazy danych klasy deskłop nie nadają się raczej do pełnowartościowej obsługi klientów WWW.

Przypadek 3 stwarza najmniejsze możliwości manewru, szczególnie gdy posiadane już oprogramowanie nie oferuje standardowych interfejsów. Zdani jesteśmy wtedy na stworzenie własnego oprogramowania pośredniczącego. Nim to jednak uczynimy, można przejrzeć w Internecie ofertę firm (jest ich wiele) specjalizujących się w dostarczaniu oraz tworzeniu na zamówienie oprogramowania pośredniczącego.

Autor jest pracownikiem Instytutu Informatyki Politechniki Warszawskiej oraz właścicielem firmy konsultingowej „CC", zajmującej się doradztwem w zakresie architektur klient-serwer, Internetu i bezpieczeństwa systemów komputerowych.


TOP 200