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

Budapesti M˝uszaki é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˝u webes architektúrák hatékonyság-vizsgálata Diplomaterv

Konzulensek: Balogh András Cserép János

Budapest, 2006.

Hallgatói nyilatkozat Alulírott Börcsök József, a Budapesti M˝uszaki é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˝uen a forrás megadásával megjelöltem.

Börcsök József

i

Összefoglalás Napjaink informatikai rendszerei között jelent˝os a webes alkalmazások szerepe. Ezek tervezése során fontos a modellezés, mivel lehet˝ové teszi a fejleszt˝ocsapat tagjai közötti együttm˝uködést, tesztesetek el˝oállítását valamint forráskód-részletek generálását is. Már a fejleszt˝orendszerek is támogatják az UML nyelv használatát, viszont az alkalmazások és modellek között csak az egyszer˝u esetekben teremtenek kapcsolatot. A korszer˝u 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˝os csoportjuk: a J2EE és a .NET rendszerek. Ez a dolgozat néhány példán keresztül a J2EE rendszerek lehet˝oségeit vizsgálja és összehasonlítja az alternatív megoldásokat. A J2EE egy szabványgy˝ujtemé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˝uködnek együtt. Az alternatív megoldások alacsonyobb szint˝u szabványokra építenek, és a fejleszt˝ok számára áttekinthet˝o, egyszer˝u 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˝ubben használható, így a fejleszt˝ok az egyszer˝u 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˝oz˝o egyszer˝usítéseket. Ez a fejleszt˝ok számára áttekinthet˝obb és kevesebb forráskódot, könnyebb tesztelhet˝oséget, gyártók közötti könnyebb választást és újrafelhasználható komponenseket jelent. A gyártók együttm˝uköd˝o termékeket szállíthatnak, melyeket üzemeltetni is egyszer˝ubb, í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˝oségek feltérképezésével kezd˝odött, és ezen lehet˝oségek mintaprojekten történ˝o kipróbálásába torkollott. A konklúzió pedig a technológiák különböz˝o szempontok szerinti értékelése.

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.

Tartalomjegyzék Összefoglalás

ii

Abstract

iii

1. Bevezet˝o 1.1. Áttekintés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2

2. Modellezési lehet˝oségek 2.1. UML modellek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Egyéb lehet˝oségek . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 4 9

3. Webes rendszerek áttekintése 3.1. Történelmi összefoglalás . . . . . 3.2. Korszer˝u technológiák áttekintése 3.3. J2EE rendszerek bemutatása . . . 3.4. J2EE architektúra . . . . . . . . .

. . . .

11 11 12 14 16

4. J2EE technológiák 4.1. Az üzleti logika megvalósításai . . . . . . . . . . . . . . . . . . . . . . 4.2. Megjelenítési réteg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Fejleszt˝oi környezetek . . . . . . . . . . . . . . . . . . . . . . . . . .

19 19 25 34

5. Esettanulmányok 5.1. A Kollégiumi Információs Rendszer bemutatása 5.2. Új igények, könnyítések . . . . . . . . . . . . 5.3. Médiatár . . . . . . . . . . . . . . . . . . . . . 5.4. MatekLap . . . . . . . . . . . . . . . . . . . . 5.5. StarOffice 8 . . . . . . . . . . . . . . . . . . .

36 36 39 41 42 43

iv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . . .

6. A vizsgált rendszerek modelljei és megvalósításai 6.1. Modellek . . . . . . . . . . . . . . . . . . . . . . . 6.2. A rendszerek architektúrája . . . . . . . . . . . . . . 6.3. A logikai rétegek és keretrendszerek együttm˝uködése 6.4. Néhány példamodul . . . . . . . . . . . . . . . . . . 6.5. Egy modul megírásának lépései . . . . . . . . . . . 7. A rendszerek értékelése és összehasonlítása 7.1. Üzleti réteg . . . . . . . . . . . . . . . 7.2. Megjelenítési réteg . . . . . . . . . . . 7.3. Összehasonlítás fejleszt˝oi oldalról . . . 7.4. Lehet˝oségek tesztelésre . . . . . . . . . 7.5. Teljesítmény viszonyok . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

44 44 48 51 61 65

. . . . .

70 70 73 77 82 85

8. Ö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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 D.2. JavaServer Faces példák . . . . . . . . . . . . . . . . . . . . . . . . . 113 E. Képerny˝oképek

116

Ábrák jegyzéke 2.1. 2.2. 2.3. 2.4.

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 .

. . . .

6 7 8 9

3.1. Háromréteg˝u alkalmazás . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. J2EE architektúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 17

4.1. 4.2. 4.3. 4.4. 4.5.

. . . . .

20 23 30 32 34

5.1. Képek a Kollégiumi Információs Rendszerr˝ol . . . . . . . . . . . . . . 5.2. A KIR felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. A KIR könyvtárai . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 37 37

6.1. Médiatár f˝obb használati esetei . . . . . . . . . . . . . . . . . 6.2. VIR szerepek . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. VIR használati esetek áttekintése . . . . . . . . . . . . . . . . 6.4. Alkalmazászerverek terhelés-kiegyenlítéssel . . . . . . . . . . 6.5. EJB egyszer˝u web modul interfésszel . . . . . . . . . . . . . 6.6. EJB portál interfésszel . . . . . . . . . . . . . . . . . . . . . 6.7. Er˝oforrások a szerveren . . . . . . . . . . . . . . . . . . . . . 6.8. Példa: hírek szerkesztése . . . . . . . . . . . . . . . . . . . . 6.9. Példa: szavazás szerkesztése . . . . . . . . . . . . . . . . . . 6.10. Példa: szavazógép; virtuális formok Java Studio Creator 2-ben

45 46 46 48 49 50 52 62 63 64

Hibernate + Spring . . . . . . . . EJB 2 és EJB 3 . . . . . . . . . . Model 2 architektúra . . . . . . . Egyszer˝u JSF felület . . . . . . . Pillanatnyi id˝ot megjelenít˝o portlet

vi

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . .

. . . . . . . . . .

6.11. Realm létrehozása Glassfish alatt (3. eset) . . . . . . . . . . . . . . . .

68

7.1. 7.2. 7.3. 7.4.

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 . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

81 83 85 88

C.1. C.2. C.3. C.4.

A VIR domain modellje . . . . . . . . . . Szavazás és örökített entitások VIR-ben . Médiatár – anyagok adminisztrációja . . . Médiatár – felhasználó-menedzsment PIM

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

107 108 109 109

E.1. E.2. E.3. E.4. E.5. E.6.

Kollégiumi Információs Rendszer . . . . . . . . . . . . . Kollégiumi Információs Rendszer – változtatható küls˝ovel MatekLap – a J2EE megvalósítás nyitóoldala . . . . . . . Alkalmazásszerver monitorozása: jConsole . . . . . . . . StarOffice 8 – egy leíró oldal . . . . . . . . . . . . . . . . StarOffice 8 – honlap szövegek szerkesztése . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

116 116 117 117 118 118

Táblázatok jegyzéke 3.1. Webes technológiák összehasonlítása . . . . . . . . . . . . . . . . . . .

12

4.1. Üzleti logikához felhasznált osztályok, interfészek . . . . . . . . . . . .

25

5.1. A KIR forrása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

7.1. 7.2. 7.3. 7.4. 7.5.

72 76 79 79 80

Üzleti rétegek összehasonlítása . . . . . . . . JSF implementációk jellemz˝oi . . . . . . . . EJB2.1 és EJB3 mér˝oszámok . . . . . . . . . Megjelenít˝o rendszerek mér˝oszámai a példára Fejleszt˝okörnyezetek áttekintése . . . . . . .

viii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Forráskódok jegyzéke 4.1 4.2 4.3 6.1 6.2 6.3 6.4 7.1 B.1 B.2 D.1 D.2 D.3 D.4 D.5

Minta servlet . . . . . . . . . . . . . . . . . . . . . . . Minta JSP . . . . . . . . . . . . . . . . . . . . . . . . . Egy web modul könyvtárszerkezete . . . . . . . . . . . Absztrakt menedzser o˝ 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 . . . . . . . . . . . . . . . . . . . . . . Az appserv-cmp.jar módosítása . . . . . . . . . . A .tpsersistence.properties file tartalma . . Minta egy felhasználót reprezentáló (JavaBean) osztályra Felhasználó objektum-relációs leképzése . . . . . . . . . Spring bean-ek megadása . . . . . . . . . . . . . . . . . JSF backing bean . . . . . . . . . . . . . . . . . . . . . JSF JSP file az el˝oz˝o példához . . . . . . . . . . . . . .

ix

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

26 27 29 55 57 58 61 84 103 103 110 110 111 113 114

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˝oségekr˝ol 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

1. Bevezet˝o Napjaink informatikai rendszerei között jelent˝os szerepet töltenek be a webes alkalmazások. F˝o alkalmazási területei az elektronikus kereskedelem (e-commerce) és elektronikus üzleti m˝uködés (e-business). Az els˝o csoportba sorolhatók a webáruházak és ügyfél kapcsolattartó rendszerek (CRM), a másodikba pedig business-2-business (B2B), bels˝o ügyviteli és egyéb nyilvántartó alkalmazások tartoznak. Ezeknek a rendszereknek több, a hagyományos alkalmazásokra nem jellemz˝o tulajdonsága van. Egy alkalmazásnak sok felhasználót kell kiszolgálni azonos id˝oben (másodpercenként akár néhány 100 vagy 1000 kérés is érkezhet) és a kérések eltér˝o platformokról érkezhetnek (több operációs rendszer, több böngész˝o, mobil eszközök). Az elérhet˝o funkciók halmaza is gyakran változik (újak jelennek meg vagy átalakulnak). A web használatának több el˝onye is van ezekben az esetekben. A kliensek platformfüggetlen módon szolgálhatók ki1, a használathoz csak egy böngész˝o telepítése szükséges és a nyílt szabványoknak köszönhet˝oen könny˝u az együttm˝ukö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˝u 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˝okritikus m˝uködés, biztonsággal kapcsolatos szigorú el˝oírások, lokális er˝oforrások kezelése, er˝os 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˝ubbek 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˝o dinamikus technológiák (pl. CGI) a mai szolgáltatásokra jellemz˝o felhasználói profil mellett nem használják hatékonyan az er˝oforrásokat, ezért helyettük hatékonyabb megoldások születtek. Ezek a fejleszt˝ok munkáját is megkönnyítették és könnyebb együttm˝uködést is lehet˝ové 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˝ové 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

1.1. Áttekintés

2

tervezési minták és újrafelhasználható komponensek alkalmazását, és a szerver oldali er˝oforrás-kezelést is hatékonyságabban valósítják meg az el˝oz˝o módszereknél. Kezdetben a fejleszt˝ok 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˝oen 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˝o (automatikusan generált vagy módszertanokat követve megírt) forráskód el˝oállítás.

1.1. Á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˝oségeket említ. Ezt követ˝oen 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˝o rétegb˝ol pedig a JavaServer Faces. Az 5. fejezet a kés˝obbi összehasonlítások alapjául szolgáló rendszereket funkcióit mutatja be: a Kollégiumi Információs Rendszert, az el˝oz˝o (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˝o felhasznált keretrendszerek és szabványok együttm˝uködésére is kitérve. A 7. fejezet több szempont szerint hasonlítja össze a megoldásokat.

2. Modellezési lehet˝oségek Az els˝o webes alkalmazások statikus oldalak voltak, melyeket hamarosan kiegészítettek dinamikus tartalom el˝oállítására alkalmas megoldások. Ezeknek nagy részére jellemz˝o volt, hogy a kimenetet egyszer˝u kiírás formájában állították el˝o, legtöbbször valamilyen küls˝o file formázásával vagy adatbázis eredmények alapján. Kés˝obb újabb felhasználói igények jelentek meg, például authentikáció, tranzakció-kezelés, hibakezelés, melyek az el˝oz˝o 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˝uködésének modellezése, másrészt ezen modelleken el˝oször összetettebb megoldások gy˝ujteményének, kés˝obb pedig tervezési mintáknak és komponenseknek az elkészítése, melyekkel az el˝oz˝o feladatok áttekinthet˝oen megoldhatók. Egy webes alkalmazáshoz többféle modell készíthet˝o, 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˝o 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 UML1 használatával elkészíthet˝o, melyekhez a modern fejleszt˝oeszközök egyre nagyobb támogatást biztosítanak. A modell elkészítése nem csak az áttekinthet˝oséget növeli, hanem lehet˝oséget biztosít egyszer˝u forráskód esetén nehezen vagy egyáltalán nem elvégezhet˝o m˝uveletekre, például a következ˝ore is: • hiba nyomonkövetése • be- és kimeneti értékek modellhez történ˝o kapcsolása • validáció és verifikáció2 1

Unified Modelling Language, Általános Modellez˝o Nyelv 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˝o követelményeket teljesítik 2

3

2.1. UML modellek

4

• a funkcionálisan eltér˝o (például megjelenít˝o é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˝ott az objektum-orientált gondolkodás szerepe is az el˝oz˝oleg elterjedt funkcionális gondolkodással szemben, mivel ezek a modellekhez közelebb állnak, könnyebb a helyességet ellen˝orizni és magasabb szint˝u tervezési minták alkalmazását teszik lehet˝ové.

2.1. 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˝o elemeket tartalmazza: • a rendszer felhasználói (szerepek) • a rendszer használati esetei (use case-ek) • adat (entity) osztályok • vezérl˝o (control) osztályok • határoló (boundary) osztályok • dinamikus m˝ukö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˝obb a kiválasztott platformon megvalósítva esetleg csak bonyolultabb módon adható meg. Ilyen

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˝oi közötti összefüggések, számosságok) és dinamikus (például egy metódus hívása el˝otti és utáni összefüggés) jellemz˝oit 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˝ok hibaellen˝orzése, feldolgozást megel˝oz˝o hibaellen˝orzés). Ennek megfelel˝oen 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˝uködést. A célplatform elemeit is tartalmazó modell a platformspecifikus modell (Platform Specific Model, PSM), melyet el˝oállíthatunk a PIM alapján kézzel vagy modelltranszformációval is. Utóbbi megoldás el˝onye, hogy a specifikáció alapján akár több platformra is kialakítható, így kés˝obb a feladatnak megfelel˝o 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˝orendszerek egyre nagyobb része teszi lehet˝ové (IBM Rational Software Architect, Sun Java Studio Enterprise 8, NetBeans 5.5). Az alábbi példa platformfüggetlen modelljének részletei tekinthet˝ok meg a következ˝o részben: A feladat egy egyszer˝u fórum komponens elkészítése. A fórum nyilvános, azaz bejelentkezés nélkül is megtekinthet˝ok a benne szerepl˝o szövegek. . . . Egy már létez˝o témához csak a belépett felhasználók szólhatnak hozzá, a saját hozzászólásukat kés˝obb 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˝o kitölteni a tárgy, illetve üzenet részét, a megjelenés id˝opontját a rendszer automatikusan kitölti. . . .

