Programozás | Java, JSP » Nyiri Imre - A Java Server Pages bemutatása és környezetének kialakítása Linux rendszeren

A Java Server Pages (JSP) bemutatása és környezetének kialakítása WEB szerver oldali fejlesztői és futtató környezet kialakítása Linux operációs rendszeren 2001. április Javított változat Készítette: Nyiri Imre nyimre@freemail.hu (0) Bevezetés A ma készülő alkalmazások jelentős része az „n” rétegű modell elve alapján készül. Ez a paradigma annyira előretört, hogy mostanában még a régi alkalmazások is e modell kapcsán kapják meg az ’1’ rétegű, illetve a „vastag kliens” jelzőt. Persze ebben a felfogásban nincs semmi új, hiszen a nagyobb programokat mindig is úgy tervezték, hogy azok vertikális és horizontális szoftver rétegekből álljanak. Itt a „réteg” szó arra is utal, hogy az egymással kommunikálni tudó szoftver komponensek hány különálló futtató környezetre bonthatóak. Amennyiben alaposan megvizsgáljuk a Unix, Windows rendszereket, akkor belátható, hogy ez a koncepció már nagyon régi (lásd a

*.so és *.dll file-okat, mint szervereket). Egy 3 rétegű alkalmazás tipikus kialakítása a következő: ADATBÁZISKEZELŐ (AB) – ÜZLETI LOGIKA (ÜL) – USER INTERFACE (UI) rétegek. Itt az ÜL/AB és a UI/ÜL rétegek egymáshoz való viszonya akár egy-egy kliens szerver modell alapján is elképzelhető. Az ÜL réteg nagyjából standard részét megvalósító alapszoftvert alkalmazás szervernek nevezzük, aminek talán a legfontosabb része egy WEB (HTTP) szerver. A WEB szerver köré építhetjük ki azt a funkcionalitást, amit az alkalmazásunk igényel. Miért is alkalmas erre a HTTP protokoll? A válasz úgy gondolom a programozáselmélet típus fogalmában keresendő. TCP szállítási réteg, illetve annak socket vagy TLI (transport layer interface) API-ja csak egy típusnélküli byte-folyamot bocsát rendelkezésünkre, ami még nagyon alacsonyszintű eszköz azoknak, akik például egy internetes áruházat akarnak kialakítani. Ezzel szemben a HTTP és a

hozzákapcsolódó társ protokollok és fogalmak (pl.-ul: MIME) egy típusos eszközt bocsátanak rendelkezésünkre, azaz a rétegek között teljes objektumok is közlekedhetnek (lásd. CORBA) Ez jelenti az igazi erőt A HTTP azonban önmagában nem jelent teljes megoldást, ezért más eszközökkel együtt (CORBA, RMI, ) érdemes azt használni és így el is jutottunk az alkalmazás szerver fogalmához. Az UI réteg egy html/xml/Java alapú (esetleg ActiveX) vékonykliens alkalmazás lehet. Az AB réteg pedig már mindenki számára ismert, hiszen az Oracle, DB/2, szoftverek jól érzékeltetik azt, hogy miket is kell e rétegben megvalósítani, illetve milyenek azok a hálózati protokollok (pl. Net *8), amelyek az AB szolgáltatások hálózaton keresztüli elérését teszik lehetővé. (1) A WEB-es alkalmazások fejlődéstörténete A Microsoft Visual InterDev dokumentációja (és szerintem is) szerint WEB-es alkalmazások fejlődését nyomon követve három nagy

korszakot vehetünk észre: 1. Az első generációs WEB szerverek korszaka Ezen megoldásokra a statikus HTML lapok és az azokba beágyazott grafikák (*.jpg, *.gif), hangok, később a mozgófilmek voltak a jellemzők. Ezt a világot egészítette ki a böngészőkbe plug-in-ként megjelenő VRML világ, valamint a böngésző oldali scriptek és a JAVA applet-ek lehetősége. Később az MS kidolgozta az applet-ek alternatívájaként funkcionáló ActiveX technológiát. 2. A második generációs WEB-es alkalmazásokra a dinamizmus megjelenése volt jellemző. A WEB-en szörfölő emberek egyre unalmasabbnak és haszontalanabbnak tartották azokat a WEB helyeket, amik csak egy könyv módjára, statikusan készültek. Ezen technológiák legfőbb képviselői a CGI programok, az SSI-k (Server Side Include). Érdekes kezdeményezés volt az is, hogy a WEB szervereket - hasonlóan más szerverekhez - egy API-val lássák el, aminek legfőbb hátránya az volt, hogy minden WEB

