WEBFEJLESZTÉS ÚJ UTAKON

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem WEBFEJLESZTÉS ÚJ UTAKON Tudományos Diákköri Dolgozat Készítették: Farkas Gábor Gáthy Lajos Szabó Marcell IV. évf. műszaki informatikus hallgatók Konzulensek: Dr. Gajdos Sándor adjunktus Budapesti Műszaki és Gazdaságtudományi Egyetem Távközlési és Médiainformatikai Tanszék Golda Bence PhD. hallgató Eötvös Loránd Tudományegyetem Informatikai Kar október 27.

2 Absztrakt Ma az egyedi igények kielégítésére készülő alkalmazások egyre nagyobb része webes technológiákon alapul. Ezekben az esetekben a fejlesztés költségeit egyetlen megrendelő viseli, az eladási ár és a versenyképesség kialakulásában döntő szerepe van a fejlesztés hatékonyságának. Miközben az egyedi alkalmazásokat ma is gyakran alacsony szintről indulva építik fel, számos keretrendszer és eszköz is létezik, amelyek a jellegzetes feladatokra általános, robusztus megoldást biztosítanak. Munkánkban újszerű, hatékonyságot növelő lehetőségeket elemeztünk, majd azok használhatóságát vizsgáltuk egy konkrét, de mégis tipikusnak mondható feltételrendszer mellett, majd pedig egy tényleges rendszerimplementáció során. Kiindulási alapnak tekintettük a tradicionális négyrétegű felépítést (adatmodell, üzleti logika, vezérlés, megjelenítés). Mindegyiknél több elterjedt megoldás lehetőségét vizsgáltuk, majd egy kiválasztott módszerrel meg is valósítottuk az adott réteget. A választás során az elsődleges szempontok a megoldás robusztussága, rugalmassága és a fejlesztés hatékonysága voltak, azonban nem feledkeztünk meg arról sem, hogy adott konkrét feladathoz is jól illeszkedjen. Az alsóbb rétegekben a Java Enterprise Edition 5.0 által biztosított objektumperzisztenciára és objektumkezelésre esett a választásunk. Az üzleti logika az Enterprise JavaBeans 3.0 specifikációjának megfelelő beanekből épül fel, ezeket egy Java EE kompatibilis alkalmazásszerver futtatja, ami modulárissá és skálázhatóbbá teszi az alkalmazást. Az alkalmazás fejlesztése során így már csak annak funkcionalitására kellett koncentrálni. A vezérlési rétegben több elterjedt webes alkalmazás-keretrendszer előnyeit és hátrányait vizsgáltuk (Spring MVC, Apache Struts, Millstone), majd a tapasztalatok alapján egy saját keretrendszert fejlesztettünk. Ez lehetővé tette, hogy a tényleges alkalmazás funkcionalitását deklaratívan, annak specifikációjával írjuk le. Ennek köszönhetően az alkalmazás fejlesztése átláthatóbbá, hatékonyabbá és könnyen dokumentálhatóvá vált. A megjelenítési rétegnél is egy újszerű koncepciót (az XAML, XUL mintájára) választottuk, ahol a megjelenés logikája teljesen függetlenített a többi rétegtől. Az adatok megjelenítéséhez használt transzformáció cserélhető és átírható a kliens oldalon is. A bemutatott elveken alapuló fejlesztés eredményességét egy elkészült, működő rendszer bizonyítja, a módszer és a választott eszközök hatékonysága pedig a fejlesztés során bizonyosodott be. Az elkészült alkalmazás a VIK Számítógép laboratórium VI. tantárgy oktatását fogja segíteni tavaszától.

3 Köszönetnyilvánítás Mindenek előtt köszönetet szeretnénk nyilvánítani mindazoknak, akik segítsége nélkül ez a dolgozat nem jöhetett volna létre. Köszönjük Dr. Gajdos Sándornak, hogy tantárgyi keretek között lehetőséget adott nekünk tudományos munka végzésére, szakmai fejlődésre, és hogy nagyban elősegítette dolgozatunk kialakulását. Köszönjük Golda Bencének a biztatását, szakmai észrevételeit és tanácsait, a dolgozatunkkal kapcsolatos lelkes segítségét, az erre fordított rengeteg időt és energiát. Köszönjük Benedek Zoltánnak, hogy Farkas Gábor az Automatizálási és Alkalmazott Informatikai Tanszéken önálló labor keretei között foglalkozhatott a kutatással. Köszönjük a Számítástudományi és Információelméleti Tanszéknek, hogy infrastruktúrájával segítette fejlesztői munkánkat. Köszönjük Tóth Dánielnek a megjelenítési réteggel kapcsolatos tanácsait, és hogy rendelkezésünkre bocsátotta a [36] és [37] irodalmakat.

4 Tartalomjegyzék ABSZTRAKT 2 KÖSZÖNETNYILVÁNÍTÁS 3 TARTALOMJEGYZÉK 4 1. BEVEZETŐ MOTIVÁCIÓNK A CÉL ÉS AZ EREDMÉNY A DOLGOZAT FELÉPÍTÉSE 6 2. CÉLKITŰZÉS, TECHNOLÓGIA-VÁLASZTÁS A PROBLÉMAOSZTÁLY A PÉLDAALKALMAZÁS TECHNOLÓGIA-VÁLASZTÁS WEBES ALKALMAZÁS TECHNOLÓGIÁK PHP ASP.Net Moodle keretrendszer JAVA JAVA ENTERPRISE EDITION A Java EE alkalmazásszerver A Java EE különböző verzióiról A MEGVALÓSÍTÁSI SÉMA A JAVA EE PLATFORM RÉSZLETES BEMUTATÁSA A beanekről Az alkalmazásszerverről részletesebben A Java EE 5.0 újításairól ELSŐ RÉTEG: AZ ADATMODELL Tárolt eljárások Object-Relational Mapping A Hibernate rendszer bemutatása Az adatmodell réteg implementációjának bemutatása MÁSODIK RÉTEG: ÜZLETI FUNKCIÓK A technológiáról Az implementációról A konfiguráció VEZÉRLÉS ÉS MEGJELENÍTÉS A példaalkalmazásunk Nem strukturált végrehajtás Szekvenciális szétválasztás JSP bevezetése MVC Felhasználói interakciók Apache Struts Tapestry Millstone 42 4

5 Saját keretrendszer koncepciója A SAJÁT VEZÉRLÉS BEMUTATÁSA Programozás a keretrendszerben Kapcsolódás az üzleti logikához Kapcsolódás a megjelenítéshez A MEGJELENÍTÉS MEGVALÓSÍTÁSA Általánosságban Absztrakt felhasználói felület definíciók Esettanulmány Webes felhasználói felület A megjelenítés a megvalósítási sémánkban Egy példa TOVÁBBI LEHETŐSÉGEK MODELLEZÉS LEHETŐSÉGEI Eszközeink Lehetőségeink A JAVA EE PLATFORM TOVÁBBI LEHETŐSÉGEI Vastagkliens alkalmazások Az alkalmazásszerver biztonsági mechanizmusai Az alkalmazásszerverek clusterbe szervezése ÖSSZEFOGLALÁS ÉS ÉRTÉKELÉS FÜGGELÉK CSOPORTMUNKA ESZKÖZÖK A PÉLDAALKALMAZÁS FEJLESZTÉSI PROJEKTJE Kiindulási anyagok, a korábbi rendszer Specifikáció Fogalomtár és use-case-ek Class Diagram Állapotgép Kliensalkalmazás A FUTTATÓKÖRNYEZET A JBoss alkalmazásszerver Adatforrás konfigurálása EGY ÁLLAPOT XML IRODALOMJEGYZÉK 76 5