2.1. UML modellek

6

2.1. ábra. UML használati esetek

2.1.1. Használati esetek (use cases) A példában következ˝o 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˝oen 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˝oséget.

2.1.2. 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˝ukö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˝oször a felhasználó kiválasztja azt a fórum témát, melyhez hozzá szeretne szólni,

2.1. UML modellek

7

2.2. á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˝o (saját) hozzászólás módosítását kezdeményezi. Ezt követ˝oen a rendszer megjeleníti az ehhez szükséges u˝ rlapot, módosítás esetén kitöltve az adatbázisban szerepl˝o 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 u˝ rlap el˝oz˝oleg beírt értékeit állítja vissza. Sikeres m˝uvelet esetén a téma hozzászólásai jelennek meg.

2.1. UML modellek

8

2.3. ábra. Fórumok UML osztálydiagrammja

2.1.3. Osztálydiagrammok Az osztálydiagrammokon már megfigyelhet˝o a webes alkalmazásokra jellemz˝o három réteg˝u 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˝orz˝o) részeket tartalmaznak. A középs˝o 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.

2.1.4. 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-

2.2. Egyéb lehet˝oségek

9

tást ábrázol-e. Kés˝obb ezek az esetek a tesztesetek el˝oállításának alapjául is szolgálnak: minden helyes és hibás lefutáshoz érdemes tesztet készíteni, így ellen˝orizhet˝o az alkalmazás m˝ukö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.

2.4. ábra. UML hozzászólás helyes lefutás szekvencia

2.2. Egyéb lehet˝oségek A webes alkalmazásoknak léteznek más modellezhet˝o 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:

2.2. Egyéb lehet˝osé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˝oen súlyozva CBMS: Customer Behavior Model Statechart: tartalma megegyezik az el˝oz˝o 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˝o típusú felhasználókról tárolja, hogy adott oldalt hányszor látogattak meg, a navigációt nem tartalmazza Az els˝o két modell különböz˝o mér˝oszámok el˝oá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˝orejelzések is készíthet˝ok, 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˝o elemekkel is ki lehet egészíteni. Nagy rendszer esetén ez tartalmazza a többréteg˝u architektúra rétegei és a számítógépek közötti leképzéseket, az egyéb kiegészít˝o elemeket (például terhelés kiegyenlít˝o, cache).

3. Webes rendszerek áttekintése Ebben a fejezetben a webes rendszerek története, a jelenlegi korszer˝u rendszerek megemlítése, majd ezek közül a J2EE1 technológia ismertetése szerepel.

3.1. Történelmi összefoglalás Az els˝o 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˝obb megjelent az igény arra, hogy dinamikus elemeket tartalmazzanak ezek az oldalak, például id˝opont, szöveg egy küls˝o file-ból vagy adatbázisból. A kényelmesebb felhasználás miatt ezeken az oldalakon el˝otérbe került a felhasználói interakció is: dinamikus linkek és u˝ rlapok (HTML beviteli mez˝ok és ezt elküld˝o gomb) segítségével választhatta ki a látogató az o˝ t érdekl˝o tartalmat. A legels˝o dinamikus oldalak HTML-be ágyazott kiegészítések voltak (Server Side Includes, SSI), melyek lehet˝ové teszik küls˝o parancsok futtatását. Mivel ez kis méretben is struktúrálatlan volt, hamar kiszorították azok a script nyelvek2, melyek HTML oldalakat állítottak el˝o. Ezek els˝o 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 PHP3 már az Apache webszerver szálkezelésével is együttm˝uködik, ahol lehet˝oség van egyszer˝u 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˝oképp, ha HTML oldalakba vannak ágyazva a logikát biztosító részek is). Elterjedésének f˝o oka, hogy egyszer˝uen használható és telepíthet˝o a fejleszt˝o- és futtató környezet is, nem szükséges pontosan érteni a háttérben történ˝o eseményeket. Ebb˝ol adódik, hogy nagyon könny˝u 1

Java to Enterprise Edition, nagyvállalati Java; az 5-ös verziótól kezdve JEE 5 olyan nyelvek, melyeket egy értelmez˝o dolgoz fel valós id˝oben, például Perl, PHP, Python 3 PHP: Hypertext Preprocessor

2

11

3.2. Korszeru˝ technológiák áttekintése

12 J2EE szabvány 30+ EJB

futtatás nyelv

PHP keretrendszer 1 nincs szabványos megoldás értelmez˝o PHP

objektum orientált megjelenítés adatbázis kapcsolódás nyílt forrású

nem HTML PHP függvények igen

igen JSP, JSF JDBC igen

technológia típusa megvalósítások száma üzleti funkciók

lefordított kód Java

.NET keretrendszer 1 .NET Managed Components lefordított kód C#, Jscript.NET, VB.NET, C++ igen ASP, ASPX ADO.NET 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˝o) 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˝u webes fejlesztéseknek két legfontosabb célplatformja a J2EE és a .NET. Ezek lefordított kódot futtatnak és áttekinthet˝o, szabványos struktúrájú alkalmazások elkészítését teszik lehet˝ové.

3.2. Korszeru˝ technológiák áttekintése Ebben a részben az el˝obb említett technológiák közül a PHP, J2EE és .NET f˝o jellemz˝oinek ö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˝odnek és hatással vannak egymásra. Mindkett˝ore érvényes, hogy nem csak weboldalak létrehozására alkalmasak, hanem a mögöttük lév˝o üzleti logika és ehhez eltér˝o (például natív, applet vagy web szolgáltatás) megjelenít˝o réteg megvalósítására is. A f˝o különbségek a következ˝ok [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

3.2. Korszeru˝ technológiák áttekintése

13

használata .NET komponens szemlélet˝u; 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˝o gyártóktól származ˝o (3rd 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˝o 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˝okben egyre szükségesebbé vált eltér˝o platformon futó alkalmazások együttm˝uködésének biztosítása. Lehetnek olyan küls˝o 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˝ofordulhat. 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˝o 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 Account4 egyes szolgáltatásait J2EE rendszer biztosítja, ezért ezzel a választással egyszer˝ubb megvalósítani az együttm˝uködést ezek és a kés˝obb részletesen ismertetett Villanykari Információs Rendszer között (alacsony szinten is) 4

a Schönherz kollégiumban m˝uköd˝o címtár szolgáltatás, melynek segítségével a kollégisták igénybe vehetnek különböz˝o szolgáltatásokat, például levelezés, naptár, nyomtatás, távolról elérhet˝o tárhely, Windows terminál

3.3. J2EE rendszerek bemutatása

14

• az operációs rendszerek és megvalósított rendszerek tekintetében különböz˝o gyártók között választási lehet˝oséget biztosít

3.3. J2EE rendszerek bemutatása A J2EE szabvány egy API5 -t definiál üzleti rendszerek elkészítéséhez. Az alapja a J2SE6 , melyet a következ˝o elemekkel egészít ki: • feltöltéssel (deployment) kapcsolatos szolgáltatásokkal, ezek XML (vagy a forráskódban elhelyezett annotation7) segítségével definiálhatók – perzisztencia (persistence) – tranzakciók (transaction) – biztonság (security) • forráskódban elérhet˝o API szolgáltatásokkal – elnevezések használata (JNDI nevek) – üzenetküldések • lehet˝osé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˝ur˝o m˝uködés 5

Application Program Interface, alkalmazás interfész 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˝ofordítási direktívák szerepét betölt˝o nyelvi elemek, melyek @name formában írandók az elé a nyelvi egység (pl. metódus, változó) elé, melyre vonatkoznak 6

3.3. J2EE rendszerek bemutatása

15

– terheléskiegyenlítés A fontosabb szolgáltatásokat a következ˝o 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˝oforrások gyártófüggetlen elérhet˝osége • JavaMail: szabványos e-mail 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˝orzés) használata • web szolgáltatások (web services) elérése • Java Management Extensions (JMX): alkalmazás monitorozása • id˝ozített futtatások Az alkalmazások elkészítése a következ˝o lépésekb˝ol áll: tervezés, forráskód megírása, telepít˝o leírók (deployment descriptors) létrehozása, csomagolás, összerakás (komponensek), telepítés (deployment). A tervezést a fejlett tervez˝oeszközök egyre hatékonyabban támogatják (UML), valamint a Java editor mellett lehet˝oséget biztosítanak a további lépések egyszer˝usítésére, a rutinszer˝u feladatok kattintással történ˝o elvégzésére. A helyes m˝uködéshez néhány esetben a szerveren különböz˝o er˝oforrá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˝oségét (Realm létrehozása). Ha ezen lépések során nem történik hiba, akkor már elérhet˝o 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˝oz˝o lépéseket egy másik szerveren is megismerhetjük és ezután ugyanazt

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).

3.4. J2EE architektúra A J2EE rendszerek a háromréteg˝u architektúrára épülnek és jól skálázhatók. Több gépb˝ol á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˝o f˝o szakaszok különböztethet˝ok meg: web szerver biztosítja a statikus tartalmak kiszolgálását, itt a file-m˝uveletek a jellemz˝ok (HTML, kép, videó, hang kérések kiszolgálása) alkalmazás szerver a feldolgozást igényl˝o 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˝u 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˝ovíthet˝o, a felhasználói felület egy weboldal, amit egyszer˝u megismerni). Ennek kialakítása nagyobb sávszélességet, er˝osebb központi er˝oforrá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ó


17

független kérések mellett az azonosságot biztosító session kezelés elegend˝o (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˝on megjelen˝o 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˝o vagy módosító SQL kéréseket. A végrehajtást követ˝oen a felhasználó visszakapja az eredményeket.

3.2. ábra. J2EE architektúra Mindhárom rétegben azonosítás és hozzáférés-ellen˝orzés végezhet˝o. A rétegek között t˝uzfal helyezhet˝o el, így biztosítva, hogy a bels˝o (fontosabb) részekhez kívülr˝ol 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˝o, mobil eszközök, web szolgáltatások) keresztül is elérhet˝ok a szolgáltatások.


18

J2EE esetén a web konténer látja el a statikus és az egyszer˝u dinamikus kérések (servlet, JSP; ezek általában csak az üzleti logika hívásokat és a megjelenít˝o logikát tartalmazzák) kiszolgálását, az EJB konténer pedig az üzleti logikát tartalmazza. Lehet˝osé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.

4. J2EE technológiák Ebben a részben néhány szabványos J2EE megoldásról és ezeket megel˝oz˝o, illetve kiegészít˝o keretrendszerr˝ol lesz szó.

4.1. 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˝oször egy egyszer˝u megoldás szerepel, mely kevés kiegészít˝o funkcionalitás mellett egyszer˝uen alkalmazható, majd az elterjedt EJB 2.1, végül az elfogadás el˝ott álló EJB 3 szabvány következik.

4.1.1. Egy könnyusúlyú ˝ megvalósítás: Hibernate + Spring A könny˝usú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˝obb módja az el˝obb 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˝usíti. Hibernate A platformfüggetlen modellben szerepl˝o domain modell segítségével lehet˝osé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˝ok objektumokon végrehajtott m˝uveletekre, 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˝okre) kell leképezni. Ezt követ˝oen a Hibernate elvégzi a szükséges m˝uveleteket: egy objektum létrehozását követ˝oen a saveOrUpdate

19

4.1. Az üzleti logika megvalósításai

20