szerver más-más API-val rendelkezhetett. A CGI programok mára már nem tekinthetőek korszerű megoldásnak, aminek a főbb okai a következők: nehezen lehet benne a HTTP protokoll állapotmentes jellegéből fakadó korlátokat kiküszöbölni (pl.ul session kezelés), a CGI scriptek lassúak és sok erőforrást igényelnek, mert minden CGI kérésnél egy teljes értékű process indul el. 3. A harmadik generációs WEB szerver alkalmazások akkor születtek meg, amikor a fejlesztőeszközöket készítő cégek rájöttek arra, hogy az inter/intranetes helyeket is érdemes lenne hagyományos applikáció-készítő szemléletben kifejleszteni. A végcél persze itt is az, hogy dinamikus HTML, újabban XML lapokat generáljunk a böngésző kliens részére. Ennek a felfogásnak nyilvánvaló előnyei vannak: használhatjuk a már ismert programozási nyelveinket és a vizuális fejlesztőeszközöket. Ennek az irányzatnak talán az első megvalósítása a Microsoft Active

Server Pages-en (ASP) alapuló megoldása volt, amely alkalmazásokat a Visual InterDev nevű eszközével lehetett elkészíteni. Mi ennek a hátránya? Az MS-re oly jellemző megoldás: nagyszerű ötlet, de több részletében is nem szabványos megoldás: Visual Basic nyelv használata a szabványos C++ vagy JAVA nyelvek helyett, a technológia - véleményem szerint csak Windows-os környezetben működik rendesen, ami az OLE, ActiveX és Windows lehetőségeinek teljes kihasználásával lehet magyarázni. A hírek szerint az MS újabb stratégiája a „.net” koncepció, ami mindjárt egy új nyelv bevezetésével indul (neve: C#). Vajon miért? Ezek után felmerül a kérdés, hogy létezik-e olyan WEB-es fejlesztő és futtató környezet, ami tudja mindazt, amit az ASP, de platform és szállító független. A válasz az, hogy IGEN. A megoldás neve hasonlít az ASP nevére: JAVA Server Pages (JSP) Itt szeretnék megjegyezni 2 dolgot: 1. A jelenlegi legelterjedtebb WEB

szerver oldali technológia talán még most is a PERL script, aminek hátránya a CGI jellegű működésben rejlik. Egyébként a PERL valószínűleg egy nagyon jól kitalált script nyelv, de szerintem újabb WEB-es alkalmazásokat nem érdemes - a már ismertetett ok miatt - ebben készíteni. 2. Jelentősen terjed egy másik script nyelves megoldás is a PHP (egyesek szerint ez a Personal Home Page, mások szerint a PHP Hipertext Processor rövidítése). A PHP egyszerűsége és nagyszerű ötlete pont az, ami a JSP és ASP technológiákat is jellemzi: készítsünk olyan HTML lapot, amibe beágyazva vannak azok a szerveroldali programok (itt PHP script), amik lefutnak egy HTTP kérés során és az így dinamikusan kialakult HTML (XML) tartalom kerül át a böngészőbe. A PHP hátránya sajnos az, hogy igazából ez is egy CGI technológia, lassú és sok tekintetben szükségtelenül bonyolult (pl.-ul: ahány adatbázis forrás, annyiféle API azok eléréséhez). (1.1)

A JSP és ASP rövid összehasonlítása Térjünk vissza a JSP technológiára! Miért is jó ez? Vegyük sorra a párhuzamokat az ASP technológiával: 1. Az ASP szerver oldali ActiveX objektumokat a JAVA nyelv osztály mechanizmusa fedi le. Ezeket az osztályokat éppen ezért servlet-eknek is nevezzük. Érdemes az üzleti logikát JavaBean-ekben vagy – az IBM és a SUN kezdeményezése kapcsán – Enterprise JavaBean-ekben (EJB) megfogalmazni. A JavaBean egy ugyanolyan komponens alapú technológiát jelent, mint ami a Delphi vagy Visual Basic (régebben VBX, manapság ActiveX) fejlesztői környezeteket is hatékonnyá tesz. A JSP abban ad nagy segítséget az alkalmazásfejlesztőnek, hogy ezeket a JavaBean-eket egyszerűen el tudja érni, azaz az alkalmazásréteg "tetején" a JSP végzi el a prezentációs és form feldolgozó funkciókat, a JSP biztosítja a kommunikációt a kliensréteg és az alkalmazáslogika között. 2. A Visual Basic script-eknek szintén

a JAVA nyelv felel meg Ki más is mozgósíthatná a *.class file-okban lévő servlet-eket mint maga a JAVA nyelv Ezen a téren az ASP és a JSP közötti hasonlatosság tökéletes. A JSP lapok az ASP-hez teljesen hasonló módon használják a <% . %>, <%= %>, <%@ %> tag-eket szerver oldalon. Ezzel a JSP is tökéletesen megvalósítja az Active Document-nek nevezett megoldást. A különbség csak az, hogy a script nyelve maga a JAVA. Itt felhívjuk a figyelmet egy nagyon fontos tényre: a *.class file-ok dinamikus betöltése miatt a teljes JAVA apparátust használhatjuk a JSP lapokon. Ez tehát azt jelenti, hogy az alkalmazást teljes egészében megírhatjuk JAVA-ban és a HTML/XML alapú user interface-t kell a JSP-ben megoldani. A JSP egyébként a servlet technológia továbbgondolása kapcsán született. Először régebben az SHTML (szerver oldali HTLM) lapok voltak, amikbe az applet-hez hasonlóan a <SERVLET code=.class> paraméterek

</SERVLET> tag-ok segítségével ágyazhattunk be egy servlet-et. A kliens oldalon ezt a http://gép/lap.shtml hívással használhattuk 3. A kliens oldali ActiveX objektumoknak a JAVA applet-ek felelnek meg Amint a kliens és a szerver oldali ActiveX objektumok is megvalósítnak egy kliens/szerver kommunikációs lehetőséget, úgy természetesen itt is megvalósul az applet és a servlet együttműködése útján. 4. Az ASP COM/DCOM technológiájának a szabványos CORBA technológia felel meg. 5. Az ASP OLE DB, ADO vagy ODBC adatbázis elérési modellje helyett a teljesen objektumorientált JDBC-t használhatjuk. Ezen a ponton hagyjuk most abba az ASP-JSP összehasonlítást. A JSP technológia minden operációs rendszeren rendelkezésünkre áll, sőt legjobb megvalósításai a GNU liszensz alá esnek, azaz ráadásul a beszerzésük (vigyázat! Nem a TCO!) ingyenesek. (1.2) A JSP à servlet mechanizmus működése A JSP lapok első használata során azokból

egy-egy servlet, azaz egy class file keletkezik. A JSP technológia célja tehát az, hogy ne kelljen a viszonylag részletgazdag servlet-ek fejlesztésével foglalkoznunk, figyelmünket a dokumentumok kialakítására irányíthassuk (hasonlóan a beágyazott PHP scripthez). Régebben a servlet-ek meghívása hasonló volt a külső CGI script-ek hívásához, azaz az URL így nézett ki: http://gép/egy servlet.class Később kialakult az SHTML technika, aminek használata a beágyazott php-hoz hasonló. Itt már megfigyelhető az, hogy a dokumentum szerkezete van a figyelem középpontjában és abba vannak beágyazva a servlet-ek. A jelenlegi JSP technika tekinthető ezen vonal csúcsának. A gondolat azért nagyszerű, mert a JSP lapok készítését egy WEB designer is el tudja készíteni (ő úgy érzékeli a jsp tag-eket, mintha azok extra html tag-ek lennének), ugyanakkor a háttérben továbbra a jól bevált servlet technológia állhat. Itt jegyzem meg, hogy ez a

felfogás tökéletes összhangban van a mostanában viharos sebességgel terjedő XML technológiával. A következő (2). szakaszban ismertetek egy olyan JSP, servlet fejlesztői és futtató architektúrát, ami bármelyik operációs rendszeren kialakítható és talán a legkorszerűbb megoldás ebben a pillanatban. A konkrét kialakítás ismertetését a Linux operációs rendszerre írom le, de az alapelvek teljesen hasonlóak más operációs rendszereknél is. A (3). pontban pedig egy példán keresztül bemutatom ezen környezet használatát is (2) A futtató, fejlesztő környezet kialakítása Nézzük először is az általam használt hozzávalókat: ü Apache 1.314 WEB szerver ü Apache JAKARTA-TOMCAT 3.21 ü SUN JAVA 2 SDK Standard Edition for Linux ü Borland Interbase v6.0 adatbázis szerver ü Borland InterClient JDBC driver az Interbase eléréséhez A fenti szoftverek közös jellemzője a stabil működés, nagy cégek gyártják őket és a beszerzésük

ingyenes. A teljes TCO (Total Cost of Ownership=a tulajdonlás teljes költsége) nem ingyenes, de ezen szoftvereknél igaz a következő: mindig csak akkor kell fizetni, ha valami hozzáadott érték keletkezik (pl.-ul: a szakember üzembeálltja a szoftvert), ellentétben az MS filozófiájával, ahol még semmi új érték nem keletkezett csak egy liszensz-et kapunk meglehetősen magas áron. Kezdjük el a WEB-es szerverünket kialakítani! A Linux telepítésével most nem foglalkozunk. (2.1) Az Apache telepítése Az Apache szerver forráskódja a www.apacheorg helyről letölthetőek A letöltendő file neve: apache 1.314targz A forráskódból telepített rendszereket a file rendszer /opt helyére másoljuk: cp apache 1.314targz /opt Csomagoljuk ki: tar -xvzf apache 1.314targz Ennek hatására a forráskód a /opt/apache 1.314 könyvtárba kerül, amire - csupán a kényelem kedvéért - csináljunk egy szimbolikus linket. Lépjünk be a könyvtárba és adjuk ki a

következő parancsot: ln -s /opt/ apache 1.314 apache A Linux rendszeren több stratégia létezik arra, hogy a forráskódból hogyan készítsünk futtatható rendszert. A legelterjedtebb az, hogy van egy configure nevű script, ami feltérképezi a Linux rendszerünket és előállít egy ahhoz illeszkedő Makefile-t. Ezt csinálja az apache is. Adjuk ki ennek megfelelően a configure parancsot: ./configure --sysconfigdir=/etc/httpd --datadir=/home/httpd --logfiledir=/var/log/httpd -- disable-rule --enable-shared=max --enable-module=most Ez a parancs olyan Makefile-t készít, ami előírja azt is, hogy hol lesz az apache config file helye (/etc/httpd), hol lesz a WEB tartalom gyökere (/home/httpd), hol lesz a logfile. Ezenfelül engedélyezzük a dinamikusan töltődő modulok használatát is. A következő lépés a forráskód lefordítása a "make" parancs kiadásával. A fordítás után a bináris kód telepítése a "make install" paranccsal

lehetséges. A futtatható apache rendszer a telepítés után a /usr/local/apache könyvtárban helyezkedik el. (2.2) A SUN JAVA 2 telepítése A .jdk122targz file-t másoljuk a /opt könyvtárba, majd az ismert tar -xvzf targz paranccsal csomagoljuk ki. Ekkor létrejön egy /opt/jdk122 könyvtár, ahol a JAVA 2 rendszer található. Készítsünk erre is egy linket: ln -s /opt/jdk1.22 jdk Egy kicsit előretekintve módosítsuk a /etc/profile file-t, mert ez az a hely ami az általunk használt bash shell környezeti változóit beállítja (Windows-ban erre az autoexec.bat-ot használnánk). # A /etc/profile végére ezt irjuk: # A java home könyvtár JAVA HOME="/opt/jdk" # A programok keresési útvonalának kiegészítése: PATH=$JAVA HOME/bin:$PATH # A TOMCAT JSP és servlet szolgáltató helye TOMCAT HOME="/opt/tomcat" # Az apache helye APACHE HOME="/usr/local/apache" TCJ=/opt/tomcat/lib JDKJ=/opt/jdk/jre/lib CLASSPATH=.:$JDKJ/rtjar

CLASSPATH=$CLASSPATH:/opt/interclient/interclient.jar CLASSPATH=$CLASSPATH:$TCJ/servlet.jar:$TCJ/jasperjar:$TCJ/antjar CLASSPATH=$CLASSPATH:$TCJ/jaxp.jar:$TCJ/parserjar CLASSPATH=$CLASSPATH:$TCJ/webserver.jar:$JAVA HOME/lib/toolsjar export CLASSPATH, JAVA HOME, TOMCAT HOME, APACHE HOME # A /etc/profile változtatás vége. Ezekkel a változtatásokkal a JAVA fordító és futtató is meg fogja találni a *.class fileokat Ezeket a *.class file-okat régebben a file rendszerbe helyezték el, majd *.zip fileban tárolták (itt is benne volt a könyvtárstruktúra) Mostanában a *.jar file-okat használnak, aminek zip a formátuma, de a jar JAVA-ban íródott. A JAVA fordító és futtató a *.class file-okat igény szerint, dinamikusan használja, amihez azonban meg kell találni őket. A keresési stratégia a következő: A program indító könyvtára, ha itt nincs, akkor a JAVA HOME által kijelölt hely. Amennyiben itt sincs, akkor a CLASSPATH által megjelölt helyeken folytatódik

a keresés. (2.3) Az Apache Jakarta-Tomcat telepítése Az apache projekt a WEB szerverét már régóta kiegészítette a servlet hívási modullal, amit a mod jserv.so (Apache JSERV csomag) modul valósít meg A JSP technika használatát az erre épülő GNU JSP tette először lehetővé. Ezt a párost váltotta fel az egységes Jakarta-Tomcat csomag, ami a servlet és JSP lehetőségeket is magában foglalja. A csomagot szintén az apache projekt www.apacheorg helyéről lehet letölteni A letöltendő file neve: jakarta-tomcat-3.21targz (bináris), illetve jakarta-tomcat-src321targz (forráskód) Másoljuk be mindkét file-t a megszokott /opt helyre, majd csomagoljuk ki a bináris csomagot a tar -xvzf . paranccsal, aminek hatására létrejön a /opt/jakarta-tomcat-3.21 könyvtár Készítsünk rá linket: ln -s /opt/jakarta-tomcat-3.21 tomcat Emlékezzünk vissza, hogy a /etc/profile file TOMCAT HOME változója erre a linkre mutat. A tomcat telepítése ezzel a

kicsomagolással lényegében befejeződött Még annyit kell csinálni, hogy a tomcat rendszer mod jk.so nevű file-ját másoljuk be a /usr/local/apache/libexec helyre. Ez az a hely, ahol az apache a dinamikusan töltődő modulokat tárolja. A mod jkso egy adaptert valósít meg az apache számára Ez azt jelenti, hogy ha *.JSP vagy servlet kérés megy az apache felé, akkor ő ezt delegálja a mod jk.so modul használatával a tomcat felé A tomcat előállítja a dinamikus HTML tartalmat, amit apache szolgáltat a kliens felé. Ahhoz, hogy az apache tényleg így működjön ezt meg kell mondani neki. Létezik a /opt/tomcat/conf könyvtárban egy "mod jk.conf-auto" file, amit nem szabad editálni, mert úgy jó, ahogy van A teendőnk csak annyi, hogy az apache konfigurációs file-jába a /etc/httpd/httpd.conf-ba utolsó sorként írjuk be a következőt: include /opt/tomcat/conf/mod jk.conf-auto Ezzel az apache jól fogja használni a kapcsolatot a tomcat felé. A

tomcat-ot viszont még konfigurálni kell, ami a server.xml és a workersproperties file-ok módosításával tehetünk meg. Mindkettő a /opt/tomcat/conf könyvtárban helyezkedik el 1. A workersproperties módosítása a következő sorok beirását, kijavítását jelenti: # adjuk meg, hogy hol van a tomcat: workers.tomcat home=/opt/tomcat # adjuk meg, hogy hol van a JAVA workers.java home=/opt/jdk # adjuk meg, hogy a Linux-ban ez a path separator jel ps=/ # A JAVA virtuális gép helye worker.inprocessjvm lib=/opt/jdk/jre/lib/i386/classic/libjvmso 1. A serverxml editálása Ha jó nekünk, hogy a JSP file-ok és a servlet-ek a /opt/tomcat/webapps/root helyen vannak, akkor ezt a file-t nem szükséges átírni. Ezzel a tomcat is működőképes lett. Hogyan indítsuk ezek után a WEB szerverünket? 1. lépés: A tomcat indítása: "/opt/tomcat/bin/startupsh" Ez a script is a kicsomagolt tomcat része. 2. lépés: Az apache indítása:

"/usr/local/apache/bin/apachectl start" A WEB szerver leállítása a "/usr/local/apache/bin/apachectl "/opt/tomcat/bin/shutdown.sh" parancspárral lehetséges stop", majd a (2.4) A Borland Interbase adatbázis szerver telepítése A Borland szabaddá tette az Interbase néven futó adatbázis szerverét, ami tudásban kb. az MS SQL szervernek felel meg. WEB-es célokra kiválóan alkalmazható A csomag telepítése rendkívül egyszerű. Az Interbase60targz csomagot másoljuk a /opt helyre és a tar -xvzf . paranccsal csomagoljuk ki Ezek után csak annyi a teendő, hogy a /etc/services file-ba beírjuk az új TCP/IP szolgáltatást, azaz a file-t a következő sorral kell kiegészíteni: gds db 3050/tcp # hálózatos interbase protokol port Ebből azt is látjuk, hogy az interbase-t használó kliensek egy másik számítógépen is futhatnak és amikor az adatbázis szervert akarják használni, akkor ezt a 3050-es tcp porton tehetik meg. Ez

hasonló az Oracle Net * protokolljához. Az Interbase szervert a következő paranccsal lehet elindítani: # az & hatására a háttében fog futni. /opt/interbase/bin/ibserver & Az Interbase telepítésekor felkerült egy isql nevű program is, ami az adatbázis felé egy SQL parancsfelületet biztosít (hasonlóan, mint az Oracle *Plus). Indítsuk el sysdba userként, masterkey password-del: isql -u sysdba -p masterkey Ekkor egy "SQL>" prompt jelenik meg, ahonnan SQL parancsokat adhatunk ki. Hozzunk létre egy új adatbázist az /opt/interbase/adatok könyvtárba: SQL> create database "/opt/interbase/adatok/webimi.gdb"; Az Interbase adatbázisok egy-egy gdb kiterjesztésű file-ban vannak (itt van minden: táblák, view-k, tárolt eljárások, triggerek, indexek, .) A következő dbgen.sql script egy táblát hot létre ebben az adatbázisban: # dbgen.sql create table TELEFONOK ( azon NUMERIC(10) NOT NULL, nev VARCHAR(50), telefon VARCHAR(20),

primary key( azon ) ); Ezt a script-tet az isql input parancsával futtathatjuk: input /opt/interbase/adatok/dbgen.sql; Próbaként szúrjunk be egy sort ebbe a táblába: Insert into TELEFONOK values(1, Nyiri Imre, 123456789); commit; Lépjünk ki az isql-ből az exit; paranccsal. (2.5) Az Interbase Java JDBC driver telepítése A driver az Interclient.targz file-ban van, amit az eddigiek szerint másoljunk az /opt könyvtárba és csomagoljuk ki. Ekkor létrejön egy /opt/interclient install temp dir könyvtár, ahova lépjünk be, majd futtassuk le az ott lévő "install.sh" scriptet A script azon kérdésére, hogy hova telepítse a JDBC driver, adjuk meg az /opt/interclient könyvtárat. A telepítés után már csak annyi a teendő, hogy az interclientjar nevű file-t hozzá appendeljük a CLASSPATH-hot a /etc/profile-ban. Ezzel kész az Interbase JDBC driver telepítése. Próbáljuk ki, hogy működik-e! Ehhez írjunk egy JAVA programot // // A program az előző

