Vyšlo na www.mediaserver.cz dne 24. června 1997
Vytištěno z adresy: http://www.earchiv.cz/axxxk160/a706k163.php3

Servlet

Servlet: označení pro programovou komponentu, napsanou v jazyku Java a určenou k provozování na WWW serveru (v protikladu k tzv. appletu, který je určen k běhu na straně klientě). Velkým přínosem servletů je jejich nezávislost na serverové platformě (k běhu servletů postačuje podpora Javy a "servletového API"), Dalším přínosem je i takové řešení bezpečnosti, které umožňuje uživatelům posílat své servlety na WWW server a zde je spouštět.

Dnešní Web již dávno není statickou záležitostí – tedy soustavou WWW stránek, které by někde byly uskladněny přesně v takové podobě, v jaké jsou následně předkládány uživatelům, kteří si je vyžádají. V mnoha situacích by to ani nebylo principiálně možné, například u nejrůznějších vyhledávacích služeb, služeb spočívajících v přístupu do databází apod. Zde není možné dopředu připravit odpovědi na všechny možné dotazy – místo toho je zde nutné WWW stránky vytvářet dynamicky až v době, kdy jsou skutečně zapotřebí, podle konkrétních momentálních požadavků. Možnost dynamického sestavování WWW stránek se ale s oblibou využívá i v jiných situacích, kde by to nezbytně nutné nebylo: například pro vkládání reklam, úpravu formátu stránky podle druhu uživatelova WWW prohlížeče, a v našich zeměpisných šířkách také pro správné překódování české diakritiky.

Konkrétní způsob, jakým se možnost dynamického generování (či alespoň přizpůsobování) řeší, se samozřejmě vyvíjel a nadále vyvíjí. Je přitom vcelku zřejmé, že dynamické generování WWW stránek je především záležitostí WWW serverů (i když určité slovo zde mohou mít i mechanismy fungující na straně klienta, jako například skriptové jazyky typu JavaScriptu, či Javovské applety). Historicky nejstarším mechanismem, používaným pro dynamické generování WWW stránek na straně serveru je tzv. CGI rozhraní (Common Gateway Interface). Lze si jej představit jako řešení, umožňující aby si WWW server zavolal na pomoc externí program, který za něj vyřeší vše potřebné. Jde přitom o běžné, samostatně spustitelné programy (v prostředí DOSU-u a Windows je možné si je představit jako programy volané z tzv. příkazové řádky), spouštěné vždy znovu a znovu pro splnění každého jednotlivého požadavku. Skutečnost, že jde o "plnohodnotné" programy, schopné samostatné existence, znamená že s jejich spouštěním i ukončováním je spojena dosti velká režie. Navíc jsou tyto programy závislé na konkrétní platformě, a nelze je tedy přenášet na jiné platformy.

Dalším řešením se stalo mnohem těsnější svázání WWW serveru a programů, které za něj budou vyřizovat potřebné požadavky. Pokud takovéto programy budou psány "přesně na míru" příslušným serverům a způsobu, jakým své požadavky vznášejí a jakým chtějí přejímat zpět výsledky, může vše fungovat mnohem efektivněji. Je k tomu samozřejmě zapotřebí přesná definice rozhraní mezi WWW serverem (přesněji HTTP démonem) a příslušnými programy: například v případě WWW serverů firmy Netscape jde o rozhraní NSAPI, a v případe WWW serverů IIS firmy Microsoft rozhraní ISAPI. I zde je ale problém s přenositelností, protože programy uzpůsobené jednomu serveru a jeho konkrétnímu rozhraní API nelze přenést na jinou serverovou platformu s jiným API.