4.1. á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˝o 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˝o adatbázis session, mely a tranzakciókezelést is tartalmazza. Érvényes session mellett könnyen elkészíthet˝o az adatelérési réteg (Data Access Objects, DAOs), mely egyszer˝u adatbázis-m˝uveleteknek megfelel˝o metódusokat használ (saveOrUpdate, delete, find, load). Ugyanitt (anonim osztályok segítségével) bonyolultabb lekérdez˝o parancsok is végezhet˝ok (execute), például sz˝urés egy hash-ben lev˝o értékek egyenl˝osé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˝oen így nincs annak sem akadálya, hogy az alkalmazásszerver perzisztenciakezel˝o rétegét a Hibernate változatra cseréljük ki, így elérve néhány, a szabványban nem szerepl˝o kiegészítést (például filter).


21

Spring A Spring egy olyan moduláris keretrendszer, mely segítségével az üzleti objektumainkat lehet kezelni és egyszer˝uen tesztelni. A moduljai közül lehet˝osé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˝ol való függetlenséget. Az üzleti logikát egyszer˝u 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˝uen 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˝u .properties file-ok használata. A függ˝oségek kezelése deklaratív módon, például XML-ben leírva történik, így elkerülhet˝o 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˝os 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.

4.1.2. 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: 2003. 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˝uen el˝oá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˝o részeket minden alkalmazásszerver egyformán támogatja (sajnos az opcionális és szabványban nem meghatározott módon szerepl˝o részek gyártónként szinte mind különböznek egy


22

kicsit). Egy már elkészült rendszer migrálása, újrafelhasználása más rendszerben ennek megfelel˝oen 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˝o típusú osztályok különböztethet˝ok 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˝oinek 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˝orzé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˝o felhasználótól érkez˝o kérést is kiszolgálhat; mivel nem kell állapotokat tárolni, ezért ahol lehet, érdemes ezt használni az er˝oforrá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˝ojét), ezért csak a legszükségesebb adatokat kell elmenteni; a mentésr˝ol és visszatöltésr˝ol (passziválás, aktiválás) a konténer gondoskodik message driven bean aszinkron m˝uködés˝u 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˝oség azonnali vissza- vagy hibajelzésre, általában er˝oforrásigényes vagy lassú m˝uveletek esetén hasznos (például bonyolult lekérdezés el˝oállítása, e-mail kiküldése, emberi beavatkozással összefügg˝o szolgáltatások)


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˝o a bonylultság, a második pedig a tesztelés megnehezítése miatt). Emellett nem elhanyagolható, hogy ez a verzió csak egyszer˝u adatmodellek használatát teszi lehet˝ové (nem tartalmazhat örökítést, nehézkes a leképzés testreszabása más adatbázis sémára).

4.2. ábra. EJB 2 és EJB 3 A 4.2. ábrán látható, hogy az el˝oz˝o 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˝oször JNDI név alapján kérhet˝o 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˝o, entitások esetén a helyi interfészben szerepl˝o metódusai érhet˝ok 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˝o telepítés után, így érdemes számolni velük. A következ˝o 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


24

fejleszt˝okörnyezetek lehet˝oségei és a gazdag irodalom miatt sok hasznos minta (best practises) található.

4.1.3. A következ˝o szabvány: EJB 3 Az EJB 3 szabvány végleges verziója a nemrég jelent meg1 , mely nagyon sok könnyítést tartalmaz az el˝oz˝o változathoz képest. Visszafelé teljes kompatibilitást biztosít, viszont a nehézkes részek helyett könnyebben alkalmazható lehet˝osé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˝ok 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˝uen 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˝u JavaBean-ek), az adatbázisra történ˝o leképzés, a lekérdezések, a közöttük lév˝o kapcsolatok, a kulcsok el˝oállítása; lehet˝oség van leszármaztatott osztályok leképzésére, valamint több relációt érint˝o lekérdezés egyedi visszatérési értékének objektumra történ˝o leképzésére • lehet˝osé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˝o 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˝orzést is végezhet 1

http://www.jcp.org/en/jsr/detail?id=220, JSR-220 néven 2006. május 11-én

4.2. Megjelenítési réteg Megoldás Hibernate, Spring EJB 2 EJB 3

25 interfész 2 4 2

osztály XML leíró 3 1 2+2 ~2 2 0

4.1. 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˝oállíthatja azokat). A 4.1. táblázat összesítve tartalmazza, hogy a három lehet˝osé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.

4.2. Megjelenítési réteg 4.2.1. Servlet J2EE rendszerekben dinamikus oldalak el˝oállítására a legrégebbi lehet˝osé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˝ové tev˝o szálkezelésr˝ol 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˝o el˝onyei é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˝osége használható, szemben a CGI és script nyelvek hasonló lehet˝oségeivel + a Java nyelvb˝ol és a servlet API-ból adódóan platformfüggetlen megoldás

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˝o 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(""); out.println("Servlet ServletExample"); out.println(""); out.println("
Servlet ServletExample at " + request.getContextPath () + "
"); out.println(""); out.close();


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

4.2.2. JSP Hamar megjelent az igény arra, hogy valamilyen jelöl˝o nyelvhez hasonló formában lehessen megadni a megjelenít˝o 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˝o 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˝o a JSP oldalakat kéri, mely JavaBean-ek segítségével jeleníti meg mögötte lév˝o (servlet) logikától származó adatokat. <TITLE>Example JSP Page


28

Table of numbers squared: <% for ( int i=0; i<10; i++ ) { %> <% } %>

number squared
<%= i %> <%= (i * i) %>

4.2. Minta JSP A JSP oldalakat a web konténer els˝o lépésben egyszer˝u servlet forráskóddá alakítja, majd lefordítja, ezt követ˝oen pedig hagyományos servlet-ként futtatja. Használatának el˝onyei és hátrányai a servletek-ekét kiegészítve: + a megjelenítést tartalmazó részek áttekinthet˝obbek a servlet-ben használt megoldásnál + könnyen b˝ovíthet˝o ú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˝ok 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˝o letöltését˝ol 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˝ol 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)


29

Egy web project tipikusan a következ˝o könyvtárszerkezetben helyezhet˝o 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

4.2.3. 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˝o módon valósítja meg a Model-View-Controller mintát: ennek a neve Model 2 architektúra2 . 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˝oá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˝uvelet sikerességét is). A megoldás el˝onye, 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


30

4.3. ábra. Model 2 architektúra karbantartó fejleszt˝onek nem kell ismernie a logika oldalt és nem is kell hozzányúlnia; ugyanakkor a megjelenít˝o logika fejlesztéséhez sem szükségesek alapos HTML ismeretek. A két részben a megjelenített adatok közösek, err˝ol közösen kell a fejleszt˝oknek megállapodni. A servlet-ek nagyobb rendszerek esetén csak a megjelenít˝o logikát tartalmazzák, az üzleti logikát EJB (vagy a használt keretrendszerre vonatkozó, pl. Spring) hívásokkal érik el.

4.2.4. Megjelenít˝o keretrendszerek A JSP és servlet technológia lehet˝oséget biztosít egyszer˝u 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˝o keretrendszerek tartalmaznak. Nagyon sok lehet˝osé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˝ujtemény, a többi rendszerrel szemben ez a J2EE szabványnak része; f˝o részei a mag (változók, URL, vezérlés), XML, többnyelv˝uség, SQL, String kezelés; a következ˝o változata a kés˝obb szerepl˝o JSF rendszerekkel is képes együttm˝uködni


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˝odött, majd a JSF (részletesen a következ˝o részben szerepel) megjelenését követ˝oen 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˝ové teszi és nem csak HTML, hanem más (szöveges) tartalmak (például XML, SQL) el˝oállítására is használható. Tapestry Az alkalmazást oldalakból rakja össze és minden oldalt komponensekb˝ol épít fel. A navigáció során szükséges URL-eket a keretrendszer állítja el˝o; beviteli ellen˝orzést, többnyelv˝u oldalak kezelését, kivételkezelést is támogat. A megjelenített HTML oldalak külön is szerkeszthet˝ok, a dinamikus tartalom illesztésére OGNL (Object Graph Navigation Language) kifejezéseket használ. Egyedi komponensek is könnyen készíthet˝ok alatta. Wicket Ennek a keretrendszernek a segítségével a többit˝ol kicsit eltér˝oen választható szét a megjelenítés és a tartalmat el˝oállító logika: a megjelenítés létrehozásához csak egyszer˝u HTML dokumentumokat kell készíteni, néhány tag-nek kiegészít˝o paramétert adva (wicket:id), valamint a <wicket:>) névtér használható még. A megjelenít˝o logika és a FORM-ok kezelése teljes mértékben a Java oldalon található, így a HTML rész szerkesztéséhez WYSIWYG3 editor is használható. A keretrendszer gazdag AJAX4 támogatást is tartalmaz. Facelets A JSF rendszerekre jellemz˝o 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˝ok 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 Asynchronous JavaScript And XML, XML segítségével kliens oldali dinamikus viselkedést megvalósító technológia, mely JavaScript nyelven alapul 4


32

4.2.5. 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˝u komponenseket tartalmaz, melyek összekapcsolhatók a megjelenített adatokkal, validátorok, konverterek kapcsolódhatnak hozzá, valamint kliens- és szerveroldali eseménykezelést tesz lehet˝ové. A m˝uködése több hasonlóságot tartalmaz az ASP.NET WebForm technológiával és a Struts rendszerrel (a JSF projekt egyik tervez˝oje készítette el˝otte a Struts-ot), a Struts-Shale kiterjesztéssel pedig jól kiegészítik egymást.

4.4. ábra. Egyszer˝u 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˝o meg, mely a következ˝oket tartalmazza: • egy JSP oldal, mely JSF tag library-t használ (ez tartalmazza a Faces komponenseket): a két beviteli mez˝ot 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˝o (navigációval és anélkül) metódusok, valamint itt implementálható egyedi validátor (értékek ellen˝orzése), konverter (értékek formátumának megadása); egy JSP oldalhoz több backing bean


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˝u változókat (pl. nyelvi beállítások, üzenetek) Ma már több fejleszt˝okö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.

4.2.6. 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˝o el˝oállítása, témák közötti választás lehet˝ové 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˝o 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˝o 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˝o doboz, egy híreket megjelenít˝o 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˝ok (a szabványban nem szerepl˝o részek megadása után). A portlet-ek életciklusa egyszer˝u: feltöltést követ˝oen 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˝o (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

4.3. Fejleszt˝oi környezetek

34

4.5. ábra. Pillanatnyi id˝ot megjelenít˝o portlet más gyártóspecifikus módok is. A megjelenítésre jellemz˝o még a megjelen˝o ablak mérete, mely lehet normál méret˝u (egy doboz az oldalon), teljes méret˝u (a teljes tartalom konténer elfoglalása) vagy minimális méret˝u (összecsukott, csak a doboz fejéce látható). A módok és a méretek között leggyakrabban a fels˝o részen elhelyezett ikonok teszik lehet˝ové a választást.

4.3. Fejleszt˝oi környezetek J2EE rendszerek fejlesztéséhez a legegyszer˝ubb szöveges editorok (például vim) is használhatók, viszont a kényelmes használathoz egy komolyabb fejleszt˝okörnyezet szükséges. A hagyományos Java fejleszt˝orendszerek 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˝o ilyen irányú könnyítések fordítási id˝oben végezték el az extra fukciókat (például telepítés a szerverre vagy automatikusan el˝oállítható leírók gyártása) ant scriptek segítségével, majd a fejleszt˝okörnyezetek segítséget nyújtottak el˝oször a szabványos, majd egyre több gyártó alkalmazásszerveréhez és keretrendszerhez is, valamint a fejlesztést kényelmesebbé tev˝o 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˝orzése). A két legelterjedtett J2EE fejleszt˝okö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˝o 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˝o két rendszerre jellemz˝o, hogy több gyártó esetén is könnyebben használhatók). Jelenleg

4.3. Fejleszt˝oi környezetek

35

a Sun NetBeans alapon két fejleszt˝okö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˝o funkciók támogatása a leginkább elvárt: • EJB (session bean, entity bean és message driven bean) létrehozása, m˝uködésükhöz szükséges er˝oforrások egyszer˝u 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˝o ellen˝orzéssel együtt • a szabványos, gyakori m˝uveletek támogatása (EJB hívása, tervezési minták, DTO) • az alkalmazások gyors és áttekinthet˝o telepítése, hiba esetén az okok pontos megjelelölése minél el˝obb • alkalmazásszerver specifikus és szabványos elemek támogatása (szerepek kezelése, hibaoldalak, tranzakció kezelés beállítása) • kiegészít˝o keretrendszerek támogatása (különböz˝o webes keretrendszerek XML leírói, ezek sémái, források közötti kapcsolatok könny˝u követése, automatikus kiegészítés, dokumentáció megjelenítése); a 6.10. ábrán egy JSF szerkesztési nézet látható • más fejleszt˝orendszerben elkészített alkalmazások használata, importálása, szinkronizáció A különböz˝o környezetek képességeit a 7.5. táblázat foglalja össze.

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˝ovü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˝osoran a felhasználói m˝uködés szempontjából szolgáltak alapjául, kisebb mértékben az ott megszokott komponensek és egyszer˝usít˝o lehet˝osé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˝o MatekLap játszott f˝o szerepet.