pontban létrehozott adatbázist használja // asz1.java, ahol asz=adat szolgáltató // import java.sql*; public class asz1 { public String ir() { String databaseURL = "jdbc:interbase://localhost/opt/interbase/adatok/webimi.gdb"; String user = "sysdba"; String password = "masterkey"; String driverName = "interbase.interclientDriver"; Driver d = null; Connection c = null; Statement s = null; ResultSet rs = null; // Driver load try { Class.forName ("interbaseinterclientDriver"); } catch ( Exception e) { return "???"; } // Kapcsolat létrehozás try { c = DriverManager.getConnection (databaseURL, user, password); } catch ( SQLException e) { return "???"; } // auto commit hamisra állítása try { c.setAutoCommit (false); } catch (java.sqlSQLException e) { return "???"; } // Egy lekérdezése try { s = c.createStatement(); rs = s.executeQuery ("select NEV, TELEFON from TELEFONOK");

ResultSetMetaData rsmd = rs.getMetaData(); int cols = rsmd.getColumnCount(); rs.next(); return rs.getString("NEV"); } catch ( SQLException e ) { return "???"; } } } // end class Most fordítsuk le a programot: "javac asz1.java" paranccsal, amelynek eredményeként egy asz1.class file keletkezik Tesztelésképpen írjunk egy konzol alapú JAVA főprogramot, ami ezt az osztályt használja: // imre.java public class imre { public static void main(String[] args) { System.outprint( new asz1()ir() ); } } A program létrehoz egy új "asz1" típusú objektumot és meghívja annak az ir() metódusát, ami a telefonok tábla első sorának NEV mezőjét, tehát a "Nyiri Imre" stringet adja vissza. A System.outprint() pedig ezt a stringet kiírja a konzolra Működik tehát az adatbázis kapcsolat. A programot a java imre paranccsal indíthatjuk el, aminek hatására a „Nyiri Imre” szöveg kiíródik a konzolra. Ezzel a fejlesztő,