Zajímavým novým řešení je pak koncepce tzv. servletů, jak se říká "prográmkům", sloužícím výše naznačeným účelům a psaným v jazyku Java. Lze si je představit jako jistou analogii appletů, neboli analogii "prográmkům" psaným také v Javě, a určeným pro běh na straně klienta. V případě servletů se však jedná o malé programy určené k běhu na WWW serveru (díky tomu tyto servlety nemusí mít žádné uživatelské rozhraní). Jejich velkou předností je nezávislost na konkrétní platformě, což je dáno "platformovou nezávislostí" samotného jazyka Java (k běhu servletů je zapotřebí pouze vhodný Java Virtual Machine na straně serveru). Servlety však na druhé straně nemohou být nezávislé na způsobu, jakým s nimi komunikuje samotný server – existuje tedy pro ně speciální "servletové API", které musí příslušný server podporovat. Příslušné "servletové API" dnes podporuje například Java Server firmy Sun (WWW server, napsaný celý v Javě), a také celá řada dalších serverů, které již byly vyvinuty s vědomím existence servletového API (viz další informace). Pro jiné WWW servery, které se servlety původně nepočítaly, existuje alespoň možnost jim takovéto rozhraní dodatečně vnutit – to dnes lze učinit se servery IIS firmy Microsoft i se servery firmy Netscape, a také s oblíbenými servery Apache.

Koncepce servletů však není jen novou, efektivnější a snáze přenositelnou implementací již delší dobu existujícího mechanismu. Přináší i novou kvalitu, kterou je zejména možnost, aby si klient sám "doručil" na server svůj vlastní "kus kódu", který pak bude na serveru vykonán (či průběžně vykonáván). Stávající WWW servery něco takového apriorně odmítají, protože nemají možnost se ochránit proti případnému "zlému" kódu, který by mohl vykonat něco co si provozovatel serveru nepřeje. Hlavní problém je v tom, že programům šitým na míru rozhraní CGI či rozhraním typu ISAPI a NSAPI (a psaným typicky v jazyku C) lze jen velmi těžko něco zakázat. V případě servletů je to naopak dosti snadné, díky samotné filosofii jazyka Java, ve kterém jsou psány.

Koncepce servletů dokonce počítá se dvěma kategoriemi těchto "kusů kódu": s důvěryhodnými servlety a nedůvěryhodnými servlety (trusted, vs. untrusted servlets). Ty nedůvěryhodné budou provozovány v samostatné "výpočetní linii" (tzv. threadu), kde je možné efektivněji "pohlídat" jejich činnost a vyvarovat se i negativním vlivům jejich chování (například pádům). Činnosti typu přístupu k místním souborům, které mohou být zdrojem bezpečnostních rizik, pak budou vyhrazeny pouze důvěryhodným servlerům. Důležité přitom je, že o rozdělení konkrétních servletů mezi důvěryhodné a nedůvěryhodné bude rozhodovat až správce konkrétního serveru – ten se může rozhodnout například takovým způsobem, že za důvěryhodné bude považovat pouze "místní" servlety (umístěné přímo na daném serveru v definovaném adresáři, a které si tudíž mohl sám zkontrolovat), a případně i takové, které sice přichází ze sítě, ale jsou zabaleny do zvláštního archivního formátu a jsou opatřeny digitálním podpisem svého autora (zatímco všechny ostatní servlety budou automaticky považovány za nedůvěryhodné, a budou jim povoleny jen takové činnosti, které nepředstavují žádná bezpečnostní rizika).

Možnosti využití servletů jsou velmi široké – kromě "obvyklého" dynamického upravování či přímo generování WWW stránek mohou například plnit roli nejrůznějších bran mezi světem WWW a světem jiných aplikací (například databázových), resp. plnit roli prostředního článku ve tříúrovňové architektuře klient/server (neboli realizovat tzv. aplikační logiku). V našich zeměpisných šířkám nejspíše budou použity i pro dynamické překódovávání češtiny. V zásadě všechny takovéto možnosti však již nabízela i dosavadní řešení na bázi CGI rozhraní a rozhraní typu ISAPI a NSAPI, zde je však výhoda v nezávislosti na konkrétní serverové platformě. S tou pak souvisí i jedno zajímavé novum: servlety mohou být jednou z forem tzv. inteligentních agentů, jak se říká "kusům kódu", které cestují sítí a přitom plní určité zadání, se kterým byly vypuštěny. Díky své nezávislosti na serverové platformě by servlety mohly snadno cestovat z jednoho serveru (s podporou "servletového API") na druhý, a zde vykonávat svou práci.


Další zdroje informací:
Odkazy na oficielní informace firmy Sun o jejím Java Serveru a servletech hledejte zde. Dokumentaci k servletům (tzv. white paper) lze najít zde.
Články zabývající se problematikou servletů lze najít např. zde, zde a zde. V tomto třetím článku je také uveden seznam odkazů na již existující WWW servery, které mají zabudovanou podporu servletů.