6 1. Bevezető 1.1. Motivációnk Webes alkalmazásokra nagy igény van, ami az Internet terjedésével még tovább fog nőni. Ezen alkalmazások változatosak, bonyolultságuk is széles skálát ölel fel. Nagy számuk miatt a legegyszerűbb alkalmazásoknál is szükség van a fejlesztés hatékonyságát növelő technikákat alkalmazni, a legnagyobb alkalmazásoknál pedig a várható terhelés miatt lehetetlen sikeres alkalmazást készíteni kész komponensek és kialakult koncepciók nélkül. Mivel a dinamikus webes tartalom alig tíz éve vált elterjedtté, még nincsenek tradicionális, állandó, kiforrott paradigmák, mint a szoftverfejlesztés más területein. Egyre újabb és jobb ötletek merülnek fel, újabb programozási nyelvek, futtatási elvek készülnek. Sőt, maguk a webes szabványok is folyamatosan bővülnek, és a böngészők újabb kiadásai egyre újabb lehetőségeket nyitnak meg A cél és az eredmény Munkánk során azt kutattuk, hogy ma, 2006-ban, milyen lehetőségek állnak a webes alkalmazások fejlesztőinek rendelkezésére. Hogy a túlzott általánosságot leszűkítsük, kiválasztottunk egy konkrét, de kellően tipikusnak tekinthető problémaosztályt. A technológiai és módszertani lehetőségek elemzésekor az irányadó az volt, hogy az ilyen problémákat milyen hatékonyan, elegánsan lehet velük megoldani. Munkánk eredménye egy általános megvalósítási séma, melyben részben kiforrott technológiákra támaszkodtunk, részben saját megoldásokat vezettünk be. Ezt a sémát egy gyakorlati igényeket is kielégítő, működő alkalmazás kifejlesztésével is verifikáltuk A dolgozat felépítése Dolgozatunk két fő egységből áll. Az elsőben definiáljuk a problémaosztályt, melyre megoldást keresünk, és eldöntjük, hogy melyik technológiára alapozzuk majd a megvalósítási sémát. A második egységben a megoldási sémánkat mutatjuk be, külön egységeket szentelve az alkalmazás rétegeinek. Az egyes rétegekben röviden bemutatjuk a kínálkozó alternatívákat, megindokoljuk a döntésünket. Részletesebben bemutatjuk a kiválasztott alternatívát, vagy az alternatívák tapasztalatait felhasználó saját megoldást. Dolgozatunk végén a séma továbbfejlesztési lehetőségeivel foglalkozunk, majd az eredményeket összefoglaljuk és értékeljük. A függelékben a sémánk verifikálására választott alkalmazás projektjének menetét és eszközeit mutatjuk be. 6

7 2. Célkitűzés, technológia-választás Munkánk kiindulópontja egy problémaosztály. A problémaosztály jellemzői alapján egy általános alkalmazás-fejlesztési, megvalósítási sémát dolgoztunk ki, az elméleti érveket egy példaalkalmazás megvalósítása során verifikáltuk. Ez a fejezet a következő fejezetben tárgyalt elméleti kutatást készíti elő. Röviden jellemezzük a példa-alkalmazást, ám a következő fejezetben egy hasonló jellemvonásokat viselő, egyszerű, "állatorvosi ló" példát elemzünk. Hogy kutatásunk ne legyen túlzottan szerteágazó, a megvalósítási séma kidolgozásának első, nagyon meghatározó lépését, a technológia-választást ebben a fejezetben, a példaalkalmazásunk alapján hozzuk meg A problémaosztály A kitűzött problémaosztály egyes webes üzleti alkalmazások rétege. Egy ilyen alkalmazás egy valós életbeli folyamat-rendszert modellezzen. Az alkalmazás minden (absztrakt) objektuma egy-egy valós világbeli objektumnak vagy fogalomnak legyen megfeleltethető meg, és ezek interakcióit kövesse a rendszer. Továbbá kikötöttük, hogy a folyamatnak sok emberi résztvevője legyen, akik a világ tetszőleges számítógépéről el akarják érni a rendszert, viszont egyszerre csak kis mennyiségű adatot jelenítsenek meg tipikusan egy, hozzájuk szorosabban kapcsolódó adathalmazon dolgozzanak A példaalkalmazás Dolgozatunkban a problémaosztályra lehetőség szerint általános megoldást keresünk, ám a platformok széleskörű áttekintése nagyon szerteágazóvá tenné a kutatást. Azért, hogy végül kézzelfogható eredményig juthassunk el, kutatásunk elején egyetlen platform mellett köteleztük el magunkat. Mivel ezt a döntést általános probléma esetén talán lehetetlen meghozni, ezért a technológia kiválasztásakor a konkrét példaalkalmazás igényeit is figyelembe vettük. Az BME műszaki informatikus hallgatói a Számítógép Laboratórium VI. tantárgy teljesítéséhez méréseket végeznek. A mérések beugróval kezdődnek, majd laborvezető segítségével mindenki elkezd egy egyéni feladatot, ezt otthon befejezi, és három napon belül beadja a hozzá elkészített jegyzőkönyvet. A folyamat irányítására és a szükséges oktatói háttérmunka megkönnyítésére egy webes alkalmazás szolgál. Ezt az alkalmazást választottuk példaalkalmazásnak. Az általános problémaosztályra kidolgozott megoldásokat az alkalmazás újraírása során próbáltuk ki a gyakorlatban. Mivel dolgozatunk témája a séma, ezért a konkrét alkalmazásról csak kevés szót ejtünk a róla a következő fejezetekben. Viszont a projekt néhány részletét érdemesnek tartottuk bemutatni, ezért a függelékben található egy részletesebb leírás a projekt menetéről. 7

8 A példaalkalmazás által támogatott folyamatról az 1. ábra 1 mutat vázlatos képet. Az ábrán szereplő fogalmakat nem részletezzük, mert erre nincsen szükség a dolgozat további részeinek megértéséhez, de bízunk benne, hogy a feladat jellegét jól szemléltetik. 1. ábra a példaalkalmazás által támogatott folyamat vázlatosan A Feladatok előkészítése fázisban egy dokumentumtár funkcionalitására van szükség. A félév előkészítésekor, a hallgatók létrehozása és a feladatok hozzájuk rendelése során adat-intenzív műveleteket futtatunk. Végül a félév során a különböző szereplők többször belépnek, és kisebb mennyiségű adatot töltenek le vagy fel, egymás eredményeire várva. A harmadik rész teszi ki a működés döntő részét Technológia-választás Olyan technológiát keresünk, amely a kijelölt problémaosztály feladatainak megoldására általánosságban alkalmas. Az optimalitást azzal mérjük, hogy a lehető legjobban megfeleljen az 1. ábrán bemutatott három fázis által támasztott általános igényeknek. Ezek 1 Megjegyezzük, hogy ez nem egy UML szemantikát követő use-case diagram, csak egy személtető ábra 8