futtató környezet minden komponense a helyére került, befejeztük a szoftverek telepítését. (3) Az Apache – JSP környezet kipróbálása A környzetet kipróbálásához felhasználjuk az eddig létrehozott teszteredményeinket: ü A webimi.gdb adatbázist (benne a TELEFONOK táblát) ü A már elkészített asz1.java és asz1class file-okat A jobb érthetőség, valamint a servlet-ek és a JSP lapok összehasonlíthatósága érdekében a elkészítünk egy olyan dinamikus html lapot generáló modult, ami olyan html lapot küld a kliensnek, ami a napszaknak megfelelően köszön, majd kiírja a TELEFONOK tábla első sorának telefontulajdonosát. (3.1) A feladat JSP alapú megoldása Nos, tehát az általunk kialakított környezet működőképességének vizsgálatához készítsünk egy nagyon egyszerű JSP lapot, aminek a neve legyen elso.jsp Ezt a böngészőből a "http://www.helyhu/elsojsp" sorral vagy egy erre mutató link-kel hívhatunk meg. Nézzük

meg a JSP file tartalmát (a JSP file-ok text file-ok): --- Itt kezdődik az elso.jsp <%@ page import="java.utilCalendar" %> <% if (Calendar.getInstanceget(CalendarAM PM) == CalendarAM ) { %> Kellemes délelöttöt kívánok! <br> <% } else { %> Kellemes délutánt kívánok! <br> <% } %> A telefontulajdonos neve: <%= new asz1().ir() %> <br> --- Itt fejeződik be az elso.jsp Az elso.jsp-re való hivatkozás után az apache felmeri, hogy ez egy JSP oldal A mod jk adapter segítségével megkéri a tomcat-et, hogy dolgozza fel ezt a file-t. A tomcat az elso.jsp file-ból a háttérben egy JAVA class-t (servlet-et) készít, majd ezt lefuttatja a JAVA VM-mel. Itt van egy fordítási fázis, ami csak ez első alkalommal történik meg, utána már mindig a lefordított class fog futni, ami gyorsabb mint a PERL, PHP megoldás, mert azok minden hivatkozásnál interpretálódnak. A futás eredménye a következő dinamikus HTML lesz

