Korszerű webes architektúrák hatékonyság-vizsgálata

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék Börcsök József Korszerű webes architektúrák hatékonyság-vizsgálata Diplomaterv Konzulensek: Balogh András Cserép János Budapest, 2006.

2 Hallgatói nyilatkozat Alulírott Börcsök József, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segédeszközök nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból vettem, egyértelműen a forrás megadásával megjelöltem. Börcsök József i

3 Összefoglalás Napjaink informatikai rendszerei között jelentős a webes alkalmazások szerepe. Ezek tervezése során fontos a modellezés, mivel lehetővé teszi a fejlesztőcsapat tagjai közötti együttműködést, tesztesetek előállítását valamint forráskód-részletek generálását is. Már a fejlesztőrendszerek is támogatják az UML nyelv használatát, viszont az alkalmazások és modellek között csak az egyszerű esetekben teremtenek kapcsolatot. A korszerű rendszerek szabványos megoldásokat használnak, tervezési mintákra épülnek és bevált gyakorlatok segítik a megvalósításokat. Két jelentős csoportjuk: a J2EE és a.net rendszerek. Ez a dolgozat néhány példán keresztül a J2EE rendszerek lehetőségeit vizsgálja és összehasonlítja az alternatív megoldásokat. A J2EE egy szabványgyűjtemény neve, mely az egyes logikai rétegekban használható API-kat tartalmaz. A web réteg JSF technológiája még nem eléggé kiforrott, a többféle megvalósítás és kiterjesztés miatt az implementációk gyakran nem működnek együtt. Az alternatív megoldások alacsonyobb szintű szabványokra építenek, és a fejlesztők számára áttekinthető, egyszerű használatot biztosítanak. A nagy gyártók alkalmazásszerverei támogatják az EJB 2 használatát az üzleti logika rétegben, a nem szabványos helyeken egyedi megoldásokat alkalmazva. Néhány keretrendszer (kevesebb funkcióval) egyszerűbben használható, így a fejlesztők az egyszerű rendszerekhez inkább ezeket használják. A Hibernate az adatkezelést, a Spring az üzleti logikát könnyíti meg. Az EJB 3 szabvány az alacsonyabb verziókkal való kompatibilitás megtartása mellett tartalmazza az előző egyszerűsítéseket. Ez a fejlesztők számára áttekinthetőbb és kevesebb forráskódot, könnyebb tesztelhetőséget, gyártók közötti könnyebb választást és újrafelhasználható komponenseket jelent. A gyártók együttműködő termékeket szállíthatnak, melyeket üzemeltetni is egyszerűbb, így megbízhatóbb szolgáltatás nyújtható. A diplomamunka egy konkrét feladat a kollégiumi rendszer újratervezéséhez és újraimplementálásához használható technológiai lehetőségek feltérképezésével kezdődött, és ezen lehetőségek mintaprojekten történő kipróbálásába torkollott. A konklúzió pedig a technológiák különböző szempontok szerinti értékelése.

4 Abstract Today, web applications are very important in information technology. Modeling is important at design time because it allows developers to collaborate, create test cases and generate parts of source code. Leading integrated developer environments contains support for UML, but they can bind application and model only in the most simply way. Modern systems are built on standard solutions, design patterns and best practises. J2EE and.net are the most well-known platforms for enterprise web applications. J2EE contains APIs that can be used in logical tiers and can be implemented in many ways. This work introduces these technologies and compares alternative standards and frameworks. JavaServer Faces inside web tier is just a half-baked standard because many implementations and extensions exist but all of them cannot co-operate. Alternatives like Wicket os Tapestry based on lower standards have simpler life-cyle and provide stuctured interface. Application servers support EJB 2 in business tier and extend it with custom solution in not strict points. There are frameworks having less services, which can be used easier so developers prefer to use them for simple applications. Hibernate simplifies persistence management and Spring simplifies business logic (in web tier). The focus of EJB 3 is ease of the development with keeping down compatibility. Less source code and manufacturer-specific element, easier testing, possibility of change application server, recyclable components are important for developerts. Manufacturers can ship co-operating products and with easier operation the quality of service is better. In that case a usable industry standard based on the older version is created from some widely-used lightweight frameworks. This work has been started to chart technologies that can be used in the redesigning and reimplementing a community portal. These facilities are demonstrated in a sample application. The conclusion contains an evaluation of the technologies in several aspects.

5 Tartalomjegyzék Összefoglalás Abstract ii iii 1. Bevezető Áttekintés Modellezési lehetőségek UML modellek Egyéb lehetőségek Webes rendszerek áttekintése Történelmi összefoglalás Korszerű technológiák áttekintése J2EE rendszerek bemutatása J2EE architektúra J2EE technológiák Az üzleti logika megvalósításai Megjelenítési réteg Fejlesztői környezetek Esettanulmányok A Kollégiumi Információs Rendszer bemutatása Új igények, könnyítések Médiatár MatekLap StarOffice iv

6 6. A vizsgált rendszerek modelljei és megvalósításai Modellek A rendszerek architektúrája A logikai rétegek és keretrendszerek együttműködése Néhány példamodul Egy modul megírásának lépései A rendszerek értékelése és összehasonlítása Üzleti réteg Megjelenítési réteg Összehasonlítás fejlesztői oldalról Lehetőségek tesztelésre Teljesítmény viszonyok Összefoglalás 90 Irodalomjegyzék 94 A. Fogalmak, rövidítések 97 B. Telepítési útmutató 101 C. UML diagrammok 107 D. Forráskód részletek 110 D.1. Hibernate, Spring D.2. JavaServer Faces példák E. Képernyőképek 116

7 Ábrák jegyzéke 2.1. UML használati esetek UML aktivitás diagramm: fórum hozzászólás Fórumok UML osztálydiagrammja UML hozzászólás helyes lefutás szekvencia Háromrétegű alkalmazás J2EE architektúra Hibernate + Spring EJB 2 és EJB Model 2 architektúra Egyszerű JSF felület Pillanatnyi időt megjelenítő portlet Képek a Kollégiumi Információs Rendszerről A KIR felépítése A KIR könyvtárai Médiatár főbb használati esetei VIR szerepek VIR használati esetek áttekintése Alkalmazászerverek terhelés-kiegyenlítéssel EJB egyszerű web modul interfésszel EJB portál interfésszel Erőforrások a szerveren Példa: hírek szerkesztése Példa: szavazás szerkesztése Példa: szavazógép; virtuális formok Java Studio Creator 2-ben vi

8 6.11. Realm létrehozása Glassfish alatt (3. eset) Java Objektum metódusok felüldefiniálása A Cactus junit segédeszköz eredménye jwebunit tesztelés Egy elosztott mérés kimenete C.1. A VIR domain modellje C.2. Szavazás és örökített entitások VIR-ben C.3. Médiatár anyagok adminisztrációja C.4. Médiatár felhasználó-menedzsment PIM E.1. Kollégiumi Információs Rendszer E.2. Kollégiumi Információs Rendszer változtatható külsővel E.3. MatekLap a J2EE megvalósítás nyitóoldala E.4. Alkalmazásszerver monitorozása: jconsole E.5. StarOffice 8 egy leíró oldal E.6. StarOffice 8 honlap szövegek szerkesztése

9 Táblázatok jegyzéke 3.1. Webes technológiák összehasonlítása Üzleti logikához felhasznált osztályok, interfészek A KIR forrása Üzleti rétegek összehasonlítása JSF implementációk jellemzői EJB2.1 és EJB3 mérőszámok Megjelenítő rendszerek mérőszámai a példára Fejlesztőkörnyezetek áttekintése viii

10 Forráskódok jegyzéke 4.1 Minta servlet Minta JSP Egy web modul könyvtárszerkezete Absztrakt menedzser ősosztályának részei EJB 2.1 saveorupdate példa EJB 3 saveorupdate példa Hírek lekérdezése belépett felhasználóhoz EJB 3 teszteset B.1 Az appserv-cmp.jar módosítása B.2 A.tpsersistence.properties file tartalma D.1 Minta egy felhasználót reprezentáló (JavaBean) osztályra D.2 Felhasználó objektum-relációs leképzése D.3 Spring bean-ek megadása D.4 JSF backing bean D.5 JSF JSP file az előző példához ix

11 Köszönetnyilvánítás Ezúton is szeretnék köszönetet mondani mindazoknak, akik segítségükkel és tanácsaikkal megkönnyítették számomra a dolgozat elkészítését. Külön szeretném kiemelni Cserép János (Sun Microsystems Magyarország) konzulensemet, aki a feladat javaslata után a legújabb lehetőségekről is folyamatosan tájékoztatott és Balogh András (BME, Méréstechnika és Információs Rendszerek Tanszék) konzulensemet, aki a modellezéssel kapcsolatos részekben segített. Továbbá köszönöm Kis Gábornak a felhasználói véleményeket és Csorvási Ágnesnek a megfogalmazási hibák javítását. x

12 1. Bevezető Napjaink informatikai rendszerei között jelentős szerepet töltenek be a webes alkalmazások. Fő alkalmazási területei az elektronikus kereskedelem (e-commerce) és elektronikus üzleti működés (e-business). Az első csoportba sorolhatók a webáruházak és ügyfél kapcsolattartó rendszerek (CRM), a másodikba pedig business-2-business (B2B), belső ügyviteli és egyéb nyilvántartó alkalmazások tartoznak. Ezeknek a rendszereknek több, a hagyományos alkalmazásokra nem jellemző tulajdonsága van. Egy alkalmazásnak sok felhasználót kell kiszolgálni azonos időben (másodpercenként akár néhány 100 vagy 1000 kérés is érkezhet) és a kérések eltérő platformokról érkezhetnek (több operációs rendszer, több böngésző, mobil eszközök). Az elérhető funkciók halmaza is gyakran változik (újak jelennek meg vagy átalakulnak). A web használatának több előnye is van ezekben az esetekben. A kliensek platformfüggetlen módon szolgálhatók ki 1, a használathoz csak egy böngésző telepítése szükséges és a nyílt szabványoknak köszönhetően könnyű az együttműködés a rendszerek között és kiszolgálás irányában is. Mivel az alkalmazás egy központi helyen fut, ezért egyszerű annak üzemeltetése, (távoli) adminisztrálása, frissítése, hasonló tesztkörnyezet kialakítása. Néhány esetben viszont nem ajánlott a web használata, például időkritikus működés, biztonsággal kapcsolatos szigorú előírások, lokális erőforrások kezelése, erős grafikai támogatás esetén. Az infrastruktúra kialakítása is nagyon fontos: a hagyományos asztali alkalmazásokkal szemben itt a kliensek egyszerűbbek is lehetnek, viszont a szervernek nagyobb a terheltsége, valamint a közöttük fennálló, gyors hálózat is fontos. A rendszerek több platformon is megvalósíthatók. Az első dinamikus technológiák (pl. CGI) a mai szolgáltatásokra jellemző felhasználói profil mellett nem használják hatékonyan az erőforrásokat, ezért helyettük hatékonyabb megoldások születtek. Ezek a fejlesztők munkáját is megkönnyítették és könnyebb együttműködést is lehetővé tettek. Így váltak a kezdetben szövegfeldolgozásra használt script nyelvek (Perl, PHP) webes rendszerek megvalósítására alkalmassá. A J2EE és.net platformok lehetővé teszik 1 néhány kliens oldali akciókezelésben gazdag, pl. JavaScriptet használó alkalmazásnál ez nehézségekbe ütközhet 1

13 1.1. Áttekintés 2 tervezési minták és újrafelhasználható komponensek alkalmazását, és a szerver oldali erőforrás-kezelést is hatékonyságabban valósítják meg az előző módszereknél. Kezdetben a fejlesztők feladata volt a teljes alkalmazás megvalósítása, ma már ez a szükséges ismeretek szerint külön szerepekre bontható. Ennek megfelelően külön személyek fejleszthetik az alkalmazás funkcionális részét, a megjelenítést, a formázást (HTML, CSS) és a tartalommal feltöltést. Az egyes részek elválasztásában fontos szerepet játszik a modellezés, valamint az ennek megfelelő (automatikusan generált vagy módszertanokat követve megírt) forráskód előállítás Áttekintés A 2. fejezet az alkalmazások modellezését tekinti át, részletesebben megvizsgálva az UML modellek legfontosabb fajtáit, valamint egyéb modellezési lehetőségeket említ. Ezt követően a webes rendszerek történetét és jelenleg használt megoldásokat ismerteti a 3. fejezet, a a 4. fejezet pedig J2EE szabványokat és keretrendszereket mutat be. Ezek közül a legfontosabbak: EJB 2, EJB 3, Hibernate, Spring, a megjelenítő rétegből pedig a JavaServer Faces. Az 5. fejezet a későbbi összehasonlítások alapjául szolgáló rendszereket funkcióit mutatja be: a Kollégiumi Információs Rendszert, az előző (PHP alapú) rendszer legnagyobb hátrányait, egy matematikával foglalkozó portált (MatekLap) és a StarOffice 8 honlapját. Ezután néhány példán keresztül a rendszerek elkészítése során tapasztaltakat foglalja össze a 6. fejezet, a modellezésre, architektúrával kapcsolatos döntésekre, különböző felhasznált keretrendszerek és szabványok együttműködésére is kitérve. A 7. fejezet több szempont szerint hasonlítja össze a megoldásokat.

14 2. Modellezési lehetőségek Az első webes alkalmazások statikus oldalak voltak, melyeket hamarosan kiegészítettek dinamikus tartalom előállítására alkalmas megoldások. Ezeknek nagy részére jellemző volt, hogy a kimenetet egyszerű kiírás formájában állították elő, legtöbbször valamilyen külső file formázásával vagy adatbázis eredmények alapján. Később újabb felhasználói igények jelentek meg, például authentikáció, tranzakció-kezelés, hibakezelés, melyek az előző rendszerek továbbfejlesztésével egyre áttekinthetetlenebbé tették az alkalmazást. Így egyre szükségesebbé vált egyrészt az alkalmazások működésének modellezése, másrészt ezen modelleken először összetettebb megoldások gyűjteményének, később pedig tervezési mintáknak és komponenseknek az elkészítése, melyekkel az előző feladatok áttekinthetően megoldhatók. Egy webes alkalmazáshoz többféle modell készíthető, például adatstruktúra, általános felépítés, részrendszerek viszonya, felhasználói viselkedés és navigáció. Ezek egy része általánosan leírható, nem szükséges kihasználnunk a webre jellemző egyéni vonásokat, így más esetekben bevált minták és eszközök használhatók (legfeljebb néhány megkötést kell tenni), más részéhez egyéni modell megalkotása szükséges. A modellek egy része a szabványos UML 1 használatával elkészíthető, melyekhez a modern fejlesztőeszközök egyre nagyobb támogatást biztosítanak. A modell elkészítése nem csak az áttekinthetőséget növeli, hanem lehetőséget biztosít egyszerű forráskód esetén nehezen vagy egyáltalán nem elvégezhető műveletekre, például a következőre is: hiba nyomonkövetése be- és kimeneti értékek modellhez történő kapcsolása validáció és verifikáció 2 1 Unified Modelling Language, Általános Modellező Nyelv 2 annak vizsgálata, hogy jól programoztuk-e le a kívánt funkciókat, illetve a funkciók valóban a specifikációban szereplő követelményeket teljesítik 3

15 2.1. UML modellek 4 a funkcionálisan eltérő (például megjelenítő és üzleti logika) részek elkülönítése forráskód generálás deklaratív jogosultságkezelés kódtranszformáció (refactoring) A modellezéssel együtt megnőtt az objektum-orientált gondolkodás szerepe is az előzőleg elterjedt funkcionális gondolkodással szemben, mivel ezek a modellekhez közelebb állnak, könnyebb a helyességet ellenőrizni és magasabb szintű tervezési minták alkalmazását teszik lehetővé UML modellek A platformfüggetlen modell (Platform Independent Model, PIM) az alkalmazás általános felépítését és feladatait képes ábrázolni, a nyelvi megvalósítástól ez áll a legtávolabb. Leggyakrabban a következő elemeket tartalmazza: a rendszer felhasználói (szerepek) a rendszer használati esetei (use case-ek) adat (entity) osztályok vezérlő (control) osztályok határoló (boundary) osztályok dinamikus működés sorrendjének ábrázolása (szekvencia diagramm) állapotok változása (például felhasználói felület akciói) navigáció A platformfüggetlen modell sok olyan összefüggést is tartalmaz, mely később a kiválasztott platformon megvalósítva esetleg csak bonyolultabb módon adható meg. Ilyen

16 2.1. UML modellek 5 lehet néhány kényszerfeltétel (Object Contraint Language, OCL), mely az UML modell statikus (például egy objektum mezői közötti összefüggések, számosságok) és dinamikus (például egy metódus hívása előtti és utáni összefüggés) jellemzőit is leírhatja. Ezek a forráskódban sok esetben csak több soros, néha többfelé szétszórtan szerepelnek (például adatbázis kényszerek, beviteli mezők hibaellenőrzése, feldolgozást megelőző hibaellenőrzés). Ennek megfelelően a PIM néhány részen az elkészült forrásnál tömörebben írja le a megvalósítandó alkalmazást. A modellvezérelt architektúra szerint (Model Driven Architecture, MDA) a platformfüggetlen modell egy alkalmazás üzleti logika funkcióit és viselkedését a technológia specifikus kódtól elkülönítve tartalmazza, így elválasztva az alkalmazást a technológiáktól, megkönnyítve a platformon belüli és azok közötti együttműködést. A célplatform elemeit is tartalmazó modell a platformspecifikus modell (Platform Specific Model, PSM), melyet előállíthatunk a PIM alapján kézzel vagy modelltranszformációval is. Utóbbi megoldás előnye, hogy a specifikáció alapján akár több platformra is kialakítható, így később a feladatnak megfelelő változatot használhatjuk (például teszteredmények alapján). A PSM segítségével szinkronizálhatjuk a forráskódunkat az UML modellel, így a forráskód változásai is megjelenhetnek a modellben (reverse engineering) és a modell változásai is a forrásban; ezt a ma használt fejlesztőrendszerek egyre nagyobb része teszi lehetővé (IBM Rational Software Architect, Sun Java Studio Enterprise 8, NetBeans 5.5). Az alábbi példa platformfüggetlen modelljének részletei tekinthetők meg a következő részben: A feladat egy egyszerű fórum komponens elkészítése. A fórum nyilvános, azaz bejelentkezés nélkül is megtekinthetők a benne szereplő szövegek.... Egy már létező témához csak a belépett felhasználók szólhatnak hozzá, a saját hozzászólásukat később módosíthatják is. Mások hozzászólását csak az adminisztrátorok módosíthatják, valamint szükség esetén törölhetnek is hozzászólásokat.... A hozzászólásoknak kötelező kitölteni a tárgy, illetve üzenet részét, a megjelenés időpontját a rendszer automatikusan kitölti....

17 2.1. UML modellek ábra. UML használati esetek Használati esetek (use cases) A példában következő szerepek szerepelnek: vendég (User, bejelentkezés nélküli felhasználó), belépett felhasználó (AuthUser) és adminisztrátor (Admin), a diagrammon (2.1. ábra) az ennek megfelelően esetek láthatók. Komplex rendszerek esetén az összetartozó funkciókat (például egy modul vagy részmodul) érdemes egy diagrammon elhelyezni, így biztosítva az áttekinthetőséget Aktivitás és állapot diagrammok Ezeknek a digrammoknak a segítségével írható le a felhasználói interfész és a modell dinamikus működése. A 2.2. ábrán a fórum hozzászólás folyamata látható: az diagramm bal oldalán a felhasználó tevékenységei, a jobb oldalon pedig a rendszer tevékenységei láthatók. Először a felhasználó kiválasztja azt a fórum témát, melyhez hozzá szeretne szólni,

18 2.1. UML modellek ábra. UML aktivitás diagramm: fórum hozzászólás majd vagy új hozzászólást választ ki, vagy egy létező (saját) hozzászólás módosítását kezdeményezi. Ezt követően a rendszer megjeleníti az ehhez szükséges űrlapot, módosítás esetén kitöltve az adatbázisban szereplő adatokkal. A felhasználó elvégzi a változtatásokat, majd a rendszer sikeres validáció esetén frissíti vagy létrehozza a hozzászólást, hiba esetén annak okát is megjelenítve az űrlap előzőleg beírt értékeit állítja vissza. Sikeres művelet esetén a téma hozzászólásai jelennek meg.

19 2.1. UML modellek ábra. Fórumok UML osztálydiagrammja Osztálydiagrammok Az osztálydiagrammokon már megfigyelhető a webes alkalmazásokra jellemző három rétegű architektúra: a perzisztens adatok, az üzleti logika és a felhasználói interfész elkülönítése. A 2.3. ábrán a teljes fórum modul osztálydiagrammja látható. A perzisztens rétegben az osztályok csak adatokat, ezekhet tartozó set és get metódusokat, valamint szinkronizáló (esetleg ellenőrző) részeket tartalmaznak. A középső részen az üzleti logika osztályai láthatók, ebben az esetben a ForumManager, baloldalt pedig a felhasználói interfészt alkotó elemek Szekvencia diagrammok A szekvencia diagrammokkal szintén a dinamikus viselkedés írható le: ezzel ábrázolhatók a rendszer folyamatainak sikeres és sikertelen lefutásai. Ugyanakkor az UML szabvány nem rögzíti, hogy a diagramm egy elvárt, egy lehetséges vagy egy valódi lefu-

20 2.2. Egyéb lehetőségek 9 tást ábrázol-e. Később ezek az esetek a tesztesetek előállításának alapjául is szolgálnak: minden helyes és hibás lefutáshoz érdemes tesztet készíteni, így ellenőrizhető az alkalmazás működésének helyessége. A 2.4. ábra egy fórum hozzászólás fontosabb lépéseit tartalmazza az elvárt lefutás szerint ábra. UML hozzászólás helyes lefutás szekvencia 2.2. Egyéb lehetőségek A webes alkalmazásoknak léteznek más modellezhető elemei is. Ezek közül az egyik legfontosabb a felhasználói viselkedés modellezése. Erre több megoldás is létezik:

21 2.2. Egyéb lehetőségek 10 CBMG: Customer Behavior Model Graph: egy irányított gráf, ahol az oldalaknak a gráf csúcsai felelnek meg, ahonnan a további navigációt az onnan induló élek jelölik a viselkedésnek megfelelően súlyozva CBMS: Customer Behavior Model Statechart: tartalma megegyezik az előző modellel, csak a megjelenítéshez szabványos UML állapottérképet használ CVM: Customer Visit Model: ez a modell különböző típusú felhasználókról tárolja, hogy adott oldalt hányszor látogattak meg, a navigációt nem tartalmazza Az első két modell különböző mérőszámok előállítására is használható, például hányszor töltöttek le egy objektumok, egy oldalt, átlagosan hányszor vesznek igénybe egy szolgáltatást, egy felhasználó átlagosan mennyit navigál a rendszerben. Ezek alapján terhelési előrejelzések is készíthetők, valamint a gráf módosításával optimalizálható a rendszer (például a gyakran keresett tartalom közelebb helyezése a belépési ponthoz). Egy másik modell az alkalmazás UML telepítési diagrammja, melyet néha nyelvfüggő elemekkel is ki lehet egészíteni. Nagy rendszer esetén ez tartalmazza a többrétegű architektúra rétegei és a számítógépek közötti leképzéseket, az egyéb kiegészítő elemeket (például terhelés kiegyenlítő, cache).