9 közül a legfontosabb a Félév menete, mert ezt a funkcióhalmazt használják a felhasználók az esetek túlnyomó többségében. Felmerült, hogy egy különálló asztali alkalmazás álljon az adminisztrátor rendelkezésére 2, amely segítségével hatékonyan végezhet adatintenzív műveleteket, így ennek megvalósíthatósága is szempont lehet a döntésnél. Mivel a felhasználók zöme a legkülönbözőbb számítógépekről szeretné használni az alkalmazást, ezért a vékony kliensre alapuló, azaz webes alkalmazás technológiák között keressük a megoldást. Fontos kikötés, hogy a technológia az operációs rendszerre ne adjon megkötést Webes alkalmazás technológiák Az informatikában nagyon nagy szerepe van az Interneten keresztül nyújtott szolgáltatásoknak, ezek között is a web alapú szolgáltatások részesedése túlnyomó, melyben a klienssel való kapcsolat HTTP protokoll szerinti, a kliens oldalon HTML és JavaScript programok és leírók szerepelnek (továbbá XML, XSLT, CSS, DHTML, Java Applet, Flash és ActiveX vezérlők használata elterjedt). Az alkalmazások nagy része azonban szerveroldalon kerül futtatásra, a HTTP kapcsolat másik oldalán. Természetesen van lehetőségünk saját webkiszolgáló írására, amely a dinamikus működést megvalósítja, ennél azonban rugalmasabb megoldás nyújt az, ha a már meglévő statikus tartalmat kiszolgáló webszervert tudjuk kiegészíteni az alkalmazásunkkal. Erre univerzális megoldást biztosít a Common Gateway Interface (CGI) [5], amely használatával a bekonfigurált HTTP kéréseket a webszerver a mi modulunknak továbbítja, majd a modulunk által adott választ adja vissza HTTP válaszként a kliensnek. Egy másik igen korán elterjedt megoldás bizonyos szkript végrehajtók alkalmazása. Ezekhez a webszerverek integráltan nyújtanak támogatást. Korábban Perl, ma sokkal inkább a PHP [4] a legelterjedtebb szkript motor, de használnak még Pythont is, és ide tartozik az ASP és ASP.NET. A CGI megközelítés egy továbbfejlesztése a Java Enterprise Edition által bevezetett Servlet [6] technológia, ahol szintén az általunk megírt program szolgálja a ki a HTTP (vagy egyéb protokollú) kérést. Tekintsünk át néhány elterjedt megvalósítást és előnyeiket-hátrányaikat a példaalkalmazásunk fényében! PHP A PHP-t hamar elvetettünk, több okból is. Mielőtt a döntésünket indokolnánk, nézzük meg, hogy milyen alapvető feladatokból áll egy webes kérés kiszolgálása. Először a kérés információból (a HTTP kérés fejléce és tartalma) ki kell bányásznunk a nekünk releváns és szükséges információt. Ezek alapján el kell döntenünk, hogy mit kell tennünk, majd ezt meg is kell tennünk. Ez általában üzleti adatok módosítását és az alkalmazás állapotának megváltoztatását jelenti. Meg kell határoznunk ezután, hogy mit kell prezentálnunk válaszként a kliensnek, majd a választ elő kell állítanunk. A válasz általában egy HTML dokumentum. Egy dinamikus tartalommal rendelkező HTML oldalt nagyon kényelmesen állíthatunk elő szövegkezelő szkript motorokkal, mint a Perl vagy a PHP, ezért nagyon csábítók ezen technológiák. Észre kell vennünk azonban, hogy az üzleti adatok kezelésére egy objektum orientált programozási nyelv sokkalta alkalmasabb. Alapvető fontosságú észrevennünk a magas szintű programozási nyelvek és a szkript nyelvek közötti különbséget. 2 Erről a függelék pontjában írunk részletesebben. 9

10 A PHP-ba épülő kiegészítő függvénykönyvtárak segítségével igen sok lehetőségünk van a leginkább szükséges adatbázis kezelésre, és további funkciók használatára is, azonban egy jól strukturált alkalmazás írására magas szintű nyelvet ildomos választanunk. A megjelenítési rétegben (a HTML kimenet előállításában) a Java Server Faces (JSF) technológia és egyéb keretrendszerek ugyanolyan kényelmes eszközt adnak, mint amit a PHP képes nyújtani. Megjegyzendő, hogy egy kisebb dinamikus weboldal kiszolgálására a PHP nagyon is alkalmas, valóban gyorsabban elkészíthető a kész termék, továbbá egy PHP kiszolgáló sokkal kisebb erőforrás-igényű, és sokkal könnyebben elérhető, mint egy Java-t futtató szerver. Amikor azonban üzleti alkalmazást fejlesztünk, fontos formális módszereket, eszközöket és megfelelő fejlesztési módszert alkalmaznunk, amelyek a helyes működésű termék előállítását nagyban segítik, ezek viszont magas szintű nyelvekre épülve elérhetők ASP.Net Az ASP.Net erősen objektum orientált, robusztus keretrendszer, melyben sok kész vezérlő és technika segíti a fejlesztést. Nagy hátránya azonban, hogy gyakorlatilag csak Windows kiszolgálón futtatható a vele készült alkalmazás. Ez viszont jelen feltételek között nem volt megengedhető, és a megvalósítási sémánkba sem kívántunk ilyen erős megkötést beépíteni Moodle keretrendszer Bár első olvasásra furcsának tűnik, de felmerült az a lehetőség is, hogy egy meglévő, hasonló alkalmazást alakítsunk át az adott problémaosztálynak megfelelően, vagy egy, a feladatot megoldó modult fejlesszünk egy általános alkalmazásrendszerbe. Rövid vizsgálódás után a Moodle-t [2] találtuk a feladathoz leginkább közeli alkalmazásnak. Ez egy nyílt forráskódú Learning Management System, mely elsősorban felsőoktatásbeli kurzusok lebonyolítására szolgáló webes portál. A számunkra hasznos funkciók, melyek készen álltak a Moodle-ben: többfajta autentikációs modul szerepkezelés adminisztrátori felülete (tanárok, diákok, kurzusok) online beadandó feladatok és tananyagok kezelése hasznos kiegészítő szolgáltatások: chat, szavazás, fórum, fogalomgyűjtemény További előny, hogy a felhasználói felületre kész koncepciót ad, és nagyon sok megjelenés ( theme ) áll rendelkezésre, és a feliratok több nyelven, köztük magyarul is megjelenhetnek. Hátránya, hogy PHP+MySQL platformra készült, így nagyobb terhelés esetén problémák merülhetnek fel, a skálázáshoz komoly üzemeltetői szakértelemre van szükség. A Moodle üzemeltetőknek szóló fórumok [3] tanulsága szerint helyes beállítások esetén is csak több száz, legfeljebb ezres nagyságrendű felhasználó kiszolgálásához elégséges egy erősebb munkaállomás hardver. Viszont ennél a nagyságrendnél is sok kevésbé szakavatott üzemeltető beleütközött a kapcsolatok számára és a lefoglalt memória méretére vonatkozó korlátokba. Továbbá ezen a platform hibája a sűrű kapcsolódás az adatbázishoz és tipikus hiba az adatbázisok helytelen indexelése, aminek rendkívül alacsony teljesítmény az eredménye. Ezeket a jelenségeket a Schönherz Zoltán Kollégium közösségi életét támogató portáloknál is tapasztaltuk, így a Moodle használatát elsősorban az alapul szolgáló technológia miatt vetettük el. 10

