W niniejszym rozdziale:
· Historia aplikacji WWW
· Obsługa serwletów
· Moc serwletów
Rozwój aplikacji Javy działających po stronie serwera — wszystko od działających samodzielnie serwletów do pełnej platformy Java 2, Enterprise Edition (J2EE) — był jednym z najbardziej ekscytujących trendów w programowaniu Javy. Język Java został utworzony pierwotnie w celu zastosowania w małych, osadzonych urządzeniach. Był on opisywany jako język do tworzenia zawartości WWW po stronie klienta w formie apletów. Jednak aż do kilku ostatnich lat potencjał Javy jako platformy do programowania po stronie serwera był niestety pominięty. Aktualnie Java jest uważana za język idealnie nadający się do programowania po stronie serwera.
Szczególnie szybko rozpoznały potencjał Javy w serwerach firmy biznesowe — Java idealnie pasuje do dużych aplikacji typu klient-serwer. Niezależna od platformy natura Javy jest niezwykle użyteczna dla organizacji posiadających heterogeniczny zbiór serwerów pracujących pod różnymi odmianami systemów operacyjnych UNIX i Windows (oraz coraz bardziej Mac OS X). Nowoczesny, obiektowy i chroniący pamięć projekt Javy pozwala programistom na skrócenie cyklów programistycznych i zwiększenie niezawodności. Dodatkowo, wbudowana w Javę obsługa sieci i interfejsów korporacyjnych dostarcza możliwości dostępu do starych danych, ułatwiając przejście ze starszych systemów klient-serwer.
Serwlety Javy są kluczowym składnikiem programowania Javy po stronie serwera. Serwlet to małe, dołączane rozszerzenie serwera, które rozszerza jego funkcjonalność. Serwlety pozwalają programistom na rozszerzanie i dostosowywanie każdego serwera WWW lub aplikacji z obsługą Javy do wcześniej nieznanego poziomu przenośności, elastyczności i łatwości. Jednak przed przejściem do szczegółów, należy spojrzeć na sprawę z pewnej perspektywy.
Chociaż serwlety mogą być wykorzystywane do rozszerzenia funkcjonalności każdego serwera z obsługą Javy, najczęściej używane są do rozszerzania serwerów WWW, stanowiąc potężny i wydajny zamiennik dla skryptów CGI. Kiedy wykorzystuje się serwlet do utworzenia dynamicznej zawartości strony WWW lub podniesienia w inny sposób funkcjonalności serwera WWW, w efekcie tworzy się aplikację WWW. Podczas, gdy strona WWW wyświetla jedynie zawartość statyczną i pozwala użytkownikowi na nawigację poprzez tę zawartość, aplikacja WWW dostarcza doświadczenia bardziej interaktywnego. Aplikacja WWW może być tak prosta jak wyszukiwanie słowa kluczowego w archiwum dokumentów lub tak złożona, jak sklep elektroniczny. Aplikacje WWW są umieszczane w Internecie oraz korporacyjnych sieciach intranet i extranet, w których posiadają one potencjał do zwiększania produktywności i zmiany sposobu prowadzenia biznesu przez małe i duże firmy.
Aby zrozumieć potęgę serwletów, należy cofnąć się i spojrzeć na pewne inne podejścia do tworzenia aplikacji WWW.
Common Gateway Interface (Wspólny Interfejs Bramek), w skrócie CGI, był jednym z pierwszych praktycznych technik tworzenia zawartości dynamicznej. Przy pomocy CGI serwer WWW przekazuje konkretne żądania do programu zewnętrznego. Wynik tego programu jest później przesyłany do klienta w miejscu statycznego pliku. Powstanie CGI pozwoliło na implementację wielu nowych rodzajów funkcjonalności na stronach WWW, a CGI szybko stał się de facto standardem, zaimplementowanym w ogromnej ilości serwerów WWW.
Interesujący jest fakt, że możliwość tworzenia przez programy CGI dynamicznych stron WWW jest ubocznym efektem ich początkowego przeznaczenia — zdefiniowania standardowej metody porozumiewania się serwera informacji z aplikacjami zewnętrznymi. To źródło wyjaśnia, dlaczego CGI posiada przypuszczalnie najgorszy do wyobrażenia okres trwałości. Kiedy serwer otrzymuje żądanie, które uzyskuje dostęp do programu CGI, musi on utworzyć nowy proces w celu uruchomienia programu CGI i potem przekazania mu, poprzez zmienne środowiskowe i standardowe wpisy, każdego bitu informacji, który może być potrzebny do wygenerowania odpowiedzi. Tworzenie procesu dla każdego takiego żądania wymaga czasu i znaczących zasobów serwera, co ogranicza liczbę żądań, które serwer może obsługiwać równocześnie. Rysunek 1.1 przedstawia okres trwałości CGI.
Rysunek 1.1. Okres trwałości CGI
Chociaż program CGI może być utworzony w prawie każdym języku, język programowania Perl stał się podstawową opcją. Zaawansowane możliwości formatowania tekstu Perla stanowią ogromną pomoc w zarządzaniu szczegółami interfejsu CGI. Tworzenie skryptu CGI w Perlu pozwala na uniezależnienie o platformy, ale wymaga również uruchomienia osobnego interpretatora Perla dla każdego żądania, co zabiera jeszcze więcej czasu i wymaga dodatkowych zasobów.
Innym często przeoczonym problemem z CGI jest niemożność interakcji programu CGI z serwerem WWW lub skorzystania z możliwości serwera po rozpoczęciu działania tego programu, ponieważ działa on jako osobny proces. Na przykład, skrypt CGI nie potrafi zapisywać informacji w dzienniku zdarzeń serwera. Większa ilość informacji na temat programowania CGI jest dostępna w książce „CGI Programming on the World Wide Web” autorstwa Shishira Gundavarama (O'Reilly).
Firma o nazwie OpenMarket stworzyła alternatywę dla standardu CGI o nazwie FastCGI. W większości aspektów, FastCGI działa podobnie do CGI — ważną różnicą jest tworzenie przez FastCGI jednego trwałego procesu dla każdego programu FastCGI, jak przedstawiono na rysunku 1.2. Eliminuje to konieczność tworzenia nowego procesu dla każdego żądania.
Rysunek 1.2. Okres trwałości FastCGI
Chociaż FastCGI jest krokiem we właściwym kierunku, ciągle posiada on problem z mnożeniem się procesów — istnieje co najmniej jeden proces dla każdego programu FastCGI. Jeżeli program FastCGI musi obsługiwać żądania równoległe, potrzebuje puli procesów, jednego na każde żądanie. Pamiętając, że każdy proces może wykonywać interpretator Perla, podejście na to nie jest skalowalne na tyle, na ile można się tego spodziewać. (Chociaż trzeba przyznać, że FastCGI może rozkładać procesy pomiędzy wieloma serwerami.) Innym problemem z FastCGI jest to, że nie pozwala on swoim programom na bliższą interakcję z serwerem. Poza tym, programy FastCGI są przenośne jedynie tak, jak język, w którym zostały napisane. Większa ilość informacji na temat FastCGI jest dostępna pod adresem http://www.fastcgi.com.
PerlEx, utworzony przez ActiveState, zwiększa wydajność skryptów CGI napisanych w Perlu pracujących na serwerach WWW pod Windows NT (Internet Information Server Microsoftu, Website Professional O'Reilly oraz FastTrack Server i Enterpise Server iPlanet). Posiada on zalety i wady podobne do FastCGI. Większa ilość informacji na temat PerlEx dostępna jest pod adresem http://www.activestate.com/plex.
Przy korzystaniu z serwera WWW Apache, inną opcją zwiększenia wydajności CGI jest wykorzystanie mod_perl. mod_perl jest modułem serwera Apache osadzającym kopię interpretatora Perla w pliku wykonywalnym Apache'a, dostarczającym pełnej funkcjonalności Perla wewnątrz Apache'a. Jego efektem jest prekompilowanie skryptów CGI przez serwer i wykonywanie ich bez rozdzielania, a związku z tym ich praca jest dużo szybsza i wydajniejsza. Jego wadą jest możliwość wykorzystania jedynie w serwerze Apache. Większa ilość informacji na temat mod_perl jest dostępna pod adresem http://perl.apache.org.
CGI/Perl posiada zaletę bycia mniej lub bardziej niezależnym od platformy sposobem na tworzenie dynamicznej zawartości WWW. Inne dobrze znane technologie tworzenia aplikacji WWW takie jak ASP i JavaScript działający po stronie serwera, są opatentowanymi rozwiązaniami pracującymi jedynie z określonymi serwerami WWW.
Kilka firm utworzyło własne interfejsy API rozszerzeń serwera dla swoich serwerów WWW. Na przykład, iPlanet/Netscape dostarcza wewnętrzny API o nazwie WAI (dawniej NSAPI), a Microsoft dostarcza ISAPI. Przy pomocy każdego z tych interfejsów, można utworzyć rozszerzenia serwera zwiększające lub zmieniające jego podstawową funkcjonalność, pozwalającą mu na obsługę zadań wcześniej delegowanych do zewnętrznych programów CGI. Jak można dostrzec na rysunku 1.3, rozszerzenia serwera występują wewnątrz głównego procesu serwera WWW.
Rysunek 1.3. Okres trwałości rozszerzeń serwera
Ponieważ specyficzne dla serwera interfejsy wykorzystują połączony kod C lub C++, rozszerzenia serwera działają niezwykle szybko i w pełni wykorzystują zasoby serwera. Nie są one jednak rozwiązaniem doskonałym. Poza tym, że są one ciężkie w tworzeniu i utrzymaniu, stanowią poważne zagrożenia dla bezpieczeństwa i niezawodności — załamanie rozszerzenia może prowadzić do załamania całego serwera, złośliwe rozszerzenie może kraść hasła użytkowników i numery kart kredytowych. Oraz, oczywiście konkretne rozszerzenia są nierozerwalnie związane z API serwera, dla którego zostały napisane, a także do konkretnego systemu operacyjnego.
iPlanet/Netscape posiada również technikę skryptów działających po stronie serwera, nazywaną server-side JavaScript, w skrócie SSJS. Podobnie jak ASP, SSJS pozwala na osadzanie fragmentów kodu w stronach HTML w celu utworzenia dynamicznej zawartości WWW. Różnica jest taka, że SSJS wykorzystuje JavaScript jako język skryptowy. Z SSJS, strony są prekompilowane w celu poprawienia wydajności. Obsługa SSJS jest możliwa jedynie w serwerach iPlanet/Netscape. Większa ilość informacji na temat programowania przy pomocy JavaScript działającego po stronie serwera dostępna jest pod adresem http://developer.netscape.com/tech/javascript/ssjs/ssjs.html.
Microsoft posiada technikę tworzenia dynamicznej zawartości WWW o nazwie Active Server Pages (Aktywne Strony Serwera), w skrócie ASP. Przy pomocy ASP, strona HTML może zawierać fragmenty osadzonego kodu (zazwyczaj VBScript lub Jscript — chociaż możliwe jest zastosowanie niemal każdego języka). Kod ten jest odczytywany i wykonywany przez serwer WWW przed wysłaniem strony do klienta. ASP został optymalizowany do tworzenia niewielkich porcji zawartości dynamicznej, większe pozostawiając składnikom COM.
Obsługa ASP jest wbudowana w Internet Information Server Microsoftu w wersji 3.0 i wyższych, dostępnym bezpłatnie pod adresem http://www.microsoft.com/iis. Obsługa innych serwerów WWW jest dostępna jako komercyjny produkt firmy Chili!Soft pod adresem http://www.chilisoft.com. Proszę pamiętać, że strony ASP działające na platformie nie będącej Windows mogą mieć problemy z powodu braku biblioteki Windows COM. Większa ilość informacji na temat programowania ActiveServerPages jest dostępna pod adresem http://www.microsoft.com/workshop/server/default.asp oraz http://www.activeserverpages.com/.
JavaServer Pages, często nazywana po prostu JSP, jest opartą na Javie alternatywą dla ASP, utworzoną i wystandaryzowaną przez firmę Sun. JSP wykorzystuje składnię podobną do ASP poza tym, że językiem skryptowym w tym przypadku jest Java. Odwrotnie niż ASP, JSP jest otwartym standardem implementowanym przez wielu producentów na wszystkich platformach. JSP jest ścisłe związana z serwletami, ponieważ strona JSP jest przetwarzana do serwletu, co stanowi część jej wykonania. JSP jest bardziej szczegółowo opisana w dalszych częściach niniejszej książki. Większa ilość informacji na temat JSP jest dostępna pod adresem http://java.sun.com/products/jsp.
W tym miejscu pojawiają się serwlety Javy. Jak wspomniano wcześniej, serwlet jest ogólnym rozszerzeniem serwera — klasą Javy, która może być dynamicznie ładowana w celu rozszerzenia funkcjonalności serwera. Serwlety są często używane w serwerach WWW, gdzie zajmują miejsce skryptów CGI. Serwlet jest podobny do poprzednio omawianego rozszerzenia serwera, poza tym, że działa on wewnątrz wirtualnej maszyny Javy (Java Virtual Machine — JVM) na serwerze (proszę spojrzeć na rysunek 1.4), tak więc są one bezpieczne i przenośne. Serwlety działają wyłącznie w domenie serwera — inaczej niż aplety, nie wymagają one obsługi Javy przez przeglądarkę WWW.
Rysunek 1.4. Okres trwałości serwletu
Inaczej niż CGI i FastCGI, które muszą wykorzystywać wiele procesów w celu obsługi oddzielnych programów i/lub oddzielnych żądań, serwlety mogą być obsługiwane przez osobne wątki w tym samym procesie, z wieloma procesami rozciągniętymi na klika serwerów wspierających. Oznacza to, że serwlety są również wydajne i skalowalne. Ponieważ serwlety działają z komunikacją dwustronną do serwera WWW, mogą bardzo ściśle współpracować z serwerem w celu wykonania działań niemożliwych dla skryptów CGI.
Inną zaletą serwletów jest ich przenośność — zarówno pomiędzy systemami operacyjnymi jak w przypadku Javy, jak i pomiędzy serwerami WWW. Jak zostanie to opisane poniżej, większość głównych serwerów WWW obsługuje serwlety. Uważa się, że serwlety stanowią najlepszą możliwą platformę dla tworzenia aplikacji WWW, a więcej informacji na ten temat zostanie podane w dalszej części tego rozdziału.
Podobnie jak sama Java, serwlety zostały zaprojektowane w celu zapewnienia maksymalnej przenośności. Serwlety obsługiwane są przez wszystkie platformy obsługujące również Javę, oraz pracują w większości podstawowych serwerów WWW[1]. Serwlety Javy zdefiniowane przez dział Java Software firmy Sun Microsystems (dawniej znany jako JavaSoft), stanowią Pakiet Opcjonalny (Optional Package) dla Javy (dawniej znany jako Rozszerzenie Standardowe — Standard Extension). Oznacza to, że serwlety zostały oficjalnie pobłogosławione przez Sun'a i stanowią część języka Java, lecz nie są częścią podstawowego API Javy. Zamiast tego, są one znane jako część platformy J2EE.
W celu ułatwienia tworzenia serwletów, Sun i Apache udostępniły klasy API niezależnie od żadnego mechanizmu WWW. Pakiety javax.servlet i javax.servlet.http składają się na Servlet API. Najnowsza wersja tych klas jest dostępna do pobrania pod adresem http://java.sun.com/products/servlet/download.html[2]. Wszystkie serwery WWW obsługujące serwlety muszą wykorzystywać te klasy wewnętrznie (chociaż mogą stosować alternatywną implementację), tak więc generalnie ten plik JAR może zostać znaleziony gdzieś wewnątrz dystrybucji serwera WWW obsługującego serwlety.
Nie jest ważne, skąd pobiera się klasy serwletów, należy posiadać je jednak w swoim systemie w celu kompilowania serwletów. Dodatkowo konieczny jest program uruchamiający serwlety (technicznie nazywany kontenerem serwletów, czasami mechanizmem serwletów), w celu przetestowania i udostępnienia serwletów. Wybór kontenera serwletów zależy po części od działającego w danym systemie serwera(ów) WWW. Istnieją trzy odmiany kontenerów serwletów — samodzielne, dołączane i osadzane.
Samodzielny kontener serwletów to serwer zawierający wbudowaną obsługę serwletów. Taki kontener posiada tę przewagę, że wszystko w nim działa niejako od razu. Jednak wadą jest konieczność oczekiwania na nową wersję serwera WWW w celu uzyskania obsługi najnowszych serwletów. Inną wadą jest także fakt, że producenci serwerów generalnie obsługują jedynie JVM dostarczoną przez samych siebie. Serwery WWW dostarczające samodzielnej obsługi to między innymi:
· Tomcat Server Apache, oficjalna wzorcowa implementacja sposobu obsługi serwletów przez kontener. Napisany całkowicie w Javie, dostępny bezpłatnie w licencji Open Source. Dostępny jest cały kod źródłowy i każdy może pomóc w jego tworzeniu. Serwer ten może działać samodzielnie lub jako dodatek dostarczający obsługi serwletów Apache'owi lub innym serwerom. Może być również wykorzystywany jako kontener osadzony. Równolegle z Tomcatem, Apache tworzy standardową implementację pakietów javax.servlet i javax.servlet.http. W trakcie pisania niniejszej książki serwlety są jedynymi pakietami java.* lub javax.* utrzymywanymi jako Open Source[3]. Proszę zobaczyć http://jakarta.apache.org.
· iPlanet Web Server Enterprise Edition Netscape'a (wersja 4.0 i późniejsze), przypuszczalnie najpopularniejszy serwer WWW zawierający wbudowaną obsługę serwletów. Niektóre testy wykazują, że posiada on najszybszą implementację serwletów. Proszę pamiętać, że chociaż wersje 3.51 i 3.6 zawierały wbudowaną obsługę serwletów, to jednak był to wczesny Servlet API 1.0 i zawierały one dużą liczbę błędów tak poważnych, że obsługa serwletów była praktycznie bezużyteczna. W celu wykorzystania serwletów z serwerami Netscape'a w wersji 3.x należy wykorzystać dołączany kontener. Proszę zobaczyć http://www.iplanet.com.
· WebSite Professional O'Reilly, o podobnej funkcjonalności do Enterprise Server iPlanet, lecz za niższą cenę. Proszę zobaczyć http://website.oreilly.com.
· Zeus Web Server, serwer WWW uważany przez niektórych za najszybszy z dostępnych. Jego lista własności jest dość długa i zawiera obsługę serwletów. Proszę zobaczyć http://www.zeus.co.uk.
· Resin Caucho, kontener Open Source, uważany za bardzo wydajny. Może być uruchamiany w trybie samodzielnym lub jako dodatek do wielu serwerów. Proszę zobaczyć http://www.caucho.com.
· LiteWebServer Gefion Software, niewielki (nieco ponad 100 KB) kontener serwletów utworzony dla zastosowań, takich jak dołączanie do wersji demonstracyjnych, gdzie niewielki rozmiar ma znaczenie. Proszę zobaczyć http://www.gefionsoftware.com/LiteWebServer.
· Jigsaw Server World Wide Web Consortium Open Source, napisany całkowicie w Javie. Proszę zobaczyć http://www.w3.org/Jigsaw.
· Java Web Server firmy Sun, serwer, od którego wszystko się rozpoczęło. Serwer ten był pierwszym serwerem implementującym serwlety oraz działał jako efektywna wzorcowa implementacja dla Servlet API 2.0. Jest on napisany całkowicie w Javie (poza dwoma bibliotekami kodu macierzystego, które powiększają funkcjonalność, lecz nie są konieczne). Sun nie kontynuuje już prac nad serwerem, koncentrując się na produktach iPlanet/Netscape w ramach sojuszu Sun-Netscape. Proszę zobaczyć http://java.sun.com/products.
Serwery aplikacji są rosnącym obszarem tworzenia. Serwer aplikacji oferuje obsługę po stronie serwera dla tworzenia aplikacji korporacyjnych. Większość aplikacji opartych na Javie obsługuje serwlety i pozostałą część specyfikacji Java 2, Enterprise Edition (J2EE).Serwery te to miedzy innymi:
· WebLogic Application Server BEA System, jeden z pierwszych i najsłynniejszych opartych na Javie serwerów aplikacji. Proszę zobaczyć http://www.beasys.com/products/weblogic.
· Orion Application Server, wysoko wydajny serwer o stosunkowo niskiej cenie, napisany całkowicie w Javie. Proszę zobaczyć http://www.orionserver.com.
· Enhydra Application Server, serwer Open Source firmy Lutris. Proszę zobaczyć http://www.enhydra.org.
· Borland Application Server 4, serwer ze specjalnym naciskiem na technologię CORBA. Proszę zobaczyć http://www.borland.com/appserver.
· WebSphere Application Server IBM, wysokowydajny serwer oparty w części na kodzie Apache'a. Proszę zobaczyć http://www-4.ibm.com/software/webservers.
· Dynamo Application Server 3 ATG, kolejny wysokowydajny serwer napisany całkowicie w Javie. Proszę zobaczyć http://www.atg.com.
· Application Server Oracle, serwer zaprojektowany do integracji z bazą danych Oracle. Proszę zobaczyć http://www.oracle.com/appserver.
· iPlanet Application Server, zgodny z J2EE większy brat iPlanet Web Server Enterprise Edition. Proszę zobaczyć http://www.iplanet.com/products/infrastructure/app_servers/nas.
· GemStone/J Application Server, serwer Javy stworzony przez firmę poprzednio znaną z serwera Smalltalk. Proszę zobaczyć http://www.gemstone.com/products/j.
· Jrun Server Allaire (poprzednio Live Software), prosty kontener serwletów, który rozrósł się do zaawansowanego kontenera dostarczającego wiele technologii J2EE włączając w to EJB, JTA i JMS. Proszę zobaczyć http://www.allaire.com/products/jrun.
· Silverstream Application Server, w pełni zgodny z J2EE serwer, który rozpoczął również od skupienia się na serwletach. Proszę zobaczyć http://www.silverstream.com.
Dołączany kontener serwletów działa jako moduł rozszerzający do istniejącego serwera — dodaje obsługę serwletów do serwera, który w oryginale nie był do tego przeznaczony, lub do serwera ze słabą lub nieaktualną implementacją serwletów. Dołączane kontenery serwletów zostały utworzone dla wielu serwerów, między innymi Apache'a, FastTrack Server i Enterprise Server iPlanet, Internet Information Server i Personal Web Server Microsoftu, Website O'Reilly, Go Webserver Lotus Domino, WebSTAR StarNine oraz AppleShare IP Apple. Dołączane kontenery serwletów to między innymi:
· ServletExec New Atlanta — moduł rozszerzający zaprojektowany do obsługi serwletów we wszystkich popularnych serwerach na wszystkich popularnych systemach operacyjnych. Zawiera bezpłatny program uruchomieniowy. Proszę zobaczyć http://www.servletexec.com.
· Jrun Allaire (dawniej Live Software), dostępny jako moduł rozszerzający do obsługi serwletów we wszystkich popularnych serwerach na wszystkich popularnych systemach operacyjnych. Proszę zobaczyć http://www.allaire.com/products/jrun/.
· Moduł Jserv projektu Java-Apache, bezpłatny kontener serwletów Open Source, który dodaje obsługę serwletów do niezwykle popularnego serwera Apache. Tworzenie Jserv zakończyło się, a Tomcat Server (działający jako moduł rozszerzający) jest jego następcą. Proszę zobaczyć http://java.apache.org/.
· Tomcat Server Apache, jak opisano poprzednio. Tomcat może być dołączony do innych serwerów takich jak Apache, iPlanet/Netscape i IIS.
Osadzany kontener jest ogólnie niewielką platformą programistyczną, która może być osadzana w innych aplikacjach. Aplikacja ta staje się prawdziwym serwerem. Osadzane kontenery serwletów to między innymi:
· Tomcat Server Apache, podczas gdy ogólnie używany samodzielnie lub dołączany, może być również osadzany w innej aplikacji, kiedy jest to potrzebne. Ponieważ serwer ten to Open Source, tworzenie większości innych osadzanych serwerów zatrzymano.
· Nexus Web Server autorstwa Andersa Kristensena, dostępny bezpłatnie program uruchamiający serwlety, implementujący większą część Servlet API, który może być w łatwy sposób dołączany do aplikacji Javy. Proszę zobaczyć http://www-uk.hpl.hp.com/people/ak/java/nexus/.
Przed przejściem do następnej części należy zapamiętać, że nie wszystkie kontenery serwletów są tworzone w jednakowy sposób. Tak więc przed wybraniem kontenera serwletów (i prawdopodobnie serwera) przy pomocy którego udostępniane będą serwlety, należy go wypróbować, prawie do granic możliwości. Sprawdzić listy dystrybucyjne. Należy zawsze sprawdzać, czy serwlety zachowują się tak, jak we wzorcowej implementacji Tomcata. Można również sprawdzić, jakie narzędzia programistyczne są dostarczane, które technologie J2EE są wspierane i jak szybko można uzyskać pomoc u producenta. W przypadku serwletów nie trzeba się martwić o zgodność z najsłabszą implementacją, tak więc należy pobrać kontener serwletów, który posiada wszystkie pożądane właściwości.
Kompletna, aktualna lista dostępnych kontenerów serwletów razem z ich obecnymi cenami jest dostępna pod adresem http://www.servlets.com.
Jak dotychczas serwlety zostały opisane jako alternatywa dla innych technologii dynamicznej zawartości WWW, lecz nie zostało tak naprawdę powiedziane, dlaczego powinny być one, zdaniem autorów, stosowane. Co sprawia, że serwlety są jednym z najlepszych sposobów programowania WWW? Zdaniem autorów posiadają one kilka zalet ponad innymi podejściami, włączając w to przenośność, moc, wydajność, wytrzymałość, bezpieczeństwo, elegancję, integrację, rozszerzalność i elastyczność. Każda z tych własności zostanie kolejno omówiona.
Ponieważ serwlety są pisane w Javie według dobrze zdefiniowanego i szeroko akceptowanego API, są one w dużym stopniu przenośne pomiędzy systemami operacyjnymi i implementacjami serwerów. Można stworzyć serwlet na komputerze pod Windows NT i z serwerem Tomcat, po czym bez problemu udostępnić go na wysoko wydajnym serwerze Uniksowym z iPlanet/Netscape Application Server. Stosując serwlety można naprawdę „napisać raz, udostępniać wszędzie”.
Przenośność serwletów nie jest tak ważną sprawą jak w przypadku apletów, z dwóch powodów. Po pierwsze, przenośność serwletów nie jest obowiązkowa. Inaczej niż w przypadku apletów, które muszą zostać przetestowane na wszystkich możliwych platformach klientów, serwlety muszą pracować jedynie na serwerach, które są wykorzystywane do tworzenia i udostępniania. Dopóki nie sprzedaje się swoich serwletów, nie trzeba się martwić o kompletną przenośność. Po drugie, serwlety unikają najbardziej pełnej błędów i niespójnie zaimplementowanej części języka Java — Abstract Windowing Toolkit (AWT), który stanowi bazę graficznych interfejsów Javy, takich jak Swing.
Serwlety m...
przempore