22 3. Webes rendszerek áttekintése Ebben a fejezetben a webes rendszerek története, a jelenlegi korszerű rendszerek megemlítése, majd ezek közül a J2EE 1 technológia ismertetése szerepel Történelmi összefoglalás Az első webes anyagok statikus HTML oldalak voltak, melyeket linkek közöttek össze. Ezek hátránya volt, hogy nehéz volt a karbantartásuk és nem lehetett dinamikussá tenni a tartalmat, azaz a felhasználó csak olvasni tudott. Később megjelent az igény arra, hogy dinamikus elemeket tartalmazzanak ezek az oldalak, például időpont, szöveg egy külső file-ból vagy adatbázisból. A kényelmesebb felhasználás miatt ezeken az oldalakon előtérbe került a felhasználói interakció is: dinamikus linkek és űrlapok (HTML beviteli mezők és ezt elküldő gomb) segítségével választhatta ki a látogató az őt érdeklő tartalmat. A legelső dinamikus oldalak HTML-be ágyazott kiegészítések voltak (Server Side Includes, SSI), melyek lehetővé teszik külső parancsok futtatását. Mivel ez kis méretben is struktúrálatlan volt, hamar kiszorították azok a script nyelvek 2, melyek HTML oldalakat állítottak elő. Ezek első változatai minden letöltésnél külön operációs rendszer folyamatot indítottak (például Perl), így nagyobb oldalak hatékony kiszolgálására nem alkalmasak. A PHP 3 már az Apache webszerver szálkezelésével is együttműködik, ahol lehetőség van egyszerű módon kezelni az adatbázis perzisztens kapcsolatokat is, hátránya viszont, hogy a forrás könnyen átláthatatlan bonyolultságúvá vált (főképp, ha HTML oldalakba vannak ágyazva a logikát biztosító részek is). Elterjedésének fő oka, hogy egyszerűen használható és telepíthető a fejlesztő- és futtató környezet is, nem szükséges pontosan érteni a háttérben történő eseményeket. Ebből adódik, hogy nagyon könnyű 1 Java to Enterprise Edition, nagyvállalati Java; az 5-ös verziótól kezdve JEE 5 2 olyan nyelvek, melyeket egy értelmező dolgoz fel valós időben, például Perl, PHP, Python 3 PHP: Hypertext Preprocessor 11

23 3.2. Korszerű technológiák áttekintése 12 PHP J2EE.NET technológia típusa keretrendszer szabvány keretrendszer megvalósítások száma üzleti funkciók nincs szabványos EJB.NET Managed megoldás Components futtatás értelmező lefordított kód lefordított kód nyelv PHP Java C#, Jscript.NET, VB.NET, C++ objektum orientált nem igen igen megjelenítés HTML JSP, JSF ASP, ASPX adatbázis kapcsolódás PHP függvények JDBC ADO.NET nyílt forrású igen igen nem 3.1. táblázat. Webes technológiák összehasonlítása hibás (lassú, struktúrálatlan és nem a specifikációnak megfelelő) oldalakat írni. Másik hátrányos tulajdonság, hogy a PHP továbbra is csak egy scriptnyelv és az objektum orientált szemlélet csak a legújabb (5-ös) verzióban jelent meg. A jelenleg korszerű webes fejlesztéseknek két legfontosabb célplatformja a J2EE és a.net. Ezek lefordított kódot futtatnak és áttekinthető, szabványos struktúrájú alkalmazások elkészítését teszik lehetővé Korszerű technológiák áttekintése Ebben a részben az előbb említett technológiák közül a PHP, J2EE és.net fő jellemzőinek összehasonlítása szerepel, a 3.1. táblázatban szerepelnek kiemelve a legfontosabb szempontok. A J2EE és.net rendszerek sok tekintetben hasonlítanak egymásra, folyamatosan fejlődnek és hatással vannak egymásra. Mindkettőre érvényes, hogy nem csak weboldalak létrehozására alkalmasak, hanem a mögöttük lévő üzleti logika és ehhez eltérő (például natív, applet vagy web szolgáltatás) megjelenítő réteg megvalósítására is. A fő különbségek a következők [15]: J2EE objektum orientált; a Java nyelvet használja; szabvány, melyet több operációs rendszer alatt több gyártó terméke is megvalósíthat, adatbázis-eléréshez JDBC

24 3.2. Korszerű technológiák áttekintése 13 használata.net komponens szemléletű; CodeDOM nyelveket (pl. C, Visual Basic) használja; keretrendszer, mely egyetlen gyártóhoz (Microsoft) kapcsolódik, adatbázis-eléréshez ADO.NET használata Kiegészítések a 3.1. táblázathoz: PHP esetén léteznek külső gyártóktól származő (3 rd party) gyorsítók, viszont ezek használata nem elterjedt és általában a PHP-val szemben nem használhatók ingyen.net esetén az említett nyelveken túl mások is használhatók, jelenleg több, mint 20 nyelv támogatott PHP esetén az adatbázis-spefikikus parancsokat általában egy saját függvénykönyvtár tartalmazza, így az alkalmazás függetleníthető az adatbázis típusától (ez Perl esetén például a DBI modul segítségével valósítható meg); ennek ellenére a perzisztens kapcsolatok kezelése a webszerver (Apache) és a PHP (php.ini) beállításaitól is függ és nehezen szabályozható. Az utóbbi időkben egyre szükségesebbé vált eltérő platformon futó alkalmazások együttműködésének biztosítása. Lehetnek olyan külső szolgáltatások, melyeket egy cég szeretne igénybe venni, viszont annak megvalósítása más platformot használ. Nagyobb cégek esetén ez még házon belül is előfordulhat. A megoldás egy platformfüggetlen kommunikációs megoldás kidolgozása, amit a web szolgáltatások (web services) biztosítanak. A következő részekben a J2EE technológia bemutatása szerepel, majd ezeket felhasználva néhány rendszer tervezése, megvalósítása és az elkészült alkalmazások összehasonlítása. A J2EE választásának okai (.NET-tel szemben): az SCH Account 4 egyes szolgáltatásait J2EE rendszer biztosítja, ezért ezzel a választással egyszerűbb megvalósítani az együttműködést ezek és a később részletesen ismertetett Villanykari Információs Rendszer között (alacsony szinten is) 4 a Schönherz kollégiumban működő címtár szolgáltatás, melynek segítségével a kollégisták igénybe vehetnek különböző szolgáltatásokat, például levelezés, naptár, nyomtatás, távolról elérhető tárhely, Windows terminál

25 3.3. J2EE rendszerek bemutatása 14 az operációs rendszerek és megvalósított rendszerek tekintetében különböző gyártók között választási lehetőséget biztosít 3.3. J2EE rendszerek bemutatása A J2EE szabvány egy API 5 -t definiál üzleti rendszerek elkészítéséhez. Az alapja a J2SE 6, melyet a következő elemekkel egészít ki: feltöltéssel (deployment) kapcsolatos szolgáltatásokkal, ezek XML (vagy a forráskódban elhelyezett annotation 7 ) segítségével definiálhatók perzisztencia (persistence) tranzakciók (transaction) biztonság (security) forráskódban elérhető API szolgáltatásokkal elnevezések használata (JNDI nevek) üzenetküldések lehetőségekkel, melyeket a konténer (az alkalmazás szabványos futtató környezete) automatikusan biztosít életciklus: a használt objektumok életciklusának kezelése többszálúság biztosítása távoli eljáráshívás (például CORBA, RMI) gyártóspecifikus szolgáltatásokkal skálázhatóság hibatűrő működés 5 Application Program Interface, alkalmazás interfész 6 Java to Standard Edition, a hagyományos Java szabvány, az 5-ös verziótól kezdve JSE 5 7 a Java SE 5 szabványban is megjelent, előfordítási direktívák szerepét betöltő nyelvi elemek, formában írandók az elé a nyelvi egység (pl. metódus, változó) elé, melyre vonatkoznak

26 3.3. J2EE rendszerek bemutatása 15 terheléskiegyenlítés A fontosabb szolgáltatásokat a következő szabványok definiálják: Java DataBase Connectivity (JDBC): gyártófüggetlen adatbázis-elérése Java Naming and Directory Interface (JNDI): szolgáltatások, erőforrások gyártófüggetlen elérhetősége JavaMail: szabványos küldés megvalósítása Java Message Service (JMS): üzenetküldés szabványos módon Java Transaction API (JTA): elosztott tranzakciókezelés Java Authentication and Authorization Service (JAAS): egyéni biztonsági rendszer (azonosítás, jogosultság-ellenőrzés) használata web szolgáltatások (web services) elérése Java Management Extensions (JMX): alkalmazás monitorozása időzített futtatások Az alkalmazások elkészítése a következő lépésekből áll: tervezés, forráskód megírása, telepítő leírók (deployment descriptors) létrehozása, csomagolás, összerakás (komponensek), telepítés (deployment). A tervezést a fejlett tervezőeszközök egyre hatékonyabban támogatják (UML), valamint a Java editor mellett lehetőséget biztosítanak a további lépések egyszerűsítésére, a rutinszerű feladatok kattintással történő elvégzésére. A helyes működéshez néhány esetben a szerveren különböző erőforrásokat kell létrehozni, például adatbázis, levélküldés, üzenetsorok (Message Queue, MQ). Néhány speciális beállítást a szervereken kézzel kell elvégezni, például az egyedi authetikáció lehetőségét (Realm létrehozása). Ha ezen lépések során nem történik hiba, akkor már elérhető az alkalmazás, egyébként pedig a konzolon (vagy log file-ban) lehet tájékozódni a hiba okáról. A J2EE rendszerek jó tulajdonsága még, hogy azonos szerverek között könnyen hordozhatók (az előző lépéseket egy másik szerveren is megismerhetjük és ezután ugyanazt

27 3.4. J2EE architektúra 16 az eredményt kapjuk), mivel a jól megírt alkalmazások nem érzékenyek a szerver alapértelmezett beállításaira (mint például PHP esetén a változók automatikus regisztrálása: register_globals) J2EE architektúra A J2EE rendszerek a háromrétegű architektúrára épülnek és jól skálázhatók. Több gépből álló felépítés esetén az egyes szerverek a teljes kiszolgálási folyamatnak csak egy-egy részfeladatát végzik el, kevesebb gép esetén egy gép több réteget is futtathat. A következő fő szakaszok különböztethetők meg: web szerver biztosítja a statikus tartalmak kiszolgálását, itt a file-műveletek a jellemzők (HTML, kép, videó, hang kérések kiszolgálása) alkalmazás szerver a feldolgozást igénylő kérések kiszolgálását végzi, itt található az üzleti logika is adatbázis szerver az adatbázisokat kezeli és kiszolgálja az SQL kéréseket 3.1. ábra. Háromrétegű alkalmazás Több területen a webes alkalmazások veszik át az eddigi natív alkalmazások szerepét is (a hálózat-hozzáférés olcsó, az alkalmazás egy központi gépen fut, melyet így nem kell kliensenként frissíteni, könnyen bővíthető, a felhasználói felület egy weboldal, amit egyszerű megismerni). Ennek kialakítása nagyobb sávszélességet, erősebb központi erőforrást és infrastruktúrát igényel. Leginkább olyan alkalmazások esetén használható, mely nem igényel bonyolult felhasználói felületet (pl. grafika vagy 3D-s alkalmazások esetén alkalmatlan), és ahol a webes azonosítás és a HTTP protokollból adódó

28 3.4. J2EE architektúra 17 független kérések mellett az azonosságot biztosító session kezelés elegendő (például hadiiparban ez sok esetben nem elég). A kérések kiszolgálása során a felhasználók a böngészőn megjelenő webes felületet használják. Az kéréseket küld a web szervernek, mely a statikus tartalmat kiszolgálja, a dinamikus kéréseket pedig az alkalmazásszervernek továbbítja. Az alkalmazásszerver elvégzi a számításokat és ha szükséges, akkor az adatbázis szerveren végrehajtja a lekérdező vagy módosító SQL kéréseket. A végrehajtást követően a felhasználó visszakapja az eredményeket ábra. J2EE architektúra Mindhárom rétegben azonosítás és hozzáférés-ellenőrzés végezhető. A rétegek között tűzfal helyezhető el, így biztosítva, hogy a belső (fontosabb) részekhez kívülről nehezebb legyen hozzáférni. A 3.2. ábrán egy ilyen rendszer architektúrája látható. Látható, hogy többféle kliensen (web böngésző, mobil eszközök, web szolgáltatások) keresztül is elérhetők a szolgáltatások.

29 3.4. J2EE architektúra 18 J2EE esetén a web konténer látja el a statikus és az egyszerű dinamikus kérések (servlet, JSP; ezek általában csak az üzleti logika hívásokat és a megjelenítő logikát tartalmazzák) kiszolgálását, az EJB konténer pedig az üzleti logikát tartalmazza. Lehetőség van arra is, hogy ezek ne külön gépen fussanak, például az alkalmazásszerver mindkét típusú konténert tartalmazhat és azonos gépen futhat még adatbázis is.

30 4. J2EE technológiák Ebben a részben néhány szabványos J2EE megoldásról és ezeket megelőző, illetve kiegészítő keretrendszerről lesz szó Az üzleti logika megvalósításai Ebben a részben az adatok tárolását és az alkalmazás funkcióit tartalmazó réteg kerül bemutatásra. Először egy egyszerű megoldás szerepel, mely kevés kiegészítő funkcionalitás mellett egyszerűen alkalmazható, majd az elterjedt EJB 2.1, végül az elfogadás előtt álló EJB 3 szabvány következik Egy könnyűsúlyú megvalósítás: Hibernate + Spring A könnyűsúlyú megoldás elnevezés azért használható, mert az alkalmazás futtatásához ebben az esetben nem szükséges alkalmazásszerver, elég csupán egy web konténer. Ennek egy áttekinthetőbb módja az előbb említett két rendszer alkalmazása: a Hibernate biztosítja a perzisztencia-kezelést, a Spring pedig az üzleti funkciók megírását egyszerűsíti. Hibernate A platformfüggetlen modellben szereplő domain modell segítségével lehetőség van az adatok perzisztens kezelését objektum-orientáltan megvalósítani: az adatbázis táblákon végrehajtott SQL lekérdezések és adatmódosítások lecserélhetők objektumokon végrehajtott műveletekre, ennek a neve objektum-relációs leképzés (Object-Relational Mapping, ORM). Ehhez meg kell adni, hogy milyen osztályokat milyen táblákra (és azok mely attribútumait mely mezőkre) kell leképezni. Ezt követően a Hibernate elvégzi a szükséges műveleteket: egy objektum létrehozását követően a saveorupdate 19

31 4.1. Az üzleti logika megvalósításai ábra. Hibernate + Spring metódus hívása elmenti a módosításokat, a delete metódus hívása törli az automatikusan leképzett rekordot. Hasonlóan, objektumokra és azok tulajdonságaira hivatkozva lehet keresni az adatok között. A D.1. és a D.2. források egy felhasználót tároló osztályt és ennek adatbázisra történő leképzését adják meg. A Spring beépített támogatást tartalmaz a Hibernate-hez, így az üzleti logika leíróiban megadhatók az adatbázis paraméterei, valamint könnyen kérhető adatbázis session, mely a tranzakciókezelést is tartalmazza. Érvényes session mellett könnyen elkészíthető az adatelérési réteg (Data Access Objects, DAOs), mely egyszerű adatbázis-műveleteknek megfelelő metódusokat használ (saveorupdate, delete, find, load). Ugyanitt (anonim osztályok segítségével) bonyolultabb lekérdező parancsok is végezhetők (execute), például szűrés egy hash-ben levő értékek egyenlőség-vizsgálata alapján, eredménye méretének korlátozása, ebben lapozás. A Hibernate új változatai illeszkednek az EJB 3 szabványhoz, annak végleges megjelenését követően így nincs annak sem akadálya, hogy az alkalmazásszerver perzisztenciakezelő rétegét a Hibernate változatra cseréljük ki, így elérve néhány, a szabványban nem szereplő kiegészítést (például filter).

32 4.1. Az üzleti logika megvalósításai 21 Spring A Spring egy olyan moduláris keretrendszer, mely segítségével az üzleti objektumainkat lehet kezelni és egyszerűen tesztelni. A moduljai közül lehetőség van csak néhánynak a használatára is. A forráskódban osztályok helyett interfészekre érdemes hivatkozni, így biztosítva a konkrét megvalósításoktól és a keretrendszertől való függetlenséget. Az üzleti logikát egyszerű POJO (plain old java object) használatával tudjuk megírni és az alkalmazás környezet (application context) egyetlen sor beállításával el tudjuk végezni, így egyszerűen megvalósítható a tesztelés (például junit tesztek) is. A Spring beépített támogatást tartalmaz a legelterjedtebb objektum-relációs leképzést biztosító keretrendszerekhez is (Hibernate, Toplink, JDO). Az üzleti logikát megvalósító objektumok esetén Singleton és Prototype beállításokat alkalmazhatunk. A konfigurációkat többféle formátumból be tudja olvasni, ezek közül a két legelterjedtebb: az XML és az egyszerű.properties file-ok használata. A függőségek kezelése deklaratív módon, például XML-ben leírva történik, így elkerülhető az EJB-k esetén használt JNDI, aminek van néhány jól kihasználható tulajdonsága (nem szükséges a futtatókörnyezet JNDI neveit ismerni, erős típusosság, tesztelés megkönnyítése). A D.3. forrásban egy Sping konfiguráció váza látható, mely beállítja az adatforrást, a Hibernate használatát, valamint a DAO és menedzser osztályokat Egy szabványos megvalósítás: EJB 2.1 Az EJB (Enterprise JavaBean) a J2EE szabvány részét képezi, a 2.1-es változata (JSR-153, végleges változat: november 24.) a legutolsó, stabil kiadása. Hamarosan megjelenik a 3-as változat, mely lefelé az eddigi rendszerekhez hasonlóan kompatibilis, mellette pedig nagyon sok könnyítést tartalmaz. A 2-es verzió kialakításánál is figyeltek arra, hogy a platformfüggetlen modell alapján egyszerűen előállítható legyen a J2EE alkalmazás (ez általában a szerepekben, osztályokban és telepítésben ki is merül), valamint a kialakult tervezési minták (design patterns) is könnyen alkalmazhatók. Mivel szabványról van szó, ezért a kötelező részeket minden alkalmazásszerver egyformán támogatja (sajnos az opcionális és szabványban nem meghatározott módon szereplő részek gyártónként szinte mind különböznek egy

33 4.1. Az üzleti logika megvalósításai 22 kicsit). Egy már elkészült rendszer migrálása, újrafelhasználása más rendszerben ennek megfelelően nem nehéz feladat: a gyártóspecifikus leírókat kell átalakítani, a többi elem változatlanul használható. A szabványban a következő típusú osztályok különböztethetők meg: entity bean adatok perzisztens tárolásához használható; két típusa van: container managed persistence (CMP) ebben az esetben a leképzést a Hibernatenél említett módon a konténer automatikusan elvégi, a lekérdezésekhez pedig egy szabványos nyelv az EJB-QL használható bean managed persistence (BMP) ekkor az SQL parancsokat az alkalmazás fejlesztőinek kell megírni, így néhány esetben (például bonylult lekérdezések, tárolt eljárások) optimálisabb megoldás kapható a típusellenőrzés és a hordozhatóság rovására session bean az üzleti logika szolgáltatásait tartalmazza, szintén két típusa van: stateless a kérésekkel kapcsolatban nem tárol (temporális) adatokat, így ugyanaz az objektum egymás után több különböző felhasználótól érkező kérést is kiszolgálhat; mivel nem kell állapotokat tárolni, ezért ahol lehet, érdemes ezt használni az erőforrás-felhasználás mértékének csökkentése céljából stateful egy felhasználótól származó kérések között valamilyen adatot tárol, például bevásárlókosár tartalma; mivel sok felhasználó esetén ezeket tárolni kell és nem mindig állapítható meg hatékonyan ezen adatok elavulásának ideje (például a felhasználó nem lép ki, csak bezárja a böngészőjét), ezért csak a legszükségesebb adatokat kell elmenteni; a mentésről és visszatöltésről (passziválás, aktiválás) a konténer gondoskodik message driven bean aszinkron működésű szolgáltatás, mely egy üzenetsorhoz szabványos módon (JMS) kapcsolódik és üzenet érkezése esetén feldolgozza azt; ebben az esetben nincs lehetőség azonnali vissza- vagy hibajelzésre, általában erőforrásigényes vagy lassú műveletek esetén hasznos (például bonyolult lekérdezés előállítása, kiküldése, emberi beavatkozással összefüggő szolgáltatások)

34 4.1. Az üzleti logika megvalósításai 23 A referenciák értékadásához JNDI nevek használata szükséges, a futtatáshoz pedig EJB konténer, melyet az alkalmazásszerverek tartalmaznak. Ez a két leginkább nehézkes része a technológiának (az első a bonylultság, a második pedig a tesztelés megnehezítése miatt). Emellett nem elhanyagolható, hogy ez a verzió csak egyszerű adatmodellek használatát teszi lehetővé (nem tartalmazhat örökítést, nehézkes a leképzés testreszabása más adatbázis sémára) ábra. EJB 2 és EJB 3 A 4.2. ábrán látható, hogy az előző megoldáshoz képest a szabványos, általánosan használható megoldásnak ára van: jóval több elem szükséges hozzá. Az üzleti logika rétegben (UserManagerBean) és a perzisztens rétegben (UserBean) is először JNDI név alapján kérhető referencia a Home objektumokra, azután pedig ezek adján vissza a kért objektumokat (melyeknek üzleti logika esetén általában a távoli interfészben szereplő, entitások esetén a helyi interfészben szereplő metódusai érhetők el). Az alsó két osztályt az alkalmazásszerver generálja, azért szerepel mégis az ábrán, mert több hiba oka ezekben található, például az EJB-QL és a telepítési leírók hibái a forráskódban nem detektálhatók, csak az alkalmazásszerverre történő telepítés után, így érdemes számolni velük. A következő dokumentumok részletesen, sok példával együtt ismertetik a technológiát és annak ajánlott alkalmazását: [2, 10]. A nehézségeket sok esetben elfedik a

35 4.1. Az üzleti logika megvalósításai 24 fejlesztőkörnyezetek lehetőségei és a gazdag irodalom miatt sok hasznos minta (best practises) található A következő szabvány: EJB 3 Az EJB 3 szabvány végleges verziója a nemrég jelent meg 1, mely nagyon sok könnyítést tartalmaz az előző változathoz képest. Visszafelé teljes kompatibilitást biztosít, viszont a nehézkes részek helyett könnyebben alkalmazható lehetőségeket ad. Ilyen könnyítések: nem szükséges XML telepítési leírók használata, ezeket Java annotációk segítségével is meg lehet adni és ebben az esetben a telepítés során legenerálja azt a szerver (így ha nagyon kell, akkor a fejlesztők meg tudják nézni, de az alkalmazás elkészítése során nem kell vele foglalkozni). a Home objektumok és JNDI nevek használata elhagyható, egyszerűen annotációkkal az egyes objektumok megkaphatók a perzisztens réteg nagyon sokat változott: többek között könnyen megadhatók az entitások (egyszerű JavaBean-ek), az adatbázisra történő leképzés, a lekérdezések, a közöttük lévő kapcsolatok, a kulcsok előállítása; lehetőség van leszármaztatott osztályok leképzésére, valamint több relációt érintő lekérdezés egyedi visszatérési értékének objektumra történő leképzésére lehetőség van a perzisztens API-t hagyományos alkalmazásokban is használni, nem szükséges hozzá EJB konténer a DTO tervezési minta kiküszöbölhető szerializált entitás-osztályok használatával a szerepek megadásához és használatához nem kell alkalmazásszerver-specifikus XML-eket írni definiáltható minden metódus hívásakor meghívandó metódus, mely például logolást, ellenőrzést is végezhet 1 JSR-220 néven május 11-én