11 A kész funkciók vizsgálata során azt állapítottuk meg, hogy egy Learning Management System olyan extra szolgáltatásokat nyújthat, melyek a kész alkalmazásunkat kedveltebbé tehetik a felhasználóknak, de az elvárt alapfunkcionalitást teljes egészében nekünk kell kifejlesztenünk. Mivel a feladatunk végül mindig egy speciálisabb munkafolyamat támogatására fog vezetni, nemigen fogunk olyan keretrendszert találni, amely ebben segít minket. Általános, elterjedt munkafolyamatokra léteznek rendszerek, de az általunk vizsgált problématípus nem az. Mindig is lesznek speciális munkafolyamatok, az ezek támogatására készült alkalmazások fejlesztésének hatékonyabbá tételére felhasználható általános megoldásokat alacsonyabb szinten kell keresni. Ha mégis kész alkalmazást szeretnénk alapul felhasználni, akkor mérlegelni kell: a kész extra szolgáltatásokért megéri-e az alkalmazást beleintegrálni egy másik rendszerbe? Az integráció mindenképp többletmunka és nehézséget jelentenek a verzióváltások. Nagyon könnyen előfordulhat, hogy a keretrendszer modellje (például a felhasználói szerepkezelés) tágabb vagy szűkebb, mint a kifejlesztendő alkalmazás. Az előbbi eset nem okoz problémát, esetleg adminisztrációs vagy számítási többletmunkát. A második esetben viszont az alkalmazás modellje nem lesz tiszta, kényszermegoldásokat kell alkalmazni. Különösen veszélyes az, hogy ez lehet, hogy csak a fejlesztés későbbi fázisaiban, vagy továbbfejlesztéskor derül ki. Tehát egy kész alkalmazásba történő integráció gyorsabbá teheti a fejlesztést, és értékes kiegészítő szolgáltatásokat adhat, viszont kockázati tényezőket hoz be a fejlesztés és továbbfejlesztés során, illetve megköti a platformot. Ennek fényében ezt a lehetőséget elvetettük Java A Java egy széles körben elterjedt, erősen objektum-orientált nyelv, így kiváló talajt biztosít egy jól tervezett alkalmazás implementálásához. A Java szinte minden operációs rendszeren elérhető, így nem köti meg kezünket a szerverrel kapcsolatban sem. A Java Servlet technológia az általános CGI megközelítés mintájára ad lehetőséget szerveroldali alkalmazások készítésére, ezen túl kiterjedt támogatást nyújt a különféle webes technológiák alkalmazásához. Az üzleti logikai részt a web kérdéseitől függetlenül készíthetjük el, majd sokféle technológia közül választhatunk a felhasználói felület megalkotásakor. A fejlesztés során felmerülő gyakori problémákra biztosít kiforrott megoldásokat a Java Enterprise Edition platform Java Enterprise Edition A Java Enterprise Edition tulajdonképpen Java platform alapú specifikációk gyűjteménye. Ezek az ún. Java Specification Requestek (JSR) [10]. Minden specifikáció egy, a nagyvállalati környezetben történő alkalmazásfejlesztés és üzemeltetés során felmerülő gyakori problémakört jár körül. Ilyen lehet például a tranzakció-kezelés [JSR907], az üzenetek kezelése [JSR914] vagy az alkalmazás menedzsment [JSR77]. Ezek a specifikációk olyan irányelveket rögzítenek az adott problémakörökben, melyek betartásával különböző gyártók által Java platformon fejlesztett megvalósítások könnyedén kombinálhatók lesznek egymással azon túl, hogy robusztus megoldásokat nyújtanak az adott problémákra. Maga a 11

12 Java EE is tulajdonképpen egy JSR specifikáció, a legújabb 5.0-ás verzióját a [JSR244] definiálja A Java EE alkalmazásszerver Ha a Java EE specifikációjában szereplő komponensek implementációit a specifikációnak megfelelően összeintegráljuk, akkor egy Java EE kompatibilis alkalmazásszervert (Application Server, AS) kapunk. Ilyen alkalmazásszerverekre lehet telepíteni az általunk fejlesztett alkalmazásokat, amelyek főként beanekből állnak. Egy bean nem más, mint szolgáltatások összessége, amelyeket más beanek vagy programok igénybe tudnak venni. Az adott alkalmazáson belül tehát a beanek szolgáltatásokat nyújtanak egymásnak, illetve néhány szolgáltatásukat az alkalmazáson kívülről is elérhetővé teszik. Ezeket a szolgáltatásokat kliensként vehetik igénybe más programok, amelyek lehetnek egyszerű Java alkalmazások, vagy más, alkalmazásszerveren futó Java EE alkalmazások beanjei. Ez utóbbi esetben a beanek futhatnak egyazon alkalmazásszerveren, vagy akár egy másik számítógépen futó alkalmazásszerveren is. Ilyenkor természetesen hálózaton keresztül kapcsolódnak az alkalmazásszerverhez, éppen úgy, ahogy az egyszerű Java alkalmazások is teszik, amennyiben egy alkalmazásszerveren futó bean szolgáltatását akarják igénybe venni A Java EE különböző verzióiról A jelenleg legjobban elterjedt verzió a J2EE 1.4-es platform [JSR151], amelynek 16 kompatibilis applikáció szerver implementációja létezik a különböző gyártók kínálatában [11] [12], melyek között ingyenesen felhasználható és kereskedelmi termékek is előfordulnak május 11-én jelentették be a Java EE 5.0 platform véglegesített specifikációját [JSR244], illetve ezzel egyszerre a Sun referencia implementációját, a Sun Java System Application Server Platform Edition 9-et. Mi ezt a nagyon korszerű technológiát választottuk a sémánk alaptechnológiájának annak ellenére, hogy a megjelenés óta eltelt kevés idő alatt ez a verzió még nem terjedt el annyira, mint elődje. Ugyanakkor már több neves gyártó dolgozik a saját implementációja elkészítésén, mint például az SAP [11]. Másrészt az új platform elterjedésére garancia lehet még a régi verziókkal való kompatibilitás, valamint az a rengeteg újítás, amivel éppen a korábbi verziók hiányosságait igyekszik felszámolni. Ha egy mondatban kellene összefoglalni a különbségeket a Java EE 5.0 és a J2EE 1.4 között, akkor azt mondhatnánk, hogy az 5.0 verzióban a fejlesztés sokkal gyorsabbá, átláthatóbbá, hatékonyabbá vált. Ahogyan ezt a Java EE 5 mottója is tükrözi: "Do more with less work." 12

