Java Servlets – interakcia a zdieľanie objektov a zdrojov 1.

Vo väčšine príkladov, ktoré nájdete na webe, sa používajú samostatné servlety, respektíve JSP. Aj v našom seriály o servletoch sme často využívali stand-alone servlety. V skutočnom svete však servlety nemôžu byť iba samostatné programy, mali by vytvárať prepojené skupiny, ktoré sú iba časťou webovskej aplikácie. Komponenty takejto aplikácie potom môžu tvoriť skupiny servletov, zdieľané objekty, HTML, JSP stránky a podobne.

Z toho samozrejme vyplýva, že prvky aplikácie (konkrétne servlety) potrebujú nejaký systém a prostriedky na vzájomnú komunikáciu a interakciu buď navzájom medzi sebou alebo s ostatnými zdrojmi web aplikácie. Týmto prostriedkom je často ServletContext object.

V nasledujúcich riadkoch sa budeme zaoberať viacerými technikami vzájomnej komunikácie a interakcie medzi servletmi, respektíve medzi servletmi a inými zdrojmi. Budeme si hovoriť o týchto typoch techník:

1. Servlet collaboration – sú dve základné techniky vzájomnej spolupráce, a to servlet filtering a servlet chaining. V tomto prípade viacero servletov spolupracuje na vytváraní vlastnej odpovede klientovi. V skutočnosti však servlety nespolupracujú priamo, ale za ich prepojenie je zodpovedný servlet kontajner. O jednej z techník sme už hovorili v článku Java Servlets – servlet filtering.
2. Response redirection – alebo presmerovanie odpovede na iný aplikačný zdroj, čo môže byť tiež servlet, HTML alebo JSP stránka.
3. Request dispatching – prostredníctvom tejto techniky môžeme predať požiadavku na ďalší servlet, ktorý sa postará o vytvorenie odpovede. A zároveň môžeme priamo získať odpoveď iného servletu a zahrnúť ju do našej.
4. Využitie externých zdrojov – s ktorými môžeme pracovať cez už spomínaný objekt ServletContext a pristupovať k nim cez metódu getResource().
5. Zdieľanie objektov – resp. atribútov, ktoré môže byť na troch úrovniach. Na úrovni aplikácie sú dostupné cez ServletContext. Ďalšia úroveň predstavuje aktuálne sedenie (session) prístupné cez HttpSession objekt a nakoniec sú to objekty spojené s aktuálnou požiadavkou dostupné cez HttpServletRequest.

Servlet collaboration – filtering a chaining

Ako som už spomenul o niečo vyššie, o technike filtrovania request a response objektov sme už hovorili, preto sa tomu už nemusím podrobnejšie venovať. V článku išlo o využitie špeciálnej komponenty odvodenenej z triedy javax.servlet.Filter, ktorá bola asociovaná s jedným alebo s viacerými servletmi. Na niektorých aplikačných serveroch, napríklad na IBM WebSphere Application Server, je možné vytvoriť trochu iný spôsob filtrovania ako už poznáme. Konkrétne môžeme využiť tzv. MIME filtrovanie. Ako vyplýva z názvu, ide o filtrovanie, ktoré sa týka používania MIME typov. Pre lepšiu predstavu si dobre prezrite tento obrázok:

Servlet MIME filtering

V tomto type filtrovania prvý servlet v poradí spracuje požiadavku a vytvorí odpoveď v užívateľsky definovanom MIME type. Tento typ je asociovaný s druhým servletom v poradí. V tom prípade je výstup prvého použitý ako vstup druhého. Takto je možné priradiť rôzne MIME typy na spracovanie rôznym servletom. V prípade, že definovaný typ nie je podporovaný browserom, môže sa odpoveď presmerovať na servlet, ktorý vráti odpoveď v text/html tvare. Tento spôsob filtrovania sa môže využiť napríklad pri konverzii z XML do HTML, i keď na tento účel dnes existujú oveľa sofistikovanejšie nástroje.

Bolo by dobré ukázať, ako sa druhý servlet v poradí vlastne dostane k výstupu prvého servletu. Celkom jednoducho cez objekt request. Uvediem ukážku (Servlet1.java):

response.setContentType(„text/xml“);
PrintWriter out = response.getWriter();
out.println(„<name>First_Servlet</name>“);

Pre tento MIME typ je na servery zaregistrovaný konkrétny servlet, ktorému je predané ďalšie riadenie (Servlet2.java):

response.setContentType(„text/html“);
PrintWriter out = response.getWriter();
BufferedReader in = request.getReader();
String line;
while((line = in.readLine()) != null)
  out.println(line);
out.println(„Second_Servlet“);

Toto je len nahrubo načrtnutý spôsob, ako získate výstup z prvého servletu. Čo s ním konkrétne vykonáte, už záleží na vás.

Servlet chaining (reťazenie)

V systéme reťazenia je pre jeden HTTP request zavolaných postupne viacero servletov, pričom každý z nich vytvorí svoju časť odpovede nezávisle od ostatných, ale v definovanom poradí. Server WebSphere poskytuje vlastnú triedu com.ibm.websphere.servlet.filter.ChainerServlet, čo je vlastne špeciálny servlet, ktorý si môžete zaregistrovať pod vlastným aliasom. Originálny request je smerovaný na tento servlet a ten sa potom postará o postupné volanie jednotlivých servletov (Servlet1, Servlet 2…). Výsledná odpoveď, zložená z jednotlivých čiastkových odpovedí, je poslaná klientovi.

Servlet filtering a chaining umožňuje webdeveloperom vytvárať modulárne systémy. Jednou z možností využitia v súvislosti s XML je, že jeden servlet môže vytvoriť alebo získať požadované XML dáta a druhý može na tieto dáta aplikovať konkrétne XSL a výsledok poslať klientovi. Znova však opakujem, že opísaný spôsob je vlastnosťou WebSphere Servera, čo na druhej strane vôbec nevylučuje, aby ste boli s touto možnosťou oboznámení.

Response redirection – presmerovanie odpovede

Ako som spomenul vyššie, odpoveď môžeme presmerovať na iný aplikačný zdroj, čo môže byť servlet, HTML alebo JSP stránka. Tento zdroj, respektíve jeho URL, musí byť pre servlet dostupný. Existujú dve formy presmerovania:

1. Štandardné presmerovanie – s využitím response.sendRedirect("login.jsp") spôsobí, že servlet „vráti“ ako odpoveď JSP stránku. Ak by to bol iný servlet, tento by nemal prístup k originálnemu request objektu, ale ako odpoveď klientovi by bola vrátená odpoveď druhého servletu. Ak potrebujete mať prístup k pôvodnému requestu, musíte použiť techniku servlet dispatchingu, o ktorej budeme hovoriť v budúcej časti.
2. Presmerovanie na error stránku – v tomto prípade je klientovi poslaný konkrétny status kód ako parameter metódy response.sendError(response.CODE). Konkrétne kódy sú preddefinované konštanty objektu response. Nižšie uvádzam prehľad niektorých známych chybových kódov.

Všetky stavové HTTP kódy môžeme rozdeliť do piatich skupín podľa nasledujúcej tabuľky:

V tomto viacmenej teoretickom článku budeme pokračovať aj nabudúce, kedy sa pozrieme na ďalšie možnosti spolupráce medzi servletmi a inými zdrojmi web aplikácie.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.