36 4.2. Megjelenítési réteg 25 Megoldás interfész osztály XML leíró Hibernate, Spring EJB ~2 EJB táblázat. Üzleti logikához felhasznált osztályok, interfészek A 4.2. ábrán megjelölve szerepelnek azok az elemek, melyeket nem kell EJB 3 használata esetén megírni (ugyanakkor a háttérben az alkalmazásszerver ilyenkor is előállíthatja azokat). A 4.1. táblázat összesítve tartalmazza, hogy a három lehetőség során melyik esetben hány osztályt és interfészt és XML leírót kell megírni. EJB 2 esetén az egyik leíró az ejb-jar.xml, a másik pedig alkalmazásszerver specifikus Megjelenítési réteg Servlet J2EE rendszerekben dinamikus oldalak előállítására a legrégebbi lehetőség a servletek használata. A servlet-ek egy web konténerben futnak, ami valójában egy olyan Java virtuális gép (JVM), ami biztosítja a servlet API funkcióit. A servlet példányok olyan HTTP kérésekre válaszoló komponensek, amiket a web konténer kezel. Ebben az esetben a párhuzamos kérések kiszolgálását lehetővé tevő szálkezelésről is a web konténer gondoskodik és ez hatékonyabb, mint külön alkalmazásokat futtatni (CGI), valamint sok kérés esetén a letöltésenkénti újraértelmezésnél is jobb (PHP). Összefoglalva a következő előnyei és hátrányai vannak a servlet használatának: + minden kérés külön szálon fut, így a kiszolgálás gyorsabb, mint a CGI esetén + skálázható: sokkal több kiszolgálás futtatható, mivel a web konténer szálakat és egy osztott memóriateret használ operációs rendszer folyamatok futtatása helyett + objektum orientált, robosztus: a Java nyelv összes lehetősége használható, szemben a CGI és script nyelvek hasonló lehetőségeivel + a Java nyelvből és a servlet API-ból adódóan platformfüggetlen megoldás

37 4.2. Megjelenítési réteg 26 + a web konténer további szolgáltatásokat is tartalmaz, például hibakezelés vagy biztonság - egyedüli alkalmazása nem ajánlott, mivel akkor a többi megoldáshoz hasonlóan összekeveredik az üzleti és megjelenítési logika A servlet-ek olyan Java osztályok példányai, melyek a HttpServlet osztályból származnak, a GET kéréseket a doget, a POST kéréseket a dopost metódusok szolgálják ki, ahogyan az a 4.1. forrásban látható. A web.xml file-ban fel kell venni a hivatkozásokat a servlet-ekre, valamint ugyanott kell megadni azt is, hogy milyen URL mintájú kérésekhez rendeljük hozzá (mapping). Tisztán servlet-eket alkalmazó megjelenítő réteg esetén a Java forráskód tartalmazza a HTML részleteket is, mely lehetetlenné teszi a fejlesztések szerep alapú elválasztását (programozó és designer), valamint a karbantartást is megnehezíti (nehezen átlátható forrás). package hu.bme.vir.servlets; import java.io.*; import java.net.*; import javax.servlet.*; import javax.servlet.http.*; public class ServletExample extends HttpServlet { protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); PrintWriter out = response.getwriter(); out.println("<html><head>"); out.println("<title>servlet ServletExample</title>"); out.println("</head><body>"); out.println("<h1>servlet ServletExample at " + request.getcontextpath () + "</h1>"); out.println("</body></html>"); out.close();

38 4.2. Megjelenítési réteg 27 } protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); } protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { processrequest(request, response); } } public String getservletinfo() { } return "Short description"; 4.1. Minta servlet JSP Hamar megjelent az igény arra, hogy valamilyen jelölő nyelvhez hasonló formában lehessen megadni a megjelenítő részeket a servlet-ekben való kiírással szemben. Erre a szabványos megoldás a JavaServer Pages (JSP) technológia. A JSP valójában egy kifordított servlet: HTML oldalba van ágyazva a Java forrás, ehhez különböző jelölések használhatók, például <% Java forras %> vagy <%=valtozo%> annak értékének kiírásához. Egy példa látható a 4.2. forrásban. Model 1 architektúra esetén a böngésző a JSP oldalakat kéri, mely JavaBean-ek segítségével jeleníti meg mögötte lévő (servlet) logikától származó adatokat. <HTML> <HEAD><TITLE>Example JSP Page</TITLE></HEAD>

39 4.2. Megjelenítési réteg 28 <BODY BGCOLOR="white"> <B>Table of numbers squared:</b> <TABLE BORDER="1" CELLSPACING="0" CELLPADDING="5"> <TR><TH>number</TH><TH>squared</TH></TR> <% for ( int i=0; i<10; i++ ) { %> <TR><TD><%= i %></TD><TD><%= (i * i) %></TD></TR> <% } %> </TABLE> </BODY> </HTML> 4.2. Minta JSP A JSP oldalakat a web konténer első lépésben egyszerű servlet forráskóddá alakítja, majd lefordítja, ezt követően pedig hagyományos servlet-ként futtatja. Használatának előnyei és hátrányai a servletek-ekét kiegészítve: + a megjelenítést tartalmazó részek áttekinthetőbbek a servlet-ben használt megoldásnál + könnyen bővíthető új elemekkel (tag library) - tisztán JSP használatával az üzleti logika kerül a megjelenítési logika közé, ami nem jobb a fordított helyzetnél - nehezebb hibát keresni Mindkét technológia esetén többféle láthatóságot rendelhetünk a változókhoz, ezek a következők lehetnek: request scope a kérés kiszolgálásának idején látható session scope a felhasználó látogatása idején (az oldal első letöltésétől az elhagyásáig) érvényes application scope a teljes alkalmazás esetén érvényes (ekkor például az értékadások esetén tranzakciókezelésről is gondoskodni kell; általában csak kevés, a web modul betöltésekor felhasznált, a teljes alkalmaztásra érvényes adatot tárolunk itt)

40 4.2. Megjelenítési réteg 29 Egy web project tipikusan a következő könyvtárszerkezetben helyezhető el: /project \ - build: leforditott web modul - dist: Osszecsomagolt web modul (.war) - src - java: Java csomagok, forrasok - test - java: Java teszt csomagok - web - WEB-INF - classes: Leforditott osztalyok,.properties - lib: Kulso csomagok, keretrendszerek - tlds: Tag library leirok \- web.xml - resources - theme - scripts \- {.jsp file-ok} 4.3. Egy web modul könyvtárszerkezete Model 2 architektúra A servlet-ek és JSP-k külön-külön összekeverték a megjelenítést és a feldolgozást, viszont kialakítható egy olyan kombináció, mely áttekinthető módon valósítja meg a Model-View-Controller mintát: ennek a neve Model 2 architektúra 2. A kéréseket ebben az esetben hagyományos módon egy servlet kapja meg. Azt értelmezve vagy megjelenít egy oldalt (a válasz előállításához a vezérlést egy JSP-nek adja át) vagy a modellen elvégzi a módosításokat (ami után általában szintén egy JSP-t jelenít meg, melyen közli a művelet sikerességét is). A megoldás előnye, hogy a megjelenítés és az üzleti funkciók közötti kapcsolat lazább, a megjelenítést módosító vagy 2 az MVC tervezési mintát már régebben is használták natív alkalmazások esetén, a Java web alkalmazásokra való alkalmazását nevezik Model 2 architektúrának vagy Model 2 tervezési mintának

41 4.2. Megjelenítési réteg ábra. Model 2 architektúra karbantartó fejlesztőnek nem kell ismernie a logika oldalt és nem is kell hozzányúlnia; ugyanakkor a megjelenítő logika fejlesztéséhez sem szükségesek alapos HTML ismeretek. A két részben a megjelenített adatok közösek, erről közösen kell a fejlesztőknek megállapodni. A servlet-ek nagyobb rendszerek esetén csak a megjelenítő logikát tartalmazzák, az üzleti logikát EJB (vagy a használt keretrendszerre vonatkozó, pl. Spring) hívásokkal érik el Megjelenítő keretrendszerek A JSP és servlet technológia lehetőséget biztosít egyszerű megjelenítés biztosítására, a Model 2 architektúra azt átláthatóvá teszi, viszont sok feladat megoldása továbbra is nehézkes. Ilyen például a makrók, vezérlési szerkezetek használata, validálás, modellhez rendelés, egyedi komponensek biztosítása, oldalsablon (template) kezelése, melyeket különböző keretrendszerek tartalmaznak. Nagyon sok lehetőség közül itt a legelterjedtebbek közül szerepel néhány ismertetése. JSTL Java Standard Tag Library, szabványos JSP tag gyűjtemény, a többi rendszerrel szemben ez a J2EE szabványnak része; fő részei a mag (változók, URL, vezérlés), XML, többnyelvűség, SQL, String kezelés; a következő változata a később szereplő JSF rendszerekkel is képes együttműködni

42 4.2. Megjelenítési réteg 31 Struts Ez a rendszer régi múltra tekint vissza (2000-ben indult, nem sokkal a Model 2 architektúra kialakulása után). Ez az egyik legelterjedtebb MVC rendszer és az évek során folyamatosan fejlődött, majd a JSF (részletesen a következő részben szerepel) megjelenését követően annak kiegészítésére használható (Shale alprojekt). Többek között újratöltés vizsgálata, kliens oldali validáció, szerver oldali kiegészített validáció, annotációk támogatása, junit tesztelés, HTML sablon használata (Clay) szerepel a szolgáltatásai között. Velocity Egy Java alapú sablonnyelv, mely a megjelenítést nem JSP alapon, hanem saját elemekkel írja le; változók, makrók használatát is lehetővé teszi és nem csak HTML, hanem más (szöveges) tartalmak (például XML, SQL) előállítására is használható. Tapestry Az alkalmazást oldalakból rakja össze és minden oldalt komponensekből épít fel. A navigáció során szükséges URL-eket a keretrendszer állítja elő; beviteli ellenőrzést, többnyelvű oldalak kezelését, kivételkezelést is támogat. A megjelenített HTML oldalak külön is szerkeszthetők, a dinamikus tartalom illesztésére OGNL (Object Graph Navigation Language) kifejezéseket használ. Egyedi komponensek is könnyen készíthetők alatta. Wicket Ennek a keretrendszernek a segítségével a többitől kicsit eltérően választható szét a megjelenítés és a tartalmat előállító logika: a megjelenítés létrehozásához csak egyszerű HTML dokumentumokat kell készíteni, néhány tag-nek kiegészítő paramétert adva (wicket:id), valamint a <wicket:>) névtér használható még. A megjelenítő logika és a FORM-ok kezelése teljes mértékben a Java oldalon található, így a HTML rész szerkesztéséhez WYSIWYG 3 editor is használható. A keretrendszer gazdag AJAX 4 támogatást is tartalmaz. Facelets A JSF rendszerekre jellemző sablonok hiányosságát pótolja ez a technológia: XHTML dokumentumokban adható meg az oldalak váza, valamint azon belül megjelölhetők helyek és ezekre az oldalt használó JSF adja meg, hogy milyen tartalom kerüljön. 3 What You See Is What You Get Amit látsz azt kapod 4 Asynchronous JavaScript And XML, XML segítségével kliens oldali dinamikus viselkedést megvalósító technológia, mely JavaScript nyelven alapul

43 4.2. Megjelenítési réteg JavaServer Faces Az 1.4-es J2EE szabványban jelent meg a JavaServer Faces komponens alapú technológia, mely a MVC tervezési mintának is megfelel. HTML és annál magasabb szintű komponenseket tartalmaz, melyek összekapcsolhatók a megjelenített adatokkal, validátorok, konverterek kapcsolódhatnak hozzá, valamint kliens- és szerveroldali eseménykezelést tesz lehetővé. A működése több hasonlóságot tartalmaz az ASP.NET WebForm technológiával és a Struts rendszerrel (a JSF projekt egyik tervezője készítette előtte a Struts-ot), a Struts-Shale kiterjesztéssel pedig jól kiegészítik egymást ábra. Egyszerű JSF felület A 4.4. ábrán látható részt alkotó forráskód vázlata a D.2. függelékben tekinthető meg, mely a következőket tartalmazza: egy JSP oldal, mely JSF tag library-t használ (ez tartalmazza a Faces komponenseket): a két beviteli mezőt a címkéjükkel és a hozzájuk tartozó üzenetkomponenssel együtt egy 3 oszlopos rács tartalmazza, valamint alatta egy checkbox és egy két gomb található a backing bean egy, az oldal mögött álló Java osztály, melyben megtalálhatók az elemekhez kötött változók, ezekhez set és get metódusok, egy konstruktor, az életciklus során meghívott metódusok, akciókezelő (navigációval és anélkül) metódusok, valamint itt implementálható egyedi validátor (értékek ellenőrzése), konverter (értékek formátumának megadása); egy JSP oldalhoz több backing bean

44 4.2. Megjelenítési réteg 33 (másik neve: managed bean) is tartozhat és a láthatósága is beállítható (request, session, application) néhány XML leíró definiálja a backing bean-eket és a navigációt, valamint alkalmazás szintű változókat (pl. nyelvi beállítások, üzenetek) Ma már több fejlesztőkörnyezet tartalmazza JSF alkalmazások esetén a fogd és vidd (drag and drop) szerkesztési mód támogatását. Ilyen például a Java Studio Creator, a JDeveloper és az Exadel Eclipse alapú alkalmazás Portál megoldások, portlet Nagyobb rendszerek esetén hasznos lehet portál megoldások felhasználása, melyek több gyakran használt szolgáltatást biztosítanak, így ezeket a funkciókat nem az alkalmazásnak kell ellátni. Ilyen lehet például a megjelenített tartalom státusznak és testreszabás során meghatározott paramétereknek megfelelő előállítása, témák közötti választás lehetővé tétele, megjelenített elemek átrendezése, integrálás más rendszerekkel. A felhasználók kezeléséhez valamilyen hozzáférés-kezelő rendszerhez (Access Manager) kapcsolódnak, mely elvégzi a regisztrációt, be- és kiléptetést, szerepek kezelését. A portálokon az oldalak szerkezetét különböző tárolók határozzák meg (például fejléc, menü, tartalom több hasábban, lábléc), ezekben úgynezvezett portleteket lehet elhelyezni. A portletek tartalmat jelenítenek meg és akciókezelés is tartozhat hozzájuk. Ilyen lehet például egy kereső doboz, egy híreket megjelenítő komponens, egy szavazógép vagy egy képajánló. A portleteket 2003-ban szabványosították JSR-168 néven, így azok több gyártó portál szerverén is elhelyezhetők (a szabványban nem szereplő részek megadása után). A portlet-ek életciklusa egyszerű: feltöltést követően inicializálódik (init), majd kéréseket szolgál ki, melyek valamilyen tartalom megjelenítésére vagy akció végrehajtására vonatkozhatnak (handle requests), végül fel is lehet függeszteni futásukat (destroy). A portlet-ek valójában speciális web alkalmazások, melyek nem a web konténerben, hanem a portlet konténerben futnak és az életciklusukat a portál szerver kezeli. Több megjelenítési módot is támogatnak: ezek közül a VIEW mód megvalósítása kötelező (megjelenítés), az EDIT mód beállítások megadására szolgál (testreszabás, paraméterezés), a HELP mód pedig a súgó funkciót biztosítja. Ezen kívül szerepelhetnek

45 4.3. Fejlesztői környezetek ábra. Pillanatnyi időt megjelenítő portlet más gyártóspecifikus módok is. A megjelenítésre jellemző még a megjelenő ablak mérete, mely lehet normál méretű (egy doboz az oldalon), teljes méretű (a teljes tartalom konténer elfoglalása) vagy minimális méretű (összecsukott, csak a doboz fejéce látható). A módok és a méretek között leggyakrabban a felső részen elhelyezett ikonok teszik lehetővé a választást Fejlesztői környezetek J2EE rendszerek fejlesztéséhez a legegyszerűbb szöveges editorok (például vim) is használhatók, viszont a kényelmes használathoz egy komolyabb fejlesztőkörnyezet szükséges. A hagyományos Java fejlesztőrendszerek sem sokkal hatékonyabbak, mivel nagyon sok szabványos és gyártóspecifikus elemet kell elhelyezni projektekben (telepítési leírók, ezek- és a forrásfile-ok között az integritás biztosítása). Az első ilyen irányú könnyítések fordítási időben végezték el az extra fukciókat (például telepítés a szerverre vagy automatikusan előállítható leírók gyártása) ant scriptek segítségével, majd a fejlesztőkörnyezetek segítséget nyújtottak először a szabványos, majd egyre több gyártó alkalmazásszerveréhez és keretrendszerhez is, valamint a fejlesztést kényelmesebbé tevő szolgáltatásokat is biztosítottak (automatikus kiegészítés, hiba helyének pontos jelölése, hibakeresés (debug), XML leírók grafikus szerkesztése és ezek tartalmának elfedése, források közötti integritás biztosítása és ellenőrzése). A két legelterjedtett J2EE fejlesztőkörnyezet a NetBeans és az Eclipse (utóbbihoz külön plugin telepítése szükséges, például WTP Web Tools Platform, vagy az erre épülő Exadel Studio). Érdemes megemlíteni még az Oracle jdeveloper rendszerét, melyet leghatékonyabban saját alkalmazásszerverük esetén lehet használni (az első két rendszerre jellemző, hogy több gyártó esetén is könnyebben használhatók). Jelenleg

46 4.3. Fejlesztői környezetek 35 a Sun NetBeans alapon két fejlesztőkörnyezetet kínál: az egyiket J2EE üzleti alkalmazások készítéséhez (Java Studio Enterprise), a másikat webes alkalmazásokhoz (Java Studio Creator). Az IBM rendszerei Eclipse-re épülnek, a legújabb ezek közül a Rational Software Architect. J2EE (webes) rendszerek fejlesztésekor a következő funkciók támogatása a leginkább elvárt: EJB (session bean, entity bean és message driven bean) létrehozása, működésükhöz szükséges erőforrások egyszerű megadása (adatbázis, MQ, adatbázis leképzés) refactoring: a forráskód transzformációi, a felhasználási helyeken történő ellenőrzéssel együtt a szabványos, gyakori műveletek támogatása (EJB hívása, tervezési minták, DTO) az alkalmazások gyors és áttekinthető telepítése, hiba esetén az okok pontos megjelelölése minél előbb alkalmazásszerver specifikus és szabványos elemek támogatása (szerepek kezelése, hibaoldalak, tranzakció kezelés beállítása) kiegészítő keretrendszerek támogatása (különböző webes keretrendszerek XML leírói, ezek sémái, források közötti kapcsolatok könnyű követése, automatikus kiegészítés, dokumentáció megjelenítése); a ábrán egy JSF szerkesztési nézet látható más fejlesztőrendszerben elkészített alkalmazások használata, importálása, szinkronizáció A különböző környezetek képességeit a 7.5. táblázat foglalja össze.

47 5. Esettanulmányok Ez a rész ismerteti az összehasonlítás alapjául szolgáló rendszereket. Ezek közül a legnagyobb múlttal a Kollégiumi Információs Rendszer (KIR) rendelkezik. A KIR szolgált a MatekLap alapjául, majd Villanykari Információs Rendszerré (VIR) bővült. Közben néhány kisebb rendszer is erre a keretrendszerre épült, például Maszat (Kollégiumi Médiatár), egy web hosting szolgáltatás menedzsment felülete és egy ügyviteli rendszer. Az eddig említett rendszerek mind a KIR PHP + XML alapú keretrendszerére épültek, így a J2EE alapú megoldásoknak elsősoran a felhasználói működés szempontjából szolgáltak alapjául, kisebb mértékben az ott megszokott komponensek és egyszerűsítő lehetőségek is felhasználhatók voltak. Az összehasonlítások bemutatásánál a StarOffice 8 EJB 2.1 alapú, JSF és Facelets megjelenítést használó magyar honlapja és az EJB 3 alapú, Wicket megjelenítéssel rendelkező MatekLap játszott fő szerepet A Kollégiumi Információs Rendszer bemutatása Az eredeti rendszer (5.1. ábra) a kollégium belépő és közösségi pontozását segítő alkalmazásból fejlődött ki, melynek első változata még Perl nyelven, a későbbi változatok pedig PHP és XML nyelveken íródtak [9]. Mivel itt egyébként is szerepeltek a kollégisták és kollégiumi egységek, ezért újabb hasznos funkciók is megjelentek: hírek, szavazások, fórumok, dokumentumtár. Ezt követően egy nyarán rendezett fejlesztői táborban ismerte meg egy csoport a PHP alapú rendszert decemberben történt egy nagyobb változtatás: a keretrendszer egy része kiegészült új funkciókkal (hibaellenőrzés, dokumentáció generálása, CSS használata formázáshoz), és ekkor készült el a VIR első változata is. A VIR később több másik egységgel való együttműködést is kezdeményezte (Info- és VillanySite 1, HK). 1 tárgyakkal kapcsolatos információkat, segédleteket, mintafeladatokat tartalmazó oldal 36

48 5.1. A Kollégiumi Információs Rendszer bemutatása ábra. Képek a Kollégiumi Információs Rendszerről A KIR felépítése A rendszer felépítése (egy kérés kiszolgálását követve) ezeknek a szempontoknak a figyelembe vételével az 5.2. ábrán látható módon ábrázolható ábra. A KIR felépítése 5.3. ábra. A KIR könyvtárai A diagram a rendszer logikai működését ábrázolja, a fizikai megvalósításban van egy kis eltérés: a feldolgozó rész az elvártaknak megfelelően nem jelenít meg tartalmat, viszont a művelet elvégzését követően nem szerveroldalon állít elő egy oldalt, melyet a felhasználó visszatérésként megkap, helyette a HTTP protokoll Location 2 parancsát ki- 2 Ha a szerver válaszának fejlécében szerepel a parancs (egy URL paraméterrel), akkor a böngésző az oldal megjelenítése helyett az itt szereplő címre ugrik.