13 3. A megvalósítási séma E fejezetben adunk részletes leírást a kialakult megvalósítási sémáról. Bizonyos részeken a már bevált technológiákat ismertetjük, míg kevésbé kiforrott területekről egy széleskörű áttekintés után kialakult saját koncepciónkat ismertetjük. Az üzleti alkalmazások fejlesztése során alapvetően kétféle architektúra szerint építhetjük alkalmazásunkat. A kétrétegű architektúrában az üzleti adatokat kezelő réteg és a vezérléssel és megjelenítéssel foglalkozó réteg különül el. Ennek komoly üzleti alkalmazásoknál való használatának hátrányairól már a bevezetésben is szóltunk a PHP kapcsán, és jelen fejezetben is még visszatérünk rá. A háromrétegű architektúrában az üzleti réteg mellett elkülönítjük a vezérlés és a megjelenítés rétegét, ez könnyebben kezelhető és jobban átlátható forráskódhoz vezet [1]. Dolgozatunkban négy rétegről beszélünk. Az üzleti rétegben külön tárgyaljuk az üzleti adatok modellezésével és tárolásával kapcsolatos kérdéseket, valamint az üzleti adatokon végzett műveletek és adatlekérdezések (üzleti funkciók) rétegét. Vezérlés és Megjelenítés Adat Megjelenítés Vezérlés Adat Megjelenítés Vezérlés Üzleti Logika Adatmodell 2. ábra A kialakult négy réteg A célkitűzés során elköteleztük magunkat a Java EE technológia alkalmazása mellett. Fontos tudnunk, hogy a Java EE-hez nem kapcsolódik egy konkrét fejlesztőeszköz vagy konkrét architektúra. A platform nagyban segíti az üzleti modell és az üzleti funkciók rétegének fejlesztését, viszonylag behatárolja ezek struktúráját. Nem ad viszont semmiféle megkötést a vezérlés felépítésével kapcsolatban. A megjelenítésre a Java Server Pages egy széles körben használható eszköz, illetve a Java 5 EE-ben a Java Server Faces nyújt bizonyos újításokat. A fejezetben áttekintjük a Java EE által nyújtott lehetőségeket az adat és az üzleti logika rétegeiben. Széleskörű áttekintést adunk a vezérlési és megjelenítési rétegben használható, harmadik fél által fejlesztett keretrendszerekről. Az itt szerzett tapasztalatok fényében bemutatjuk a kialakult saját koncepciónkat és egy általunk kifejlesztett keretrendszert. A fejezet végén a megjelenítési technológiák kérdéseit külön vizsgáljuk. Mielőtt a négy réteg bemutatnánk, áttekintést adunk a Java EE platformról. 13

14 3.1. A Java EE platform részletes bemutatása A beanekről Mint említettük korábban, a bean szolgáltatásokat definiál és azokat mások számára elérhetővé teszi. Természetesen egy alkalmazás által nyújtott szolgáltatások típusukat tekintve is sokfélék lehetnek. Ennek megfelelően a Java EE platformon használatos beaneknek is több típusa létezik [7] [8]: Az entitás beanek (Entity Beans) az alkalmazásban használt adatok modellezésével és tárolásával foglalkoznak. Segítségükkel az üzleti alkalmazás adatmodelljét entitásokból építhetjük fel, ahol minden entitástípust az entitás által birtokolt attribútumok definiálnak. Ezen belül pedig egy entitáspéldányt az attribútumokhoz rendelt értékek határoznak meg, egyértelműen. Az entitástípusok között kapcsolatokat, relációkat definiálhatunk, amelyek jellegüket tekintve szintén többfélék lehetnek. Ezeket az adatokat és kapcsolatokat az adatmodellezésben jól ismert módszerekkel ábrázolhatjuk entitás-relációs vagy osztálydiagramon. A modell megalkotásán túl általános feladat még az entitások állapotának kezelése, úgymint az attribútumok és a relációk megadása/megváltoztatása, valamint a végrehajtott változtatások maradandó formában való tárolásának megoldása. Ez utóbbira a Java EE platformon például a napjainkban egyre jobban elterjedő ún. Object-Relational Mapping (ORM) technikák nyújthatnak integrált segítséget. Ennek részleteiről az adatmodell réteg bemutatásánál lesz szó. A szolgáltatás beanek (Session Beans) a procedurális folyamatokat írják le. Ezek tárolják mindazokat az algoritmusokat, amelyek az üzleti problémakör egyes problémáinak vagy részproblémáinak megoldási menetét definiálják. A szolgáltatás beanek szolgáltatásainak igénybevételével ezen folyamatok végrehajtását kezdeményezhetjük. Az itt általánosan felmerülő feladatok közé tartozik a különböző eljárások végrehajtásához való jogosultságok kezelése, vagy például a végrehajtott folyamatok atomiságát biztosító tranzakció-kezelés megoldása. A Java EE környezetben a szolgáltatás beanek fejlesztése során mindezekre egyszerűen kezelhető mégis robusztus megoldásokat vehetünk igénybe. A szolgáltatás bean rendelkezhet olyan állapot információkkal, amelyek egy adott kliens felől érkező két hívás között megőrzik állapotukat. Ilyenkor állapottal bíró szolgáltatás beanről (Stateful Session Bean) beszélünk, míg ellenkező esetben állapot nélküli szolgáltatás beannel (Stateless Session Bean) van dolgunk. Ennél speciálisabb funkciója van az üzenetvezérelt beaneknek (Message Driven Beans). Ezek aszinkron üzenetvezérelt kommunikációt tesznek lehetővé akár az alkalmazás egyes részei között, akár kooperáló alkalmazások között. A fent említett három bean típus nagyrészt lefedi az üzleti problémák megoldásához szükséges területeket. Ezek együttesen alkotják az Enterprise JavaBeans specifikációját, melynek legújabb, 3.0-ás verzióját a [JSR220] specifikálja. Ezen kívül léteznek még más, speciális funkciót megvalósító bean típusok is. Ezek elsősorban nem az üzleti problémák megoldását hivatottak támogatni, hanem az alkalmazással kapcsolatos egyéb feladatokat. Ilyenek például a menedzsment beanek (Management Beans), amelyek az egyes szolgáltatások menedzselésével kapcsolatos funkciókat láthatnak el, például a szolgáltatások betöltése, elindítása, leállítása. 14

15 A beanek használatának értékelése Vizsgáljuk meg ezek után, hogy a fent megismertetett alkalmazásfejlesztési koncepciók milyen előnyöket nyújtanak a fejlesztés során. Először is fontos kiemelni, hogy a beanek használata a problémák dekompozíciójára késztet, ami lehetővé teszi, hogy a bonyolult problémákat kis, könnyebben átlátható és kezelhető részproblémákra bontsuk. Éppen ezért a dekompozíció alapeleme a modern szoftverfejlesztési gyakorlatoknak. A beanek típusainak szétválasztása pedig arra készteti a fejlesztőt, hogy különválassza az alkalmazás kódjának különböző jellegű részeit. Ez is nagyban növeli a kezelhetőséget és az átláthatóságot, valamint szinte elkerülhetetlen nagy rendszerek fejlesztése esetén. Szintén fontos pozitívum, hogy valamilyen alkalmazásfejlesztési sémához rögzíti a fejlesztőt, amely bár elég általános ahhoz, hogy ne jelentsen korlátozást a problémák megvalósíthatóságra nézve, de mégis egy könnyen átlátható struktúrát ad a rendszernek. Ha ez még párosul is az adott szoftverfejlesztési gyakorlat elterjedtségével, akkor lehetővé teszi, hogy egy a platformot ismerő programozó hamarabb el tudjon igazodni egy számára ismeretlen kódban, mint általános esetben. Ez a Java EE platformra a szigorú előírások miatt kiemelten igaz Az alkalmazásszerverről részletesebben Mint korábban megemlítettük, az alkalmazásunk beanjeit egy arra alkalmas alkalmazásszerver futtatja. Vizsgáljuk meg most egy kicsit közelebbről az alkalmazásszerver alapú koncepciót. Ez valójában a kliens-szerver architektúra alapján történő fejlesztést hivatott megkönnyíteni. Ugyanis annak ellenére, hogy a kliens-szerver modell általánosan jól használható, egy szerver alkalmazás kifejlesztése tradicionális módszerekkel sokkal több munkát igényel, mint amennyit a megoldandó üzleti feladat megkívánna. Ez legtöbbször abból adódik, hogy olyan problémákat kell megoldani a szerver alkalmazás fejlesztése során, mint például a konkurens működés, tranzakció-kezelés vagy éppen az elosztott működés. Ezen a problémakörök önmagukban is elég összetettek és sok csapdát rejtenek, így aztán az ezekbe fektetett munka sokszorosa lehet a valódi probléma megoldására fordított költségeknek. Ezen próbál segíteni az alkalmazásszerver alapú koncepció azáltal, hogy az általánosan előforduló problémákra robusztus, integrált megoldásokat biztosít, így a fejlesztőknek csak a valódi probléma megoldására kell közvetlenül koncentrálniuk. Az említett megoldások hatékony megvalósításával pedig az alkalmazás teljesítménye is növelhető. A kompatibilitás megőrzése Fontos azonban kiemelni egy problémát, ami éppen az integrált megoldások alkalmazásából adódik. Ez az adott megvalósítástól való függés. Ha ezek a megoldások nem képesek más rendszerekkel együttműködni, vagy adott esetben velük kompatibilisek maradni, akkor ez nagy visszatartó tényező lehet. Ezt a problémát igyekszik kiküszöbölni a Java EE platform a specifikációk rögzítésével. Ennek köszönhetően a Java EE platformra fejlesztett alkalmazások nagyrészt függetlenek tudnak maradni a konkrét alkalmazásszerverimplementációtól. Ez természetesen csak bizonyos korlátok mellett teljesülhet, hiszen a specifikációk nem kezelik, nem kezelhetik annyira szigorúan az egyes implementációs előírásokat, különben a gyártóknak nem maradna mozgástere a saját implementációjuk elkészítése során. Mégis lehetőség van a specifikációkat követve olyan Java EE alapú alkalmazást készíteni, ami könnyedén futtatható különböző gyártók kompatibilis implementációin. 15

