|  | ||||||||
|  | ||||||||
| | ||||||||
| | ||||||||
 | kategória |  | ||||||||
|
| ||||||||||
 |  |
| | |
|
| ||
| |
|
||||||||||
Servlet (Servlet-CGI összehasonlítás: elönyei abból, hogy folyamatosan a memóriában van; életciklus, request, response, paraméterek kezelése; session, hogyan azonosítja a felhasználót)
A nagy ötlet az, hogy bizonyos webcímek mögött nem egy elöre elkészített ("statikus") tartalom, hanem egy program rejtözik, ami a böngészö kérése alapján meghívódik és röptében generál egy változó ("dinamikus") válaszdokumentumot.
A CGI-program egyszerüen a szokásos bementi csatornáján ("standard input") vagy egy környezeti változón keresztül ka 929b13j pja meg a felhasználó kérését és válaszát a kimeneti csatornájára ("standard output") írja. A specifikáció tartalmaz egy adag környezeti változót is, amit a webszerver a program meghívása elött beállít a program számára és amelyekböl a program mindenféle okosságokat olvashat ki a kérésre vonatkozóan. Az elkészült programokat egyszerüen be kell másolni a webszerver egy megfelelöen konfigurált könyvtárába és már készen is van a webalkalmazás. Minden egyéb, hálózatkezeléssel kapcsolatos problematika már a webszerver vállát nyomja.
A HTTP protokoll szabványa definiálja, hogyan tárgyal a böngészö és a webszerver egymással. Két alapvetö módszer van, amellyel a kliens a szervernek adatot küldhet, ezeket a megfelelö HTTP parancs nevéröl GET és POST metódusnak nevezik. Lényegileg mind a kettö azonos, a különbség ott van, hol utaznak a webszervernek küldött adatok. A GET metódusnál magához a webcímhez füzik egy kérdöjel után, a POST metódusnál a HTTP kérés törzsébe ágyazzák. A CGI-program a kimenetére kell írja elöször a HTTP fejléc általa beállított részeit, majd egy üres sor után magukat az adatokat.
A CGI-nek egyszerüsége mellett problémái is akadnak, mindenekelött zabálja a gépkapacitást, úgy a memóriát, mint a gépidöt. Minden CGI-kérésre egy teljesértékü processz lódul meg, betöltödik, memóriát foglal, csak azért, hogy kiírjon néhány karaktert, majd hasonlóan nagy felhajtással távozik. Ha a program scriptben íródott, akkor minden egyes kérésnél a script értelmezöprogramja is betöltödik, fejlettebb rendszernél (pl. Perl) csak egyszer, de shell scriptnél minden kérésre betöltödik, majd távozik egy shell processz.
A szervlet egy speciális Java program, amely a webszerverrel együttmüködve a szerveroldalon lehetövé teszi HTML oldalak dinamikus létrehozását és paraméterezését. A szükséges osztályok és interfészek a javax.servlet csomagban találhatóak. Azok a szervletek, amelyek a HTTP protokollt használják, a javax.servlet.http.httpServlet leszármazottjai.
A szervlet elönyei a CGI programmal szemben:
platformfüggetlen, hiszen Javában íródik
a webszerveren belül állandóan futó virtuális gép sokkal gyorsabb kiszolgálást eredményez, mintha minden kérés kiszolgálásához külsö programindítás történne
a virtuális gép miatt leegyszerüsödik a kéréskiszolgálások szinkronizációja
a szervlet átirányíthatja a kérést egy másik szervlethet, ezáltal dinamikusan lehet alkalmazkodni a webszerver terheltségéhez
egy szervlet könnyen megörzi az információkat az azonos helyröl jövö egymás utáni kérések kiszolgálása között
A szervlet csak egyszer töltödik be, majd mindaddig a tárban marad, amíg ki nem töltik onnan, általában az adminisztációs programmal. A szervlet betöltödésének idöpontját a Java Webszerverben be lehet állítani, meg lehet mondani, hogy egy szervlet már a szerver betöltödésekor kerüljön a tárba vagy csak akkor, amikor elöször hivatkoznak rá.
Meg lehet csinálni, hogy a szervlet emlékezzen az elözö hívásokra.
A HTTP tranzakcióelvü, a kérés után jön a válasz, majd a kapcsolat lezárul. A kapcsolat felépítése és lezárása azonban mindenhol, a TCP/IP-ben is idöbe telik, így ha folyton lezárjuk a kapcsolatot a kliens és szerver között, sokba kerülhet nekünk. Alapvetöen erre nincs szükség a böngészök és szerverek "keepalive" szolgáltatása miatt. Mind a szerver, mind a böngészö megpróbálja életben tartani a kapcsolatot, hogy esetleg egy újabb HTTP tranzakciót indíthasson rajta. Mindkét oldalnak jogában áll lebontani, de ha a "keepalive" engedélyezve van, törekedni fognak, hogy ezt ne kelljen megtenniük.
A trükk azon alapszik, hogy a szerverek a HTTP fejlécben megmondják, mennyi adatot küldenek, így a böngészö tudja, mikor ért véget a válasz, még ha a szerver nem is bontja le a kapcsolatot. A probléma csak akkor van, ha a szerver nem küldi el az üzenet hosszát, mert ekkor tényleg csak abból tudni a tranzakció végét, hogy a szerver lebontotta a kapcsolatot.
Amikor a szervlet betöltödik a tárba, inicializálódik inicializációs paraméterek alapján és ezeknek a feldolgozása lehet az init metódusban (példányosítás).
Betöltödött szervlet hívásokat kaphat, ekkor a service nevü metódusa hívódik meg. Majdnem minden lényeges dolog a service metódusban történik. Ez két paramétert kap, egyik paraméterobjektuma a kérést, másik a rá adandó választ jelképezi. Amit CGI-ben a környezeti változók kiolvasásával tudtunk meg, itt a HttpServletRequest objektum mezöi és metódusai mondják el. Amit régen a kimenetre írtunk, azt most a HttpServletResponse objektum kezeli. Itt most a következö történik: beállítjuk a válasz típusát text/html-re, majd megnyitjuk a kimeneti csatornát és beleírjuk a generált HTML dokumentumot.
A ServletRequest intefész a klienskérés paramétereinek és jellemzöinek, a kliens gép címének, a kérést kiszolgáló szerver gép címének, valamint a kérés tartalmának olvasásást lehetövé tevö metódusokat definiál.
A ServletResponse interfész a szervlet válaszának jellemzöit beállító, valamint a válasz kiírását lehetövé tevö metódusokat definiál.
A HttpServlet implementálja a service metódust, és a HTTP klienskéréseket azok HTTP típusától függöen a következö metódusokhoz továbbítja:
doGet (HttpServletRequest, HttpServletResponse)
doPost (HttpServletRequest, HttpServletResponse)
Kérés átirányítása:
a HttpServletResponse sendRedirect metódusával. Ilyenkor egy abszolút URL-t kell megadni
Hiba jelzése:
a HttpServletResponse sendError metódusával
Végül pályafutásának befejezése elött destroy nevü metódusát hívják meg, ez akkor lehet fontos, ha valamilyen rendszereröforrást kaparintott meg, amit vissza kell adjon.
A klienshez tartozó adatokat a kliens tárolja, és azokat minden kéréskor elküldi a szervletnek. Erre való a süti. A süti szöveges információ, amelyet a kliens böngészöprogram tárol el. A süti a kliensoldalon tárolódik és egy adott webszerverhez tartozik, így ha egy webszerveren több szervlet is fut, akkor mindegyik olvashatja a másikak által létrehozott sütiket. A sütik tartalmára a süti nevével lehet hivatkozni. A sütik csak HTTP protokoll esetén használhatók, ezért minden sütivel kapcsolatos típus és metódus javax.servlet.http csomagban található. A klienstöl kapott sütiket a HttpServletRequest getCookies metódusával lehet lekérdezni, amely azokat egy tömbben adja vissza. Ha új sütit szeretnénk a kliensnél eltároltatni, akkor a sütit a süti létrehozása és a paraméterek megadása után a HttpServletResponse addCookie metódusával kell a kliensnek elküldeni. Már létezö sütit újra el kell küldeni a kliensnek, ha annak valamelyik jellemzöje megváltozott.
A süti azt jelenti, hogy a szerver speciális HTTP-fejléceket küld, aminek hatására a kliens ezen fejlécek tartalmát elmenti egy kis adatbázisba. Egy süti megmondja, meddig él, ki ô és kire vonatkozik, valamint névvel azonosított változóértéket is visz. Valahányszor a böngészöt arra a webcím-csoportra irányítják, amire a süti vonatkozik, a böngészö HTTP-fejlécekben elküldi a süti utolsó ismert értékét.
A böngészökben ki lehet kapcsolni a sütik fogadását vagy figyelmeztetést kérni, ha ilyet kapunk. Nem lehet tehát arra számítani, hogy sütijeinket mindig letárolják, ezért egy sütit használó programnál mindig fel kell készülni arra, hogy a süti nem jön vissza.
Elöfordulhat, hogy a sütiken alapuló információtárolás nem müködik (pl. a kliens nem foglalkozik a sütik tárolására vonatkozó kéréssel). Egy másik módszer a session-ök használata. Ebben az esetben a szerver tárolja az információt. Minden klienskapcsolat, amely a ugyanazt a környezetet használja, ugyanazokat az adatokat is fogja látni. A környezetet a szerver tartja nyilván, az azonosítóját (session id) eljuttatja a klienshez, majd a kliens a kapott azonosítóra hivatkozva lehetövé teszi, hogy a szerver adatokat rendeljen a klienshez, ez a kapcsolat alatt mindig elérhetö lesz (a szerver a session id alapján azonosítja a klienst minden kéréskor). Egy klienskapcsolat-környezetet a HttpSession osztály reprezentál, melynek jellemzöi:
azonosító: a klienskapcsolat-környezet szöveges azonosítója, lekérdezni a getId metódussal lehet, beállítása pedig annak létrehozásakor, automatikusan történik
létrehozás idöpontja
legutolsó hozzáférés idöpontja
élettartam.
A kapcsolatkörnyezet automatikusan megszünik, ha annak érvényességi idötartama alatt nem történik hivatkozás rá.
6. JSP (születésének okai, hogyan fut le egy JSP lap, lap részei, JSP és Bean-ek kapcsolata; JSP hátrányai)
A JSP a szervlethez hasonlóan egy klienstöl érkezö kérés alapján valamilyen szöveges, leggyakrabban HTML vagy XML formátumú dokumentum dinamikus, szerveroldali elöállítására szolgáló technológia. Míg a szervletek esetében a Java kódban elrejtve szerepelnek a szöveget a kimenetre kiíró utasítások, addig a JSP-nél a rögzített szöveg közé rejtve szerepelnek az oldal tartalmát módosító utasítások.
Születésének oka az volt, hogy fejlesztöi szerették volna a servletek programozásának nehézségeit elrejteni a programozásban kevésbé jártas emberek elöl azzal, hogy szétválasztják az oldal programozási részét a tartalomtól és a designtól. A JSP lehetövé teszi a munkamegosztást, azaz hogy egyszerre több fejlesztö foglalkozzon ugyanannak az oldalnak más-más részével.
Egy JSP oldalra vonatkozó kérés esetén a következö történik:
a kliens elküldi a kérést a szervernek
a web- vagy alkalmazásszerver felismeri, hogy egy JSP fájlra vonatkozik a kérés, így továbbítja azt a JSP containernek, ami általában a webkiszolgáló része
a JSP fordító a .jsp fájlból sorról-sorra haladva elöállítja a neki megfelelö java szervlet forrását
a java kódot a javac fordítóval lefordítja egy .class fájlba
inicializálja a szervletet, majd a szervlet a kérést megkapva elöállítja az oldal végleges szövegét
a válasz végül eljut a klienshez
A fordító a JSP egyszerübb, szövegvezérelt formátumából szervlet kódot készít, és valójában ez szolgálja ki a kérést. Fordítani csak az elsö kérés kiszolgálásakor szükséges. A JSP oldal szövegében található Java kód változatlanul bekerül a belöle készített szervlet forrásába, így a JSP megörzi a szervletek elönyét: tetszöleges Java API vagy saját Java osztály meghívható. Egy JSP oldal könnyen kommunikál egy szervlettel, és ez fordítva is igaz.
A következök lehetnek:
direktívák
script-elemek
akcióelemek
Minden olyan literál, amit a fordító nem ismer fel, egy az egyben bekerül az elöállított oldal szövegébe.
a JSP containernek szóló utasítások, nem módosítják az elöállított oldal szövegét
a page direktíva
az egész oldalra vonatkozó jellemzöket állíthatjuk be
a fordítási egységben bárhol elöfordulhat, de az import kivételével minden attribútumnak csak egyszer adhatunk értéket
fordítási egység: ad adott oldal és az include direktívával beillesztett oldalak összessége
az attribútumok a következök:
4 language: a script-részletekben, kifejezésekben és a deklarációkban használt programozási nyelv
4 extends: megadja, hogy a JSP oldalból készült osztály melyik osztálynak legyen a leszármazottja
4 import: az oldalból készülpöö szervlet import listáját egészíthetjük ki
4 session: true vagy false értéke adja meg, hogy az oldalban akarunk-e session-t használni
4 puffer: meghatározza az out változó pufferelésének módját
4 info: megadhatjuk az oldal rövid leírását
4 errorPage: annak a JSP oldalnak a címe, ahová az oldalban fellépö kivételt továbbítani szeretnénk
4 contentType: megadja az oldal típusát és karakterkódolását
az include direktíva
adott fájl fordítás elötti beillesztésére szolgál
a beillesztés statikus
attribútuma: file, melynek értéke egy fájlra mutató relatív URL
a taglib direktíva
a fordító által felismert kifejezések kiegészíthetök saját tagekkel, melyek könyvtárakba rendezhetöek
a direktíva segítségével adhatjuk meg, hogy a fordító hol keresse a saját elemeinket definiáló tag library descriptor-t
attribútumai:
4 uri: megadja az elemkönyvtárat azonosító szimbolikus vagy tényleges URL-t
4 prefix: azt a prefixet adja meg, amelyet egy kettösponttal elválasztva a saját elemeink neve elé kell majd tenni ahhoz, hogy hivatkozni tudjunk rájuk
fajtái:
deklaráció
script-részlet (scriptlet)
kifejezés
scriptletek
kifejezések
olyan script-nyelvü elemek, amelyeket a fordító String típusra hozhat, és közvetlenül a kimenetre írhat
a típuskonverzió sikertelensége esetén a fordításkor hibaüzenetet kapunk
lehetöség van saját akciókat definiáló custom tag library-k írására, ezáltal egyszerübben lehet kezelni a saját kódrészleteket
a saját akciók mögött egy-egy Java osztály áll, amely felhasználhatja, és általában fel is használhatja az attribútumok értékeit, valamint az implicit objektumok (például a kérés) paramétereit, és ezek alapján valamilyen szerveroldali feladatot végez el, például ír a kimenetre
fontos szerepet játszik a kód-újrafelhasználásban is, mivel akár egy oldalon belül is többször felhasználható
a <jsp:useBean> akció
többféle funkciót egyesít
lényege, hogy megpróbálja megkeresni a megadott névtérben (scope) megadott néven (id) szereplö objektumot, és az oldal script.nyelve számára szintén id néven elérhetövé tenni, type típusúra kényszerítve
használható objektumok, így JavaBeanek példányosítására is, ugyanis ha a keresés nem jár sikerrel, akkor a class vagy a beanName attribútumok alapján megkísérli példányosítani az adott osztályt, elhelyezi a kapott objektumot a scope névtérben és az id értékeként megadott néven a scriptnyelv számára is elérhetövé teszi az új objektumot
kötelezö értéket adni az id attribútumnak, valamint type és class attribútumok közül legalább az egyiknek
összefoglalva
4 az id és a scope alapján megpróbálja megkeresni az objektumot az adott névtérben
4 az oldal scriptnyelvében deklarál egy változót id néven és type tíoussal, ha type nincs definiálva, akkor a típus class lesz
4 ha megtalálta az objektumot, akkor típuskényszerítéssel type típusúra hozza és értékül adja a létrehozott változónak
4 ha az objektumot nem találta meg, és se a class, se a useBean attribútum nem volt megadva, akkor a feldolgozás véget ér
4 ha az objektumot nem találta meg, és a class értékeként megadott osztály rendelkezik nyilvános konstruktorral, akkor példányosítja
4 ha az objektumot nem találta meg, és a beanName adott, akkor létrehoz egy új objektumot, és ezt értékül adja a script-változónak, és elhelyezi a scope által meghatározott névtérben
4 ha a jsp:useBean törzse nem üres, akkor feldolgozza. A törzsben lévö script-elemek számára az új változó már elérhetö
7. Taglib (milyen igények vezettek a létrejöttéhez; hogyan kapcsolódik egy JSP-laphoz; mit ír le a TLD, hogyan épül fel egy tag, hogyan befolyásolják a lapgenerálást a függvények visszatérési értékei)
Miért taglib?
A JSP a szervlethez hasonlóan egy klienstöl érkezö kérés alapján valamilyen szöveges, leggyakrabban HTML vagy XML formátumú dinamikus, szerveroldali elöállítására szolgáló technológia. Hátránya, hogy a JSP nem különül el a HTML kódtól, ezért átláthatatlan.
A JSP lehetöséget biztosít saját elemkönyvtárak (custom tag library) készítésére, ezáltal a kódok átláthatóbbá váltak, és lehetöség nyílt a kód megosztására és újrafelhasználására. További elöny, hogy az elemkönyvtárak hordozhatóak, azaz az oldal programozási nyelvétöl és a készítötöl függetlenül bármikor felhasználhatóak.
A JSP által felismert akcióelem-készlet tehát kibövíthetö saját tagekkel, melyek könyvtárakba rendezhetöek (custom tag library). A taglib direktíva segítségével adhatjuk meg a fordító számára, hogy hol keresse a saját elemeinket definiáló tag library descriptor-t. A direktívának az elsö saját elem elöfordulása elött szerepelnie kell.
Két attribútuma van:
uri: az elemkönyvtárat azonosító szimbolikus vagy tényleges URI
prefix: kettösponttal elválasztva a saját elemeink neve elé kell tenni, csak így tudunk rájuk hivatkozni. A prefixek célja a névterek szétválasztása, amire azért van szükség, mert egy oldalba taglib direktívákkal tetszöleges számú elemkönyvtárat "importálhatunk".
A taglib kapcsolódása egy JSP laphoz
A TLD egy egyszerü szerkezetü XML dokumentum, amely a JSP containernek és a könyvtárat felhasználóknak szolgál információkkal a könyvtárról és a benne szereplö elemekröl.
A TLD fájl felépítése:
<?xml version='1.0' encoding='iso-8859-2' ?>
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<taglib>
<tlibversion>1.0</tlibversion>
<jspversion>1.1</jspversion>
<shortname>mal</shortname>
<tag>
<name>greetings</name>
<tagclass>malary.greetings</tagclass>
<attribute>
<name>type</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue>
</attribute>
<attribute>
<name>time</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
</tag>
<tag>
<name>ciklus</name>
<tagclass>malary.ciklus</tagclass>
<attribute>
<name>count</name>
<required>true</required>
</attribute>
</tag>
<tag>
<name>feltetel</name>
<tagclass>malary.feltetel</tagclass>
<attribute>
<name>logikai</name>
<required>true</required>
</attribute>
</tag>
</taglib>
Saját elem készítése során elöször a TLD-t kell elkészíteni, majd meg kell írni az elemnek szánt feladatokat elvégzö elemkezelöt. Az elemkezelö egy olyan tulajdonságokkal rendelkezö JavaBean, amely megvalósítja a javax.servlet.jsp.tagext csomag Tag, vagy BodyTag interfészét. Az interfészek azokat a metódusokat tartalmazzák, amiken keresztül a JSP oldalból készült szervlet az elemkezelö osztállyal kommunikál.
A Tag intefész három metódussal rendelkezik:
doStartTag: a JSP oldalból készített szervletben ez hívódik meg a nyitóelem helyén. Az eljárás visszatérési értéke SKIP_BODY vagy EVAL_BODY_INCLUDE lehet. Az elöbbi esetben (ez az alapértelmezett) a törzs nem kerül feldolgozásra, az utóbbi esetben viszont igen.
doEndTag: a záróelem helyén hívódik meg, Két lehetséges értéke az EVAL_PAGE és a SKIP_PAGE. Az elöbbi esetben (ez az alapértelmezett) folytatódik az oldal végrehajtása, utóbbi esetben pedig befejezödik.
release: a szervlet már végzett az elemkezelö objektummal.
A BodyTag interfész legfontosabb metódusai:
doInitBody: egyszer, a törzs elsö kiértékelése elött hívódik meg.
doAfterBody: a törzs minden végrehajtása után meghívódik. Ha nem volt törzs megadva, vagy a doStartTag metódus SKIP_BODY értéket ad vissza, akkor egyik sem hívódik meg. Lehetöség van a törzs többszöri kiértékelésére: amennyiben a doAfterBody EVAL_BODY_TAG értékkel tér vissza, akkor a törzs kódja újra végrehajtódik, ha pedig SKIP_BODY-t ad vissza, akkor a törzs feldolgozása véget ér.
8. XML (eredete, létrejöttének okai, részei, alkotóelemei, szintaktika, mire használható a DTD)
9. SAX és DOM (különbségek, elönyök, hátrányok, DOM objektumok)
Lásd az XML - Gondolatok a hordozható adatokról (2001, 17 oldal) címü doksit.
Találat: 362