49 5.1. A Kollégiumi Információs Rendszer bemutatása 38 használja utasítja a felhasználó böngészőjét egy másik oldal letöltésére. Egyetlen ilyen kérés minden böngésző alatt megfelelően működik, viszont a hálózatot fölösleges forgalommal terheli, tisztább megoldás lenne az ábrán átható változat, amikor a feldolgozás is egyetlen kérés válasz párral megoldódna. Az ábrázolt változat hátránya viszont a könyvjelző felvétele: később látható hogy azt megvalósító technológiák esetén éppen ezért nem használható a böngészők könyvjelzője, mivel abban nem jelennek meg a HTTP POST paraméterek. Az 5.1. táblázat és az 5.3. ábra az egyes szerkezeti egységek elérését és a megvalósítás nyelvét ismerteti, ezt követően pedig a ezeket részletezem a megértéshez szükséges mértékben. Könyvtár Funkció Nyelv Leírás classes keret PHP a böngésző felhasználó kezelése, jogosultságok config control XML vezérlés content view XML megjelenítés doc LATEX, TXT dokumentáció func model PHP feldolgozó logika html view HTML az oldalak HTML váza hook-ok használatával images view képek a rendszer (tartalom nélküli) képei jmods keret PHP a keretrendszer nodes keret XML + PHP megjelenítésben használt saját tag-ek definíciója site_config.xml XML általános, portál szintű attribútumok, objektumok 5.1. táblázat. A KIR forrása A rendszer működése A rendszerben külön van választva a modulok vezérlése, a megjelenítés és a feldolgozó függvények. A modulok konfigurációja írja le XML nyelven, hogy milyen szolgáltatások érhetők el benne, azok megjelenítő vagy feldolgozó oldalak-e, milyen josogultság szükséges az eléréshez, milyen változókat töltsön be automatikusan a modul. A megjelenítés HTML vázakat használ, melyre XML-ben leírt, HTML, saját függvény és

50 5.2. Új igények, könnyítések 39 makrókat tartalmazó megjelenítő komponensek adhatók meg, a többszörös és rekurzív hívást is lehetővé téve. A feldolgozás egyszerű PHP függvények hívása. Az oldal használatához az előző elemeknek valamilyen transzformációja szükséges, mely futtatható (ebben az esetben PHP) kódot eredményez. A fordítás azért hasznos, mert az azonnali transzformáció jelentős többletterhelést okozna. Az egyszerű elérhetőség miatt a fordító webes felületen érhető el (a KIR keretrendszert felhasználva), mely a vele megegyező gépen található forrásból készíti el a felhasználható PHP kódokat. A transzformáció lépései a következők: 1. új könyvtárszerkezet kialakítása, a nem XML típusú file-ok megfelelő könyvtárakba másolása: a feldolgozó függvényeket, képeket és a HTML vázat a fordító nem értelmezi, csak a megfelelő könyvtárakba másolja a későbbi lefordított fileokban szerelő hivatkozásoknak megfelelően 2. a konfigurációs leírások alapján a modulok meghatározása, a vezérlő szerkezetek előállítása: ekkor SAX 3 segítségével egy fát épít, mely az XML elemeit tartalmazza, kiegészítve egyéb specifikus attribútumokkal és (például csomópont kimenetét előállító) függvényekkel (az egyszerű DOM 4 fa ezért nem alkalmazható) 3. saját (megjelenítő) XML tag-ek elérhetőségét biztosítás PHP függvényként 4. megjelenítő oldalakat leíró XML file-okból függvények előállítása, közöttük lévő kapcsolatok esetén függvényhívások használata 5. a modulok vezérlését végző kódrészek előállítása 5.2. Új igények, könnyítések A PHP alapú rendszer a következő hiányosságokkal rendelkezik: 3 Simple API for XML, XML dokumentumok soros feldolgozására alkalmas szabvány 4 Document Object Model, szabvány, mely XML dokumentum alapján objektumokból egy fát épít

51 5.2. Új igények, könnyítések 40 A(z adat)modell hiánya Nincs a rendszernek modellje, csak forráskód. Ebből következik, hogy néha kis változtatásokhoz is sok módosítást kell kézzel végezni és hogy a fejlesztők túlságosan szabad kezet kapnak: sok olyan dolgot meg lehet tenni, mely a keretrendszet kijátszva nem az eredeti elképzelések szerint valósít meg egy funkciót (ami akkor hátrányos, ha meg kell érteni az adott részleteket vagy ha a keretrendszer változását követően már nem működőképes) ezek általában akkor fordulnak elő, ha valaki a rendszer alaposabb ismerete nélkül gyorsan akar elkészíteni egy részletet. Azt is itt érdemes megemlíteni, hogy az adatmodell hiánya miatt a megjelenítő részekben SQL lekérdezések szerepelnek: ez gyors fejlesztések és kis bonyolultságú rendszerek esetén használható, viszont nagyobb fejlesztőcsoport esetén vagy későbbi változtatások alkalmával nagyon megnehezíti a feladatot. PHP hátrányok A rendszer néhány negatív tulajdonsága a PHP alapokból következik. Ezek egyike, hogy minden külön cache kiegészítés nélkül minden letöltésnél újraértelmezi az érintett forráskódokat. Ez kis látogatószám és nem túl bonyolult oldalak esetén még hasznos is lehet, mivel így nem kell minden változás esetén fölöslegesen újrafordítani nagyobb részeket vagy a memóriában tartani a gyakran használt objektumokat, viszont nem skálázható megoldás. Az adatbázisokhoz kapcsolódáshoz a PHP és Apache konfigurálásánál is be kell állítani a paramétereket (legyenek-e perzisztens kapcsolatok, ha igen, akkor mennyi legyen, ami nem fog le fölöslegesen sok kapcsolatot azok közül, melyeket az adatbázis biztosít, viszont nem is annyira kevés, hogy túlságosan hamar elfogyna). A megjelenített tartalmat és megjelenítő logikát általában egyéni megoldásokkal lehet biztosítani, melyek esetén például a FORM mezőinek és a változóknak a kötése is nehéz feladat. Ezenkívül a sessionkezelést, az azonosítást és jogosultságkezelést is nekünk kell megvalósítani.

52 5.3. Médiatár 41 Megjelenítés A megjelenítés a KIR eredeti verziójában lehetővé tette több téma használatát (a KIR mellett teljesen azonos rendszer biztosította az Oldboys portált az öregek és a Gólyportált a gólyák számára). Ez a témakezelés viszont nehézkesen használható volt és csak kevés CSS formázást használt, nagyrészt HTML változatok közül a megfelelő kiválasztását jelentette. Ebből adódik, hogy a letöltött oldalak forráskódja bonyolult volt, sok esetben nem is azonos formában jelent meg a böngészőkben és az oldalak forráskódja is fölöslegesen nagy méretű volt. A VIR rendszer már CSS használatával oldotta meg a formázást, ahol a témák kezelése mellett a különböző megjelenítések (skin) közül történő választás is lehetővé vált. Közös elemek Nincsenek gyakran használt és elterjedt megoldások a közös feladatok megoldására, mint például a logolás és a hibakezelés. A hibakezelés esetén például teljesen a fejlesztőkön múlik, hogy a hibát a keretrendszer (nem túlságosan fejlett) lehetőségeit kibővítve vagy teljesen egyedi megoldásokkal valósítják meg azt. Hiba esetén a felhasználó számára történő visszajelzést pedig az egyedi session megoldások használata (szintén a programozón múlik, hogy mit rak bele) is nehezíti. Dokumentáció hiánya, tanulás nehézségei Jelenleg sem érhető el a rendszer teljes egészét leíró, friss dokumentáció. Míg egyes részeihez részletes anyagok és minták találhatók, addig máshol dokumentálatlan funkciók is előfordulnak. A keretrendszer aktív fejlesztői átlátják ezeket a részeket is, viszont az egyediség megnehezíti a tanulást is Médiatár A kollégiumi közösségi tevékenységekről gazdag médiaanyag áll rendelkezésre: különböző rendezvények (például Schönherz Qpa, Fesztivál7,... ) és körök (például

53 5.4. MatekLap 42 KSzK 5, Táncklub, Banális Közhely) kép-, hang- és videóanyaga. A BSS 6 is nagy mennyiségű filmarchívummal rendelkezik. Ekkora mennyiség mellett nehéz a nyilvántartás, a keresés és az elérhetőség biztosítása is. Ennek megoldására kezdődött egy médiatár tervezése, röviden MASZAT (Multimédia Archívum Szerver Architektúra Találdki). A hasonló feladatokat ellátó galéria alkalmazások 7 sajnos nem voltak képesek ellátni az elvárt feladatokat (néhány funkciójuk az elvártnál jobb is volt, míg más helyeken hiányosságok fordultak elő). A médiatár fő célja, hogy többféle kategóriarendszer szerint lehessen benne keresni (például események, csoportok, helyszínek, idő). Ezt a hagyományos hierarchikus struktúra nem biztosítja hatékonyan, ezért a megjelenítést a keresési feltételek folyamatos szűkítésével (visszafelé lépkedve enyhítésével) állítja elő. Ennek megfelelően böngészéskor (előre felkínált lehetőségek a továbblépésre) ezek szerint az előre meghatározott kategóriák mentén, kereséskor pedig saját feltételek megadásával lehetséges továbblépni. Jelenleg a kollégiumban ezek a anyagok szétszórva találhatók meg és sok olyan van közöttük, mely nem elérhető állandóan (például valaki CD-re kiírta és már egyik nagyobb, folyamatosan működő szerveren sem található meg, vagy csak néha indítja el a megosztását). A médiatár így a hiány pótlására létrejött, jól kereshető, az anyagok nagy részét tartalmazó archívum MatekLap A MatekLap egy olyan webes portál, melynek két célja van: az egyik egy matematikával kapcsolatos, fejtörő feladatokat, különböző rendezvények (táborok, vetélkedők) és a kialakult közösségek kapcsolattartását elősegítő rendszer kialakítása, folyamatos továbbfejlesztése és üzemeltetése; a másik pedig kísérletezés különböző webes technológiákkal, a fejlesztési, külső adminisztrátori és felhasználói igények figyelembe vételével. Az első rendszer a KIR keretrendszert használta (még a jelenleg futó aktív változat 5 Kollégiumi Számítástechnikai Kör 6 Budavári Schönherz Studió 7 például Gallery, Gallery2:

54 5.5. StarOffice 8 43 is PHP alapú). A mostani változat fő funkciói: hírek, fórumok, szavazógép, üzenőfal dokumentumtár, feladattár rendezvények (tábor, vetélkedő, találkozó) oldalai: leírás, jelentkezés, résztvevők, szervezők, tanárok, szótár, fényképek, program, eredmények fejtörő: feladatok kiírása hetente és ehhez értékelő felület A rendszernek van néhány specialitása is: a rendezvények adatai (résztvevők, iskolák, szervezők) egy független, távoli adatbázisból frissülnek, a képek már a Gallery 2 PHP alapú galéria alkalmazással is együttműködnek, néhány funkció futásához időzítés szükséges (kiértékelések, új feladatok kiírása). A J2EE rendszer tervezése tartalmazza ezeknek a funkcióknak az újraértékelését, kiegészítő szolgáltatások hozzákapcsolását (galéria, wiki, külső hírforrások), a struktúra átláthatóságának biztosítását. A rendszer több helyen testreszabható, paraméterezhető, átalakítható különböző szintű fejlesztők számára (fejlesztők, tartalom feltöltők, adminisztrátorok) StarOffice 8 A StarOffice honlap megírása az előző rugalmas kialakítással szemben egy specifikációnak megfelelő rendszer elkészítését jelentette. Fő funkciói: hírek, fórumok, segítségnyújtás, letöltések, dinamikus termékleírások, külső hírek, bannerek. Mivel itt fontos a szolgáltatás rendelkezésre állása, stabilitása, ezért egy kész szabvány használatával, EJB 2.1 alapokon került megvalósításra. A környezet konfigurálásáról a B. függelékben és az EJB 3 rendszerrel történő összehasonlító részekben lesz később szó.

55 6. A vizsgált rendszerek modelljei és megvalósításai A következőkben az előző fejezetben szereplő rendszerekhez készített platformfüggetlen, majd J2EE modellek olvashatók, majd architektúrával kapcsolatos megoldások és alacsonyabb szintű fejlesztői döntések szerepelnek Modellek A médiatár viszonylag kevés funkcióval rendelkezik, ezek áttekintése a 6.1. ábrán látható: User Management felhasználók adminisztrálása, ide tartozik a regisztráció, a be- és kilépés kezelése, a felhasználók karbantartása (jelszó kiküldése, törlés); mindhárom szerep számára tartalmaz funkciókat Maszat Usage a médiatár elsődleges funkció szerinti használata, például böngészés, keresés, letöltés, megtekintés; ezeket a szolgáltatásokat a szerepektől függetlenül lehet elérni Maszat Management a médiatár tartalmának kialakítása, így a feltöltést, módosítást, törlést tartalmazza; a bejelentkezett felhasználók és az adminisztrátorok érik el ezeket a funkciókat (az adminisztrátorok minden funkciót, a bejelentkezettek pedig engedély szerint hozzáadást és saját elemek módosítását) Maszat Administration a rendszer kartabtartása, ide tartozik a kategóriák, szerkesztése és a törlések véglegesítése (fizikai törlés) A VIR és MatekLap ennél jóval több funkcióval rendelkezik, ezért a 6.2. ábrán csak a szerepek szerepelnek, a funkciók pedig a 6.3. ábrán látható módon csoportosíthatók. 44

