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"), Dalsím přínosem je i takové řesení bezpeč 20220c25u nosti, které umozňuje uzivatelům posílat své servlety na WWW server a zde je spoustět.

Dnesní Web jiz dávno není statickou zálezitostí - 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 uzivatelům, kteří si je vyzádají. V mnoha situacích by to ani nebylo principiálně mozné, například u nejrůznějsích vyhledávacích sluzeb, sluzeb spočívajících v přístupu do databází apod. Zde není mozné dopředu připravit odpovědi na vsechny mozné dotazy - místo toho je zde nutné WWW stránky vytvářet dynamicky az v době, kdy jsou skutečně zapotřebí, podle konkrétních momentálních pozadavků. Moznost dynamického sestavování WWW stránek se ale s oblibou vyuzí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 uzivatelova WWW prohlízeče, a v nasich zeměpisných sířkách také pro správné překódování české diakritiky.

Konkrétní způsob, jakým se moznost dynamického generování (či alespoň přizpůsobování) řesí, se samozřejmě vyvíjel a nadále vyvíjí. Je přitom vcelku zřejmé, ze dynamické generování WWW stránek je předevsím zálezitostí WWW serverů (i kdyz 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 nejstarsím mechanismem, pouzí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 řesení, umozňující aby si WWW server zavolal na pomoc externí program, který za něj vyřesí vse potřebné. Jde přitom o bězné, samostatně spustitelné programy (v prostředí DOSU-u a Windows je mozné si je představit jako programy volané z tzv. příkazové řádky), spoustěné vzdy znovu a znovu pro splnění kazdého jednotlivého pozadavku. Skutečnost, ze jde o "plnohodnotné" programy, schopné samostatné existence, znamená ze s jejich spoustěním i ukončováním je spojena dosti velká rezie. Navíc jsou tyto programy závislé na konkrétní platformě, a nelze je tedy přenáset na jiné platformy.

Dalsím řesením se stalo mnohem těsnějsí svázání WWW serveru a programů, které za něj budou vyřizovat potřebné pozadavky. Pokud takovéto programy budou psány "přesně na míru" příslusným serverům a způsobu, jakým své pozadavky vznásejí a jakým chtějí přejímat zpět výsledky, můze vse 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říslusný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í, protoze 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 řesení je pak koncepce tzv. servletů, jak se říká "prográmkům", slouzícím výse 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 vsak jedná o malé programy určené k běhu na WWW serveru (díky tomu tyto servlety nemusí mít zádné uzivatelské rozhraní). Jejich velkou předností je nezávislost na konkrétní platformě, coz 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 vsak 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říslusný server podporovat. Příslusné "servletové API" dnes podporuje například Java Server firmy Sun (WWW server, napsaný celý v Javě), a také celá řada dalsích serverů, které jiz byly vyvinuty s vědomím existence servletového API (viz dalsí informace). Pro jiné WWW servery, které se servlety původně nepočítaly, existuje alespoň moznost 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ů vsak není jen novou, efektivnějsí a snáze přenositelnou implementací jiz delsí dobu existujícího mechanismu. Přinásí i novou kvalitu, kterou je zejména moznost, 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ězně vykonáván). Stávající WWW servery něco takového apriorně odmítají, protoze nemají moznost 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, ze programům sitým na míru rozhraní CGI či rozhraním typu ISAPI a NSAPI (a psaným typicky v jazyku C) lze jen velmi tězko 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 mozné 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ůlezité přitom je, ze o rozdělení konkrétních servletů mezi důvěryhodné a nedůvěryhodné bude rozhodovat az správce konkrétního serveru - ten se můze rozhodnout například takovým způsobem, ze za důvěryhodné bude povazovat pouze "místní" servlety (umístěné přímo na daném serveru v definovaném adresáři, a které si tudíz mohl sám zkontrolovat), a případně i takové, které sice přichází ze sítě, ale jsou zabaleny do zvlástního archivního formátu a jsou opatřeny digitálním podpisem svého autora (zatímco vsechny ostatní servlety budou automaticky povazovány za nedůvěryhodné, a budou jim povoleny jen takové činnosti, které nepředstavují zádná bezpečnostní rizika).

Moznosti vyuzití servletů jsou velmi siroké - kromě "obvyklého" dynamického upravování či přímo generování WWW stránek mohou například plnit roli nejrůznějsí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 nasich zeměpisných sířkám nejspíse budou pouzity i pro dynamické překódovávání čestiny. V zásadě vsechny takovéto moznosti vsak jiz nabízela i dosavadní řesení na bázi CGI rozhraní a rozhraní typu ISAPI a NSAPI, zde je vsak 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 vypustě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.