(csak, amit a böngészőből látunk): Kellemes délutánt kívánok! A telefontulajdonos neve: Nyiri Imre Ugye milyen nagyszerű? Volt egy komplett JAVA alkalmazásunk az asz1.class file-ban (ezt egy kis túlzással egy JavaBean-nek is nevezhetnénk), amit csak elegánsan meghívtunk a JSP lapról. Ugyanakkor az is látszik, hogy tetszőleges JAVA programok írhatók be a JSP lapokra. (3.2) A feladat servlet alapú megoldása Természetesen most csak egy nagyon egyszerű megoldást fogunk látni, így aki a servletek akarja tanulmányozni, annak ajánljuk a SUN servlet specifikációit. Nézzük a programot: // Importok import javax.servlethttp*; import javax.servlet*; import java.io*; import java.net*; import java.utilCalendar; // // Ennek hívása a böngészőből: // http://gépnév/elso.class // public class elso extends HttpServlet { // a servlet inicializálása public void init( ServletConfig conf ) throws ServletException { super.init( conf ); } // Ez a servlet

szolgáltatása: html lap előállítás // public void service( HttpServletRequest req, // input kérés HttpServletResponse res ) // html outputhoz { String sz = (new asz1()).ir(); // a TELEFONOK táblából String udv; // üdvözlés if (Calendar.getInstanceget(CalendarAM PM) == CalendarAM ) { udv = „Kellemes délelöttöt kívánok! <br>”; } else { udv = „Kellemes délutánt kívánok! <br>”; } res.SetContentType(„text/html”); ServletOutputStream out = res.getOutpitStream(); out.println(„<head><title>Az elsoclass</title></head><body>”); out.println( udv ); out.println(„A telefontulajdonos neve: „); out.println( sz ); outprintln(„</body>”); } // end service } // end elso class Tekintettel arra, hogy a tomcat is servetté fordítja a JSP lapot (a tomcat „work” könyvtárában mindig megnézhetjük azt is, hogy hogyan is néz ki ennek a JSP-ből előállított servlet-nek *.java forrása), azaz a