5.1. A Kollégiumi Információs Rendszer bemutatása Az eredeti rendszer (5.1. ábra) a kollégium belép˝o és közösségi pontozását segít˝o alkalmazásból fejl˝odött ki, melynek els˝o változata még Perl nyelven, a kés˝obbi 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˝oen egy 2002. nyarán rendezett fejleszt˝oi táborban ismerte meg egy csoport a PHP alapú rendszert. 2004. decemberben történt egy nagyobb változtatás: a keretrendszer egy része kiegészült új funkciókkal (hibaellen˝orzés, dokumentáció generálása, CSS használata formázáshoz), és ekkor készült el a VIR els˝o változata is. A VIR kés˝obb több másik egységgel való együttm˝uködést is kezdeményezte (Info- és VillanySite1, HK). 1

tárgyakkal kapcsolatos információkat, segédleteket, mintafeladatokat tartalmazó oldal

36

5.1. A Kollégiumi Információs Rendszer bemutatása

37

5.1. ábra. Képek a Kollégiumi Információs Rendszerr˝ol

5.1.1. 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ó.

5.2. ábra. A KIR felépítése 5.3. ábra. könyvtárai

A

KIR

A diagram a rendszer logikai m˝ukö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˝oen nem jelenít meg tartalmat, viszont a m˝uvelet elvégzését követ˝oen nem szerveroldalon állít el˝o egy oldalt, melyet a felhasználó visszatérésként megkap, helyette a HTTP protokoll Location2 parancsát ki2

Ha a szerver válaszának fejlécében szerepel a parancs (egy URL paraméterrel), akkor a böngész˝o az oldal megjelenítése helyett az itt szerepl˝o címre ugrik.

5.1. A Kollégiumi Információs Rendszer bemutatása

38

használja utasítja a felhasználó böngész˝ojét egy másik oldal letöltésére. Egyetlen ilyen kérés minden böngész˝o alatt megfelel˝oen m˝ukö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˝o felvétele: kés˝obb látható hogy azt megvalósító technológiák esetén éppen ezért nem használható a böngész˝ok könyvjelz˝oje, 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˝oen pedig a ezeket részletezem a megértéshez szükséges mértékben. Könyvtár classes

Funkció keret

Nyelv PHP

config content doc func html

control view model view

XML XML LATEX, TXT PHP HTML

view keret keret

képek PHP XML + PHP

images jmods nodes

XML

site_config.xml

Leírás a böngész˝o felhasználó kezelése, jogosultságok vezérlés megjelenítés dokumentáció feldolgozó logika az oldalak HTML váza hook-ok használatával a rendszer (tartalom nélküli) képei a keretrendszer megjelenítésben használt saját tag-ek definíciója általános, portál szint˝u attribútumok, objektumok

5.1. táblázat. A KIR forrása

5.1.2. A rendszer mukö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˝ok el benne, azok megjelenít˝o 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

5.2. Új igények, könnyítések

39

makrókat tartalmazó megjelenít˝o komponensek adhatók meg, a többszörös és rekurzív hívást is lehet˝ové téve. A feldolgozás egyszer˝u PHP függvények hívása. Az oldal használatához az el˝oz˝o 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˝os többletterhelést okozna. Az egyszer˝u elérhet˝oség miatt a fordító webes felületen érhet˝o el (a KIR keretrendszert felhasználva), mely a vele megegyez˝o 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˝ok: 1. új könyvtárszerkezet kialakítása, a nem XML típusú file-ok megfelel˝o 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˝o könyvtárakba másolja a kés˝obbi lefordított fileokban szerel˝o hivatkozásoknak megfelel˝oen 2. a konfigurációs leírások alapján a modulok meghatározása, a vezérl˝o szerkezetek el˝oállítása: ekkor SAX3 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˝oállító) függvényekkel (az egyszer˝u DOM4 fa ezért nem alkalmazható) 3. saját (megjelenít˝o) XML tag-ek elérhet˝oségét biztosítás PHP függvényként 4. megjelenít˝o oldalakat leíró XML file-okból függvények el˝oállítása, közöttük lév˝o kapcsolatok esetén függvényhívások használata 5. a modulok vezérlését végz˝o kódrészek el˝oállítása

5.2. Új igények, könnyítések A PHP alapú rendszer a következ˝o hiányosságokkal rendelkezik: 3 4

Simple API for XML, XML dokumentumok soros feldolgozására alkalmas szabvány Document Object Model, szabvány, mely XML dokumentum alapján objektumokból egy fát épít

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˝ol következik, hogy néha kis változtatásokhoz is sok módosítást kell kézzel végezni és hogy a fejleszt˝ok 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˝oen már nem m˝uköd˝oképes) – ezek általában akkor fordulnak el˝o, 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˝o részekben SQL lekérdezések szerepelnek: ez gyors fejlesztések és kis bonyolultságú rendszerek esetén használható, viszont nagyobb fejleszt˝ocsoport esetén vagy kés˝obbi 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˝o logikát általában egyéni megoldásokkal lehet biztosítani, melyek esetén például a FORM mez˝oinek é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.

5.3. Médiatár

41

Megjelenítés A megjelenítés a KIR eredeti verziójában lehet˝ové 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˝o kiválasztását jelentette. Ebb˝ol 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˝okben és az oldalak forráskódja is fölöslegesen nagy méret˝u 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˝o megjelenítések (skin) közül történ˝o választás is lehet˝ové 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˝okön múlik, hogy a hibát a keretrendszer (nem túlságosan fejlett) lehet˝oségeit kib˝ovítve vagy teljesen egyedi megoldásokkal valósítják meg azt. Hiba esetén a felhasználó számára történ˝o 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˝o 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˝ofordulnak. A keretrendszer aktív fejleszt˝oi átlátják ezeket a részeket is, viszont az egyediség megnehezíti a tanulást is.

5.3. Médiatár A kollégiumi közösségi tevékenységekr˝ol gazdag médiaanyag áll rendelkezésre: különböz˝o rendezvények (például Schönherz Qpa, Fesztivál7, . . . ) és körök (például

5.4. MatekLap

42

KSzK5 , Táncklub, Banális Közhely) kép-, hang- és videóanyaga. A BSS6 is nagy mennyiség˝u filmarchívummal rendelkezik. Ekkora mennyiség mellett nehéz a nyilvántartás, a keresés és az elérhet˝oség biztosítása is. Ennek megoldására kezd˝odö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ások7 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˝o). A médiatár f˝o célja, hogy többféle kategóriarendszer szerint lehessen benne keresni (például események, csoportok, helyszínek, id˝o). 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˝ukítésével (visszafelé lépkedve enyhítésével) állítja el˝o. Ennek megfelel˝oen böngészéskor (el˝ore felkínált lehet˝oségek a továbblépésre) ezek szerint az el˝ore 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˝o állandóan (például valaki CD-re kiírta és már egyik nagyobb, folyamatosan m˝uköd˝o 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˝o, az anyagok nagy részét tartalmazó archívum.

5.4. MatekLap A MatekLap egy olyan webes portál, melynek két célja van: az egyik egy matematikával kapcsolatos, fejtör˝o feladatokat, különböz˝o rendezvények (táborok, vetélked˝ok) és a kialakult közösségek kapcsolattartását el˝osegít˝o rendszer kialakítása, folyamatos továbbfejlesztése és üzemeltetése; a másik pedig kísérletezés különböz˝o webes technológiákkal, a fejlesztési, küls˝o adminisztrátori és felhasználói igények figyelembe vételével. Az els˝o rendszer a KIR keretrendszert használta (még a jelenleg futó aktív változat 5

Kollégiumi Számítástechnikai Kör Budavári Schönherz Studió 7 például Gallery, Gallery2: http://gallery.menalto.com 6

5.5. StarOffice 8

43

is PHP alapú). A mostani változat f˝o funkciói: • hírek, fórumok, szavazógép, üzen˝ofal • dokumentumtár, feladattár • rendezvények (tábor, vetélked˝o, találkozó) oldalai: leírás, jelentkezés, résztvev˝ok, szervez˝ok, tanárok, szótár, fényképek, program, eredmények • fejtör˝o: feladatok kiírása hetente és ehhez értékel˝o felület A rendszernek van néhány specialitása is: a rendezvények adatai (résztvev˝ok, iskolák, szervez˝ok) 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˝uködnek, néhány funkció futásához id˝ozí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˝o szolgáltatások hozzákapcsolását (galéria, wiki, küls˝o hírforrások), a struktúra átláthatóságának biztosítását. A rendszer több helyen testreszabható, paraméterezhet˝o, átalakítható különböz˝o szint˝u fejleszt˝ok számára (fejleszt˝ok, tartalom feltölt˝ok, adminisztrátorok).

5.5. StarOffice 8 A StarOffice honlap megírása az el˝oz˝o rugalmas kialakítással szemben egy specifikációnak megfelel˝o rendszer elkészítését jelentette. F˝o funkciói: hírek, fórumok, segítségnyújtás, letöltések, dinamikus termékleírások, küls˝o 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˝o összehasonlító részekben lesz kés˝obb szó.

6. A vizsgált rendszerek modelljei és megvalósításai A következ˝okben az el˝oz˝o fejezetben szerepl˝o rendszerekhez készített platformfüggetlen, majd J2EE modellek olvashatók, majd architektúrával kapcsolatos megoldások és alacsonyabb szint˝u fejleszt˝oi döntések szerepelnek.

6.1. 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˝odleges 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˝ol 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

6.1. Modellek

45

6.1. ábra. Médiatár f˝obb használati esetei A MatekLap ezek közül a kollégiumhoz kapcsolódó részeket nem tartalmazza (belép˝oigénylés, éjszakai vendégfogadás). A fórumra vonatkozó platformfüggetlen modellb˝ol a 2. fejezet tartalmaz részleteket, a VIR modelljéb˝ol 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˝ová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

6.1. Modellek

46

6.2. á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˝oen megjelen˝o ablakok felvétele Fortune Management a honlapon megjelen˝o, véletlenszer˝uen választott idézetek szerkesztése, megjelenítése Banner Management az oldalon megjelen˝o hírdetések adminisztrálása Message Management üzen˝ofal, melyen a felhasználók egymásnak vagy csoportjaiknak írhatnak

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˝u 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˝od˝ok belép˝o- és közösségi pontozásának megkönnyítését végz˝o modul A webes rendszerekre jellemz˝o háromréteg˝u logikai architektúra ezekben az esetekben a következ˝o módon finomítható: perzisztencia az adatok perzisztens leképzését végz˝o réteg, ezen belül: adatmodell a rendszer adatait tároló Java objektumok és kapcsolataik adatelérés m˝uveletek 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˝uködéséért felel˝os rész, ezen belül szintén megkülönböztethet˝o: eseménykezelés a felhasználói események (akciók) kezelését végzi, ide tartozik az adatok ellen˝orzé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˝os rész formázás a megjelenített tartalom formázását végzi el (skin) A J2EE modell a következ˝o lépések segítségével készíthet˝o el a platformfüggetlen modellb˝ol: 1. az entitás osztályok alapján entity bean-ek (EJB 2.1, EJB 3), vagy egyszer˝u Java osztályok (POJO) + leképzés (XML vagy XDoclet) létrehozása (Hibernate)

6.2. A rendszerek architektúrája

48

2. 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˝o (control) osztályokból session bean-ek készítése (EJB) vagy egyszer˝u Java osztályok (Spring) 4. a határoló osztályokból a megjelenít˝o réteg el˝oállítása: oldalszerkezetek, navigáció, (HTML) tartalom, megjelenít˝o 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˝u fizikai architektúra a skálázás szempontjából fontos: egy terhelés-kiegyenlít˝o a kéréseket valamilyen szempont (általában round robin, esetleg a session megtartásának a lehet˝osé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˝o rendszer új fizikai egységek hozzáadásával tovább b˝ovíthet˝o.

6.4. ábra. Alkalmazászerverek terhelés-kiegyenlítéssel Lehet˝osé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˝o esetén is elérhet˝o 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˝ok.


49

A 6.5. ábrán egy olyan eset látható, amikor az EJB el˝ott egyszer˝u JSF web modul végzi a megjelenítést: az alkalmazás megjelenít˝o 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˝oforrásokat (adatbázis, SMTP szerver, üzenetsor). Eltér˝o webes megjelenít˝o keretrendszer csak a web konténeren belüli m˝uködésre van hatással.

6.5. ábra. EJB egyszer˝u web modul interfésszel Ett˝ol 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˝u feltöltés és konfigurálás, parancssorból történ˝o 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˝orzé-


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˝oség van.) A 6.6. ábrán a portál megoldás architektúrája látható.

6.6. ábra. EJB portál interfésszel Az EJB-t nem tartalmazó esetben a web konténeren belül szerepl˝o modul szerkezetének egy része látható a 4.1. ábrán, ezt az „egyszer˝u web és EJB” esetben látott JSF komponensekkel kell csak kiegészíteni.

6.3. A logikai rétegek és keretrendszerek együttmuködése ˝

51

6.3. A logikai rétegek és keretrendszerek együttmukö˝ dése A szabványos technológiák használata mellett biztosítani kell azok hatékony együttm˝uködését, valamint a lehet˝oséget, hogy a kés˝obb egy-egy réteg szükség esetén lecserélhet˝o legyen (például egy hatékonyabb vagy egyszer˝ubb megoldásra). Általában a megírt osztályok helyett célszer˝u az ahhoz tartozó interfészeket külön biztosítani és a felhasználás helyén arra hivatkozni. Az el˝oz˝o részben bemutatott rendszerek alapján a következ˝ok a legfontosabb funkciók, melyek a szabványokra építve valósíthatók meg.

6.3.1. Er˝oforrások elérése Az alkalmazásszerverek különböz˝o er˝oforrá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˝o levelez˝o er˝oforrá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˝ové 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 o˝ 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˝oforrásokat legegyszer˝ubb IoC segítségével elérhet˝ové 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).

