W niniejszym rozdziale:
" Historia aplikacji WWW
" Obsługa serwletów
" Moc serwletów
Rozdział 1.
Wprowadzenie
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.
Historia aplikacji WWW
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
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óz
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 z
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).
FastCGI
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
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.
mod_perl
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.
Inne rozwiązania
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.
Interfejsy rozszerzeń serwera
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.
JavaScript działający po stronie serwera
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.
Active Server Pages
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
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.
Serwlety Javy
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.
Obsługa serwletów
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 WWW1. 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.html2. Wszystkie serwery WWW obsługujące serwlety muszą
1
Proszę zauważyć, że niektórzy producenci serwerów WWW posiadają swoje własne implementacje Javy działającej po
stronie serwera, niektóre z nich noszą również nazwę serwletów. Są one generalnie niekompatybilne z serwletami Javy
utworzonymi przez Sun'a. Większość z tych producentów konwertuje swoją obsługę Javy do standardowych serwletów lub
wprowadzają obsługę standardowych serwletów równolegle, w celu zapewnienia wstecznej kompatybilności.
2
W pewnym momencie planowano dołączenie tych klas do JDK 1.2. Póz
niej jednak zdecydowano na utrzymanie ich
niezależności od JDK w celu ułatwienia dokonywania poprawek do Servlet API.
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.
Samodzielne kontenery serwletów
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
z
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 Source3.
Proszę zobaczyć http://jakarta.apache.org.
" iPlanet Web Server Enterprise Edition Netscape'a (wersja 4.0 i póz
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.
3
Implementacja javax.servlet i javax.servlet.http w standardzie Open Source spowodowała naprawienie
wielu błędów (na przykład, autor miał okazję poprawić obsługę warunkowego GET w HttpServlet) i kwestii
niekompatybilności. Istnieje nadzieja, że przykład ten wspomoże w udostępnieniu większej ilości oficjalnych pakietów Javy
jako Open Source
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łączane kontenery serwletów
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.
Osadzane kontenery serwletów
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/.
Uwagi dodatkowe
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.
Potęga serwletów
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.
Przenośność
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.
Moc
Serwlety mogą wykorzystywać pełną moc jądra API Javy  pracę w sieci i dostęp do URL-i, wielowątkowość,
kompresję danych, łączność z bazami danych (JDBC), serializację obiektów, zdalne wywoływanie metod (RMI)
oraz integrację ze starymi programami (CORBA). Serwlety mogą również korzystać z platformy J2EE, która
zawiera obsługę Enterprise JavaBeans (EJBs), transakcji rozproszonych (JTS), standaryzowanych wiadomości
(JMS), wyszukiwania katalogów (JNDI) oraz zaawansowanego dostępu do baz danych (JDBC 2.0). Lista
standardowych API dostępnych serwletom rośnie, czyniąc tworzenie aplikacji WWW szybszym, łatwiejszym i
bardziej niezawodnym.
Jako autor serwletów, można wykorzystać dowolną z mnóstwa niezależnych klas Javy i składników JavaBeans.
Serwlety mogą używać niezależnego kodu w celu obsługi zadań takich jak wyszukiwanie według wyrażeń
regularnych, tworzenie wykresów danych, dostosowany dostęp do baz danych, zaawansowana praca w sieci,
analiza składniowa XML oraz tłumaczenia XSLT.
Serwlety są również sprawne w umożliwianiu komunikacji klient-serwer. Posiadając oparty na Javie aplet i
oparty na Javie serwlet, można wykorzystać RMI i serializację obiektu w komunikacji klient-serwer, co oznacza,
że ten sam kod można wykonać zarówno na maszynie klienta, jak i na serwerze. Wykorzystywanie po stronie
serwera języków innych niż Java jest znacznie bardziej skomplikowane, jako że konieczne jest tworzenie swoich
własnych protokołów do obsługi komunikacji.
Wydajność i wytrzymałość
Wywoływanie serwletów charakteryzuje się bardzo wysoką wydajnością. Kiedy serwlet zostaje załadowany,
pozostaje w pamięci serwera jako pojedynczy egzemplarz obiektu. Następnie serwer wywołuje serwlet do
obsługi żądania przy pomocy prostego wywołania metody. Inaczej niż w przypadku CGI, nie trzeba wywoływać
procesu ani interpretatora, tak więc serwlet może rozpocząć obsługę żądania niemal natychmiast. Wielokrotne,
równoległe żądania są obsługiwane przez osobne wątki, tak więc serwlety są w wysokim stopniu skalowalne.
Serwlety są obiektami z natury trwałymi. Ponieważ serwlet zostaje w pamięci serwera jako pojedynczy
egzemplarz obiektu, automatycznie zachowuje swój stan i może utrzymywać kontakt z zasobami zewnętrznymi,
takimi jak połączenia z bazami danych. W innym przypadku przywrócenie połączenia mogłoby zabrać
kilkanaście sekund.
Bezpieczeństwo
Serwlety obsługują bezpieczne praktyki programowania na różnych poziomach. Ponieważ są one pisane w Javie,
dziedziczą po niej silne bezpieczeństwo typów. Podczas gdy większość wartości w programie CGI, włączając w
to element numeryczny taki, jak numer portu serwera, są traktowane jako łańcuchy, wartości w Servlet API są
manipulowane przy pomocy ich naturalnych typów, tak więc numer portu serwera jest reprezentowany jako
integer. Automatyczne zbieranie śmieci przez Javę i brak wskaz
ników oznaczają, że serwlety są generalnie
bezpieczne od problemów z zarządzaniem pamięcią, takich, jak uszkodzone wskaz
niki, niewłaściwe odwołania
do wskaz
ników oraz uszczerbki pamięci.
Serwlety mogą bezpiecznie obsługiwać błędy, dzięki mechanizmowi obsługi wyjątków lub kontrolerowi dostępu
Javy. Jeżeli serwlet wykona dzielenie przez zero lub inne nieprawidłowe działanie, wyrzuca wyjątek, który może
być bezpiecznie wychwycony i obsłużony przez serwer, który zapisze błąd w dzienniku zdarzeń i przeprosi
użytkownika. Jeżeli podobny wyjątek napotkałoby rozszerzenie serwera oparte na C++, przypuszczalnie
nastąpiłoby załamanie serwera.
Serwer może chronić siebie w większym stopniu poprzez zastosowanie menedżera bezpieczeństwa lub
kontrolera dostępu Javy. Serwer może wykonywać swoje serwlety pod ochroną dokładnego kontrolera dostępu
który, na przykład wymusza politykę bezpieczeństwa zaprojektowaną do strzeżenia przed złośliwym lub z
le
zaprojektowanym serwletem dążącym do zniszczenia systemu plików serwera.
Elegancja
Elegancja kodu serwletów jest uderzająca. Kod serwletów jest czysty, obiektowy, modularny i zadziwiająco
prosty. Jednym z powodów tej prostoty jest sam Servlet API, który zawiera metody i klasy obsługujące wiele
rutynowych elementów programowania serwletów. Nawet zaawansowane operacje, takie jak obsługa cookies i
śledzenie sesji, są rozkładane na odpowiednie klasy. Kilka bardziej zaawansowanych, lecz także popularnych
zadań zostało pozostawione poza API, i w tych przypadkach autorzy próbowali to naprawić i tak powstał zbiór
przydatnych klas w pakiecie com.oreilly.servlet.
Integracja
Serwlety są ściśle zintegrowane z serwerem. Ta integracja pozwala serwletowi na współpracę z serwerem w
sposób niedostępny dla programów CGI. Na przykład, serwlet może wykorzystywać serwer w celu
przetłumaczenia ścieżek plików, dokonania logowania, sprawdzenia uwierzytelnienia oraz wykonania
odwzorowania typu MIME. Właściwe dla konkretnego serwera rozszerzenia mogą wykonać większość tej pracy,
lecz proces ten jest zazwyczaj znacznie bardziej złożony i obfity w błędy.
Rozszerzalność i elastyczność
Servlet API jest zaprojektowany w celu zapewnienia łatwej rozszerzalności. W obecnym czasie, API zawiera
klasy z wyspecjalizowaną obsługą serwletów HTTP. Lecz w póz
niejszym okresie może być ona rozszerzona i
zoptymalizowana dla innego typu serwletów, czy to produkcji Suna, czy innej firmy. Jest również możliwe, że
jego obsługa serwletów HTTP może być dalej rozwijana.
Serwlety cechują się również elastycznością w tworzeniu zawartości. Mogą tworzyć prostą zawartość przy
pomocy wyrażeń out.println(), lub generować skomplikowany zbiór stron przy pomocy mechanizmu
szablonów. Mogą tworzyć stronę HTML przez traktowanie strony jako zestawu obiektów Javy, lub tworzyć
stronę HTML przez wykonanie transformacji XML do HTML. Serwlety mogą być nawet łączone w celu
utworzenia całkowicie nowych technologii takich jak JavaServer Pages. Nie wiadomo, do czego jeszcze zostaną
wykorzystane.