servlet-ek kezelését is nyilván ismeri, alkalmazhatnánk ezt a servlet-et is a fent bemutatott környezetben. Az azonban talán már mindenki előtt nyilvánvaló, hogy érdemes kihasználni azt, ahogy a JSP technológia a servlet-et automatikusan előállítja. (4) Záró gondolatok Ez az írás csak egy rövid ismertető volt arra nézve, hogy miért is és hogyan használható a Java nyelv a szerver oldali programozáshoz. Van néhány olyan kérdés még, amit tisztázni kell, mielőtt valaki belevág ezen technológia mélyebb használatába. Nézzük őket! (4.1) Milyen fejlesztőeszköz használható? Az nyilvánvaló, hogy egy egyszerű Java fejlesztői környezet (Borland Jbuilder, Oracle Jdeveloper, IBM VisualAge for Java) nem elégséges, hiszen a *.java, *.class file-okon kívül még a következő nyersanyagokra is szükség van: ü HTML lapszerkesztő ü JSP lapszerkesztő ü CGI scriptek írása, kezelése ü Applet készítő eszköz ü HTML script írást

támogató eszköz (JavaScript, VB script) ü Grafikák, hangok, stb. kezelése Ezenfelül ezeket az alapanyagokat egy egységes WEB alkalmazásként kell tudni menedzselni. Ezt a feladatot az MS Visual InterDev remekül ellátja, de létezik az IBM gondozásában (és ez e-Business jegyében) egy másik eszköz is, ami ugyanilyen magas szinten tud egy WEB-es alkalmazást kialakítani és menedzselni, sőt a JSP technológiabeli támogatottsága egyértelműen jobb az InterDev-nél: IBM WebSphere Stúdió. A JavaBean-eket érdemes az IBM VisualAge for Java vagy bármilyen más JAVA fejlesztői környezetben létrehozni, majd ezeket a Stúdió segítségével lehet a WEB-es alkalmazásunkba integrálni (a bean-ekkel való kommunikáció megszervezése). A VisualAge-ben úgy lehet tesztelni a web-es alkalmazást, hogy egyidőben egyik ablakban látjuk a JSP kódot, a mellette lévőben a JSP-ből előállított servlet kódját, a harmadik ablakban pedig magát a generált html vagy WAP