6.3.2. Lekérdezések tárolása Az alkalmazás m˝uködéséhez a kulcs alapján történ˝o 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.


52

6.7. ábra. Er˝oforrások a szerveren EJB 2.1 esetén ezeket EJBQL használatával lehet megírni és a telepít˝o leíróban elhelyezni. Sajnos a 2.1 -es változat kifejez˝oké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˝o 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˝u web modulban) már több funkció elérhet˝o a Hibernate QL (HQL) SQL kiegészítésnek megfelel˝oen és ezek jól átláthatóan a DAO rétegben találhatóak, így kés˝obb is könnyen elérhet˝ok. EJB 3 esetén az EJBQL lehet˝oségei is b˝ovültek, ha pedig nem lenne elég, akkor szabványos SQL lekérdezések is ezzel megegyez˝o szintaktikával használhatók. Az eredmények esetén egyedi mez˝ok mellett lehet˝oséget biztosít azok külön (nem entitás) objektumokba leképzésére.

6.3.3. Adatok szállítása, validáció EJB 2.1 használatakor a különböz˝o rétegek közötti adatátadásra a DTO-k használatosak, aminek több oka is van: áttekinthet˝oség, az interfészek állandósága (csak egyetlen


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˝u validációs funkciók ellátására: az egyszer˝u formai ellen˝orzéséket itt megvalósítva az elérhet˝ové válik közvetlenül a felhasználói akciókezelést követ˝oen (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˝orzé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˝orzésekkel. Ugyanígy a DTO tartalmazhat metódusokat a konzolra történ˝o kiíráshoz, a hash képzéshez vagy egy másik objektummal való egyenl˝oség vizsgálatához. Spring + Hibernate kombináció és EJB3 esetén POJO használata miatt elegend˝o, 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˝orzé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˝orzést minden entitás esetén azonos néven lehet hívni. EJB 3 esetén ezek az ellen˝orz˝o metódusok annotációval is jelölhet˝ok (pl. @PrePersist, @PreUpdate), í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˝oen 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˝ok), más esetben ez külön hívással végezhet˝o el (pl. fórum hozzászólásainak listázása fórum lekérdezését követ˝oen); 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˝oen 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˝u fejleszt˝orendszerek már kisebb-nagyobb mértékben támogatják a DTO-k entity bean-ekb˝ol történ˝o generálását.


54

6.3.4. Egyszerusítések ˝ Java 5 használatával A Java 5 használatával (melyet már az alkalmazásszerverek jelent˝os része támogat vagy a közeljöv˝oben támogatni fog) több helyen áttekinthet˝obb, egyszer˝ubb forráskód készítésére van lehet˝oség, például: • áttekinthet˝o iteráció for-ciklus használatával, Iterator típus és kézzel történ˝o típuskonverzió nélkül • felsorolástípus alkalmazásával az elgépelési hibák száma csökkenthet˝o, mivel azok már fordítási id˝oben kiderülnek • a kivételkezelés az el˝oz˝o felsorolástípus és üzenetköteg (bundle) felhasználásával egyszer˝uen megvalósítható: a validálás és feldolgozás során el˝oforduló hibák gy˝ujteményét (Collection) egy kivételben a megjelenít˝o réteghez visszajuttatva az a megfelel˝o nyelvi szöveget tudja megjeleníteni

6.3.5. Közös és gyakori funkciók Az üzleti funkciók jelent˝os része használja a közös funkciókat, ide tartozik például az e-mail küldés és a logolás. Ezeket az áttekinthet˝oség és karbantarthatóság miatt célszer˝u egy helyen megírni. Erre egyszer˝u web alkalmazás esetén hasznos lehet a Singleton tervezési minta, EJB esetén pedig vagy külön session bean vagy egyszer˝ubb esetben elegend˝o egy közös o˝ 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 o˝ 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˝o gyakran használt metódusait érdemes megemlíteni: • entitások mentése vagy módosítása (saveOrUpdate) • entitások törlése (delete)


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˝opont vagy állapot alapján el˝oá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˝o formában megvalósítani: EJB 2.1 session bean-ek Ebben az esetben a közös o˝ s tartalmazza a logolásért és a letölt˝o felhasználó lekérdezéséért felel˝os részeket, az entitások mentését el˝okészít˝o általános részt és az el˝obb 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˝o típusú objektumok egyenl˝osé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() {

6.3. A logikai rétegek és keretrendszerek együttmuködése ˝ 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);

56


57

} catch (CreateException e) { throw e; } } finally { key = keyGenerator.getNextValue(); } return key; } }

6.1. Absztrakt menedzser o˝ 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˝oszö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˝o betöltése következik a kulcstól függ˝oen. 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) {


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 o˝ sosztályban elhelyezni, ezeket meg lehet adni az entitás osztályában is, @PrePersist és @PreUpdate 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˝u, lehet-e módosítani, lehet-e üres, . . . ). Ezekkel a logika rész a 6.3. forrás szerint egyszer˝usödik. A flush metódus hívása az adatbázisban el˝oállított értéket frissíti vissza a memóriában lév˝o 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


59

A JNDI mechanizmus egyszer˝usítése miatt már nem szükséges lookup metódusokat hívni, a hivatkozások deklarációjánál elég az @EJB annotáció használata (dependency injection).

6.3.6. Megjelenít˝o 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˝o 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˝omenü elemei) vagy dinamikusak (pl. almenü, hírek szövege). Üzenetkötegeket használva külön lehet választani az oldalak szerkezetét˝ol a statikus szövegeket, ráadásul kellemes mellékhatásként ezzel az oldal statikus része könnyen többnyelv˝uvé tehet˝o (egyszer˝uen 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˝o oldalvázban már elég a kulcsokat használni. JSF esetén az f:loadbundle tag segítségével tölthet˝o be egy ilyen üzenetköteg, Wicket esetén pedig a komponens HTML váza mellett egy vele megegyez˝o nev˝u .properties file létrehozásával. Dinamikus elemeknél a többnyelv˝uség támogatása kicsit összetettebb, ekkor ugyanis az üzleti logikának a m˝uveletek során a nyelvnek megfelel˝o entitásokra kell sz˝urni (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˝uen lehet alkalmazni Wicket esetén is: a legfels˝o szint˝u oldal o˝ sosztályban DOM használatával felépíthet˝o egy navigációs struktúra, melyet az akciókezel˝o komponensek meg tudnak hívni.

6.3.7. Jogosultságok kezelése A felhasználók több csoportja különíthet˝o el, akik a szolgáltatások különböz˝o köréhez férnek hozzá. A beléptetés (hitelesítés, authentikáció) ellen˝orzi egy felhasználóról, hogy valóban az-e, akinek állítja magát, míg a jogosultság-ellen˝orzés (engedélyezés, authorizáció) egy er˝oforrás elérését teszi lehet˝ové vagy tiltja meg. Az üzleti logika kiszolgálhat megbízható és nem megbízható megjelenít˝o rétegeket is, ezért a jogosultságok kezelését a szolgáltatásokban is figyelembe kell venni. Ilyen


60

lehet például felhasználói adatok lekérdezése esetén a rejtett mez˝ok 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˝o halmazát láthatják, ezt a sz˝urést pedig már az üzleti oldalon el lehet végezni. Néhány authentikációval és authorizációval kapcsolatos lehet˝oséget a 6.5.2. fejezet mutat be.

6.3.8. Megjelenített komponensek • egyedi komponensek [beleértve az oldaltöredékeket, oldalakat is] • validáció lehet˝osé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˝ol és szerept˝ol függ˝o) megjelenítés A megjelenít˝o réteg még a következ˝o á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˝o oldal jelenik meg, majd belépést követ˝oen az eredetileg kért oldal jelenik meg • letöltések: bináris adatok kiszolgálása, neki megfelel˝o MIME típussal; a kérés paraméterében szerepl˝o azonosító láthatóságát a szerver ellen˝orzi és egy webr˝ol nem elérhet˝o könyvtárból szolgálja ki a tartalmat

6.4. Néhány példamodul

61

6.4. Néhány példamodul Az eddig leírtakat a következ˝o 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˝o rendszerek jellegzetességeinek vizsgálatára alkalmas, valamint az üzleti logika is kicsit nagyobb mennyiség˝u ellen˝orzést tartalmaz (jogosultságok, szavazott-e már a felhasználó az adott szavazáson).

6.4.1. 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˝o felhasználóra vonatkozó hivatkozást is tartalmaznak. A megjelenít˝o oldalak viszonylag egyszer˝uek, csak a csoportba tartozás vizsgálata szükséges. Ez egy összetett lekérdezéssel valósítható meg legegyszer˝ubben: 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˝oz˝oeknél könnyebben használhatók az objektumok közötti navigációk és a JOIN m˝uveletek: 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˝o lekérdezés implicit módon tartalmazza a Group osztályt és az a JOIN kulcsszóval könnyen összerendelhet˝o 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)


62

ORDER BY news.creation DESC"

6.4. Hírek lekérdezése belépett felhasználóhoz Az el˝oz˝o lekérdezés negatívuma, hogy a küls˝o 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˝o. A küls˝o kérésben explicit módon megadva a JOIN news.groups kifejezést, majd erre alkalmazva a csoportokra vonatkozó vizs-

gálatot elkerülhet˝o az el˝obb említett fölösleges kapcsolás is (ezt a jobb adatbázis-kezel˝o rendszerek bels˝o értelmezés során elintézik).

6.8. á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˝o menü, jelöl˝onégyzet csoport, dátum beviteli mez˝o komponensek is el˝ofordulnak, 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˝o szegélye és címkéje felt˝un˝o szín˝u lesz és egy összegzés helyen a hiba szövege látható. A kötelez˝o mez˝oket szerencsés el˝ore jelezni, ami így sok esetben azok hiányából adódó fölösleges szerver oldali feldolgozást el˝oz 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


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.

6.4.2. 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˝u 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˝orzi, hogy valóban jogosult-e az illet˝o 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˝usítése (és hatékonysága) miatt célszer˝u 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˝oségek láthatók, belépve a szavazni is lehet (˝urlap komponensek jelennek meg), adminisztrátorként, illetve szavazást követ˝oen pedig az eredmények is láthatók (utóbbi esetben az u˝ rlap elemek elt˝unnek).

6.9. á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 6.10. á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˝ubb módja többsoros szövegbeviteli mez˝o használata,


64

6.10. á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˝obbi módosítás miatt van szükség: módosításkor is lehet˝osé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˝o JSF keretrendszerek tartalmaznak hasonló funkciójú komponenst, viszont ezek nem teljesen felelnek meg az elvárásoknak (létez˝o pont átnevezése, rendezés), így legyegyszer˝ubb saját komponenst készíteni, mely így nem függ a gyártók verzió-frissítéseit˝ol sem. Az els˝o á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˝ové (a hozzájuk kapcsolódó akciókezel˝ok változtatják meg a lista elemeinek sorrendjét), az átnevezés pedig az új opció felvételéhez használt mez˝o és egy kiegészít˝o gomb elhelyezésével valósítható meg. Ezekben az esetekben a validációk is az eddigiekt˝ol eltér˝o megoldást kívánnak: az opciók felvétele esetén ugyanis nem kell ellen˝orizni a cím mez˝o kitöltését, míg a felvétel esetén az új pont felvételéhez tartozó mez˝ot. Wicket esetén ezt az akciókezel˝o metódusokban, Creator 2 JSF esetén pedig úgynevezett virtuális u˝ rlapok segítségével lehet megoldani. A virtuális formok egyetlen akciókezel˝o elemet (gomb, link) és néhány bevi-

6.5. Egy modul megírásának lépései

65

teli mez˝ot tartalmaznak és a keretrendszer gondoskodik arról, hogy a feldolgozás során csak az akciókezeléshez kapcsolódó mez˝oket validálja.

6.5. Egy modul megírásának lépései Egy modul elkészítése a következ˝o 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˝ok 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˝ujtése 4. Session bean elkészítése (a) üzleti funkció összegy˝ujté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˝oség) (c) visszahelyezés NetBeans alá: i. EJB híváshoz szükséges csomag átmásolása


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˝o – Portál konfigurálása: a portletek megfelel˝o tárolókban történ˝o elhelyezése, paraméterezése

6.5.1. Eszközök a fejlesztés támogatásához Az el˝oz˝o pontokat követve több fejleszt˝oeszköz is használható az alkalmazás elkészítése során. A többivel szemben a NetBeans alapú megoldás el˝onyei a következ˝ok: • kis méret, könny˝u telepíthet˝oség, egyszer˝u integráció a vizsgált alkalmazásszerverekkel (Sun AS, JBoss, Tomcat) • a megjelen˝o új szabványok, keretrendszerek gyors támogatása (Java 5, EJB 3), fogd-és-vidd JSF fejleszt˝okörnyezet (Creator 2), új komponensek támogatása • a fejleszt˝orendszer és a munkakönyvtárak áttekinthet˝osége Ugyanakkor néhány szempontból rosszabbnak bizonyult a több kornyezett˝ol:


67

• több párhuzamos fejlesztésb˝ol adódó inkompatibilitás (5, 5.5, 6; Studio Creator 1, 2; Studio Enterprise 8); erre a lehet˝oségek telepítése pluginként jelent megoldást

6.5.2. Azonosítás, szerepek kezelése Az alkalmazások több megoldás szerint is ellen˝orízhetik a kérések jogosultágát. Ezek közül a leggyakoribb az el˝oz˝o részben már ismertetett beléptetés és a jogosultság ellen˝orzése, ami ugyancsak több módon is elvégezhet˝o: • a teljes folymatatot az alkalmazás végzi (beléptetés, lekérések között az azonosítás meg˝orzése, hozzáférés ellen˝orzése) • JAAS (Java Authentication and Authorization Service, Java Hitelesít˝o és Engedélyez˝o Szolgáltatás1 ) használatával: az ellen˝orzé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˝orzéseket teljes mértékben a konténer végzi Az els˝o megoldás hátránya, hogy sok kódolást igényl˝o, egyedi megoldás. Az alkalmazás készít˝oinek 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˝o. 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˝oen is tárolni kell, vagy teljesen megbízhat˝o 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˝ubb, 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˝ok ezek az információk. 1

a UNIX rendszerekben megszokott PAM (Pluggable Authentication Module) Java megfelel˝oje


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˝oen a felhasználóhoz kapcsolódó Principal objektum az EJB oldalon is elérhet˝o, amir˝ol a new InitialContext() parancs gondoskodik.

6.11. ábra. Realm létrehozása Glassfish alatt (3. eset) A harmadik esetben is szükség van egy modul megírására (f˝obb elemei megegyeznek az el˝oz˝ovel). A modulra jellemz˝o, hogy er˝osen alkalmazásszerver specifikus. Ezen kívül viszont minden szabványos módon kezelhet˝o: ezek egy része deklaratívan, egy másik része programozottan adható meg. A következ˝o lehet˝oségek érhet˝ok el: • az alkalmazás (vagy a szerver globálisan) beállíthatja a birodalmat (realm), melyet az el˝obb említett kiegészít˝o 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˝o oldalt, ami megjelenik akkor, ha a kérés egy szereppel elérhet˝o URL-re vonatkozik – megadja a hibák esetén megjelen˝o oldalakat (hibás belépés, 403 oldal a belépést követ˝o hiányzó jogosultság esetén) – getRemoteUser, isUserInRole, getUserPrincipal metódusok segítésével kérhet˝ok adatok a lekér˝o felhasználóról – URL-ekez szerepeket rendel, így a letölthet˝oséget korlátozza (XML)


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˝orzést követ˝oen 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˝orzé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˝ur˝o 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˝onek 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˝ové 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˝u (néhány oldalból álló), prototípus vagy azonosítás nélküli rendszerek esetén az els˝o 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.

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˝oen ez a fejezet összefoglalja az egyedi vonásokat, az el˝onyös és hátrányos tulajdonságokat és különböz˝o szempontok szerint összehasonlítja a megoldásokat.

7.1. Üzleti réteg A három bemutatott lehet˝osé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˝obb el˝onye, 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˝oforrásigénye is. Az EJB 3 szabvány sok tekintetben az EJB 2 utóbbi rendszerek egyszer˝usítéseit alkalmazó változata. A fejleszt˝ok szempontjából leginkább az új lehet˝oségek (pl. perzisztens réteg új elemei) és az egyszer˝usítések (gyártófügg˝o XML leírók helyett annotációk) a legfontosabbak. A Java EE (JSR-244) és ennek részét képez˝o EJB 3 (JSR-220) szabvány végleges változatai 2006. május 11-én jelentek meg. Párhuzamosan készülnek az ezt támogató alkalmazásszerverek is: Glassfish1 (mintaimplementáció), JBoss, Oracle. A perzisztens réteget támogató két legjelent˝osebb rendszer: Toplink (Glassfish, Oracle) és Hibernate (JBoss). A szabványnak köszönhet˝oen a perzisztens réteg a szervereken lecserélhet˝o, 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

7.1. Üzleti réteg

71

Spring

Hibernate

+ Inversion of Control használata

+ elterjedt ORM keretrendszer

+ bean-ek injektálása XML-ben egy- + könnyen használható (egyedül és szer˝uen megadható együttm˝uködve is) + beépített Hibernate támogatás

+ annotációk használata (regebben

XDoclet támogatás) + az üzleti logika POJO segítségével + egyszer˝u adatbázis séma generálás megoldható + POJO használata

+ könnyen tesztelhet˝o

- forráskódok és XML leírók redun- + objektum-orientált lekérdezések danciája - implementáció, nem szabvány - nem szabványos megoldás EJB 2.1

EJB 3

+ elterjedt, robosztus, szabványos

+ EJB 2.1, Hibernate, Spring kedvez˝o tulajdonságait tartalmazza

+ 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˝oállítása, adatbázis séma)

+ ú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

- sok gyártóspecifikus elem (XML leírók, biztonság) - jelenleg (2006. április) még csak - nehezen tesztelhet˝o (konténer szükséges hozzá)

szabványtervezet

7.1. Üzleti réteg

adattovábbítás O/R leképzés örökített entitás JOIN lekérdezés deklaratív jogosultságok tranzakciók validálás adatok mentése

üzleti logika hívása aszinkron üzenetküldés el˝ore definiált sz˝urés

72 Hibernate + Spring sorosítás XML / XDoclet + + -

EJB 2.1 DTO generált XML XML

EJB 3 sorosítás annotációk + + XML / annotáció

kézzel

konténer / kézzel

DTO, check() DAO, Hibernate saveOrUpdate metódusa service locator (Spring kontextus, getBean) -

DTO, check() set metódusok

konténer / annotációval / kézzel annotáció .persist(), .merge()

@Filter

service locator annotáció (JNDI) + XML message bean -

driven message bean -

driven

7.1. táblázat. Üzleti rétegek összehasonlítása Az el˝oz˝o táblázatokon az egyes lehet˝oségek legf˝obb el˝onyeit és hátrányait lehet látni, míg 7.1. táblázat a lehet˝oségeket és a különböz˝o funkciókra biztosított megoldásokat veti össze. Gyakran használt, az EJB 3 szabványban nem szerepl˝o kiegészítések: • lusta (lazy) betöltés˝u objektumok leválasztása (detach), mely másik konténerben való felhasználásához szükséges (JOIN jelleg˝u lekérdezés esetén erre van lehet˝oség a FETCH kulcsszó megadásával); ez a Hibernate.initialize() paranccsal vagy a forrás konténerben lekérdezést követ˝o végiglépkedéssel oldható meg • a kapcsolatok mentén lehet˝osé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˝oállítása alkalmazható (a rendezés mez˝oit az entitás


73

osztályok statikus konstans felsorolásaként megadva fordítási id˝oben ellen˝orizhet˝o a felhasznált paraméterek helyessége) • apró eltérések az implementációk között (ez els˝osorban 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˝o törléséhez el˝obb 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˝ol 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˝ore megírt, pozicionálást használó komponens) • az alapvet˝o Object metódusok felüldefiniálása több m˝uvelet esetén szükséges (cache alkalmazása, web modulban történ˝o akciókezelés során egyenl˝oség vizsgálata), ezért célszer˝u lenne generálni (például annotációkból, megjelölve az egyenl˝oség és a hash esetén figyelembe vett mez˝oket) • cache alkalmazásának lehet˝oségét nem tartalmazza a szabvány (opcionális elemként sem), ezért ennek eléréshez implementáció-függ˝o 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˝o réteg megírására a középs˝o 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˝oleges portlet (JSR-168) technológia.


74

A megjelenít˝o 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˝o 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˝uség, modellel történ˝o ö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˝ové 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˝olük el˝oá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˝ol 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˝u kiértékelését is. A JSF összetett életciklus-modellje az akciókezelés széles körének feldolgozását lehet˝ové teszi, ugyanakkor a legegyszer˝ubb esetekben túl bonyolultnak t˝unhet 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˝o (például könyvjelz˝ovel elmenthet˝o oldalak). A megjelenít˝o rendszerek egy másik része nem is használ JSP-re emlékeztet˝o jelöléseket. A Velocity egy egyszer˝u 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˝uen definiálhatók egyedi komponensek is (a hozzá tartozó


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˝oen a hozzá kapcsolódó (azonos nev˝u) Java forrásokban a Swing-hez hasonlóan add metódussal adható meg az adott helyen szerepl˝o 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˝ubb és a felületek összerakása egyszer˝u eszközökkel is gyorsan és könnyen elvégezhet˝o, tesztelhet˝o. Az új fejlesztési változatok több látványos funkciót is támogatnak (AJAX, jól kinéz˝o URL), a testreszabhatóság miatt pedig könnyen kiegészíthet˝o (például a JSF-hez hasonló navigációs leírással). JSF

Wicket

+ szabványos, jó eszköztámogatás

+ hagyományos szemlélethez közeli

+ sok kiegészít˝o komponensek

+ az alakkészletben is gazdag elem-

+ modellekkel jól leírható + navigáció leírása, állapotkezelés, validátorok, konverterek

készlet (komponensek, AJAX, validáció) + egyszer˝uen készíthet˝ok komponensek

egyedi

+- sokféle komponens készíthet˝o, de + könnyen b˝ovíthet˝o (ServiceLocator, ennek módja nehézkes navigáció) - az életciklus-kezelés néha bonyolult, + újrafelhasználható komponensek eltér a verziók között (1.x) - a kiegészít˝o készletek gyártófügg˝ok - POST változók használata - JSTL-lel csak az 1.2 változat m˝uködik (iterátor komponens hiánya)

+ egyszer˝u hibakezelés - nem szabványos - még aktív fejlesztés alatt áll, kisebb fejleszt˝oközösség

Creator 2 kiegészített

JSF verzió fejleszt˝okörnyezet

1.0, 1.1 (, 1.2)

felhasználhatóság, ár futtató szerver

nyílt

1.1 1.0 (WS 6.0) Sun Java Studio IBM RatioCreator 2 nal Software Architect nyílt kereskedelmi

elemkészlet

dokumentáció facelet támogatás

Websphere kiegészített

ADF Faces gazdagon kiegészített 1.1 jDeveloper

minden nem túl Sun AS, Sun PS, régi web konténer Glassfish, Pluto

IBM Websphere

kereskedelmi (nyílt) Oracle AS

gazdag igen

kevés igen

gazdag igen

gazdag igen

MyFaces kiegészített


Reference Impl. alap

1.1 Exadel Studio

nyílt Tomcat, Glassfish, Websphere, JBoss gazdag többé-kevésbé

7.2. táblázat. JSF implementációk jellemz˝oi

76

7.3. Összehasonlítás fejleszt˝oi oldalról

77

JSF esetén a szabványos részek használata már nem elegend˝o egy korszer˝u 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˝oit foglalja össze a 7.2. táblázat. A portál megoldás az eddig említett megjelenít˝o 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˝obb készültek el hozzá az újabb megjelenít˝o rendszereket (pl. JSF) alkalmazó, stabilan m˝uköd˝o b˝ovítések (2005-2006). A Creator 2 beépítve tartalmaz JSF esetén is használható Pluto tesztkörnyezetet, melyet a 2006. 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-rc3 2006. május 1-én jelent meg). A különböz˝o 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˝ové teszi a szabvány és több el˝ore elkészített komponens is használható (id˝ojárás, hírforrások). Alkalmazásuk el˝ott fontos azonban megvizsgálni a nyújtott új funkciókat, az er˝oforrá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˝u webes keretrendszerek, melyeket nem támogat.

7.3. Összehasonlítás fejleszt˝oi oldalról Az EJB 3 szabvány egyik fontos célja a fejleszt˝ok 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˝oen az esetek többségében egyszer˝u 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.


78

A másik fontos könnyítés a telepítési leírók egyszer˝usí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˝okö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˝o helyén adhatók meg • kevesebb gyártóspecifikus tulajdonságot kell figyelembe venni: a gyártófügg˝o részek nagy részét sem a felület, hanem az alkalmazásszerver állítja el˝o (EJB, JNDI, er˝oforrás hivatkozások) A függ˝oségek feloldása (dependency injection) pedig a JNDI mechanizmust egyszer˝usí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˝o el˝ol elfedi az EJB 3 és az azt tartalmazó JEE 5 szabvány). Az egyértelm˝usé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˝u jellemz˝o 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˝o 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˝o oldalak (v) és oldalvázak (template, 4 db); Wicket esetén statikus oldalak, megjelen˝o oldalak (v), komponensek összetev˝okb˝ol állnak. Facelets használata nélkül (tisztán JSF


Java osztályok száma domain.*: DTO.*: services.*: interfészek száma domain.*: services.*: XML leírók száma ebb˝ol kézzel módosított

79 EJB 2.1

EJB 3

d d s

d 0 s

2d (3d) 2d (4d) 3 1

0 ≤s 1 0

7.3. táblázat. EJB2.1 és EJB3 mér˝oszámok megoldással) a megjelen˝o oldalak mindegyikét ki kellene egészíteni a vázban szerepl˝o megfelel˝o részekkel (ez kb. 10 kB méret˝u). Wicket esetén a több újrahasznosítható komponens miatt van több HTML és Java file.