56 6.1. Modellek ábra. Médiatár főbb használati esetei A MatekLap ezek közül a kollégiumhoz kapcsolódó részeket nem tartalmazza (belépőigénylés, éjszakai vendégfogadás). A fórumra vonatkozó platformfüggetlen modellből a 2. fejezet tartalmaz részleteket, a VIR modelljéből pedig a C. függelék. User Management felhasználók adminisztrálása (regisztrálás, be- és kilépés, engedélyezés, visszautasítás, (nyilvános) adatlapok, linkek a hozzájuk tartozó bejegyzésekre (felvett hír, hozzászólások, feltöltött anyagok), keresés Group and Role Management csoportok és szerepek nyilvántartása, kollégiumi hierarchia módosítása, csoportok adatlapja, tagságok szerkesztése, vezetőváltás News Management hírek kezelése: hír megjelenítése, felvétele, módosítása, törlése, kiemelése, keresés a hírek között, hírkategóriák adminisztrálása

57 6.1. Modellek ábra. VIR szerepek 6.3. ábra. VIR használati esetek áttekintése Guest Management vendégfogadás, vendégek listázása Spool Management belépést követően megjelenő ablakok felvétele Fortune Management a honlapon megjelenő, véletlenszerűen választott idézetek szerkesztése, megjelenítése Banner Management az oldalon megjelenő hírdetések adminisztrálása Message Management üzenőfal, melyen a felhasználók egymásnak vagy csoportjaiknak írhatnak

58 6.1. Modellek 47 Vote Management szavazógép: szavazások megjelenítése, adminisztrálása, archívum elérése Document Management dokumentumtár, mely egyszerű file-okat tárol hierarchikus szerkezetben és ennek használatát, adminisztrálását biztosítja Request Management a Schönherz Kollégiumhoz kötődők belépő- és közösségi pontozásának megkönnyítését végző modul A webes rendszerekre jellemző háromrétegű logikai architektúra ezekben az esetekben a következő módon finomítható: perzisztencia az adatok perzisztens leképzését végző réteg, ezen belül: adatmodell a rendszer adatait tároló Java objektumok és kapcsolataik adatelérés műveletek elvégzését (lekérdezés, keresés, beszúrás, módosítás, törlés) biztosítja (Data Access Object, DAO) üzleti logika a szolgáltatásokat biztosító réteg felhasználói felület a felhasználói felület (UI) megjelenítéséért és működéséért felelős rész, ezen belül szintén megkülönböztethető: eseménykezelés a felhasználói események (akciók) kezelését végzi, ide tartozik az adatok ellenőrzése és a hibákra való reakció is, valamint ez a réteg hívja a szolgáltatásokat megjelenítés a komponensek megjelenítéséért és a tartalom kiírásáért felelős rész formázás a megjelenített tartalom formázását végzi el (skin) A J2EE modell a következő lépések segítségével készíthető el a platformfüggetlen modellből: 1. az entitás osztályok alapján entity bean-ek (EJB 2.1, EJB 3), vagy egyszerű Java osztályok (POJO) + leképzés (XML vagy XDoclet) létrehozása (Hibernate)

59 6.2. A rendszerek architektúrája az adatosztályokból DTO (Data Transfer Object, adatátviteli objektum) létrehozása (EJB 2.1, a másik két technológia esetén elég az adatosztályoknak sorosíthatónak lenni) 3. a vezérlő (control) osztályokból session bean-ek készítése (EJB) vagy egyszerű Java osztályok (Spring) 4. a határoló osztályokból a megjelenítő réteg előállítása: oldalszerkezetek, navigáció, (HTML) tartalom, megjelenítő logika, eseménykezelés, üzleti funkciók hívása 6.2. A rendszerek architektúrája Ebben a részben az alkalmazás telepítésére vonatkozó áttekintés látható. A többrétegű fizikai architektúra a skálázás szempontjából fontos: egy terhelés-kiegyenlítő a kéréseket valamilyen szempont (általában round robin, esetleg a session megtartásának a lehetőségével) szerint továbbítja a kiszolgáló egységek felé, így a kiszolgálási teljesítmény határát megközelítő rendszer új fizikai egységek hozzáadásával tovább bővíthető ábra. Alkalmazászerverek terhelés-kiegyenlítéssel Lehetőség van az alkalmazásszerverek fürtözésére is, amikor a szerverek egy logikai egységként láthatók és egy csomópont kiesése esetén nem csak a további kérések érkeznek a többi eszközhöz (ez terhelés-kiegyenlítő esetén is elérhető funkció), hanem a felhasználókhoz tartozó session sem szakad meg. Sok esetben a web- és EJB konténerek külön is fürtözhetők.

60 6.2. A rendszerek architektúrája 49 A 6.5. ábrán egy olyan eset látható, amikor az EJB előtt egyszerű JSF web modul végzi a megjelenítést: az alkalmazás megjelenítő rétege a web konténerben fut, a logika az EJB konténerben. Az EJB réteg objektumait a web modul JNDI név alapján éri el, valamint az EJB réteg is JNDI név használatával éri el a szükséges erőforrásokat (adatbázis, SMTP szerver, üzenetsor). Eltérő webes megjelenítő keretrendszer csak a web konténeren belüli működésre van hatással ábra. EJB egyszerű web modul interfésszel Ettől nagyobb mértékben eltér az a rendszer, melynek megjelenítését portál szerver végzi. A portál szerver egy web konténerben futva szolgálja ki a kéréseket. A web alkalmazást ugyancsak a web konténerben kell elhelyezni (ez lehet egyszerű feltöltés és konfigurálás, parancssorból történő telepítés a portál szerverre vagy webes felületen keresztüli telepítés). Ezután az alkalmazásban definiált tárolókban a megadott portletek jelennek meg, melyek tartalmát servlet-ek, JSP vagy JSF felhasználásával is meg lehet adni. Ebben az esetben általában az authentikációt és a jogosultságok ellenőrzé-

61 6.2. A rendszerek architektúrája 50 sét, felhasználó- és csoportkezelést egy külön alkalmazás (Access Manager) végzi, így ezeket a részeket nem kell az alkalmazásban elkészíteni. (Access Manager használatára hagyományos alkalmazások esetén is lehetőség van.) A 6.6. ábrán a portál megoldás architektúrája látható ábra. EJB portál interfésszel Az EJB-t nem tartalmazó esetben a web konténeren belül szereplő modul szerkezetének egy része látható a 4.1. ábrán, ezt az egyszerű web és EJB esetben látott JSF komponensekkel kell csak kiegészíteni.

62 6.3. A logikai rétegek és keretrendszerek együttműködése A logikai rétegek és keretrendszerek együttműködése A szabványos technológiák használata mellett biztosítani kell azok hatékony együttműködését, valamint a lehetőséget, hogy a később egy-egy réteg szükség esetén lecserélhető legyen (például egy hatékonyabb vagy egyszerűbb megoldásra). Általában a megírt osztályok helyett célszerű az ahhoz tartozó interfészeket külön biztosítani és a felhasználás helyén arra hivatkozni. Az előző részben bemutatott rendszerek alapján a következők a legfontosabb funkciók, melyek a szabványokra építve valósíthatók meg Erőforrások elérése Az alkalmazásszerverek különböző erőforrások elérését biztosítják JNDI mechanizmusok keresztül, így azok menedzselése (pl. megnyitás, lezárás) nem az alkalmazás feladata. Ide tartozik az adatbázis kapcsolat (CMP esetén ennek elérését a konténer végzi), az üzenetsorok (pl. message driven bean-ek esetén) vagy a JavaMail API-nak megfelelő levelező erőforrás. Azért, hogy az alkalmazásban ne kelljen redundánsan tárolni ezeket a neveket, a lekérést egy központi funkcióval érdemes elérhetővé tenni a Service Locator tervezési minta szerint (EJB 2 esetén ez szükséges, EJB 3 esetén nem), valamint a hívó függvényeket a rendundancia csökkentése céljából például egy közös ősben vagy a Service Locator Singleton megvalósításaként lehet elhelyezni. A web rétegben érdemes valamilyen cache mechanizmust is használni, mely gyorsítja a JNDI névfeloldást (6.7. ábra). Spring használatával az erőforrásokat legegyszerűbb IoC segítségével elérhetővé tenni: az applicationcontext.xml leíróban egy bean-t létrehozni, melyet a felhasználó bean-ben a keretrendszer állít be (set metódus hívásával) Lekérdezések tárolása Az alkalmazás működéséhez a kulcs alapján történő lekérdezésen kívül más lekérdezésekre is szükség van, ezek közül némelyik még paraméterekkel is rendelkezik.

63 6.3. A logikai rétegek és keretrendszerek együttműködése ábra. Erőforrások a szerveren EJB 2.1 esetén ezeket EJBQL használatával lehet megírni és a telepítő leíróban elhelyezni. Sajnos a 2.1 -es változat kifejezőképessége is elmarad még a leggyakrabban használt szabványos SQL képessége mögött is, így sokszor szükség lehet kézzel történő adatbázis-kapcsolódásra és szabványos SQL használatára. Mivel az adatbázis sémáját CMP esetén a konténer hozza létre és továbbfejlesztés esetén ez gyakran változik is, ezért ezeket a lekérdezéseket folyamatosan frissíteni kell. Tisztán Hibernate esetén (pl. egyszerű web modulban) már több funkció elérhető a Hibernate QL (HQL) SQL kiegészítésnek megfelelően és ezek jól átláthatóan a DAO rétegben találhatóak, így később is könnyen elérhetők. EJB 3 esetén az EJBQL lehetőségei is bővültek, ha pedig nem lenne elég, akkor szabványos SQL lekérdezések is ezzel megegyező szintaktikával használhatók. Az eredmények esetén egyedi mezők mellett lehetőséget biztosít azok külön (nem entitás) objektumokba leképzésére Adatok szállítása, validáció EJB 2.1 használatakor a különböző rétegek közötti adatátadásra a DTO-k használatosak, aminek több oka is van: áttekinthetőség, az interfészek állandósága (csak egyetlen

64 6.3. A logikai rétegek és keretrendszerek együttműködése 53 paraméter szükséges), teljesítményviszonyok ([10]). Mivel egy web- és EJB modulban is használt elem, ezért ideális az egyszerű validációs funkciók ellátására: az egyszerű formai ellenőrzéséket itt megvalósítva az elérhetővé válik közvetlenül a felhasználói akciókezelést követően (FORM feldolgozásának megkezdésekor), így hibás esetben nem szükséges az EJB hívás. Érvényes esetben pedig az üzleti logika oldalán is meghívható ugyanez az ellenőrzés (így nem kell redundás forráskódot készíteni), kiegészítve természetesen a bonyolultabb (például adatbázis-elérést használó) ellenőrzésekkel. Ugyanígy a DTO tartalmazhat metódusokat a konzolra történő kiíráshoz, a hash képzéshez vagy egy másik objektummal való egyenlőség vizsgálatához. Spring + Hibernate kombináció és EJB3 esetén POJO használata miatt elegendő, ha azok sorosíthatók, így nem szükséges az entitás objektumok mellett új objektumokat létrehozni (így minden DTO lekérdezés helyén kihagyhatunk egy objektum létrehozást). Az ellenőrzések itt is megadhatók ezeknek az objektumoknak a metódusaként, ekkor érdemes egy adott interfészt létrehozni, mely alapján ezt az ellenőrzést minden entitás esetén azonos néven lehet hívni. EJB 3 esetén ezek az ellenőrző metódusok annotációval is így a futás során automatikusan kivétel generálódik hibás adat mentésének kísérletekor. Amikor az objektum adatbázisból betöltött entitást tartalmaz, akkor a funkciónak megfelelően hasznos lehet a kapcsolódó entitás értékét is beállítani (pl. egy fórum hozzászólás esetén a fórumot is, így ezek az adatok is könnyen megjeleníthetők), más esetben ez külön hívással végezhető el (pl. fórum hozzászólásainak listázása fórum lekérdezését követően); ezek a lekérdezett adatok mennyisége és a szükséges adatbázislekérdezések száma alapján optimalizálhatók. Adatbázisba írás esetén a kapcsolódó entitások azonosítója külön paraméterként (sorosított objektumok) vagy attribútumként (DTO) adhatók meg, így az üzleti logika egy lekérdezést követően tudja beállítani a kapcsolatot. Gyakran használt funkció még az adatobjektum kiírása, összehasonlítása más objektummal és hash érték képzése, ezért ezeket a metódusokat is érdemes a DTOban megvalósítani. A korszerű fejlesztőrendszerek már kisebb-nagyobb mértékben támogatják a DTO-k entity bean-ekből történő generálását.

65 6.3. A logikai rétegek és keretrendszerek együttműködése Egyszerűsítések Java 5 használatával A Java 5 használatával (melyet már az alkalmazásszerverek jelentős része támogat vagy a közeljövőben támogatni fog) több helyen áttekinthetőbb, egyszerűbb forráskód készítésére van lehetőség, például: áttekinthető iteráció for-ciklus használatával, Iterator típus és kézzel történő típuskonverzió nélkül felsorolástípus alkalmazásával az elgépelési hibák száma csökkenthető, mivel azok már fordítási időben kiderülnek a kivételkezelés az előző felsorolástípus és üzenetköteg (bundle) felhasználásával egyszerűen megvalósítható: a validálás és feldolgozás során előforduló hibák gyűjteményét (Collection) egy kivételben a megjelenítő réteghez visszajuttatva az a megfelelő nyelvi szöveget tudja megjeleníteni Közös és gyakori funkciók Az üzleti funkciók jelentős része használja a közös funkciókat, ide tartozik például az küldés és a logolás. Ezeket az áttekinthetőség és karbantarthatóság miatt célszerű egy helyen megírni. Erre egyszerű web alkalmazás esetén hasznos lehet a Singleton tervezési minta, EJB esetén pedig vagy külön session bean vagy egyszerűbb esetben elegendő egy közös ősosztály (ekkor minden leszármazott eléri a funkciókat és nem kell a JNDI mechanizmust használni). EJB esetén a JNDI lekérdezéseket is egy ősben érdemes megvalósítani, viszont EJB 2.1 esetén mellette még a telepítési leíróban (ejb-jar.xml) is fel kell venni a hivatkozásokat. Az üzleti osztályoknak még a következő gyakran használt metódusait érdemes megemlíteni: entitások mentése vagy módosítása (saveorupdate) entitások törlése (delete)

66 6.3. A logikai rétegek és keretrendszerek együttműködése 55 entitás lekérdezése azonosító alapján, ha nincs ilyen, akkor kivétel vagy üres objektum visszaadása (getbyid) entitások egy csoportjának lekérdezése (mind, kategória szerinti, dinamikusan, például időpont vagy állapot alapján előállított feltétel szerinti) Mivel ezek a funkciók a legtöbb entitás esetén szükségesek, ezért érdemes általános, több helyen használható, paraméterezhető formában megvalósítani: EJB 2.1 session bean-ek Ebben az esetben a közös ős tartalmazza a logolásért és a letöltő felhasználó lekérdezéséért felelős részeket, az entitások mentését előkészítő általános részt és az előbb említett JNDI lookup metódusokat is. Az AbstractDTO egy olyan osztály, melyben a DTO interfész metódusai absztrakt metódusok és több DTO esetén használt közös metódusokat tartalmaz (például külünböző típusú objektumok egyenlőségének vizsgálata). public class AbstractManagerBean { protected SessionContext context; protected void log(string logmessage) { lookuplogmanagerbean().log(new LogEntry(logMessage, Level.INFO, getcallerusername())); } protected void log(string logmessage, String source) { lookuplogmanagerbean().log(new LogEntry(logMessage, Level.INFO, getcallerusername(), source)); } protected String getcallerusername() { Principal principal = context.getcallerprincipal(); return principal.getname(); } protected Long getcalleruserid() {

67 6.3. A logikai rétegek és keretrendszerek együttműködése 56 } UserLocal user = getcalleruser(); if (user!= null) { return user.getkey(); } return null; protected Long presaveorupdate(abstractdto dto) throws StarofficeException { Collection<ErrorCodes> messages; if (dto == null) { messages = new Vector<ErrorCodes>(); messages.add(errorcodes.unexpectederror); throw new StarofficeException(messages); } Long key = dto.getkey(); messages = dto.check(); // throw exception after bad parameters if (messages.size() > 0) { throw new StarofficeException(messages); } return key; } protected Long getnextkey(string entityname) throws CreateException { Long key = null; KeyGeneratorLocalHome keygeneratorhome = lookupkeygeneratorbean(); KeyGeneratorLocal keygenerator = null; try { keygenerator = keygeneratorhome. findbyprimarykey(entityname); } catch (FinderException ex) { try { keygenerator = keygeneratorhome. create(entityname);

68 6.3. A logikai rétegek és keretrendszerek együttműködése 57 } } } catch (CreateException e) { throw e; } } finally { key = keygenerator.getnextvalue(); } return key; 6.1. Absztrakt menedzser ősosztályának részei Ezután például egy könyvtár mentése a 6.2. forráskódon látható: először a kulcs lekérdezése szerepel a paraméter alapján (ez kivételt dob validálási hiba esetén), majd új entitás létrehozása vagy meglévő betöltése következik a kulcstól függően. Ezután jön az adatok majd a kapcsolatok beállítása. public ReturnType saveorupdatedirectory( DirectoryDTO directorydto) throws StarofficeException { Long key = presaveorupdate(directorydto); DocDirectoryLocal directory = null; try { if (key == null) { key = getnextkey("directory"); directory = directoryhome.create(key); } else { directory = directoryhome.findbyprimarykey(key); } } catch (FinderException ex) { log("cannot find directory", "DMBean::souDirectory"); throw new MyExceptionErrorCodes.UnexpectedError); } catch (CreateException ex) { log("dir or pk not created", "DMBean::souDirectory"); throw new MyExceptionErrorCodes.UnexpectedError); } directory.syncwithdto(directorydto); if (directorydto.getparent()!= null) {

69 6.3. A logikai rétegek és keretrendszerek együttműködése 58 } try { DocDirectoryLocal parent = directoryhome. findbyprimarykey(directorydto.getparent()); directory.setparent(parent); } catch (FinderException ex) { } } log("dir #"+key+" is created", "DMBean::souDirectory"); return new ReturnType(key, new Vector<ErrorCodes>()); 6.2. EJB 2.1 saveorupdate példa Az entitások validálása megadható az entitás osztályok ejbstore metódusában is, viszont ekkor a kliens oldali részeken ezeket külön is meg kell írni. EJB 3 session bean-ek EJB 3 esetén nem szükséges validációs részeket az ősosztályban elhelyezni, ezeket meg lehet adni az entitás osztályában annotációkkal megjelölve. Az attribútumokra pedig egyesével lehet állítani, hogy azokra milyen feltételek teljesülhetnek (lehet-e null értékű, lehet-e módosítani, lehet-e üres,... ). Ezekkel a logika rész a 6.3. forrás szerint egyszerűsödik. A flush metódus hívása az adatbázisban előállított értéket frissíti vissza a memóriában lévő objektumba (ez nem mindig szükséges, de pl. PostgreSQL szekvenciák mellett meg kell adni). public ReturnType saveorupdatenewscategory( NewsCategory newscategorydto) throws MyException { if (newscategorydto.getkey() == null) { // initialize entity em.persist(newscategorydto); em.flush(); } else { em.merge(newscategorydto); } Long key = newscategorydto.getid(); return new ReturnType(key, null); } 6.3. EJB 3 saveorupdate példa

70 6.3. A logikai rétegek és keretrendszerek együttműködése 59 A JNDI mechanizmus egyszerűsítése miatt már nem szükséges lookup metódusokat hívni, a hivatkozások deklarációjánál elég annotáció használata (dependency injection) Megjelenítő réteg elemeinek különválasztása Az MVC tervezési mintát követve a megjelenítésben külön válik a megjelenített tartalom, a megjelenítő logika és a vezérlés. A megjelenített tartalmat tovább is lehet bontani: HTML vázra (template) és szövegekre. A szövegek lehetnek statikusak (pl. egy oldalon a főmenü elemei) vagy dinamikusak (pl. almenü, hírek szövege). Üzenetkötegeket használva külön lehet választani az oldalak szerkezetétől a statikus szövegeket, ráadásul kellemes mellékhatásként ezzel az oldal statikus része könnyen többnyelvűvé tehető (egyszerűen egy kulcs érték párokat tartalmazó file-ban kell megírni a másik nyelv szövegeit és új néven elmenteni), azután a megjelenítő oldalvázban már elég a kulcsokat használni. JSF esetén az f:loadbundle tag segítségével tölthető be egy ilyen üzenetköteg, Wicket esetén pedig a komponens HTML váza mellett egy vele megegyező nevű.properties file létrehozásával. Dinamikus elemeknél a többnyelvűség támogatása kicsit összetettebb, ekkor ugyanis az üzleti logikának a műveletek során a nyelvnek megfelelő entitásokra kell szűrni (pl. hírek, fórumok, események, feladok). A navigáció esetén hasznos a JSF esetén megjelent, oldalak közötti navigációt XMLben leíró megoldás, melyet egyszerűen lehet alkalmazni Wicket esetén is: a legfelső szintű oldal ősosztályban DOM használatával felépíthető egy navigációs struktúra, melyet az akciókezelő komponensek meg tudnak hívni Jogosultságok kezelése A felhasználók több csoportja különíthető el, akik a szolgáltatások különböző köréhez férnek hozzá. A beléptetés (hitelesítés, authentikáció) ellenőrzi egy felhasználóról, hogy valóban az-e, akinek állítja magát, míg a jogosultság-ellenőrzés (engedélyezés, authorizáció) egy erőforrás elérését teszi lehetővé vagy tiltja meg. Az üzleti logika kiszolgálhat megbízható és nem megbízható megjelenítő rétegeket is, ezért a jogosultságok kezelését a szolgáltatásokban is figyelembe kell venni. Ilyen

71 6.3. A logikai rétegek és keretrendszerek együttműködése 60 lehet például felhasználói adatok lekérdezése esetén a rejtett mezők kezelése: a vendégek, a belépett felhasználók, az adminisztrátorok és a privát csoportok tagjai az adatok különböző halmazát láthatják, ezt a szűrést pedig már az üzleti oldalon el lehet végezni. Néhány authentikációval és authorizációval kapcsolatos lehetőséget a fejezet mutat be Megjelenített komponensek egyedi komponensek [beleértve az oldaltöredékeket, oldalakat is] validáció lehetősége (web rétegben, néhány esetben kliens oldalon is) komponensek újrahasznosítása azonosan: megjelenítés több helyen leszármaztatva: hasonló megjelenítés, például regisztráció / opcionális (feltételtől és szereptől függő) megjelenítés A megjelenítő réteg még a következő általános funkciókat tartalmazza: egységes kódolás (UTF-8) használata: a lekért HTML oldalak és a megadott adatok egységes kódolást használva jelennek meg, ezt egy filter biztosítja hibaoldalak (403, 404): a gyakori hibaoldalak egyedi felüldefiniálása, a 403-as hibaoldal jelenik meg akkor is, amikor az oldal megtekintéséhez szükséges jogosultsággal nem rendelkezik a felhasználó belépés, kilépés kezelése: ha egy link megtekintéséhez belépés szükséges, de vendégként nyitja meg egy látogató, akkor automatikusan a bejelentkező oldal jelenik meg, majd belépést követően az eredetileg kért oldal jelenik meg letöltések: bináris adatok kiszolgálása, neki megfelelő MIME típussal; a kérés paraméterében szereplő azonosító láthatóságát a szerver ellenőrzi és egy webről nem elérhető könyvtárból szolgálja ki a tartalmat

72 6.4. Néhány példamodul Néhány példamodul Az eddig leírtakat a következő példák szemléltetik. A Hírek modul a legtöbb rendszerben megtalálható, ezért alkalmas az összehasonlítások bemutatására. A szavazógép felülete pedig kicsit bonyolultabb, ezért a megjelenítő rendszerek jellegzetességeinek vizsgálatára alkalmas, valamint az üzleti logika is kicsit nagyobb mennyiségű ellenőrzést tartalmaz (jogosultságok, szavazott-e már a felhasználó az adott szavazáson) Hírek funkciók: aktuális, archív hírek és egy teljes hír megjelenítése, adminisztráció (felvétel, módosítás, törlés) szerepek: vendég, belépett felhasználó, hír adminisztrátor A hírek néhány entitással is kapcsolatban állnak: pontosan egy kategóriába tartoznak és változó számú (0..) csoport tekintheti meg. Ezen kívül a szerző felhasználóra vonatkozó hivatkozást is tartalmaznak. A megjelenítő oldalak viszonylag egyszerűek, csak a csoportba tartozás vizsgálata szükséges. Ez egy összetett lekérdezéssel valósítható meg legegyszerűbben: csak azokat a híreket adja vissza a logikai réteg, melyek a belépett felhasználó csoportja számára láthatók. A 6.4. lekérdezés érdekessége, hogy az EJB3 szabványban már az előzőeknél könnyebben használhatók az objektumok közötti navigációk és a JOIN műveletek: a news.groups.id kifejezés egy adott hírhez kapcsolódó összes csoport azonosítóját vizsgálja, míg a memb.group.id kifejezés segítségével a belső lekérdezés implicit módon tartalmazza a Group osztályt és az a JOIN kulcsszóval könnyen összerendelhető a felhasználóval. SELECT DISTINCT news FROM News news WHERE news.expire > :expire AND news.groups.id IN ( SELECT memb.group.id FROM Member memb JOIN memb.user usr WHERE usr.id = :usrid)

73 6.4. Néhány példamodul 62 ORDER BY news.creation DESC" 6.4. Hírek lekérdezése belépett felhasználóhoz Az előző lekérdezés negatívuma, hogy a külső lekérdezés az adatbázis-kommunikáció során használt SQL parancsban a Groups tábla kapcsolását is tartalmazza, amire nincs szükség: a hírek csoportok összerendelés ugyanis tartalmazza a csoport azonosítóját és a feltétel ez alapján is kiértékelhető. A külső kérésben explicit módon megadva a JOIN news.groups kifejezést, majd erre alkalmazva a csoportokra vonatkozó vizsgálatot elkerülhető az előbb említett fölösleges kapcsolás is (ezt a jobb adatbázis-kezelő rendszerek belső értelmezés során elintézik) ábra. Példa: hírek szerkesztése A felhasználói felület oldaláról az adminisztráció érdekes még: egy hír szerkesztésénél legördülő menü, jelölőnégyzet csoport, dátum beviteli mező komponensek is előfordulnak, ezek esetén is biztosítani kell a modellhez való kapcsolást (binding), alapértelmezett értékek megjelenítését (módosításnál aktuális kategória, aktuális csoportok). A hibakezelés során a hiba helyének pontos jelzése szükséges: például az adott mező szegélye és címkéje feltűnő színű lesz és egy összegzés helyen a hiba szövege látható. A kötelező mezőket szerencsés előre jelezni, ami így sok esetben azok hiányából adódó fölösleges szerver oldali feldolgozást előz meg. Egy oldal megjelenítése során hasznos még az azzal szoros kapcsolatban álló navigációs elemeket megjeleníteni egy erre a célra fenntartott helyen. Ebben a példában a

74 6.4. Néhány példamodul 63 hír szerkesztése mellett szerepel a hír törlése és a szerkesztés megszakítása. Ez szintén a navigációs útvonalak hosszát, így közvetve a szerver lekérések számát csökkenti Szavazógép funkciók: aktuális, archív szavazások megjelenítése, szavazás, adminisztráció (listázás, felvétel, módosítás, törlés) szerepek: vendég, belépett felhasználó, szavazás adminisztrátor A szavazógép esetén az egyszerű funkciók bonyolultsága hasonlít a hírekére: megjelenítés és adminisztráció. Ezt egészíti ki a szavazás, mely során az alkalmazás logika ellenőrzi, hogy valóban jogosult-e az illető a szavazásra (csoport-tagság, eddig még nem szavazott), majd atomi módon elvégzi a szavazást. Itt a lekérdezések egyszerűsítése (és hatékonysága) miatt célszerű aggregátumokat tárolni, például egy szavazáson leadott szavazatok száma, egy pontra leadott szavazatok száma. Az aktuális szavazás több formában jelenik meg: vendégként csak a lehetőségek láthatók, belépve a szavazni is lehet (űrlap komponensek jelennek meg), adminisztrátorként, illetve szavazást követően pedig az eredmények is láthatók (utóbbi esetben az űrlap elemek eltűnnek) ábra. Példa: szavazás szerkesztése Ebben az esetben is a szavazás szerkesztésének felhasználói felülete (6.9. és ábrák) tartogat kisebb kihívást: egy szavazáshoz új pont felvételének felhasználóbarát megvalósítását. Ennek legegyszerűbb módja többsoros szövegbeviteli mező használata,

75 6.4. Néhány példamodul ábra. Példa: szavazógép; virtuális formok Java Studio Creator 2-ben melyben soronként számozva, elválasztó karakter után szerepel a pontok neve. A számozásra a későbbi módosítás miatt van szükség: módosításkor is lehetőséget kell teremteni új pontok beszúrására, régi törlésére, nevének megváltoztatására a szavazatok számának figyelembe vétele mellett. Különböző JSF keretrendszerek tartalmaznak hasonló funkciójú komponenst, viszont ezek nem teljesen felelnek meg az elvárásoknak (létező pont átnevezése, rendezés), így legyegyszerűbb saját komponenst készíteni, mely így nem függ a gyártók verzió-frissítéseitől sem. Az első ábrán egy Wicket, a másodikon egy Creator 2 JSF megoldás látható. A rendezést a fel és le irányú nyilak teszik lehetővé (a hozzájuk kapcsolódó akciókezelők változtatják meg a lista elemeinek sorrendjét), az átnevezés pedig az új opció felvételéhez használt mező és egy kiegészítő gomb elhelyezésével valósítható meg. Ezekben az esetekben a validációk is az eddigiektől eltérő megoldást kívánnak: az opciók felvétele esetén ugyanis nem kell ellenőrizni a cím mező kitöltését, míg a felvétel esetén az új pont felvételéhez tartozó mezőt. Wicket esetén ezt az akciókezelő metódusokban, Creator 2 JSF esetén pedig úgynevezett virtuális űrlapok segítségével lehet megoldani. A virtuális formok egyetlen akciókezelő elemet (gomb, link) és néhány bevi-

76 6.5. Egy modul megírásának lépései 65 teli mezőt tartalmaznak és a keretrendszer gondoskodik arról, hogy a feldolgozás során csak az akciókezeléshez kapcsolódó mezőket validálja Egy modul megírásának lépései Egy modul elkészítése a következő pontok segítségével foglalható össze. Az (EJB2) -vel jelölt pontok csak EJB 2 használata esetén szükségesek. 1. Entity bean megírása 2. DTO megírása (EJB2) (a) mezők felvétele (EJB2) (b) check() metódus (c) getdto() és setupfromdto() metódusok (EJB2) (d) equals() és hashcode() metódus 3. Hibaüzenetek (kulcsok) összegyűjtése 4. Session bean elkészítése (a) üzleti funkció összegyűjtése (b) (junit) tesztesetek megírása (c) üzleti funkciók megvalósítása 5. Tesztek futtatása, értékelése 6. Felhasználói felület JSF alapú felület, Java Studio Creator 2 használatával (a) kapcsolódás a Creator 2 -höz: EJB importálása (b) felület összerakása (drag and drop lehetőség) (c) visszahelyezés NetBeans alá: i. EJB híváshoz szükséges csomag átmásolása

77 6.5. Egy modul megírásának lépései 66 ii. csomagnevek, hivatkozások frissítése iii. oldalvázakra illesztés (Facelet) iv. új nyelvi elemek bevezetése (hibaüzenetek felsorolás típussal, kollekciók típusának megadása) v. tesztelés Wicket alapú felület, NetBeans 5.5 használatával (a) oldal osztály és komponensek származtatása (b) egyedi paraméterek beállítása (helyi menü pontjai, URL paraméterek) (c) HTML elészítése (d) Wicket komponensek beillesztése, kiegészítés validációval portál környezetbe illesztés (Portal Server esetén): Portlet megírása: web modul másolása és portlet leíró (portlet.xml) megírása Feltöltés (deploy): másolás a szerverre, telepítés parancssorból; Sun Portal Server 7 esetén webes felületen keresztül is elvégezhező Portál konfigurálása: a portletek megfelelő tárolókban történő elhelyezése, paraméterezése Eszközök a fejlesztés támogatásához Az előző pontokat követve több fejlesztőeszköz is használható az alkalmazás elkészítése során. A többivel szemben a NetBeans alapú megoldás előnyei a következők: kis méret, könnyű telepíthetőség, egyszerű integráció a vizsgált alkalmazásszerverekkel (Sun AS, JBoss, Tomcat) a megjelenő új szabványok, keretrendszerek gyors támogatása (Java 5, EJB 3), fogd-és-vidd JSF fejlesztőkörnyezet (Creator 2), új komponensek támogatása a fejlesztőrendszer és a munkakönyvtárak áttekinthetősége Ugyanakkor néhány szempontból rosszabbnak bizonyult a több kornyezettől:

78 6.5. Egy modul megírásának lépései 67 több párhuzamos fejlesztésből adódó inkompatibilitás (5, 5.5, 6; Studio Creator 1, 2; Studio Enterprise 8); erre a lehetőségek telepítése pluginként jelent megoldást Azonosítás, szerepek kezelése Az alkalmazások több megoldás szerint is ellenőrízhetik a kérések jogosultágát. Ezek közül a leggyakoribb az előző részben már ismertetett beléptetés és a jogosultság ellenőrzése, ami ugyancsak több módon is elvégezhető: a teljes folymatatot az alkalmazás végzi (beléptetés, lekérések között az azonosítás megőrzése, hozzáférés ellenőrzése) JAAS (Java Authentication and Authorization Service, Java Hitelesítő és Engedélyező Szolgáltatás 1 ) használatával: az ellenőrzéseket egy authentikációs modul végzi, melyet külön kell telepíteni a szerverre, a belépett felhasználóhoz kapcsolódó Principal objektum kezelését viszont az alkalmazás végzi az alkalmazásszerver J2EE mechanizmusával: ehhez is szükséges egy modul megírása, viszont itt a felhasználók követését, az ellenőrzéseket teljes mértékben a konténer végzi Az első megoldás hátránya, hogy sok kódolást igénylő, egyedi megoldás. Az alkalmazás készítőinek kell biztosítani, hogy minden egység azonosan értelmezze az eltárolt adatokat, azok legyenek konzisztensek, a felhasználó navigációja során folyamatosan legyenek elérhető. A web session kezelését, lejáratát az alkalmazásnak kell kezelni. A megoldás hiányossága még, hogy az EJB konténerben újabb hitelesítés szükséges, melyhez a jelszót a web rétegben az azonosítást követően is tárolni kell, vagy teljesen megbízhatő kliens réteg szükséges (szoros illesztéssel, nehézkesen használható interfészekkel, a szolgáltatások nehéz újra felhasználásával). Mivel a használatához nem szükséges külön tanulás, ezért a legegyszerűbb, néhány szolgáltatást nyújtó, nem újrahasznosítható esetekben jöhetnek csak számításba. A második megoldás annyiban különbözik, hogy a hitelesítéshez és engedélyezéshez szükséges lekérdezéseket (adatbázis, LDAP) nem az alkalmazásban, hanem külön modulban kell megírni, valamint az EJB oldalon elérhetők ezek az információk. 1 a UNIX rendszerekben megszokott PAM (Pluggable Authentication Module) Java megfelelője

79 6.5. Egy modul megírásának lépései 68 A modul szabványos interfésszel rendelkezik, így több helyen is fel lehet használni (például több alkalmazás közös felhasználó adatbázissal). A belépést követően a felhasználóhoz kapcsolódó Principal objektum az EJB oldalon is elérhető, amiről a new InitialContext() parancs gondoskodik ábra. Realm létrehozása Glassfish alatt (3. eset) A harmadik esetben is szükség van egy modul megírására (főbb elemei megegyeznek az előzővel). A modulra jellemző, hogy erősen alkalmazásszerver specifikus. Ezen kívül viszont minden szabványos módon kezelhető: ezek egy része deklaratívan, egy másik része programozottan adható meg. A következő lehetőségek érhetők el: az alkalmazás (vagy a szerver globálisan) beállíthatja a birodalmat (realm), melyet az előbb említett kiegészítő osztály határoz meg a felhasználók szerepét a csoport-tagságok alapján állítja be (XML leíró) a web modul: megadja a bejelentkező oldalt, ami megjelenik akkor, ha a kérés egy szereppel elérhető URL-re vonatkozik megadja a hibák esetén megjelenő oldalakat (hibás belépés, 403 oldal a belépést követő hiányzó jogosultság esetén) getremoteuser, isuserinrole, getuserprincipal metódusok segítésével kérhetők adatok a lekérő felhasználóról URL-ekez szerepeket rendel, így a letölthetőséget korlátozza (XML)

80 6.5. Egy modul megírásának lépései 69 JSF esetén néhány kiegészítés (pl. MyFaces) esetén használható szerepekkel kapcsolatos vizsgálat (visibleonuserrole), Wicket esetén az ellenőrzést követően a Java forrásban állítható be, hogy egy komponens megjelenjen vagy ne az EJB modul: eléri a web konténerben található belépési információkat (iscallerinrole, getcallerprincipal) a session bean-ekhez és azok metódusaihoz való hozzáférést korlátozhatja bizonyos szerepekre, vagy megtilthatja mindenki számára (XML) a teljes session bean-re vonatkozóan beállíthatja, hogy az abból indulú hívások milyen szerepnek látszódjanak (runas) (XML) EJB oldalon a deklaratív és programozott ellenőrzések (ilyen sorrendben) egymás után is következhetnek (például egy felhasználó adatainak letöltésekor deklaratívan megadható, hogy csak belépett felhasználók érjék el ezt a szolgáltatást, majd saját vagy adminisztrátori szerep esetén a teljes adat visszaadható, egyéb esetekben pedig egy szűrő a megadott láthatóság alapján szabályozhatja a visszaadott eredményt). Az EJB esetén az XML-lel jelölt deklaratív részek EJB 3 esetén annotációkkal is leírhatók. Glassfish esetén az authentiációs modult a domain (és a szerver) lib könyvtárában kell elhelyezni és a login.conf file-ban kell felvenni a birodalmat, WebSphere esetén a szerver lib/ext könyvtárában kell elhelyezni a modult. Mindkét esetben a hozzá szükséges adatbázis kapcsolódáshoz szükséges meghajtónak is elérhetőnek kell lenni. Komplex oldal(ak) esetén többek között egyszeres belépést (SSO, Single SignOn), központi hitelesítést, a felhasználók, csoportok, szerepek, szolgáltások hierarchikus tárolását teszik lehetővé a Hozzáférés Menedzserek (Access Manager), melyek a portál és hagyományos J2EE rendszereken kívül más alkalmazásoknál is felhasználhatók. Ezek alapján egyszerű (néhány oldalból álló), prototípus vagy azonosítás nélküli rendszerek esetén az első megoldás is elfogadható, mivel ehhez nem szükségesek külön beállítások az alkalmazásszerveren. Ha szerepekhez kapcsolódó funkciókat tartalmaz az alkalmazás, akkor már az elején érdemes a harmadik esetet alkalmazni a szabványos és átlátható vizsgálatok miatt.

81 7. A rendszerek értékelése és összehasonlítása A technológiák és konkrét megvalósítások ismertetését követően ez a fejezet összefoglalja az egyedi vonásokat, az előnyös és hátrányos tulajdonságokat és különböző szempontok szerint összehasonlítja a megoldásokat Üzleti réteg A három bemutatott lehetőség (Spring + Hibernate, EJB 2, EJB 3) közül mindegyik esetén található olyan terület, melyen hatékonyan alkalmazható. Az EJB 2.1 legfőbb előnye, hogy robosztus, szabványos és a nagy gyártók támogatják. A Spring + Hibernate páros olyan esetekben lehet hasznos alternatíva, amikor nem szükséges a teljes EJB (és alkalmazásszerver) funkcionalitás (például szerepek, tranzakciók, üzenetsorok, monitorozás, fürtözés elhagyhatók), ilyenkor ugyanis kisebb a futtatókörnyezet erőforrásigénye is. Az EJB 3 szabvány sok tekintetben az EJB 2 utóbbi rendszerek egyszerűsítéseit alkalmazó változata. A fejlesztők szempontjából leginkább az új lehetőségek (pl. perzisztens réteg új elemei) és az egyszerűsítések (gyártófüggő XML leírók helyett annotációk) a legfontosabbak. A Java EE (JSR-244) és ennek részét képező EJB 3 (JSR-220) szabvány végleges változatai május 11-én jelentek meg. Párhuzamosan készülnek az ezt támogató alkalmazásszerverek is: Glassfish 1 (mintaimplementáció), JBoss, Oracle. A perzisztens réteget támogató két legjelentősebb rendszer: Toplink (Glassfish, Oracle) és Hibernate (JBoss). A szabványnak köszönhetően a perzisztens réteg a szervereken lecserélhető, például Glassfish alatt Hibernate perzisztencia használata könnyen beállítható. 1 a Glassfish PE (Platform Edition) végleges változata a szabvány napján jelent meg 70

82 7.1. Üzleti réteg 71 Spring Hibernate + Inversion of Control használata + bean-ek injektálása XML-ben egyszerűen megadható + beépített Hibernate támogatás + az üzleti logika POJO segítségével megoldható + könnyen tesztelhető - forráskódok és XML leírók redundanciája - nem szabványos megoldás + elterjedt ORM keretrendszer + könnyen használható (egyedül és együttműködve is) + annotációk használata (regebben XDoclet támogatás) + egyszerű adatbázis séma generálás + POJO használata + objektum-orientált lekérdezések - implementáció, nem szabvány EJB 2.1 EJB 3 + elterjedt, robosztus, szabványos + tervezési mintákra épül - sok része túlságosan bonyulult (JNDI, sok interfész) - ORM nehézségei (örökítés, DTO előállítása, adatbázis séma) - sok gyártóspecifikus elem (XML leírók, biztonság) - nehezen tesztelhető (konténer szükséges hozzá) + EJB 2.1, Hibernate, Spring kedvező tulajdonságait tartalmazza + új funkciókkal kiegészített perzisztencia réteg + nem szükséges külön DTO osztály +- adatok tárolásához persist hívása szükséges - jelenleg (2006. április) még csak szabványtervezet

83 7.1. Üzleti réteg 72 Hibernate + Spring EJB 2.1 EJB 3 adattovábbítás sorosítás DTO sorosítás O/R leképzés XML / XDoclet generált XML annotációk örökített entitás JOIN lekérdezés deklaratív jogosultságok - XML XML / annotáció tranzakciók kézzel konténer / kézzel konténer / annotációval / kézzel validálás DTO, check() DTO, check() annotáció adatok mentése DAO, Hibernate set metódusok saveorupdate metódusa üzleti logika hívása aszinkron üzenetküldés előre definiált szűrés.persist(),.merge() service locator service locator annotáció (Spring kontextus, (JNDI) + XML getbean) - message driven message bean táblázat. Üzleti rétegek összehasonlítása driven Az előző táblázatokon az egyes lehetőségek legfőbb előnyeit és hátrányait lehet látni, míg 7.1. táblázat a lehetőségeket és a különböző funkciókra biztosított megoldásokat veti össze. Gyakran használt, az EJB 3 szabványban nem szereplő kiegészítések: lusta (lazy) betöltésű objektumok leválasztása (detach), mely másik konténerben való felhasználásához szükséges (JOIN jellegű lekérdezés esetén erre van lehetőség a FETCH kulcsszó megadásával); ez a Hibernate.initialize() paranccsal vagy a forrás konténerben lekérdezést követő végiglépkedéssel oldható meg a kapcsolatok mentén lehetőség van deklaratív módon megadni a rendezést, viszont az EJBQL lekérdezéseknél ez nem szerepel a szabványban; megoldásként a lekérdezések dinamikus előállítása alkalmazható (a rendezés mezőit az entitás

84 7.2. Megjelenítési réteg 73 osztályok statikus konstans felsorolásaként megadva fordítási időben ellenőrizhető a felhasznált paraméterek helyessége) apró eltérések az implementációk között (ez elsősorban a megvalósítások hibáiból adódik), például COUNT eredményt adó EJBQL lekérdezés eredményét a Toplink (és a szabvány) Long, a Hibernate Integer típusú objektumban adja vissza entitások azonsító alapján történő törléséhez előbb be kell tölteni az objektumok, majd törölni; ez megfelel az OO szemléletnek, viszont két SQL parancsot jelent (csak a törléshez ebből a második is elég lenne) entitások kapcsolódása közötti több több, több egy kapcsolatban a Collection típus leszármazottjai nem minden esetben használhatók (ez az implementációtól is függ), így néhány esetben szükség lehet az ezek közötti átalakításra, amihez a specifikusabb típus irányú átalaításnál ciklus szükséges (például a felületen List típus vár egy előre megírt, pozicionálást használó komponens) az alapvető Object metódusok felüldefiniálása több művelet esetén szükséges (cache alkalmazása, web modulban történő akciókezelés során egyenlőség vizsgálata), ezért célszerű lenne generálni (például annotációkból, megjelölve az egyenlőség és a hash esetén figyelembe vett mezőket) cache alkalmazásának lehetőségét nem tartalmazza a szabvány (opcionális elemként sem), ezért ennek eléréshez implementáció-függő parancsok szükségesek persist és merge kiadása szükséges az entitások mentésekor (átlátszóság csökkenése) 7.2. Megjelenítési réteg A megjelenítő réteg megírására a középső rétegnél sokkal színesebb paletta használható, ezek közül a részletesen vizsgált rendszerek: JavaServer Faces és Wicket, illetve az ezekre merőleges portlet (JSR-168) technológia.

85 7.2. Megjelenítési réteg 74 A megjelenítő rendszerek nagy része JSP alapú. Ezek hasonlítanak a más (például PHP) webes nyelveken megszokott leírási módra: egy HTML-hez hasonló jelölő nyelven írhatók le a megjelenített elemek, az adatok pedig Java objektumokon (JavaBeanek) keresztül adhatók át. Itt a típuskezelés a script-nyelveknél fejlettebb, ugyanakkor a hibakezelés, navigáció, többnyelvűség, modellel történő összekapcsolás, (újrahasznosítható) komponensek használata még mindig nehézkes, sok redundáns, kézzel megírt struktúrálatlan elem szükséges hozzá. A JSF lehetővé teszi az említett problémák megoldását, a JSP szintaxisához hasonlóan, tag könyvtárak felhasználásával írhatók le az oldalak, illetve oldal töredékek. Valóban azonban ez nem teljesen a JSP kiterjesztése: JSP esetén a megjelenítést egy belőlük előállított servlet végzi (JSP = kifordított servlet) JSF esetén a megjelenítést egy servlet (Faces Servlet) végzi, mely a backing beanek, az oldal leírások (JSP-hez hasonló formátumú XML dokumentumok) és a konfigurációs leírók felhasználásával végzi Ezekből következik az is, hogy JSF oldalak esetén a tag könyvtárak nem használhatók a JSP-hez azonos módon, valamint az egyik legnagyobb hátránya, hogy a JSTL könyvtár sem alkalmazható (iterátorok, feltétel vizsgálatok). Az 1.2 -es szabvány (ami már a JEE 5-nek is része) már tartalmazza a két típusú (# és $) kifejezések egyenértékű kiértékelését is. A JSF összetett életciklus-modellje az akciókezelés széles körének feldolgozását lehetővé teszi, ugyanakkor a legegyszerűbb esetekben túl bonyolultnak tűnhet a használata. Az oldalak közötti navigáció látványos módon leírható (XML, melyet több grafikus eszköz feldolgoz), viszont a POST változók használata sok esetben nehézkes és kerülendő (például könyvjelzővel elmenthető oldalak). A megjelenítő rendszerek egy másik része nem is használ JSP-re emlékeztető jelöléseket. A Velocity egy egyszerű makró kiegészítés, mely HTML-ben használható, míg a fejlettebb rendszerek esetén teljesen szabványos HTML dokumentumok használhatók. Tapestry esetén a HTML leírókban a jwcid attribútum jelöli, hogy az adott helyre milyen komponens kerüljön, a paraméterek pedig ugyanannak a HTML tag-nek a paraméterei lehetnek. Egyszerűen definiálhatók egyedi komponensek is (a hozzá tartozó

86 7.2. Megjelenítési réteg 75 HTML és Java kód megírása szükséges), a szolgáltatások pedig Hivemind segítségével adhatók meg (dependency injection). Wicket esetén a HTML részekben csak néhány speciális tag-re (<wicket:child>, <wicket:panel>) és a wicket:id attritútumra lehet szükség, mely a komponenseket azonosítja. Ezt követően a hozzá kapcsolódó (azonos nevű) Java forrásokban a Swing-hez hasonlóan add metódussal adható meg az adott helyen szereplő komponens. A HTML kódok ekkor nem tartalmaznak semmi logikát, az teljes mértékben a Java forrásokban található, így a grafikusok dolga is egyszerűbb és a felületek összerakása egyszerű eszközökkel is gyorsan és könnyen elvégezhető, tesztelhető. Az új fejlesztési változatok több látványos funkciót is támogatnak (AJAX, jól kinéző URL), a testreszabhatóság miatt pedig könnyen kiegészíthető (például a JSF-hez hasonló navigációs leírással). JSF Wicket + szabványos, jó eszköztámogatás + sok kiegészítő komponensek + modellekkel jól leírható + navigáció leírása, állapotkezelés, validátorok, konverterek +- sokféle komponens készíthető, de ennek módja nehézkes - az életciklus-kezelés néha bonyolult, eltér a verziók között (1.x) - a kiegészítő készletek gyártófüggők - POST változók használata - JSTL-lel csak az 1.2 változat működik (iterátor komponens hiánya) + hagyományos szemlélethez közeli + az alakkészletben is gazdag elemkészlet (komponensek, AJAX, validáció) + egyszerűen készíthetők egyedi komponensek + könnyen bővíthető (ServiceLocator, navigáció) + újrafelhasználható komponensek + egyszerű hibakezelés - nem szabványos - még aktív fejlesztés alatt áll, kisebb fejlesztőközösség

87 Reference Impl. Creator 2 Websphere ADF Faces MyFaces elemkészlet alap kiegészített kiegészített gazdagon kiegészített kiegészített JSF verzió 1.0, 1.1 (, 1.2) (WS 6.0) fejlesztőkörnyezet Sun Java Studio IBM Rational jdeveloper Exadel Studio Creator 2 Software Architect felhasználhatóság, nyílt nyílt kereskedelmi kereskedelmi nyílt ár (nyílt) futtató szerver minden nem túl Sun AS, Sun PS, IBM Websphere Oracle AS Tomcat, Glassfish, régi web konténer Glassfish, Pluto Websphere, JBoss dokumentáció gazdag gazdag kevés gazdag gazdag facelet támogatás igen igen igen igen többé-kevésbé 7.2. táblázat. JSF implementációk jellemzői 7.2. Megjelenítési réteg 76

88 7.3. Összehasonlítás fejlesztői oldalról 77 JSF esetén a szabványos részek használata már nem elegendő egy korszerű alkalmazás elkészítéséhez, ezért a gyártók a gyakori igények kielégítésére összetett komponensekkel egészítették azt ki (fa, kiválasztó lista, tab,... ). Ilyen implementációk: Oracle ADF Faces, MyFaces, Java Studio Creator 2 és IBM RSA kiterjesztések. Ezek jellemzőit foglalja össze a 7.2. táblázat. A portál megoldás az eddig említett megjelenítő rétegeket használja fel az alkotóelemek (portletek) megjelenítésére, kiegészítve: felhasználó-kezeléssel, portletek közötti kommunikációval, állapotok és megjelenítési méretek használatával. A szabvány már régebben (2003) megjelent, majd később készültek el hozzá az újabb megjelenítő rendszereket (pl. JSF) alkalmazó, stabilan működő bővítések ( ). A Creator 2 beépítve tartalmaz JSF esetén is használható Pluto tesztkörnyezetet, melyet a januárban megjelent Sun Portal Server 7 szerverre változtatás nélkül lehet feltölteni. Wicket esetén az 1.2-es verzióban tervezik a JSR-168 szabvány támogatását (az 1.2-rc május 1-én jelent meg). A különböző gyártók portál szerverei ma már támogatják a JSR-168 szabványt, melyet egyedi elemekkel egészítenek ki. Az oldalak tartalma könnyen összeállítható, valalmint a testreszabhatóságot (tartalom, kinézet) is lehetővé teszi a szabvány és több előre elkészített komponens is használható (időjárás, hírforrások). Alkalmazásuk előtt fontos azonban megvizsgálni a nyújtott új funkciókat, az erőforrás- és üzemeltetési igényeket és a tervezett megoldás megvalósíthatóságát. A portletek közötti kommunikáció nem része a szabványnak, nem érik el a teljes futtató alkalmazást (pl. linkek oldalakra), a vezérlést leíró kódokat teljesen el kell különíteni és vannak népszerű webes keretrendszerek, melyeket nem támogat Összehasonlítás fejlesztői oldalról Az EJB 3 szabvány egyik fontos célja a fejlesztők dolgának megkönnyítése: a régebbi EJB szabványokkal való teljes kompatibilitás mellett a redundáns elemek és kézzel írt leírók számának csökkentése jellemzi. Ennek megfelelően az esetek többségében egyszerű Java osztályok (POJO) megírása is elég, azoknak nem kell EJB interfészeket megvalósítani, valamint a hely és távoli interfészek megadása sem szükséges külön file-okban.

89 7.3. Összehasonlítás fejlesztői oldalról 78 A másik fontos könnyítés a telepítési leírók egyszerűsítése: ezeket nem szükséges megírni, legtöbb bennük található elem a Java forrásokban annotációkkal megadható, ami két helyen jelent könnyítést: a leírók szerkezetét nem a fejlesztőkörnyezetnek kell ismerni, így nem kell az abban található grafikus editorokra hagyatkozni azok módosításakor (tranzakciók, biztonsági beállítások), ezek a beállítások a Java kód megfelelő helyén adhatók meg kevesebb gyártóspecifikus tulajdonságot kell figyelembe venni: a gyártófüggő részek nagy részét sem a felület, hanem az alkalmazásszerver állítja elő (EJB, JNDI, erőforrás hivatkozások) A függőségek feloldása (dependency injection) pedig a JNDI mechanizmust egyszerűsíti le nagy mértékben (alaposan megfigyelve a szerverre telepített alkalmazást a hagyományos megoldás látható, viszont ezt a fejlesztő elől elfedi az EJB 3 és az azt tartalmazó JEE 5 szabvány). Az egyértelműséget tovább növeli egy minta implementáció (Reference Implementation) létezése: a Glassfish alkalmazásszerver. Az alábbiakban néhány számszerű jellemző látható, a 7.3. táblázaton egy EJB 2.1 és EJB 3 összehasonlítás (példaalkalmazás: StarOffice 8 és MatekLap hírek, regisztráció és adatmódosítás részei), a 7.4. táblázaton pedig két webes rendszer összehasonlítás (MatekLap JSF és Wicket rendszerrel, EJB 3 -ra építve). A felhasznált jelölések: perzisztens osztályok száma (d): az alkalmazásban használt entitások száma szolgáltatás osztályok száma (s): a Use Case csomagok száma (szorosan összetartozó funkciók) szolgáltatások száma (s nyilvános metódusai): a Use Case -ek száma megjelenítő oldalak száma (v): a közvetlenül aktorokhoz kapcsolódó Use Case-ek száma A JSP és HTML számok JSF esetén statikus oldalak (belépés, hibák), megjelenő oldalak (v) és oldalvázak (template, 4 db); Wicket esetén statikus oldalak, megjelenő oldalak (v), komponensek összetevőkből állnak. Facelets használata nélkül (tisztán JSF

90 7.3. Összehasonlítás fejlesztői oldalról 79 EJB 2.1 EJB 3 Java osztályok száma domain.*: d d DTO.*: d 0 services.*: s s interfészek száma domain.*: 2d (3d) 0 services.*: 2d (4d) s XML leírók száma 3 1 ebből kézzel módosított táblázat. EJB2.1 és EJB3 mérőszámok megoldással) a megjelenő oldalak mindegyikét ki kellene egészíteni a vázban szereplő megfelelő részekkel (ez kb. 10 kb méretű). Wicket esetén a több újrahasznosítható komponens miatt van több HTML és Java file. JSF + Facelets Wicket JSP / HTML file-ok = = 23 ezek mérete (kb) = = 30.5 Java osztályok száma 9 24 ezek mérete (kb) ezek sorainak száma XML leírók száma 8 3 ezek mérete (kb) táblázat. Megjelenítő rendszerek mérőszámai a példára További olyan tényezők, melyek az egyes megvalósítások, keretrendszerek kiválasztásában szerepet játszanak: dokumentáció mennyisége, használhatósága (kitöltött JavaDoc, példák, bevált gyakorlatok, tervezési minták) támogatás (főrumok, levelezési listák, hibabejelentés); az itt feltett kérdésekre adott válaszok gyorsasága, helyessége, alkalmazhatósága Ezekben például a Wicket (és a Tapestry + Hivemind) megjelenítő keretrendszerek a JSF-nél jobbnak bizonyulnak, mivel JSF esetén nem létezik egységes, a többivel

91 7.3. Összehasonlítás fejlesztői oldalról 80 együttműködő megvalósítás és fórum, ahol mindegyik rendszerre alkalmazható és kellően részletes támogatás lenne elérhető A fejlesztőkörnyezetek lehetőségei Az előző részekben már szerepeltek a fejlesztőrendszerek általános jellemzői, itt az egyes környezetek és szabványok támogatásának összefoglalása látható (7.5. táblázat). A + a támogatást jelöli, - esetén a fejlesztőrendszer nem tartalmazza az adott funkciót, ~ jellel a kis mértékben támogatott esetek (a környezet tud róla) szerepelnek. NB 5 NB 5.5 WTP Exadel RSA JSC 2 J2SE UML EJB EJB DTO ~ ~ EJB hívás web.xml ~ ~ - JSF ~ ~ MyFaces Virtuális form táblázat. Fejlesztőkörnyezetek áttekintése Egyszerűsítő lehetőség entity bean-ekhez Az entitások fejlesztési szakaszában az entitások Object osztályból származó metódusainak (hashcode, equals, tostring) karbantartása sok időt igényel, ezért a Reflection API segítségével egy általánosabb, ugyanakkor teljesítményben gyengébb megoldás készíthető: JSE 5 annotációk segítségével megjelölhetők a figyelembe venni kívánt mezők (és get metódusok). A példában egy közös entitás ős konstruktora beállította az osztályok statikus tömbjében a felhasználandó metódusokat ezek hívásával kapta meg visszatérési értékét a hashcode és equals metódus

92 7.3. Összehasonlítás fejlesztői oldalról 81 A mérések 500, 1000, 2000, 5000 és objektum esetén, minden alkalommal 5 ismétléssel szerepelnek. A példában az objektumok létrehozása során azt minden megelőző objektummal is összehasonlítja a natív Java alkalmazás; ennek oka, az összehasonlítások gyakori alkalmazásából adódik: egy listában (például legördülő menü) kell kiválasztani az aktuális értéket (létrehozó és módosító oldalakon gyakran előfordul). Mivel ekkor az objektumok számával négyzetesen nő az összehasonlítások száma, valamint az esetek nem lineáris elhelyezkedésűek, ezért az adatok ábrázolását egy gyökvonás, majd egy logaritmus számítás előzte meg (7.1. ábra). A legnagyobb függvény ábrázolja a származtatott metódus használatát, a legkisebb az örökítés nélküli, teljesen megírt metódusokat. A középső görbe örökített kontruktorral és megírt összehasonlító és hash képző metódussal rendelkező esetre vonatkozik. A számítások során nem volt megfigyelhető különbség a get hívások, illetve az attribútumok közvetlen használata között ábra. Java Objektum metódusok felüldefiniálása

93 7.4. Lehetőségek tesztelésre 82 EJB 2 szabványt támogató fejlesztőrendszerek már automatikusan támogatták a DTO objektumokon belül ezeknek a metódusoknak a generálását, viszont használatuk körülményes maradt (az entitások változtatását követően szinkronizálásra volt szükség). A fejlesztés szakaszában az említett reflektív API-t használó módszerrel egy rugalmasabb, teljesítményben nem túlságosan elmaradó megoldás készíthető Lehetőségek tesztelésre A fejlesztések fontos része a tesztelés. Az üzleti logika tesztelésére már kifinomult módszerek léteznek, míg a felhasználói felület esetén szegényebb eszközkészletből lehet választani. Egy teszteset valamilyen művelet(sor) elvégzését és azt követően a kapott és elvárt eredmény azonosságának vizsgálatát jelenti. Az egység (unit) tesztek egy-egy metódus vizsgálatát tartalmazzák, az integráciciós tesztelés pedig több szolgáltatást együttműködését is vizsgálja. Egy osztály értékhatárainak vizsgálatára épülő (domain analysis) és állapotgráffal (state chart) leírt dinamikus működésnek megfelelő viselkedést ellenőrző tesztesetek is megadhatók. A tesztesetek csoportokba szervezhetők, valamint a csoportok hierarchiába is rendezhetők. Java esetén a junit keretrendszer használható ezek megadására és futtatására. Ezt sok fejlesztőkörnyezet beépítve is tartalmazza, valamint önállóan is futtatható, utóbbi esetben az eredmények szöveges és grafikus formában is megtekinthetők. Egyszerű Java alkalmazások esetén a junit rendszer könnyen használható, viszont J2EE rendszerek esetén az alkalmazások eltérő környezetben futnak (web és EJB konténerben), így kiegészítő megoldás szükséges az alkalmazásához. A legegyszerűbb esetben az EJB hívások egy kliens alkalmazásban találhatók, így a junit rendszer a kliensben használható. A kliens megoldásnak több hátránya is van: Local interface használata esetén a bean-ek nem érhetők el távoli hívással (a hívó félnek azonos JVM-en belül kell lennie). Legtöbb esetben az EJB hívások szerver oldali kódokból (servlet, JSP) indul, így

94 7.4. Lehetőségek tesztelésre 83 a kliens alkalmazás eltérő futtatókörnyezetéből adódóan eltérő teszteredmények keletkezhetnek. Az üzleti logika mellett a webes alkalmazások megjelenítő rétegének tesztelése is szükséges lehet ábra. A Cactus junit segédeszköz eredménye Ezekre megoldás kínál a Jakarta Cactus teszt keretrendszer, mely a junit teszteket egy servletben futtatja. A fejlesztés egyszerűsítése céljából ant taszk is definiálható, mely a teszt futása előtt szükség esetén elindítja, majd leállítja az alkalmazásszervert. A futási eredményeket XML formátumban állítja elő, mely XSL stílus megadásával jól áttekinthető, táblázatos formában jelenik meg (7.2. ábra). A TestNG keretrendszer a junit lehetőségeit egészíti ki, például Java 5 annotációkkal adhatók meg a tesztesetek, szervezhetők csoportba, valamint a futás eredménye az XML formátum mellett részletesebb, HTML formában is megtekinthető. A könnyűsúlyú alternatívák (pl. Spring) tesztelése is egyszerűbb az EJB 2 alkalmazásokénál, ugyanis a futtatókörnyezet sokkal egyszerűbben biztosítható és a teszteléshez nem szükséges az alkalmazászerver futása: az applicationcontect.xml helyének

95 7.4. Lehetőségek tesztelésre 84 megadásával állítható be a Spring IoC lehetőségét biztosító konténere, melyhez így telepítés (deploy) sem szükséges. Az EJB 3 bean-ek egyszerű Java osztályok (POJO), ezért a használatukhoz és így a teszteléshez sem szükséges alkalmazásszerver környezet (természetesen ekkor a szerver oldali, pl. JavaMail erőforrások sem érhetők el). A perzisztens réteg ez EJB 3 szabványban konténeren kívül, natív alkalmazásokban, így hagyományos junit tesztek esetén is használható. A 7.1. forrásban a tesztesetekhez szükséges EntityManager beállítása és a Hibernate session lezárása látható. public class UserManagerBeanTest extends TestCase { UserManagerBean instance = null; public UserManagerBeanTest(String testname) { super(testname); } protected void setup() throws Exception { instance = new UserManagerBean(); em = instance.getentitymanager(); if (em == null) { EntityManagerFactory emf = Persistence. createentitymanagerfactory("mateklaptestunit"); em = emf.createentitymanager(); } } protected void teardown() throws Exception { try { EntityManagerImpl hem = (EntityManagerImpl) instance.getentitymanager(); hem.getsession().getsessionfactory().close(); } catch (Exception e) { } } //... } 7.1. EJB 3 teszteset A web modulok tesztjei a felület elemeinek vizsgálatát, a felhasználói akciók szimulációját és az erre adott válaszok helyességének ellenőrzését is tartalmazzák. Erre

96 7.5. Teljesítmény viszonyok 85 kínál megoldást a jwebunit keretrendszer, mely képes a navigációt (linkek létezését és követését), űrlapokat (FORM-ok kitöltését és elküldését), akciókezelést követően oldal vizsgálatát elvégezni (7.3. ábra) ábra. jwebunit tesztelés 7.5. Teljesítmény viszonyok Ennek a résznek a célja egy példa alkalmazás válaszidejének vizsgálata. Különböző terheltségek mellett szerepelnek a válaszidők, EJB 2 és EJB 3 megvalósítás esetén A méréshez használt alkalmazás A mért érték mindkét technológia esetén egy-egy nyitóoldal letöltési ideje. Ez az adatbázisban szereplő hírek közül megjeleníti az aktuálisakat, néhány dinamikus tartalmat (adatbázisból származó szöveg, RSS hírek). A hírforrás elemei az első letöltést követően cache-ből érhetők el, a külső URL-hez kapcsolódást igénylő modulok (pl. képajánló) és külső hivatkozások a mérés során ki vannak kapcsolva. Ez a távoli függőségek leválasztása miatt szükséges.

97 7.5. Teljesítmény viszonyok 86 Az EJB 2 alkalazás tesztelése a StarOffice 8 nyitóoldalát, az EJB 3 teszt a MatekLap nyitóoldalát vizsgálta. A két alkalmazás esetén az üzleti- és megjelenítő logika, valamint az adatbázis lekérdezések azonos bonyolultságúak. Az egy letöltés során lekérdezett eredmények száma is megegyezik (8 rekord). A megjelenítő réteg mindkét eseteben JSF alapú, kiegészítve a Facelets keretrendszerrel A mérés környezete Az első méréshez használt konfiguráció lényeges elemei: szerver: 3 GHz Pentium 4 CPU (engedélyezett HyperThreading), 2 GB memória, SATA II háttértár (60 MB/sec olvasási sebesség bufferből) kliens: 100 Mbit/sec hálózaton keresztül kapcsolódik Az elosztott mérés konfigurációja (az IL.405. laborban): 3 GHz Pentium 4 CPU, a VMware környezetben 1 engedélyezett CPU, 1,5 GB engedélyezett memória, a csomópontok között 100 Mbit/sec hálózat. Az 5 db résztvevő számítógép funkciói szerint: 1 db Apache web szerver + JK modul terheléskiegyenlítéshez 1 db kliens 3 db azonosan beállított Glassfish alkalmazásszerver, helyi PostgreSQL adatbázissal 2 A méréshez használt parancs: httperf 3. Minden esetben 5000 kérés kiszolgálása szerepel, egyre növekvő másodpercenkénti letöltési szám mellet. Az oldalak kiszolgálásához időkorlát kapcsolódik [10 sec], ennek túllépése esetén a kérést sikertelennek (client timeout) értékeli az mérőprogram. A két mért alkalmazás a szerveren eltérő domain alatt szerepel, így lehetőség van csak a vizsgálathoz szükséges futtatására. A másodpercenkénti letöltések számát lépésenként 10-zel növelve meghatározható az a pont, mely fölött megjelennek az időtúllépés miatt sikertelen kérések. A legelső, 20 kérés / sec eset mérésére használat parancs: 2 Külön adatbázis szerver használata a később szereplő eredményeknél rosszabb teljesítményt adott, ennek oka a hálózat sávszélessége. 3

98 7.5. Teljesítmény viszonyok 87 $ httperf --verbose --timeout=10 --port=82 --server=joeb.sch.bme.hu \ --client=0/1 --port=82 --uri=/portal/index.faces --rate=20 \ --send-buffer= recv-buffer= num-conns=500 --num-calls= Eredmények Az elvárás alapján az első néhány esetben hibák (időtúllépés) nélkül lefut a kiszolgálás, egyre növekvő válaszidővel. Ezt követően egy ponttól kezdve a kérések egy részére nem érkezik válasz a megadott korláton belül, nagyobb mennyiség esetén pedig a kérések egyre kevesebb részének kiszolgálására képes a szerver. Ennek oka, hogy még a megelőző kérések feldolgozását végzi, így azokon kívül az új kérésekkel sem végez időben. Erre a hibára megoldás lehet a kapcsolatok várakoztatásának csökkentése (a mérés esetén ez az érték 10 sec), viszont a felhasználók szempontjából (bizonyos mértékik) a lassabb válasz kedvezőbb a nem elérhető szolgáltatás hibaüzenetnél. A következő ábrákon látható grafikonok és alattuk lévő táblázatok foglalják össze a mérési eredményeket. A tengelyek jelentése és mértékegysége: X-tengely: másodpercenkénti kérések száma [1/s] bal Y-tengely: válaszidő [ms], logaritmikus skála jobb Y-tengely: hibás válaszok (hiba és időtúllépés) aránya [%] Az elosztott eset környezetében elvégzett néhány mérés az egy szerveres felállításhoz hasonló eredményeket ad. Ennek célja a terheléskiegyenlítő működésének vizsgálata. Ekkor a kéréseket valóban egyenletesen kapják meg az alkalmazásszerverek. A kiszolgálók hibáját követően az adott irányba nem továbbít kéréseket a terheléskiegyenlítő. Egy webes felületen követhető a kiszolgálók állapota, a feléjük küldött kérések száma, valamint ugyanitt van lehetőség azok ki- és visszakapcsolására is. A 7.4. ábrán egy elosztott mérés kimenete látható, mely másodpercenként 150 kérést hajtott végre. Három kiszolgáló esetén, háromszoros kérésszám mellett a válaszidők hasonlók az eredeti kérésszám mellett egy csomópontnál mért értékekhez. Az elosztott esetben külön adatbázis szerver alkalmazása mellett viszont rosszabb eredmények születnek, melynek oka a hálózat. A kliens kiszolgálások és adatbázis adatforgalom is azonos, 100 Mbit-es hálózaton történik, így a 11 Mbyte/sec átviteli

99 7.5. Teljesítmény viszonyok 88 sebesség elérését követően nem növelhető tovább a közötti kérésszám [1/s] (a sávszélesség-kihasználtság például az iftop nevű paranccsal ellenőrizhető) ábra. Egy elosztott mérés kimenete [1/s] Kapcsolódás [ms] Válaszidő [ms] Hibák aránya [%] valódi ráta 20 24,4 23, ,7 34, ,6 28, ,7 236, ,7 766, ,2 798, ,9 1353, ,2 1595,3 6, ,1 2221,9 24,

100 7.5. Teljesítmény viszonyok 89 [1/s] Kapcsolódás [ms] Válaszidő [ms] Hibák aránya [%] valódi ráta 20 27,2 25, ,6 35, ,2 36, ,2 80, ,6 155, ,5 2340,3 6, ,7 2865,5 30, ,4 3288,7 42, Értékelés Az EJB 2 és EJB 3 megoldások során tapasztalt eredmények a várakozásoknak megfelelően nem térnek el jelentősen. Az alkalmazásszerver hasonlóan kezeli a két esetet (például az EJB 3 annotációk egy részéből a telepítés során hagyományos XML leíró részlet keletkezik). Mindkét rendszer másodpercenként kiszolgálást képes az említett környezetben kiszolgálni. Az EJB 2 alkalmazásnál az adatátvitel DTO használatával történt. Az első EJB 3 mérés során feltűnően rossz eredmények születtek, mely az entity bean-ek sorosítására volt visszavezethető: remote interface használata esetén a sorosítás nagyon sok CPU terhelést jelentett TopLink és Hibernate használatával is: 20 kérés / sec mellett 90 %-os kihasználtság az egy gépes rendszerben. Ezután ekkos is DTO-t alkalmazva ugyanilyen terhelés 80 kérés / sec esetén volt megfigyelhető. Megoldást jelent még a problémára local interface használata, ugyanis csak webes megjelenítő réteg esetén remote interface elsősorban csak valódi HA 4 esetén szükséges. 4 High Availability: nagy rendelkezésre állás, a szerverek Enterprise Edition változatán alakítható ki

101 8. Összefoglalás A korszerű webes rendszerek jelentős része J2EE alapú megoldás. Ezek az objektumorientált Java nyelvre épülnek, mely könnyen modellezhető. A platformfüggetlenség széles környezetben történő futtatást tesz lehetővé és mivel egy API gyűjteményről van szó, ezért a gyártók a szabványos elemeket egyéni lehetőségekkel egészíthetik ki. Rendszerek tervezésénél egyre fontosabb szempont a modellezés és ezt felhasználva alacsonyabb szintű modellek származtatása és forráskód generálása. Az UML szabványos, széles körben elterjedt modellező nyelv, melynek egyes elemeit a legújabb fejlesztőrendszerek már szervesen tartalmazzák, így lehetővé téve a platformfüggetlen modellből platformspecifikus (J2EE) modell, majd forráskód (Java osztályok, metódusok, üzleti funkciók) előállítását és ezeket érintő modell forrás szinkronizációt (reverse engineering). Ugyanakkor még sok területen nincs megfelelő eszköztámogatás (state chart felhasználása, szekvencia diagramm pontos jelentése nem szerepel a szabványban), így ezekben az esetekben a modell és alkalmazás közötti leképzés és ellenőrzés a fejlesztők feladata (az UML kifejezőereje nagyobb, mint a megvalósított alkalmazásé). A J2EE platform egy szabványos API gyűjtemény, melynek előnye, hogy a megvalósítás mellett azt a gyártók egyedi elemekkel egészíthetik ki. Ugyanez túlságosan szigorú szabványok esetén hátrány is, mivel könnyen sok, inkompatibilis megoldás terjedhet el. A tervezésnél ezért figyelembe vették a jellemző tervezési mintákat, bevált gyakorlatokat [10], valamint a gyártók és a fejlesztők is képviselhették érdekeiket (ezért a végleges verzió néha sok idő alatt készült el, mint az EJB 3 [JSR-244] esetén). Az így kapott szabványos megoldás felhasználásával készített alkalmazás biztosítja a gyártók közötti szabad választást, így egyéb szempontok (kiegészítések, teljesítmény, üzemeltetés, ár) is érvényesíthetők, valamint egyes komponensek más rendszerekben, más platformon, más gyártó termékén is használhatók. A szabvány a legtöbb esetben egy idő után elavul a gyors fejlődésből adódóan. Megoldásként az opcionális lehetőségeket felhasználva különböző alternatív kiegészítések jelennek meg, melyekre jellemző, hogy nem könnyen működnek együtt más opcionális elemekkel, valamint használatukhoz a futtatórendszer kiegészítése szükséges, így meg- 90

102 91 nehezítve a gyártók közötti szabad választást. A változások egyik forrása a (kezdetben egyszerű) keretrendszerek szabványossá alakítása (Jakarta Taglibs JSTL), másik forrása keretrendszerek lehetőségeinek felhasználása a szabvány új verziójában (Hibernate és Spring egyszerűsítéseinek megjelenése EJB 3-ban). Az alsóbb szintű (például Java) fejlődések is kihatással lehetnek a felsőbb szintekre (például telepítési leírók egyszerűsítése) és a platformok (J2EE,.NET) folyamatosan hatnak egymásra is (ASP.NET WebForm JavaServer Faces). Az EJB 2 szabvány a hozzá kapcsolódó tervezési mintákkal az előző változatokhoz képest jobb teljesítményt ért el: kisebb hálózati forgalom szükséges az átviteli objektumok és Session Façade tervezési minta használatával. Ugyanakkor néhány esetben egyedi megoldások szükségesek: a hagyományos SQL-hez képest az (EJB 2) EJB-QL nagyon sok megszorítást tartalmaz (beágyazott SELECT, aggregált műveletek, navigáció, függvénykészlet), a JNDI nevek feloldása forráskódban bonyolult, a jogosultságés tranzakció-kezelés gyártóspecifikus XML leírók szerekesztését igényli. Az alternatív megoldások (Hibernate, Spring) sok rendszer esetén így használhatóbbnak bizonyulnak, leginkább azokban az esetekben, amikor egyébként sem szükséges az EJB konténer és alkalmazás szerver funkcióinak teljes tára. Az EJB 3 az előbb említett hiányosságokat orvosolta a lefelé kompatibilitás megőrzése mellett, valamint a szabványos megoldásból adódóan az erre épülő alkalmazások nem függnek keretrendszerektől és a gyártófüggő részek mérete is kisebb. A web esetén a JavaServer Faces az ASP.NET WebForm mintájára alakult ki. Ez tartalmazza a legfontosabb HTML űrlap elemeket és a kitöltött adatokat egyszerűen képes az adatmodellnek megfelelő objektumokba írni. A validációra, adatok konvertálására és akciókezelésre is tartalmaz megoldásokat, melyek az előtte használt szabványos eszközökkel (Model 2 architektúra) nehezen elvégezhető. Negatívuma, hogy egyszerű esetekben túl bonyolult az életciklus-modellje, a navigáció nehézségei (POST küldés, böngésző vissza gombja). Sok kiegészítő implementáció jelent meg (MyFaces, ADF Faces, Sun és IBM kiegészítései), melyek nehezen működnek együtt és eltérő JSF verziókra épülnek. Az új funkciók (template, AJAX) is kiegészítő rendszerek használatát igénylik (Facelets, jmaki). Web alkalmazások (és modulok) esetén az üzleti logikánál még több alternatíva található. Ezek különböző szinteken egészítik ki a szabványt: a Struts JSP-re és JSF-re

103 92 (Struts-Shale) épít, mások a servletre (Wicket, Tapestry). Ezeknek a keretrendszereknek a használatakor az alkalmazás fejlesztőinek szükséges mérlegelni az ebből származó előnyöket (általában egyszerűbb, a feladathoz jobban illeszkedik, könnyebben használató) és hátrányait (a fejlesztése és támogatottsága fejlesztőcsapatoktól függ, nem nagy gyártóktól). Sok esetben ezekhez a keretrendszerekhez is tartalmaznak támogatást a fejlesztőrendszerek (pl. Wicket NetBeans plugin). A portletek a servletek kiegészítései, melyek egy web konténerbe telepített portál környezetben futnak. Ebben az esetben a portál extra funkciókat szolgáltat, például tartalom összegyűjtése, információk biztosítása a felhasználóról, nézetek és méretek definiálása portletekhez. A megjelenítést a portleteken belül valamilyen hagyományos webes rendszer (servlet, JSP, JSF, Wicket) végzi. Több forrást megjelenítő webes rendszer esetén lehet célszerű a használata, mivel a tartalmak könnyen integrálhatók használatával, ugyanakkor az erőforrás-igénye és költsége is jelentősebb a hagyományos webes rendszerekénél. A J2EE rendszerek megoldásai és fejlesztési folyamata az alkalmazásokkal kapcsolatba kerülő több csoport számára is kedvező. A fejlesztők irányából érkező visszacsatolások eredményét tartalmazzák az új változatok (egyszerűsítések, hordozhatóság, újrafelhasználhatóság) és az implementáció és futtatás több operációs rendszeren is elvégezhető. A gyártók a szabványos elemekből adódóan együttműködő alkalmazások elkészítését teszik lehetővé (protokollok, egyes részerendszerek kicserélése más gyártó megoldására [pl. Hibernate EntityManager]) és a web szolgáltatások (web services) a rendszerek közötti laza csatolást teszi lehetővé. Az üzemeltetők a csökkenő számú gyártófüggő elemek és konfigurációs lépések miatt magasabb színvonalú (rendelkezésre állás, biztonság) szolgáltatás nyújtására képesek. A felhasználók pedig a kényelmes kezelést segítő kiegészítésekkel már a szabványok előtt találkozhatnak (pl. AJAX) és ergonimikus alkalmazásokkal találkozhatnak.

104 Irodalomjegyzék [1] Cay Horstmann David Geary. Core JavaServer Faces. Prentice Hall, ISBN: [2] Gerald Brose Ed Roman, Rima Patel Sriganesh. Mastering Enterprise JavaBeans. Wiley Publishing, Inc, third edition, ISBN: [3] GoF Erich Gamma. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Professional, ISBN: [4] Neal Ford. Art of Java Web Development. Manning, ISBN: [5] Marty Hall. Core Servlets and JavaServer Pages. Prentice Hall, ISBN: [6] Rick Hightower. Jakarta-Struts Live. SourceBeat, ISBN: [7] Dave Minter Jeff Linwood. Building Portals with the Java Portlet API. Apress, ISBN: [8] Rod Johnson. Introducing the spring framework. TheServerSide.com, SpringFramework. [9] Cserép János. Xml nyelvek használhatóságának vizsgálata web alapú rendszerek tervezéséhez és fejlesztéséhez. Master s thesis, Budapesti Műszaki Egyetem, [10] Floyd Marinescu. EJB Design Patterns Advanced Patterns, Processes and Idioms. Wiley Publishing, Inc, ISBN:

105 [11] Sun Microsystems. Web component development with java technology, Sun SL-314 kurzus jegyzete. [12] Sun Microsystems. Developing application for the j2ee platform, Sun FJ- 310 kurzus jegyzete. [13] Matt Raible. Spring Live, chapter 2. SourceBeat, ISBN: [14] Derek Yang Shen. Put jsf to work. JavaWorld, html. [15] Chad Vawter and Ed Roman. J2ee vs microsoft.net a comparison of building xml-based web services. The Middleware Company, Webcímek 1 Java EE Java EE 5 dokumentáció J2EE 1.4 dokumentáció Hírportálok Aquarium blogok gyűjteménye TheServerSide.com JavaWorld 1 A webes hivatkozások az oldalak május 13-i tartalmára vonatkoznak.

106 IRODALOMJEGYZÉK 95 Keretrendszerek web alkalmazásokhoz Spring keretrendszer Tapestry HiveMind Struts Wicket Wicket keretrendszer Wicket kiegészítések Wicket rendszerrel kapcsolatos hírek JavaServer Faces JSF hírek gyűjteménye MyFaces JSF implementáció és Tomahawk komponensek ADF Faces (Oracle) Facelets template rendszer JSF oldalakhoz Fejlesztőkörnyezetek NetBeans JSF fejlesztőrendszer: Sun Java Studio Creator 2

107 IRODALOMJEGYZÉK 96 Eclipse Eclipse kiegészítés J2EE web alkalmazások készítéséhez Tesztelés junit keretrendszer jwebunit keretrendszer TestNG keretrendszer Cactus keretrendszer UML modellezés Hivatalos UML oldal az OMG honlapján NetBeans kiegészítő csomag, mely UML 2 támogatást is tartalmaz Futtatórendszerek Glassfish alkalmazásszerver Apache webszerver JK Apache modul használata (Tomcat, JBoss, Glassfish szerverekhez) Példa alkalmazások MatekLap StarOffice 8 honlap Villanykari Információs Rendszer

108 A. Fogalmak, rövidítések AJAX Asynchronous JavaScript And XML; interaktív web alkalmazások létrehozására alkalmas technológia, mely a kliens és szerver között kis mennyiségű adatmozgások segítségével csökkenti a válaszidőt és a szerver terhelését is, mivel így nem kell minden eseményt követően a teljes oldalt újratölteni API Application Program Interface; alkalmazás felület, mely más rendszerekkel való együttműködést tesz lehetővé AS Application Server, alkalmazásszerver; J2EE futtatására alkalmas környezet, mely tartalmazza az ehhez szükséges elemeket (EJB konténer, erőforrások), valamint lehetőséges biztosít ezek menedzseléséhez BMP Bean Managed Persistence; annak jelölése, hogy az entity bean-ek perzisztens tárolását olyan osztály végzi, melyet a fejlesztő írt meg, leggyakrabban a CMPnél speciálisabb, hetékonyabb megoldások esetén használt megoldás CMP Container Managed Persistence; annak jelölése, hogy az entity bean-ek perzisztens tárolását a konténer végzi, mely részeket nem a fejlesztőnek kell megírnia CGI Common Gateway Interface; dinamikus web kérések kiszolgálására alkalmas szabvány, a web szerver ennek használatakor minden kéréshez külön folyamatot indít CSS Cascading Style Sheet; HTML oldalak formázásához használható nyelv DAO Data Access Object, adatelérési objektum; célja a perzisztens adattár és a feldolgozó logika közötti kapcsolatot biztosítani, és az egyes oldalak változásait, egyedi jellegzetességeit elfedni DOM Document Object Model; Platform- és nyelvfüggetlen felület, mely dokumentumok tartalmának, struktúrájának és megjelenítésének dinamikus elérését és módosítását teszi lehetővé.

109 98 DTO Data Transfer Object, adatátviteli objektum; két réteg (általában web és üzleti logika) közötti adatokhoz használt, sorosítható formátum) EJB Enterprise JavaBean; a J2EE API egy része, mely a szerveroldali üzleti logika és perzisztens adatok komponenseit írja le HQL Hibernate Query Language; a Hibernate keretrendszer objektum orientált lekérdezőnyelve HTML HyperText Markup Language; web oldalak jelölőnyelve, W3C szabvány IoC Inversion of Control vagy Dependency Injection; objektum-orientált elv, melynek célja az egységek közötti függőségek csökkentése: ha az alkalmazás kér egy objektumot (a konténertől), akkor előbb azt a konténer létrehozza és beállítja a függőségeit, ilyen Java keretrendszerek pl. HiveMind, Spring JAAS Java Authentication and Authorization Service; Java alatt hitelesítés és engedélyezés elvégzésére alkalmas API JDBC Java Database Connectivity; szabványos Java API különböző adatbázisok egységes felületű elérésére JEE, J2EE Java Enterprise Edition; szerver oldali Java, API gyűjtemény többrétegű, skálázható, Java alapú alkalmazások elkészítéséhez JMS Java Message Service; Java alkalmazások közötti üzenetek küldésére alkalmas szabványos API JNDI Java Naming and Directory Interface; a J2EE rendszerek névfeloldási mechanizmusa JSE, J2SE Java Standard Edition; a hagyományos Java nyelv szabványa JSF JavaServer Faces; Java alapú web alkalmazás komponens alapú keretrendszer, mely célja a felhasználói felületek fejlesztésének egyszerűsítése JSP JavaServer Pages; HTML tartalom megjelenítésére alkalmas szabvány, egy kifordított servlet-nek felel meg

110 99 KIR Kollégiumi Információs Rendszer; a Schönherz Kollégium közösségi portálja, a későbbi VIR elődje MDA Model Driven Architecture, Modellvezérelt Architektúra; OMG szabványokra építve választja el az alkalmazás- és üzleti logikát a platform specifikus megvalósításoktól MVC Model View Controller; egy alkalmazás megjelenítő-, modell- és vezérlő részeinek elválasztására használható tervezési minta OCL Object Constraint Language, Objektum Kényszerfeltételek Nyelve; UML modellek esetén az objektumok közötti invariáns és dinamikus kényszerfeltételek leírását teszi lehetővé OMG Object Management Group; nagyvállalati rendszerek közötti együttműködést lehetővé tevő szabványokat megalkotó és karbantartó nyílt, non-profit csoport ORM Object-Relational Mapping, objektum-relációs leképzés; az objektumok és a relációs adatbázis közötti kapcsolat leírása PHP PHP: Hypertext Preprocessor névből származó mozaikszó, dinamikus web oldalak írására alkalmas scriptnyelv PIM Platform Independent Model, Platformfüggetlen modell; egy OMG szabványokra épülő modell, mely nem tartalmazza az ezt megvalósító platform (pl. J2EE,.NET) elemeit PSM Platform Specific Model, Platformspecifikus modell; a rendszer platformjának (J2EE,.NET) elemeit (pl. session bean, entity bean) tartalmazó modell POJO Plain Old Java Object, hagyományos Java objektumok; egyszerű Java objektumok, melyeknek az EJB 2 szabvány bean-jeitől eltérően nem kell megvalósítani különböző szabvány interfészeket SQL Structured Query Language; szabványos nyelv relációs adatbázisokon műveletek (lekérdezés, létrehozás, módosítás, törlés, jogosultságok és séma beállítása) elvégzésére

111 100 UML Unified Modeling Language, Egységes Modellező Nyelv; az OMG szabványos, modellezéshez használt jelölésrendszere VIR Villanykari Információs Rendszer; a Villanykarosok közösségi és tanulmányi portálja XML extensible Markup Language; egyszerű, rugalmas szöveges formátum, mely többek között kommunikációra, könnyen feldolgozható leírásokra alkalmas

112 B. Telepítési útmutató Objektum-relációs leképzés beállítása Ahhoz, hogy az alkalmazásszerveren működjön az objektum-relációs leképzés, néhány esetben változtatást kell végezni: ha az alapértelmezett adatbáziskezelő rendszerek között nem található meg a használni kívánt, akkor annak JDBC meghajtóját telepíteni kell. PostgreSQL esetén a következő lépések elvégzése szükséges (a használni kívánt adatbázis létrehozását követően) régebbi (8.1) alkalmazásszerveren. Az újabb verziók (8.2, Glassfish) már támogatják a használatát, így azok esetén elegendő a JDBC meghajtó elérési útban történő elhelyezése. A példában az alkalmazásszerver az $APP_HOME helyen érhető el. 1. JDBC meghajtó letöltése, mely a html címen érhető el 2. a letöltött.jar file-nak az alkalmazásszerver megfelelő (például lib/) könyvtárába másolása ($APP_HOME/lib/) 3. az $APP_HOME/sbin/asadmin program indítását követően (a start-domain -u admin parancs, majd a jelszó megadásával) az alkalmazásszerver elindítása 4. belépés az adminisztrációs felületre ( admin felhasználóval 5. JDBC driver helyének ($APP_HOME/lib/postgresql.jar) megadása az "Application Server JVM settings (tab) Path settings (altab)" helyen, a Classpath suffix szövegdobozban 6. JDBC meghajtó osztályának (org.postgresql.driver) megadása a -Djdbc.drivers kezdetű sorban az "Application Server JVM settings (tab) JVM Options (altab)" helyen 101

113 az előző két pont Platform Edition alkalmazásszerver esetén érvényes, Enterprise Edition esetén a "Configuration server-config" helyen találhatók a mezők 8. "Resources JDBC Connection Pools" alatt új pool felvétele pl. a következő adatokkal: General Settings: Name: PostgresqlPool Datasource Class: org.postgresql.jdbc3.jdbc3poolingdatasource Resource Type: javax.sql.datasource Pool Settings: alapértelmezett beállítások Connection Validation: alapértelmezett beállítások Transaction Isolation: alapértelmezett beállítások Properties: következő tulajdonságok felvétele servername: adatbázisszerver neve databasename: adatbázis neve user: adatbázis felhasználó port: adatbázis eléréséhez használt port password: adatbázis felhasználó jelszava 9. "Resources JDBC JDBC Resources" alatt új erőforrás felvétele pl. a következő adatokkal: JNDI Name: jdbc/postgresql Pool Name: PostgresqlPool Status: Enabled 10. az alkalmazásszerver appserv-cmp.jar file-jának módosítása ($APP_HOME/lib helyen található), ennek segítségével válik lehetővé az előzőleg beregisztrált PostgreSQL erőforrás esetén az automatikus leképzés használata; a módosítás során az SQL92 jellemzőket másoljuk át PostgeSQL-hez is:

114 103 cd $APP_HOME cp lib/appserv-cmp.jar lib/appserv-cmp.jar.orig mkdir appserv-cmp.d cd appserv-cmp.d jar xvf../appserv-cmp.jar cp appserv-cmp.d/com/sun/jdo/spi/persistence/generator/ \ database/sql92.properties \ appserv-cmp.d/com/sun/jdo/spi/persistence/generator/ \ database/postgresql.properties cp appserv-cmp.d/com/sun/jdo/spi/persistence/support/sqlstore/ \ database/sql92.properties appserv-cmp.d/com/sun/jdo/spi/persistence/support/sqlstore/ \ database/postgresql.properties (cd appserv-cmp.d; jar cvf../appserv-cmp.jar *) B.1. Az appserv-cmp.jar módosítása 11. alapértelmezésben az SQL lekérdezésekben rosszul vannak az idézőjelek, ezért a következő beállítást is el kell végezni: az $APP_HOME/domains/domain1/config könyvtárban el kell helyezni egy.tpersistence.properties file-t, melynek tartalma a következő: database.postgresql.quote_char_end= database.postgresql.quote_char_start= database.postgresql.rtrim= database.postgresql.rtrim_post= database.postgresql.sqrt=sqrt database.postgresql.abs=abs B.2. A.tpsersistence.properties file tartalma A lépések elvégzését és az alkalmazásszerver újraindítását követően az elérhetővé válik a jdbc/postgresql JDBC erőforrás, mely JNDI lekéréssel kapható meg.

115 104 Glassfish környezet beállítása A MatekLap alkalmazás futtatásához szükséges környezet a következő lépések segítségével állítható be: 1. Glassfish letöltése és az ott leírtaknak megfelelően telepítése (jar futtatása, konfigurálás ant segítségével) a $GLASSFISH_HOME könyvtárba 2. külső és authentikációs könyvtárak bemásolása a $GLASSFISH_HOME/lib könyvtárba (legfrissebb verziók): MatekLapRealm.jar commons-logging.jar commons-modeler.jar log4j.jar postgresql.jar tomcat-ajp.jar 3. a MatekLapRealm.jar file domainhez tartozó lib könyvtárába másolása 4. a domain (Glassfish) elindítása és webes felületen történő konfigurálása (vagy a kész domain.xml átmásolása): realm létrehozása, Security Manager bekapcsolása a következő JVM opciók hozzáadása: -Dorg.apache.commons.logging.Log=\ org.apache.commons.logging.impl.log4jlogger -Dlog4j.configuration=file:///\${com.sun.aas.instanceRoot}\ /config/log4j.properties -Dcom.sun.enterprise.web.connector.enableJK= szerver erőforrások felvétele (adminisztrációs felületen vagy fejlesztőkörnyezetből): connection pool, JDBC resource, JavaMail resource, queue, queue factory

116 a domain docroot könyvtárában az alapértelmezett HTML oldal kicserélése (/ kontextus) 7. alkalmazás telepítése (deploy) Apache, Tomcat A célnak (médiatár) megfelelően a beállításban a kéréseket az Apache szolgálja ki, ezek közül a *.faces és a do.* mintára illeszkedő URL-eket továbbítja a Tomcatnek. Ennek beállításához szükséges a mod_jk Apache modul, mely (alapértelmezés szerint) a 8009-es helyi porton kapcsolódik a Tomcathez. Az Apache és Tomcat telepítése a hozzájuk tartozó telepítési leírás alapján egyszerűen elvégezhető (Linux alatt csak csomagként kell telepíteni). A kapcsolat létrehozásához mod_jk2 modult is használható, ebben az esetben a workers2.properties file-t kell használni. A 2-es verzió fejlesztése megszakadt, ezért az 1-es verzió az ajánlott. Az Apache konfigurációjában a következő beállításokat célszerű elvégezni: <IfModule mod_jk.c> JkWorkersFile /usr/local/tomcat/conf/workers.properties JkLogFile /var/log/apache/mod_jk.log JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " </IfModule> A workers.properties file tartalma: workers.tomcat_home=/usr/local/tomcat workers.java_home=/usr/local/java ps=/ worker.list=ajp13 worker.ajp12.port=8007 worker.ajp12.host=localhost worker.ajp12.type=ajp12 worker.ajp12.lbfactor=1 worker.ajp13.port=8009

117 106 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=ajp12, ajp13 Apache alatt (több domain esetén a kiválasztott VirtualHost szekción belül) gyökérkönyvtárként az alkalmazásnál használt (web konténer esetén is érvényes) könyvtárat kell megadni, majd URL mintákat kell megadni a továbbított kérésekhez. Ugyanitt a terheléskiegyenlítő azonosítója (a példában loadbalancer) is használható. DocumentRoot /usr/local/tomcat/webapps/maszat JkMount /*.jsp ajp13 JkMount /manager/* ajp13 JkMount /*.faces ajp13 JkMount /do.* ajp13 JkMount /DisplayStuff ajp13 <Location ~ "^.*WEB-INF"> AllowOverride None Order deny,allow Deny from all </Location> <Location ~ "^.*META-INF"> AllowOverride None Order deny,allow Deny from all </Location>

118 C. UML diagrammok C.1. ábra. A VIR domain modellje 107

119 C.2. ábra. Szavazás és örökített entitások VIR-ben 108

120 109 C.3. ábra. Médiatár anyagok adminisztrációja C.4. ábra. Médiatár felhasználó-menedzsment PIM

121 D. Forráskód részletek D.1. Hibernate, Spring package hu.bme.sch.maszat.model.businessobject; public class User { private Integer id; private String loginname; private String password; private String ; public User() { } // set and get methods } D.1. Minta egy felhasználót reprezentáló (JavaBean) osztályra <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" " <hibernate-mapping package="hu.bme.sch.maszat.model.businessobject"> <class name="user" table="users"> <id name="id" column="usr_id" unsaved-value="undefined"> <generator class="sequence"/> </id> <property name="password" column="usr_password" type="text"/> <property name="loginname" column="usr_loginname" unique="true" not-null="true" length="32"/> <property name=" " 110

122 D.1. Hibernate, Spring 111 </class> column=" " unique="true" type="text"/> </hibernate-mapping> D.2. Felhasználó objektum-relációs leképzése <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" " <beans> <!-- DataSource Definition --> <bean id="datasource" class="org.apache.commons.dbcp.basicdatasource" destroy-method="close"> <property name="driverclassname"> <value>org.postgresql.driver</value> </property> <property name="url"> <value>jdbc:postgresql://localhost:5432/maszat</value> </property> <property name="username"><value>maszat</value></property> <property name="password"><value>jelszo</value></property> </bean> <!-- Hibernate SessionFactory Definition --> <bean id="sessionfactory" class="org.springframework.orm.hibernate3.localsessionfactorybean"> <property name="mappingresources"> <list> <value>hu/bme/sch/maszat/model/businessobject/user.hbm.xml</value> </list> </property> <property name="hibernateproperties"> <props> <prop key="hibernate.dialect"> org.hibernate.dialect.postgresqldialect </prop> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.cglib.use_reflection_optimizer">true</prop> <prop key="hibernate.cache.provider_class">

123 D.1. Hibernate, Spring 112 org.hibernate.cache.hashtablecacheprovider</prop> <prop key="hibernate.hbm2ddl.auto">create</prop> </props> </property> <property name="datasource"> <ref bean="datasource"/> </property> </bean> <!-- Spring Data Access Exception Translator Defintion --> <bean id="jdbcexceptiontranslator" class="org.springframework.jdbc. support.sqlerrorcodesqlexceptiontranslator"> <property name="datasource"><ref bean="datasource"/></property> </bean> <!-- Hibernate Template Defintion --> <bean id="hibernatetemplate" class="org.springframework.orm. hibernate3.hibernatetemplate"> <property name="sessionfactory"> <ref bean="sessionfactory"/> </property> <property name="jdbcexceptiontranslator"> <ref bean="jdbcexceptiontranslator"/> </property> </bean> <bean id="userdao" class="hu.bme.sch.maszat.model.dao.hibernate.userdaohibernateimpl"> <property name="hibernatetemplate"> <ref bean="hibernatetemplate"/> </property> </bean> <bean id="transactionmanager" class="org.springframework.orm. hibernate3.hibernatetransactionmanager"> <property name="sessionfactory"> <ref local="sessionfactory"/> </property> </bean> <bean id="usermanager" class="hu.bme.sch.maszat.service.impl.usermanagerimpl"> <property name="userdao"><ref local="userdao"/></property> </bean>

124 D.2. JavaServer Faces példák 113 </beans> D.3. Spring bean-ek megadása D.2. JavaServer Faces példák package hu.staroffice.web.beans; // imports public class NewPostDemo extends AbstractPageBean { // Java Studio Creator Component Definition // -> component variables, setters and getters public NewPostDemo() { } protected SessionBean1 getsessionbean1() { return (SessionBean1)getBean("SessionBean1"); } protected RequestBean1 getrequestbean1() { return (RequestBean1)getBean("RequestBean1"); } protected ApplicationBean1 getapplicationbean1() { return (ApplicationBean1)getBean("ApplicationBean1"); } public void init() { super.init(); } public void preprocess() { } public void prerender() { } public void destroy() { } } public String savebutton_action() { // handle save event return "success"; } D.4. JSF backing bean

125 D.2. JavaServer Faces példák 114 <?xml version="1.0" encoding="utf-8"?> <jsp:root version="1.2" xmlns:f=" xmlns:h=" xmlns:jsp=" xmlns:ui=" <jsp:directive.page contenttype="text/html;charset=utf-8" pageencoding="utf-8"/> <f:view> <ui:page binding="#{newpostdemo.page1}" id="page1"> <ui:html binding="#{newpostdemo.html1}" id="html1"> <ui:head binding="#{newpostdemo.head1}" id="head1"> <ui:link binding="#{newpostdemo.link1}" id="link1" url="/resources/stylesheet.css"/> </ui:head> <ui:body binding="#{newpostdemo.body1}" id="body1" style="-rave-layout: grid"> <ui:form binding="#{newpostdemo.form1}" id="form1"> <ui:statictext binding="#{newpostdemo.statictext1}" id="statictext1" style="..." text="uj hozzaszolas"/> <h:panelgrid binding="#{newpostdemo.gridpanel1}" columns="3" id="gridpanel1" style="..." width="528"> <ui:label binding="#{newpostdemo.label1}" for="subjectfield" id="label1" text="targy"/> <ui:textfield binding="#{newpostdemo.subjectfield}" id="subjectfield" required="true" style="width: 336px"/> <ui:message binding="#{newpostdemo.message1}" for="subjectfield" id="message1" showdetail="false" showsummary="true"/> <ui:label binding="#{newpostdemo.label2}" for="bodyfield" id="label2" text="szoveg"/> <ui:textarea binding="#{newpostdemo.bodyfield}" id="bodyfield" style="height: 153px; width: 336px"/> <ui:message binding="#{newpostdemo.message2}" for="bodyfield" id="message2" showdetail="false"

126 D.2. JavaServer Faces példák 115 showsummary="true"/> </h:panelgrid> <ui:checkbox binding="#{newpostdemo.useubbcheckbox}" id="useubbcheckbox" label="ubb kodok hasznalata" style="..."/> <ui:button binding="#{newpostdemo.previewbutton}" id="previewbutton" style="..." text="elonezet"/> <ui:button binding="#{newpostdemo.savebutton}" id="savebutton" style="..." text="elment"/> </ui:form> </ui:body> </ui:html> </ui:page> </f:view> </jsp:root> D.5. JSF JSP file az előző példához

127 E. Képernyőképek E.1. ábra. Kollégiumi Információs Rendszer E.2. ábra. Kollégiumi Információs Rendszer változtatható külsővel 116

128 117 E.3. ábra. MatekLap a J2EE megvalósítás nyitóoldala E.4. ábra. Alkalmazásszerver monitorozása: jconsole