16 Itt jegyezzük meg, hogy önmagában a lehetőség a kompatibilitásra még nem lenne elég, ha a technológia nem lenne támogatott, és nem léteznének ténylegesen különböző implementációk. A Java EE esetében elmondhatjuk, hogy nem ez a helyzet. A platform eddigi sikereinek köszönhetően olyan gyártók sorakoztak fel a specifikációk mellett saját implementációikkal, mint például az IBM [13], az Oracle [14], az SAP [15] és Java platform megalkotója, a Sun [16]. Fontos szempont továbbá, hogy a platform folyamatosan fejlődik megoldásokat kínálva a korábbi verziók hiányosságaira, amelyekre a tényleges fejlesztések során derül fény igazán. Ennek ellenére a specifikációkban mindig nagy hangsúlyt fektetnek a korábbi verziókkal való kompatibilitás megőrzésére, illetve a kompatibilitás fenntartásának lehetőségére. Ez nagy pozitívum a platformon már kifejlesztett alkalmazások élettartamának megítélésében A Java EE 5.0 újításairól Ebben a részben azt tekintjük át, hogy mitől vált tényleg hatékonyabbá a Java EE 5.0 platformon való fejlesztés a korábbi verziókhoz képest. A továbbiakban elsősorban a J2EE 1.4-ben használt EJB 2.1 [JSR153] [7] és a Java EE 5.0-ban bevezetett EJB 3.0 [JSR220] [8] közötti különbségekre alapozunk, ezekből indulunk ki, valamint megemlítjük az általánosan alkalmazható újításokat is. A meta-információkról Az applikáció-szerver alapú koncepciót követve a tradicionális fejlesztéshez képest megjelenik egy új fejlesztési lépés: a komponensek működésének összehangolása, integrálása egymással, más alkalmazások komponenseivel illetve a platform által nyújtott szolgáltatásokkal. Ez a fejlesztési lépés az angol nyelvhasználatban az application integration nevet viseli. Ezt a műveletet célszerű elválasztani a forráskód írásától, hiszen akkor tudjuk kiaknázni a modularitásból és az újrafelhasználhatóságból adódó előnyöket. Éppen ezért már a korábbi verziókban is megszokott gyakorlattá vált főleg nagy projektekben hogy az alkalmazás összeállítását erre a feladatra dedikált emberek végzik, akik lehet, hogy részt sem vesznek az egyes komponensek fejlesztésében. Sőt szintén főleg nagy projektek esetén gyakran előfordul, hogy más által fejlesztett és saját fejlesztésű komponensekből állítják össze az alkalmazást. Célszerűtlen lenne emiatt, ha az együttműködést leíró információkat a forráskódban elhelyezett utasítások formájában kellene tárolni, hiszen így a komponens nem maradhatna független a felhasználási környezetétől. Ez éppen a komponensek újrafelhasználhatóságát korlátozná jelentős mértékben. Ezért a Java EE 5.0 előtti verziókban különálló leíróállományokat használtak ezeknek a meta-információknak a leírására. Ezek az állományok az esetek nagy többségében XML formátumúak. Ez jó megoldás abból a szempontból, hogy az egyes komponensekhez a felhasználásuk különböző helyein más-más leíróállományokat készíthetünk. Felmerült azonban egy olyan probléma ezzel kapcsolatban, amely mégis sok kényelmetlenséget szült a fejlesztések során. Nyilvánvaló, hogy mivel a leíróállományokban a komponensekre, a Java nyelven megírt osztályokra, azok metódusaira, attribútumaira hivatkozunk, általában a nevüket használva. Így azonban mégsem válhat függetlenné a forráskódtól a leíró állomány ami egyébként teljesen természetes is viszont kényelmetlen állandóan a két állomány között váltogatva készíteni a leíró állományt, mindemellett sok plusz munkát is jelent. Az integráción dolgozó fejlesztők jobban szerették volna az együttműködési információkat annak a közelében elhelyezni, amire azok ténylegesen is vonatkoznak. Ezért hamar kialakultak olyan eszközök, amelyek a forráskódba ágyazott megjegyzésekben 16

