Java Servlets - interakcia a zdie╛anie objektov a zdrojov
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:
- 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.
- Response redirection - alebo presmerovanie odpovede na in² aplikaΦn² zdroj, Φo m⌠₧e by¥ tie₧ servlet, HTML alebo JSP strßnka.
- 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.
- 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().
- 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):
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):
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:
- è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.
- 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.
| konÜtanta | popis |
|---|---|
| SC_CONTINUE | 100 - indikuje, ₧e servlet obdr₧al ·vodn· Φas¥ po₧iadavky a klient m⌠₧e pokraΦova¥ a posla¥ aj zvyÜn· Φas¥. |
| SC_MOVED_ PERMANENTLY | 301 - indikuje, ₧e po₧adovan² zdroj bol permanentne pres¥ahovan² na inΘ miesto a vÜetky ostatnΘ po₧iadavky by mali by¥ smerovanΘ na novΘ URL. |
| SC_BAD_REQUEST | 400 - indikuje, ₧e po₧iadavka poslanß klientom bola syntakticky nesprßvna. |
| SC_UNAUTHORIZED | 401 - indikuje, ₧e poslanß po₧iadavka vy₧aduje HTTP autentifikßciu. |
| SC_FORBIDDEN | 403 - indikuje, ₧e servlet pochopil po₧iadavku, ale odmietol ju vykona¥ (naprφklad z d⌠vodu nedostatoΦn²ch prßv). |
| SC_NOT_FOUND | 404 - indikuje, ₧e po₧adovan² zdroj je nedostupn². |
| SC_HTTP_VERSION_ NOT_SUPPORTED | 505 - indikuje, ₧e servlet nepodporuje alebo odmietol verziu HTTP protokolu, ktorß bola pou₧itß v danej po₧iadavke. |
VÜetky stavovΘ HTTP k≤dy m⌠₧eme rozdeli¥ do piatich skupφn pod╛a nasleduj·cej tabu╛ky:
| rozsah k≤dov | kateg≤rie |
|---|---|
| 100-199 | InformaΦnß kateg≤ria. |
| 200-299 | Po₧iadavka od klienta bola ·speÜne spracovanß. |
| 300-399 | Po₧iadavka bola presmerovanß. |
| 400-499 | Po₧iadavka od klienta je nekompletnß. |
| 500-599 | Server error. |
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.
P°edchozφ Φlßnky
- Java Servlets - i18n
- Java Servlets - JDBC, JNDI a dßtovΘ zdroje II
- Java Servlets - JDBC, JNDI a dßtovΘ zdroje I
- Java Servlets - servlet filtering
- Java Servlets - session tracking II
- Java Servlets - session tracking
- Java Servlets - state tracking
- Java Servlets - perzistencia a serializßcia objektov
- Java Servlets - spracovanie formulßra II
- Java Servlets - spracovanie formulßra
- Java Servlets - web.xml - pokraΦovanie
- Java Servlets - web.xml
- Java Servlets - vytvorenie jednoduchΘho servletu
- Java Servlets - ₧ivotn² cyklus servletu
- Java Servlets - predstavenie technol≤gie