JSP / HTML file-ok ezek mérete (kB) Java osztályok száma ezek mérete (kB) ezek sorainak száma XML leírók száma ezek mérete (kB)

JSF + Facelets 4 + 7 + 8 = 19 40 + 20.5 + 20.5 = 81 9 94 3256 8 40

Wicket 4 + 8 + 11 = 23 10 + 9.5 + 11 = 30.5 24 55 1568 3 8

7.4. táblázat. Megjelenít˝o rendszerek mér˝oszámai a példára További olyan tényez˝ok, 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˝orumok, 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˝o keretrendszerek a JSF-nél jobbnak bizonyulnak, mivel JSF esetén nem létezik egységes, a többivel


80

együttm˝uköd˝o megvalósítás és fórum, ahol mindegyik rendszerre alkalmazható és kell˝oen részletes támogatás lenne elérhet˝o.

7.3.1. A fejleszt˝okörnyezetek lehet˝oségei Az el˝oz˝o részekben már szerepeltek a fejleszt˝orendszerek általános jellemz˝oi, 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˝orendszer 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 J2SE5 + + + + UML + EJB 2.1 + + + EJB 3 + + DTO ~ ~ EJB hívás + + web.xml ~ + JSF ~ ~ + MyFaces + Virtuális form -

RSA + + + ~ + -

JSC 2 + + + +

7.5. táblázat. Fejleszt˝okörnyezetek áttekintése

Egyszerusít˝ ˝ o lehet˝osé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˝ot 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˝o: JSE 5 annotációk segítségével megjelölhet˝ok a figyelembe venni kívánt mez˝ok (és get metódusok). A példában • egy közös entitás o˝ 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


81

A mérések 500, 1000, 2000, 5000 és 10000 objektum esetén, minden alkalommal 5 ismétléssel szerepelnek. A példában az objektumok létrehozása során azt minden megel˝oz˝o 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˝o menü) kell kiválasztani az aktuális értéket (létrehozó és módosító oldalakon gyakran el˝ofordul). Mivel ekkor az objektumok számával négyzetesen n˝o az összehasonlítások száma, valamint az esetek nem lineáris elhelyezkedés˝uek, ezért az adatok ábrázolását egy gyökvonás, majd egy logaritmus számítás el˝ozte 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˝o görbe örökített kontruktorral és megírt összehasonlító és hash képz˝o metódussal rendelkez˝o esetre vonatkozik. A számítások során nem volt megfigyelhet˝o különbség a get hívások, illetve az attribútumok közvetlen használata között.

7.1. ábra. Java Objektum metódusok felüldefiniálása

7.4. Lehet˝oségek tesztelésre

82

EJB 2 szabványt támogató fejleszt˝orendszerek 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˝oen 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˝o.

7.4. Lehet˝osé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˝ol lehet választani. Egy teszteset valamilyen m˝uvelet(sor) elvégzését és azt követ˝oen 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˝uködését is vizsgálja. Egy osztály értékhatárainak vizsgálatára épül˝o (domain analysis) és állapotgráffal (state chart) leírt dinamikus m˝uködésnek megfelel˝o viselkedést ellen˝orz˝o tesztesetek is megadhatók. A tesztesetek csoportokba szervezhet˝ok, valamint a csoportok hierarchiába is rendezhet˝ok. Java esetén a jUnit keretrendszer használható ezek megadására és futtatására. Ezt sok fejleszt˝okö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˝ok. Egyszer˝u Java alkalmazások esetén a jUnit rendszer könnyen használható, viszont J2EE rendszerek esetén az alkalmazások eltér˝o környezetben futnak (web és EJB konténerben), így kiegészít˝o megoldás szükséges az alkalmazásához. A legegyszer˝ubb 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˝ok 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


83

a kliens alkalmazás eltér˝o futtatókörnyezetéb˝ol adódóan eltér˝o teszteredmények keletkezhetnek. • Az üzleti logika mellett a webes alkalmazások megjelenít˝o rétegének tesztelése is szükséges lehet.

7.2. á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˝usítése céljából ant taszk is definiálható, mely a teszt futása el˝ott 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˝o, mely XSL stílus megadásával jól áttekinthet˝o, táblázatos formában jelenik meg (7.2. ábra). A TestNG keretrendszer a jUnit lehet˝oségeit egészíti ki, például Java 5 annotációkkal adhatók meg a tesztesetek, szervezhet˝ok csoportba, valamint a futás eredménye az XML formátum mellett részletesebb, HTML formában is megtekinthet˝o. A könny˝usúlyú alternatívák (pl. Spring) tesztelése is egyszer˝ubb az EJB 2 alkalmazásokénál, ugyanis a futtatókörnyezet sokkal egyszer˝ubben biztosítható és a teszteléshez nem szükséges az alkalmazászerver futása: az applicationContect.xml helyének


84

megadásával állítható be a Spring IoC lehet˝oségét biztosító konténere, melyhez így telepítés (deploy) sem szükséges. Az EJB 3 bean-ek egyszer˝u 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˝oforrások sem érhet˝ok 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˝orzését is tartalmazzák. Erre

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), u˝ rlapokat (FORM-ok kitöltését és elküldését), akciókezelést követ˝oen oldal vizsgálatát elvégezni (7.3. ábra).

7.3. á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˝o terheltségek mellett szerepelnek a válaszid˝ok, EJB 2 és EJB 3 megvalósítás esetén.

7.5.1. 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˝o 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˝o letöltést követ˝oen cache-b˝ol érhet˝ok el, a küls˝o URL-hez kapcsolódást igényl˝o modulok (pl. képajánló) és küls˝o hivatkozások a mérés során ki vannak kapcsolva. Ez a távoli függ˝oségek leválasztása miatt szükséges.


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˝o 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˝o réteg mindkét eseteben JSF alapú, kiegészítve a Facelets keretrendszerrel.

7.5.2. A mérés környezete Az els˝o 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˝ol) • 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˝o 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ázissal2 A méréshez használt parancs: httperf3. Minden esetben 5000 kérés kiszolgálása szerepel, egyre növekv˝o másodpercenkénti letöltési szám mellet. Az oldalak kiszolgálásához id˝okorlát kapcsolódik [10 sec], ennek túllépése esetén a kérést sikertelennek (client timeout) értékeli az mér˝oprogram. A két mért alkalmazás a szerveren eltér˝o domain alatt szerepel, így lehet˝osé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˝otúllépés miatt sikertelen kérések. A legels˝o, 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˝obb szerepl˝o eredményeknél rosszabb teljesítményt adott, ennek oka a hálózat sávszélessége. 3

http://www.hpl.hp.com/research/linux/httperf/docs.php


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=4096 --recv-buffer=16384 --num-conns=500 --num-calls=1