17 speciálisan elhelyezett információk alapján legenerálták a szükséges XML leíróállományokat. Az egyik legelterjedtebb ilyen eszköz lett az XDoclet. Ezzel a megoldással viszont az volt a probléma, hogy az esetlegesen elkövetett jelölésbeli tévesztések miatt így is szükség volt a legenerált XML állományok végignézésére, ellenőrzésére. Ezen kívül a legenerált állományokat kézzel módosítani sem volt célszerű, hiszen a módosítások a következő generálás során megsemmisültek volna pedig erre a leíróállományok véglegesítésekor gyakran szükség lett volna. Erre a Java EE 5 a következő megoldást nyújtja: a leíró meta-információk nagy része már a Java SE 5.0-ban [JSR176] annotációk (Annotations) által kerül tárolásra. Ez nem más, mint egy nyelvi támogatás meta-adatok tárolására a Java nyelvben. Ennek több előnye is van. Egyrészt az adatok azon dolgok közelében kerülnek tárolásra, amire vonatkoznak, ez segíti az átláthatóságot azáltal, hogy a fejlesztő látja azt, amire a meta-információk vonatkoznak. Másrészt mivel nyelvi elem, ezért fordítási időben szintaktikai ellenőrzésen megy át, sőt számos integrált grafikus fejlesztőkörnyezet (IDE) biztosít szerkesztés közbeni szintaxisellenőrzést is. Az annotációk használata nem csak az EJB 3.0 specifikációjának megfelelő beanek fejlesztésében van jelen, hanem annotációkkal definiálhatjuk például a tranzakció-kezelés paramétereit, a biztonsági beállításokat és jogosultságokat, vagy a szolgáltatások névtérben (JNDI) történő megkeresését, regisztrálását. Természetesen ezekben az esetekben is megmaradt az XML leíró állományok használatának, valamint a két módszer kombinálásának lehetősége is. Generikus típusok Jelentős előrelépések történtek továbbá afelé, hogy a sok helyen előforduló, hasonló kódrészletek által elvégzett feladatokat általánosan megvalósítsák, amennyiben erre lehetőség van. Jó példa erre a beanek életciklusának kezelése, amelyhez az EJB 2.1-ben még interfészeket kellett definiálni, illetve azok metódusait implementálni, amelyek kódja mindig azonos sémára épült. Az ilyen funkciók a Java SE 5.0 másik újításának, a generikus típusoknak köszönhetően általánosan implementálva lettek, megszabadítva a fejlesztőt ezek elkészítésének terhétől. Meg kell jegyeznünk, hogy a generikus programozás csak a Java SE korábbi verzióihoz képes újítás, más programozási nyelvekben, mint például a C++, már korábban is létezett. A Java SE 5 implementációja ezeknek a tapasztalataiból merített, és sikerült egy a technológia általános gyermekbetegségeitől mentes megvalósítást kidolgoznia. Fontos szempont az is, hogy az ilyen általános megoldásoknak általában sokkal robusztusabbnak kell lenniük, több szolgáltatást kell tudniuk nyújtani, mint az egyénileg készített implementációk. Ehhez kapcsolódóan jelentős előrelépés figyelhető meg a leggyakrabban alkalmazott stratégiák alapértelmezésként való felhasználásában, valamint a korábbi verziókban szereplő nehezen vagy kényelmetlenül használható megoldások logikusabbá tételében. A mindezeknek köszönhető egyszerűsödést jól példázza az, hogy míg az EJB 2.1-es verziójában 4 6 fájl volt szükséges egy entitás bean leírásához (1 entitás osztály, 2 4 interfész és egy leíró XML állomány), addig az EJB 3.0 specifikációit követve mindez egyetlen Java osztályban megtehető az annotációk használatával. A régi rendszerekkel való kompatibilitás megőrzése érdekében pedig megmaradt az XML leíró állományok használatának lehetősége, valamint a korábbi entitás-életciklust vezérlő interfészek emulálása vagy használata is módunkban áll. Ennek köszönhetően a 2.1-es EJB specifikációnak megfelelő beanek gond nélkül igénybe tudják venni a 3.0-ás specifikáció alapján készített beanek szolgáltatásait, és fordítva. 17

18 A perzisztencia kezelése Az EJB 3.0 specifikációjában talán a legnagyobb áttörés az entitások perzisztenciájának kezelésében történt. Az EJB 2.1-ben elsősorban más kiforrott módszerek hiányában a perzisztencia kezelése teljesen a felhasználóra volt bízva [7]. Erre a specifikáció csak keretet biztosított. A legelterjedtebb gyakorlatok szerint ez úgy történt, hogy az entitás betöltésekor és eltárolásakor lefutó metódusok SQL kéréseket futtattak egy adatbázisban JDBC-n keresztül, így tárolták el az entitás objektum attribútumainak értékeit az adatbázisban. Ez a módszer is rendkívül sematikus volt, ennek megfelelően hamarosan megjelentek olyan eszközök, amelyek grafikus varázslókon keresztül legenerálták ezeket a kódokat. A kódgenerálással kapcsolatos aggályainkat pedig már a meta-információkról szóló részben kifejtettük. A Java EE 5 megoldása erre a problémára az ún. Container Managed Persistence (CMP) bevezetése [8], amellyel a következőképpen dolgozhatunk: Annotációkkal definiáljuk, hogy az entitás beanek egyes attribútumait milyen stratégia szerint szeretnénk tárolni, például milyen adattípusként akarjuk kezelni a bennük tárolt értékeket. Ezek a beállítások természetesen amennyire lehet, automatikusak, tehát például az adattípusokat a rendszer többnyire a forráskódból deríti ki, a fejlesztőnek csak a kétes esetekben például dátumok kezelésénél kell specifikálnia a beállításokat. Az applikáció szerveren ezután egy perzisztencia- vagy entitásmenedzser (persistence manager) az annotációkban definiált beállításoknak megfelelően elvégzi az entitás objektumok adatainak eltárolását illetve visszatöltését az alkalmazásszerver és az adatbázis között. Maga az entitásmenedzser egy meghatározott programozói interfészt, konkrétan az EJB 3.0 Persistence API-t követi [JSR220], ennek köszönhetően az egyes entitásmenedzser-megvalósítások az alkalmazásszerveren cserélhetők. Sőt, az alkalmazásszerveren futó különböző alkalmazások egy időben más-más entitásmenedzsert is használhatnak. Léteznek olyan entitásmenedzser implementációk is, amelyek a különböző adatbázis kezelő rendszereket is egységesen tudnak kezelni, ráadásul néhány esetben úgy, hogy még azok speciális lehetőségeit is ki tudják aknázni. Ez biztosítja alkalmazásaink számára a függetlenséget egy-egy adott adatbázis kezelő rendszer használatától, illetve annak gyártójától is. Az entitások elérésére, vezérlésére az EJB 3.0 Persistence API-ban definiált EntityManager interfészen keresztül van lehetőségünk - többek között. Ez kínálja fel az entitás-életciklus vezérlési metódusait is, mint például az entitás tartalmának mentése, betöltése, frissítése, vagy az entitás törlése. Emellett természetesen megmaradt az egyéni perzisztencia-kezelés lehetősége is, ezt nevezi az EJB 3.0 specifikációja Bean Managed Persistence-nek (BMP). Szemléletváltozás a komponensek függésében Végül, de nem utolsó sorban ejtsünk szót a technológiai szempontból talán legkomolyabb szemléletváltásról, fejlődésről [8]. Ehhez azt kell tudnunk, hogy Java EE 5.0 előtt a beaneket alkotó osztályoknak és interfészeknek a Java EE platform beépített osztályaiból vagy interfészeiből kellett származniuk. Erre akkor technológiai okok miatt volt szükség. Ez az elkészített beaneket a J2EE platformhoz kötötte, vagyis a forráskódjuk közvetve nem volt újrahasznosítható a J2EE alkalmazások körén kívül, például egy Java SE kliensalkalmazásban, hiszen az ősosztályaik és interfészei itt nem voltak elérhetőek. Ez egyértelmű hiányosság, hiszen a kliens programban is szükségünk lehet például egy lekérdezett entitás attribútumait tároló osztályra, itt azonban az entitás bean már nem lesz 18