vagy VoiceXML stb. kódját Az így kialakított és letesztelt alkalmazás ezután bármiben környezetben futtatható (Oracle Appserver, Apache+tomcat, websphere stb.) Egy tanulási célra alkalmas fejlesztői környezet a Sun JSWDK 1.0 eszköz, ami ingyenesen letölthető. (4.2) A html form-ok feldolgozása A HTML form feldolgozás kihasználja a Bean/JSP előnyeit. Az mindenkinek tetszhet, ahogy a PHP egy „nev” nevű beviteli elemet $nev néven ér el. A JSP-ben sem bonyolultabb a helyzet. Egy html form "nev" és "lakcim" nevű mezőjét a bean egy-egy metódusával tudjuk kezelni, amiket célszerűen: getNev(), getLakcim() névre keresztelhetünk, ami után azt a JSP engine automatikusan kezelni képes. Ezt a mechanizmust hívják introspection-nek, és hihetetlen módon leegyszerűsíti a form feldolgozást. (4.3) A WEB hely design-jának megvalósítása A JSP lap lényegében egy html lap, szerkesztése-formázása gyakorlatilag bármilyen html

editorban történhet. A servlet-ek baja az volt (hasonlóan a CGI scriptek-hez), hogy a prezentációt kód formájában magukban hordozzák. Ha az alkalmazás kinézetén valami nem tetszik, akkor a servlet kódjába kell belenyúlni, azt újra kell fordítani és deploy-olni, szóval a logika és a design egyetlen megbonthatatlan egységet képez. A valóságban azonban vannak emberek, akik jól tudnak programozni és vannak olyanok, akik szép design-t képesek csinálni. Ennek megfelelően biztosítani kell a külön munkavégzés lehetőségét. Persze úgy is fogalmazhatunk, hogy a JSP megkíméli a programozót a design beprogramozásától, mert azt ezek után vizuálisan is elkészítheti. A programozók elkészítik a bean-eket, a designer-ek pedig a JSP lapokat, amit ugyanúgy tudnak formázni, mintha HTML lapok lennének. A JSP/Bean szemléletű alkalmazás módosítása egyszerű: ha valami rossz a logikában, akkor annak kijavításához nem kell a designer és ez

fordítva is igaz. Irodalomjegyzék (1) (2) (3) (4) (5) (6) http://java.suncom http://javasite.bmehu http://www.servletscom www.javasoftcom/products/jsp http://www.jspincom http://www.jspinsidercom