7.5.3. Eredmények Az elvárás alapján az els˝o néhány esetben hibák (id˝otúllépés) nélkül lefut a kiszolgálás, egyre növekv˝o válaszid˝ovel. Ezt követ˝oen 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˝oz˝o kérések feldolgozását végzi, így azokon kívül az új kérésekkel sem végez id˝oben. 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˝obb a „nem elérhet˝o szolgáltatás” hibaüzenetnél. A következ˝o ábrákon látható grafikonok és alattuk lév˝o 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˝o [ms], logaritmikus skála • jobb Y-tengely: hibás válaszok (hiba és id˝otú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˝o m˝ukö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˝oen az adott irányba nem továbbít kéréseket a terheléskiegyenlít˝o. Egy webes felületen követhet˝o a kiszolgálók állapota, a feléjük küldött kérések száma, valamint ugyanitt van lehet˝osé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˝ok 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


88

sebesség elérését követ˝oen nem növelhet˝o tovább a 80-90 közötti kérésszám [1/s] (a sávszélesség-kihasználtság például az iftop nev˝u paranccsal ellen˝orizhet˝o).

7.4. ábra. Egy elosztott mérés kimenete

[1/s] Kapcsolódás [ms] Válaszid˝o [ms] Hibák aránya [%] valódi ráta 20 24,4 23,5 0 20 30 35,7 34,7 0 30 40 29,6 28,4 0 40 50 531,7 236,6 0 50 60 809,7 766,2 0 60 70 1881,2 798,8 0 70 80 2356,9 1353,0 0 80 90 3646,2 1595,3 6,68 82.1 100 5284,1 2221,9 24,12 58.6


89

[1/s] Kapcsolódás [ms] Válaszid˝o [ms] Hibák aránya [%] valódi ráta 20 27,2 25,5 0 20 30 32,6 35,3 0 30 40 38,2 36,4 0 40 50 47,2 80,7 0 50 60 158,6 155,0 0 60 70 4484,5 2340,3 6,32 58.8 80 6347,7 2865,5 30,84 47.6 90 7687,4 3288,7 42,30 44.0

7.5.4. Értékelés Az EJB 2 és EJB 3 megoldások során tapasztalt eredmények a várakozásoknak megfelel˝oen nem térnek el jelent˝osen. Az alkalmazásszerver hasonlóan kezeli a két esetet (például az EJB 3 annotációk egy részéb˝ol a telepítés során hagyományos XML leíró részlet keletkezik). Mindkét rendszer másodpercenként 60-80 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˝o EJB 3 mérés során felt˝un˝oen rossz eredmények születtek, mely az entity bean-ek sorosítására volt visszavezethet˝o: 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˝o. Megoldást jelent még a problémára local interface használata, ugyanis csak webes megjelenít˝o réteg esetén remote interface els˝osorban csak valódi HA4 esetén szükséges.

4

High Availability: nagy rendelkezésre állás, a szerverek Enterprise Edition változatán alakítható ki

8. Összefoglalás A korszer˝u webes rendszerek jelent˝os része J2EE alapú megoldás. Ezek az objektumorientált Java nyelvre épülnek, mely könnyen modellezhet˝o. A platformfüggetlenség széles környezetben történ˝o futtatást tesz lehet˝ové és mivel egy API gy˝ujteményr˝ol van szó, ezért a gyártók a szabványos elemeket egyéni lehet˝oségekkel egészíthetik ki. Rendszerek tervezésénél egyre fontosabb szempont a modellezés és ezt felhasználva alacsonyabb szint˝u modellek származtatása és forráskód generálása. Az UML szabványos, széles körben elterjedt modellez˝o nyelv, melynek egyes elemeit a legújabb fejleszt˝orendszerek már szervesen tartalmazzák, így lehet˝ové téve a platformfüggetlen modellb˝ol platformspecifikus (J2EE) modell, majd forráskód (Java osztályok, metódusok, üzleti funkciók) el˝oállítását és ezeket érint˝o modell–forrás szinkronizációt (reverse engineering). Ugyanakkor még sok területen nincs megfelel˝o 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˝orzés a fejleszt˝ok feladata (az UML kifejez˝oereje nagyobb, mint a megvalósított alkalmazásé). A J2EE platform egy szabványos API gy˝ujtemény, melynek el˝onye, 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˝o tervezési mintákat, bevált gyakorlatokat [10], valamint a gyártók és a fejleszt˝ok is képviselhették érdekeiket (ezért a végleges verzió néha sok id˝o 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˝ok, 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˝o után elavul a gyors fejl˝odésb˝ol adódóan. Megoldásként az opcionális lehet˝oségeket felhasználva különböz˝o alternatív kiegészítések jelennek meg, melyekre jellemz˝o, hogy nem könnyen m˝uködnek együtt más opcionális elemekkel, valamint használatukhoz a futtatórendszer kiegészítése szükséges, így meg90

91 nehezítve a gyártók közötti szabad választást. A változások egyik forrása a (kezdetben egyszer˝u) keretrendszerek szabványossá alakítása (Jakarta Taglibs → JSTL), másik forrása keretrendszerek lehet˝oségeinek felhasználása a szabvány új verziójában (Hibernate és Spring egyszer˝usítéseinek megjelenése EJB 3-ban). Az alsóbb szint˝u (például Java) fejl˝odések is kihatással lehetnek a fels˝obb szintekre (például telepítési leírók egyszer˝usí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˝oz˝o 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˝uveletek, 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˝obb említett hiányosságokat orvosolta a lefelé kompatibilitás meg˝orzése mellett, valamint a szabványos megoldásból adódóan az erre épül˝o alkalmazások nem függnek keretrendszerekt˝ol és a gyártófügg˝o 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 u˝ rlap elemeket és a kitöltött adatokat egyszer˝uen képes az adatmodellnek megfelel˝o objektumokba írni. A validációra, adatok konvertálására és akciókezelésre is tartalmaz megoldásokat, melyek az el˝otte használt szabványos eszközökkel (Model 2 architektúra) nehezen elvégezhet˝o. Negatívuma, hogy egyszer˝u esetekben túl bonyolult az életciklus-modellje, a navigáció nehézségei (POST küldés, böngész˝o vissza gombja). Sok kiegészít˝o implementáció jelent meg (MyFaces, ADF Faces, Sun és IBM kiegészítései), melyek nehezen m˝uködnek együtt és eltér˝o JSF verziókra épülnek. Az új funkciók (template, AJAX) is kiegészít˝o 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˝o szinteken egészítik ki a szabványt: a Struts JSP-re és JSF-re

92 (Struts-Shale) épít, mások a servletre (Wicket, Tapestry). Ezeknek a keretrendszereknek a használatakor az alkalmazás fejleszt˝oinek szükséges mérlegelni az ebb˝ol származó el˝onyöket (általában egyszer˝ubb, a feladathoz jobban illeszkedik, könnyebben használató) és hátrányait (a fejlesztése és támogatottsága fejleszt˝ocsapatoktól függ, nem nagy gyártóktól). Sok esetben ezekhez a keretrendszerekhez is tartalmaznak támogatást a fejleszt˝orendszerek (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˝ujté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˝o webes rendszer esetén lehet célszer˝u a használata, mivel a tartalmak könnyen integrálhatók használatával, ugyanakkor az er˝oforrás-igénye és költsége is jelent˝osebb a hagyományos webes rendszerekénél. A J2EE rendszerek megoldásai és fejlesztési folyamata az alkalmazásokkal kapcsolatba kerül˝o több csoport számára is kedvez˝o. A fejleszt˝ok irányából érkez˝o visszacsatolások eredményét tartalmazzák az új változatok (egyszer˝usí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˝o. A gyártók a szabványos elemekb˝ol adódóan együttm˝uköd˝o alkalmazások elkészítését teszik lehet˝ové (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˝ové. Az üzemeltet˝ok a csökken˝o számú gyártófügg˝o 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˝o kiegészítésekkel már a szabványok el˝ott találkozhatnak (pl. AJAX) és ergonimikus alkalmazásokkal találkozhatnak.

Irodalomjegyzék [1] Cay Horstmann David Geary. Core JavaServer Faces. Prentice Hall, 2004. ISBN: 0-1314-6305-5. [2] Gerald Brose Ed Roman, Rima Patel Sriganesh. Mastering Enterprise JavaBeans. Wiley Publishing, Inc, third edition, 2005. ISBN: 0-7645-7682-8. [3] GoF Erich Gamma. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Professional, 1994. ISBN: 0-2016-3361-2. [4] Neal Ford. Art of Java Web Development. Manning, 2003. ISBN: 1-9323-9406-0. [5] Marty Hall. Core Servlets and JavaServer Pages. Prentice Hall, 2003. ISBN: 0-1308-9340-4. [6] Rick Hightower. Jakarta-Struts Live. SourceBeat, 2004. ISBN: 0-9748-8430-8. [7] Dave Minter Jeff Linwood. Building Portals with the Java Portlet API. Apress, 2004. ISBN: 1-5905-9284-0. [8] Rod Johnson. Introducing the spring framework. TheServerSide.com, 2003. http://theserverside.com/articles/article.tss?l= 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˝uszaki Egyetem, 2002. [10] Floyd Marinescu. EJB Design Patterns – Advanced Patterns, Processes and Idioms. Wiley Publishing, Inc, 2002. ISBN: 0-4712-0831-0. 93

[11] Sun Microsystems. Web component development with java technology, 2002. Sun SL-314 kurzus jegyzete. [12] Sun Microsystems. Developing application for the j2ee platform, 2005. Sun FJ310 kurzus jegyzete. [13] Matt Raible. Spring Live, chapter 2. SourceBeat, 2004. ISBN: 0-9748-8434-0. [14] Derek Yang Shen. Put jsf to work. JavaWorld, 2004. http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf. html.

[15] Chad Vawter and Ed Roman. J2ee vs microsoft.net – a comparison of building xml-based web services. The Middleware Company, 6 2001.

Webcímek1 Java EE http://java.sun.com/javaee/5/docs/tutorial/doc/ Java EE 5 dokumen-

táció http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ J2EE 1.4 dokumentá-

ció

Hírportálok http://blogs.sun.com/roller/page/theaquarium Aquarium blogok gy˝ujte-

ménye http://www.theserverside.com TheServerSide.com http://www.javaworld.com JavaWorld 1

A webes hivatkozások az oldalak 2006. május 13-i tartalmára vonatkoznak.

IRODALOMJEGYZÉK

95

Keretrendszerek web alkalmazásokhoz http://www.springframework.org Spring keretrendszer http://jakarta.apache.org/tapestry/ Tapestry http://jakarta.apache.org/hivemind/ HiveMind http://struts.apache.org Struts

Wicket http://wicket.sourceforge.net Wicket keretrendszer http://wicket-stuff.sourceforge.net Wicket kiegészítések http://jroller.com/page/dashorst Wicket rendszerrel kapcsolatos hírek

JavaServer Faces http://java.sun.com/javaee/javaserverfaces/ http://www.jsfcentral.com JSF hírek gy˝ujteménye http://myfaces.apache.org MyFaces JSF implementáció és Tomahawk kompo-

nensek http://theserverside.com/news/thread.tss?thread_id=38669 ADF Fa-

ces (Oracle) http://facelets.dev.java.net Facelets template rendszer JSF oldalakhoz

Fejleszt˝okörnyezetek http://www.netbeans.org NetBeans http://developers.sun.com/prodtech/javatools/jscreator JSF fejlesz-

t˝orendszer: Sun Java Studio Creator 2

IRODALOMJEGYZÉK

96

http://www.eclipse.org Eclipse http://www.exadel.com Eclipse kiegészítés J2EE web alkalmazások készítéséhez

Tesztelés http://www.junit.org/index.htm jUnit keretrendszer http://jwebunit.sourceforge.net jWebUnit keretrendszer http://testng.org/doc/ TestNG keretrendszer http://jakarta.apache.org/cactus/ Cactus keretrendszer

UML modellezés http://www.uml.org Hivatalos UML oldal az OMG honlapján http://www.netbeans.org/products/enterprise/ NetBeans kiegészít˝o cso-

mag, mely UML 2 támogatást is tartalmaz

Futtatórendszerek http://glassfish.dev.java.net Glassfish alkalmazásszerver http://www.apache.org Apache webszerver http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingMod_jkWithJBoss JK

Apache modul használata (Tomcat, JBoss, Glassfish szerverekhez)

Példa alkalmazások http://www.mateklap.hu MatekLap http://www.staroffice8.hu StarOffice 8 honlap http://vir.sch.bme.hu Villanykari Információs Rendszer

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˝u adatmozgások segítségével csökkenti a válaszid˝ot és a szerver terhelését is, mivel így nem kell minden eseményt követ˝oen a teljes oldalt újratölteni API Application Program Interface; alkalmazás felület, mely más rendszerekkel való együttm˝uködést tesz lehet˝ové AS Application Server, alkalmazásszerver; J2EE futtatására alkalmas környezet, mely tartalmazza az ehhez szükséges elemeket (EJB konténer, er˝oforrások), valamint lehet˝osé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˝o í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˝onek 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˝ové.

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˝onyelve HTML HyperText Markup Language; web oldalak jelöl˝onyelve, 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˝oségek csökkentése: ha az alkalmazás kér egy objektumot (a konténert˝ol), akkor el˝obb azt a konténer létrehozza és beállítja a függ˝osé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˝o adatbázisok egységes felület˝u elérésére JEE, J2EE Java Enterprise Edition; szerver oldali Java, API gy˝ujtemény többréteg˝u, 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˝usítése JSP JavaServer Pages; HTML tartalom megjelenítésére alkalmas szabvány, egy kifordított servlet-nek felel meg

99 KIR Kollégiumi Információs Rendszer; a Schönherz Kollégium közösségi portálja, a kés˝obbi VIR el˝odje 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˝o-, modell- és vezérl˝o 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˝ové OMG Object Management Group; nagyvállalati rendszerek közötti együttm˝uködést lehet˝ové tev˝o 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˝ol származó mozaikszó, dinamikus web oldalak írására alkalmas scriptnyelv PIM Platform Independent Model, Platformfüggetlen modell; egy OMG szabványokra épül˝o 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˝u Java objektumok, melyeknek az EJB 2 szabvány bean-jeit˝ol eltér˝oen nem kell megvalósítani különböz˝o szabvány interfészeket SQL Structured Query Language; szabványos nyelv relációs adatbázisokon m˝uveletek (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

100 UML Unified Modeling Language, Egységes Modellez˝o 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˝u, rugalmas szöveges formátum, mely többek között kommunikációra, könnyen feldolgozható leírásokra alkalmas

B. Telepítési útmutató Objektum-relációs leképzés beállítása Ahhoz, hogy az alkalmazásszerveren m˝ukö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˝o 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˝o lépések elvégzése szükséges (a használni kívánt adatbázis létrehozását követ˝oen) 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˝o a JDBC meghajtó elérési útban történ˝o elhelyezése. A példában az alkalmazásszerver az $APP_HOME helyen érhet˝o el. 1. JDBC meghajtó letöltése, mely a http://jdbc.postgresql.org/download. html címen érhet˝o el 2. a letöltött .jar file-nak az alkalmazásszerver megfelel˝o (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˝oen (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 (http://localhost:4848) 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˝u sorban az "Application Server → JVM settings (tab) → JVM Options (altab)" helyen 101

102 7. az el˝oz˝o 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˝ok 8. "Resources → JDBC → Connection Pools" alatt új pool felvétele pl. a következ˝o 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˝o 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˝oforrás felvétele pl. a következ˝o 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˝ové az el˝oz˝oleg beregisztrált PostgreSQL er˝oforrás esetén az automatikus leképzés használata; a módosítás során az SQL92 jellemz˝oket másoljuk át PostgeSQL-hez is:

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˝ojelek, ezért a következ˝o 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˝o: 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˝oen az elérhet˝ové válik a jdbc/Postgresql JDBC er˝oforrás, mely JNDI lekéréssel kapható meg.

104

Glassfish környezet beállítása A MatekLap alkalmazás futtatásához szükséges környezet a következ˝o lépések segítségével állítható be: 1. Glassfish letöltése és az ott leírtaknak megfelel˝oen telepítése (jar futtatása, konfigurálás ant segítségével) a $GLASSFISH_HOME könyvtárba 2. küls˝o é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˝o konfigurálása (vagy a kész domain.xml átmásolása): • realm létrehozása, Security Manager bekapcsolása • a következ˝o 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=8009

5. szerver er˝oforrások felvétele (adminisztrációs felületen vagy fejleszt˝okörnyezetb˝ol): connection pool, JDBC resource, JavaMail resource, queue, queue factory

105 6. 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˝oen 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˝o 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˝uen elvégezhet˝o (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˝o beállításokat célszer˝u elvégezni: JkWorkersFile /usr/local/tomcat/conf/workers.properties JkLogFile /var/log/apache/mod_jk.log JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

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

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˝o 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 AllowOverride None Order deny,allow Deny from all AllowOverride None Order deny,allow Deny from all

C. UML diagrammok

C.1. ábra. A VIR domain modellje

107

108

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

109

C.3. ábra. Médiatár – anyagok adminisztrációja

C.4. ábra. Médiatár – felhasználó-menedzsment PIM

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 email; public User() { } // set and get methods }

D.1. Minta egy felhasználót reprezentáló (JavaBean) osztályra <property name="password" column="usr_password" type="text"/> <property name="loginName" column="usr_loginname" unique="true" not-null="true" length="32"/> <property name="email"

110

D.1. Hibernate, Spring

111

column="email" unique="true" type="text"/>

D.2. Felhasználó objektum-relációs leképzése <property name="driverClassName"> org.postgresql.Driver <property name="url"> jdbc:postgresql://localhost:5432/maszat <property name="username">maszat <property name="password">jelszo <property name="mappingResources"> <list> hu/bme/sch/maszat/model/businessobject/User.hbm.xml <property name="hibernateProperties"> <props> <prop key="hibernate.dialect"> org.hibernate.dialect.PostgreSQLDialect <prop key="hibernate.show_sql">true <prop key="hibernate.cglib.use_reflection_optimizer">true <prop key="hibernate.cache.provider_class">

D.1. Hibernate, Spring

112

org.hibernate.cache.HashtableCacheProvider <prop key="hibernate.hbm2ddl.auto">create <property name="dataSource"> <property name="dataSource"> <property name="sessionFactory"> <property name="jdbcExceptionTranslator"> <property name="hibernateTemplate"> <property name="sessionFactory"> <property name="userDAO">

D.2. JavaServer Faces példák

113

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


114

<jsp:root version="1.2" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:ui="http://www.sun.com/web/ui"> <jsp:directive.page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"/>

115

showSummary="true"/>

D.5. JSF JSP file az el˝oz˝o példához

E. Képerny˝oképek

E.1. ábra. Kollégiumi Információs Rendszer

E.2. ábra. Kollégiumi Információs Rendszer – változtatható küls˝ovel

116

117

E.3. ábra. MatekLap – a J2EE megvalósítás nyitóoldala

E.4. ábra. Alkalmazásszerver monitorozása: jConsole

118

E.5. ábra. StarOffice 8 – egy leíró oldal

E.6. ábra. StarOffice 8 – honlap szövegek szerkesztése

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

Recommend Documents

Servlet ServletExample at " + request.getContextPath () + "