19 használható, új osztályt kell létrehoznunk erre a célra. Az említett szituációban ez egy bevált gyakorlat volt a J2EE 1.4-es és azt megelőző verzióiban. Ezeket az objektumokat adathozzáférési objektumoknak (Data Access Object, DAO) hívták [7]. A fenti elveket követő komponenseket az angol terminológiában "corse grained" komponenseknek nevezik, ahol a név a komponensek és a platform közötti szoros függőségre utal. Ezzel szemben a Java EE 5.0 már az ún. "fine grained" komponensek filozófiáját követi, ahol tehát a komponensek csak lazán kötődnek a platformhoz, és nem Java EE környezetben is felhasználhatók [8]. Ezt úgy éri el, hogy nem követeli meg a bean osztályoktól azt, hogy bármilyen beépített osztályból vagy interfészekből származzanak. Ennek megfelelően tehát a bean osztályok egyszerű Java osztályok, vagy ahogyan nevezni szokták: POJO-k (Plain Old Java Object). Az osztályokban a bean típusát és az ehhez szükséges további információkat is annotációkban adhatjuk meg. Ezt Java technológiák idő közben megvalósult fejlődése tette lehetővé, melynek köszönhetően a lefordított Java osztályok működése lépésenként lejátszható. Ezáltal feleslegessé váltak a korábban ismertetett DAO-khoz hasonló megoldások, hiszen például az entitások esetében az entitás osztály egy példánya könnyedén hordozhatja az entitás információit a Java SE kliensalkalmazás felé Első réteg: az adatmodell Az adatok perzisztens módon való tárolásának feladata szinte minden alkalmazás fejlesztése során jelen van, hol kisebb, hol nagyobb jelentőséggel. Amennyiben ezek az adatok nagy mennyiségűek, strukturáltak és az alkalmazás szempontjából meghatározóak, akkor célszerű lehet az adattároláshoz erre a célra kifejlesztett rendszereket segítségül hívni ahelyett, hogy magunk implementálnánk ezeket a funkciókat. Amennyiben az adatokat egy vagy több alkalmazás példányai egyszerre, megosztottan használhatják, valamint szükség van az adatok között feltételek alapján történő keresések végrehajtására, akkor erre a legjobb megoldás mindenképpen egy adatbázis kezelő rendszer alkalmazása lehet. Ezek közül is elsősorban kiforrottságuk, piaci elterjedtségük és támogatottságuk miatt a relációs adatbázis kezelő rendszerek Relational Database Management System, RDBMS jöhetnek szóba. Az Oracle Database termékek mellett technológiai vezető pozíciójuk, valamint az Egyetemen hozzáférhető támogatottsága miatt döntöttünk valamint részben azért is, mert a Számítógéplabor VI. tárgy keretein belül is ennek a használatával ismerkednek meg a hallgatók. Az Oracle adatbázis kezelő termékei az SQL szabványaival kompatibilisek, így például Java platformon a megfelelő Java Database Connectivity (JDBC) driver segítségével végrehajthatunk SQL utasításokat az adatbázisban. Ennek a kliens oldali megoldásnak a legnagyobb hátránya éppen abban rejlik, hogy az adatok kinyerésére vagy módosítására szolgáló utasítást a kliens oldalon rakja össze a program, sokszor a felhasználói felületen meghatározott feltételek alapján. Ezeken a hátrányosságokon az általános relációs adatbázis kezelő driverek mint például a JDBC valamelyest képesek segíteni, például előre fordított SQL utasítások és paraméter behelyettesítés használatával, de a hatékony fejlesztés még így is nagyfokú kódolási fegyelmet kívánna meg. Ezen kényelmetlenségek miatt már a technológia választás elején elhatároztuk, hogy ezt a szemléletet biztosan nem fogjuk követni Tárolt eljárások Nem csak a fent említett problémákra nyújtanak megoldást a tárolt eljárások, hanem teljesítmény szempontjából is komoly előrelépést hoznak a kliens oldali feldolgozáshoz 19

20 képest. A mögötte álló filozófia abból áll, hogy az adatbázis kezelők SQL nyelvi támogatását ami egyértelműen deklaratív kiegészítik procedurális végrehajtási lehetőségekkel. Ezeket általában az adatbázis kezelő rendszer saját gyártóspecifikus procedurális nyelvén vehetjük, amelybe SQL utasításokat ágyazhatunk. Az Oracle Database termékekben ez a nyelv a PL/SQL nevet viseli, ahol a PL a Procedural Language rövidítése, ez is utal a nyelv procedurális jellegére. A tárolt eljárás, vagy angol nevén stored procedure (SP) tulajdonképpen nem más, mint SQL valamint procedurális vezérlési és adatfeldolgozási utasítások szekvenciája, amit egy paraméteres eljárásba szervezzük, és az adatbázis szerveren tárolódik értelmezett, lefordított formában. Ezt a névvel ellátott eljárást aztán kliens oldalról akár SQL utasításból meg lehet hívni, át lehet adni neki a megfelelő paramétereket, és a rendszer végrehajtja az eljárásban tárolt utasításokat. Két dolgot fontos itt kiemelni, amik a jelentős teljesítménynövekedést biztosítják: 1. Egyrészt azt, hogy futásidőben a parancs értelmezése a korábban bemutatott kliens oldali szemlélethez képest itt csak töredéknyi erőforrást igényel, hiszen csak az eljárás nevét és paramétereit kell azonosítani szemben az SQL utasítások teljesítményigényes fordításával. Ebben az esetben ez a fordítás csak egyszer, a tárolt eljárás elkészítésekor történik meg, nem pedig futási időben minden híváskor. 2. Másrészt, ha a tárolt eljárás bonyolultabb műveleteket végez, például adatlekérdezések alapján adatmódosító parancsokat hajt végre, akkor a helyben történő végrehajtásnak köszönhetően az adatok nem kerülnek átvitelre a hálózaton, szemben a kliens oldali esettel. Ez a hálózat áteresztő képessége és késleltetése, valamint a hálózati forgalom járulékos adminisztrációs feladatai miatt jelentős teljesítménynövekedést is okozhat a kliens oldali feldolgozáshoz képest. A fent felsorolt pozitívumai miatt felmerült, hogy tárolt eljárásokat vezessünk be a sémába. Ezt a megfontolást erősítette bennünk az is, hogy így az üzleti logikát függetleníteni tudtuk volna az alkalmazás megvalósításától azáltal, hogy az üzleti logika funkcióit tárolt eljárások segítségével a szerver oldalon valósítjuk meg. Sőt még a különböző technológiák (pl.: PHP, JSP, Java) vegyítésére is lehetőséget nyitott ez a megoldás. Mindemellett volt már gyakorlatunk az Oracle adatbázis kezelő rendszerek használatában és adminisztrációjában, valamint a PL/SQL nyelv programozásában Object-Relational Mapping A szóba jöhető technológiák után kutatva merült fel egy merőben új technológia, az ún. Object-Relational Mapping (ORM) használatának lehetősége is, először akkor, amikor már egyre inkább a Java alapú technológiák felé fordultunk. Maga a technológia egy konkrét, Java alapú implementáción, a Hibernate-en keresztül került a figyelmünkbe. ORM technológia használata azt jelenti, hogy az alkalmazásunkban használt perzisztens objektumok osztályhierarchiáját egy relációs sémához kötjük. Ezzel tulajdonképpen egy kétirányú transzformációt definiálunk az adatmodell objektum-orientált és relációs ábrázolása között. A transzformáció definiálására azért van szükség, mert önmagában véve az objektum-orientált és a relációs adatábrázolási modellek közötti átjárás közel sem egyértelmű. Egyrészt különböző stratégiák állhatnak rendelkezésünkre speciális problémakörök kezelésére (ilyen például az öröklés), másrészt a két rendszer konkrét implementációjától függő eltéréseket is kezelni kell például az adattípusok összeegyeztetését. Ezekre természetesen a rendszerbe beépített sémák állnak rendelkezésünkre, nekünk csak ki kell választanunk a konkrét esetekhez a legjobban illeszkedőt. Miután a transzformációt sikeresen definiáltuk a rendszer ezen információk alapján már automatikusan végzi el a perzisztencia kezelését, amibe legszűkebb körben beletartozik az objektum állapotának mentést (perzisztálás) és annak az 20