Szabadon választott hálózati J2ME/MIDP alkalmazás fejlesztése

Átírás

1 Szabadon választott hálózati J2ME/MIDP alkalmazás fejlesztése Készítette: Novák György Témavezető: Bátfai Norbert Debreceni Egyetem Informatikai Intézet Debrecen 2004.

2 Tartalomjegyzék 1. Bevezető A használt technológiák Vezeték nélküli hálózatok J2ME Webszolgáltatások Szervletek Castor A rendszerrel szemben támasztott követelmények Funkcionális követelmények Nem funkcionális követelmények A rendszer implementációja Kliens oldal Szerver oldal Mindkét oldalon használt objektumok Kommunikáció Tesztelés Összefoglalás Mellékletek: A Conference rendszer leírása A rendszer rövid leírása A rendszerben előforduló személyek és használati esetek A rendszerben szereplő objektumok...51 Ábrajegyzék...54 Irodalomjegyzék...55

3 1. Bevezető Aki járt már valamilyen konferencián, az tudja, hogy szokás különböző tájékoztató füzetekkel ellátni a vendégeket, melyekben benne van a konferencia előadásainak időpontja, valamint rövid leírása. Ezen füzetecske mérete a konferencia méretével arányosan nő, így egy komolyabb konferencián már kényelmetlen egy vaskos kis könyvecskéből keresgetni, hogy milyen előadás is lesz a kávészünet után (a helyzet még rosszabb, ha több szekcióban, párhuzamosan zajlanak az előadások). Gondoljuk el, hogy mennyivel egyszerűbb lenne, ha csak elővennénk a mobilunkat, vagy a PDA-nkat, és azon egy kis Java programot elindítva, az rögtön megmutatná, hogy milyen előadások zajlanak éppen, mik lesznek a következők, és minden olyan információt egykét gombnyomással elérnénk, amelyre az adott pillanatban szükségünk lehet! Mivel napjainkban már szinte minden embernek van mobil telefonja (van akinek több is), sőt esetenként PDA-ja is, és az újabb (1-2 éves) készülékek nagy része képes Java nyelven írt programok futtatására, ezért az előbb felvázolt lehetőség sok ember számára megkönnyítheti a konferenciák programjának káoszában való eligazodást. Miután már létezik egy web-es felületű rendszer (Conference, lásd 7. fejezet), mely konferenciák szervezését segíti, így most a célom egy mobil környezetben (mobil telefonokon, PDA-kon) futó alkalmazás elkészítése, mely képes a már meglévő rendszerhez kapcsolódni. Ha elkészül ez az alkalmazás, akkor a felhasználónak nem lesz más dolga, mint a web-es felületen regisztrálnia magát, letölteni a mobil készülékére a programot, és máris használhatja a rendszert, azaz áttekinthető formában mindig rendelkezésére áll az általa kiválasztott konferenciák programja. 3

4 2. A használt technológiák Ebben a fejezetben a fejlesztés során felhasználásra kerülő technológiákról adok egyegy rövid ismertetőt. Ezek a leírások semmiképpen nem tekinthetők a technológiákat minden részletre kiterjedően bemutató írásoknak, mindössze egy általános áttekintést próbálok nyújtani, kiemelve azokat a jellemzőket, melyek a készülő alkalmazás szempontjából fontosak. A tárgyalt technológiákhoz bőséges irodalom áll rendelkezésre (mind könyv, mind az Interneten fellelhető ismertetők formájában), amiből az általam is használt írások megtalálhatók az irodalomjegyzékben (lásd: 55. oldal) Vezeték nélküli hálózatok Azt hiszem nyugodtan mondhatjuk, hogy napjaink informatikai világa szinte elképzelhetetlen hálózatok nélkül. A hálózatok előnye többek között az erőforrások megosztása, a megbízhatóság növelése, vagy például az egymással való kommunikáció lehetősége. Ha az asztali számítógépek világát nézzük, akkor a legelterjedtebb hálózat az Internet, mely mára szinte minden számítógépet használó emberhez eljutott. Mikor megjelentek a kézi számítógépek, PDA-k, valamint később a (Java) programokat is futtatni képes mobil telefonok, akkor arra is igény mutatkozott, hogy ezekről a felhasználó elérhessen más gépeket, például kezelni tudja az asztali gépén tárolt dokumentumait. A korábban már jól bevált vezetékes hálózat azonban ebben a környezetben nem alkalmazható, hiszen ezen készülékek legnagyobb erőssége a hordozhatóságuk, amit egy falba dugott kábel rögtön semmissé tesz. Így tehát nem maradt más, mint hogy vezeték nélküli hálózatokat készítsenek a mérnökök. A vezeték nélküli (más néven WiFi, vagy b) hálózatok kialakításához először is szükség van valamilyen adathordozó közegre, mely esetünkben vagy infravörös fény, vagy 2,4-2,4835 GHz-es tartományba eső rádióhullám. Mint tudjuk az infravörös megoldásnak a hátránya az, hogy a kommunikáló feleknek látniuk kell egymást, azaz az infravörös fénynek el kell jutnia (természetesen egyenes úton, akadályok nélkül) az egyik számítógépből a másikba. A rádióhullámoknál ilyen probléma nincs, mivel azok minden irányban terjednek. Másrészt szükségünk van valamilyen protokollra, mely szabályozza, hogy a hálózat mely tagja mikor küldhet adatot a hálózaton. Ez a protokoll az IEEE es szabvány szerint a CSMA/CA, melynek részleteibe nem kívánok belemenni, csak annyit emelnék ki, hogy a hálózat tagja csak akkor küld adatot, ha éppen más nem folytat kommunikációt. Egy magasabb szinten, a hálózati rétegben, olyan problémákat kell megoldani, melyek a vezetékes hálózatok esetén nem merültek fel. Ilyen például az az eset, mikor valaki egy kézi számítógéppel kapcsolódott egy vezeték nélküli hálózathoz (mondjuk egy egyetem saját hálózatához), és sétál az illető a készülékkel a 4

5 kezében. Az ilyen kiépített vezeték nélküli hálózatok általában úgy vannak megoldva, hogy azon a területen, amit le kívánnak fedni, bizonyos távolságokban úgynevezett elérési pontokat építenek ki, melyekkel a felhasználók készülékei közvetlenül kommunikálnak. Ha a felhasználó sétál, akkor az egyik ilyen elérési pont hatóköréből átkerülhet egy másik hatókörébe, de neki ebből nem szabad észrevennie semmit. A vezeték nélküli hálózatok kialakításának egy másik lehetősége, mikor nincsenek kiépített elérési pontok, mindössze a készülékeket, melyeket közös hálózatba kívánunk kapcsolni, olyan közel helyezzük el egymáshoz, hogy képesek legyenek a többiek által kibocsátott rádióhullámokat megfelelően fogni. Ezen a módon például kialakítható egy ad hoc hálózat egy tárgyalás időtartamára úgy, hogy a tárgyaló felek a laptopjaikkal, PDAikkal leülnek egy asztalhoz, és máris működik a kommunikáció. Napjainkban rohamos léptekkel folyik a vezeték nélküli hálózatok kiépítése. Egyre többet hallhatunk repülőterekről, egyetemekről, bevásárlóközpontokról, ahol lehetőség van ilyen hálózatok elérésére. Mindez azonban semmit sem érne, ha nem lennének olyan eszközök, melyek képesek kihasználni ezt a lehetőséget. Szerencsére a legtöbb megjelenő PDA rendelkezik ezzel a képességgel, vagy kapható hozzá olyan kiegészítő, mely lehetővé teszi a vezeték nélküli hálózatok elérését. Itt jutottunk el addig a pontig, ahol világossá válik, hogy mi köze a vezeték nélküli hálózatoknak a MobilConference-hez. Ha belegondolunk, a konferenciákra ellátogató emberek nagy valószínűséggel rendelkeznek legalább egy mobil telefonnal, de akár PDA-val is. (A mobil telefonok is vezeték nélküli hálózatot használnak, de az különbözik az általam tárgyaltaktól, így ebben a fejezetben csak a PDA-kra figyelünk.) Tehát ha valaki elmegy egy konferenciára, ahol az épületben van kiépített vezeték nélküli hálózat, akkor a PDA-ját elővéve, elindítva a MobilConference-t, máris el tudja érni a központi Conference rendszert, és így hozzájut minden olyan információhoz, melyet a rendszerünk nyújtani hivatott J2ME A Java, mint technológia, 1995-ös megjelenése után dinamikus fejlődésnek indult, és egyre több alkalmazási területen jelent meg. Legfőbb területének a Web-böngészők és a beágyazott megoldások (gondolok itt a JavaCard technológiára) számítottak. Szintén jelentős területnek számított az úgynevezett set-top box 1 -ok piaca, valamint ugyanezen irányvonalon a webphone -okba szánt PersonalJava szoftver. A webphone-ok fejlődése '97-ben kezdett igazán beindulni, mikor is három vállalat (Alcatel Alsthom SA, Northern Telecom Ltd. és a Samsung Csoport) is bejelentette, hogy olyan Java alapú telefonokat (webphone-okat) fog készíteni, melyek képesek lesznek hálózatokhoz (így az Internethez is) kapcsolódni, és onnan tartalmakat 1 A set-top box egy olyan készülék, melyet a televízióra kötve lehetővé teszi, hogy böngésszünk az Interneten. 5

6 letölteni (bővebben lásd George Lawton cikkét [ME01]) januárjában Antero Taivalsaari és Bill Bush, a Sun két munkatársa, elkezdtek egy olyan Java virtuális gépet fejleszteni, mely a kis, hordozható eszközöket célozza meg, és ezért az addig kereskedelmi forgalomban lévő legkisebb virtuális gépnél is tízszer kevesebb helyet foglal el. Az első implementáció még az év májusában bemutatásra került a Sun belső konferenciáján. Ezek után a Motorola is érdeklődni kezdett a fejlesztés iránt, így felgyorsultak az események, a kísérleti projektből igazi termék lett. Az elkészült virtuális gép a KVM nevet kapta. A legkisebb változata kb méretű, de az általánosan használt változata is mindössze kb. Érdekességként talán érdemes megemlíteni, hogy a KVM-et C-ben implementálták, és az előbb említett általános változat forráskódja körülbelül sor (megjegyzésekkel együtt). (További érdekességek olvashatók a KVM atyjának is nevezett Antero Taivalsaarival készült interjúban [ME02].) A Java, mint technológia tehát a számítástechnika szinte minden területén megjelent. Az 1. ábrán látható, hogy milyen részekre osztható a technológia. A bal oldalon látható a J2EE, mely a szerverekre szánt változat, ez a legbővebb kiadás. A következő a J2SE, mely az asztali gépeken futó rendszerek megvalósítását teszi lehetővé. A következő két oszlop együtt alkotja a J2ME-t, azaz a Java 2 Platform, Micro Edition-t, mely a mobil, illetve beágyazott technológiákhoz ad eszközrendszert. A család legkisebb tagja a Java Card, mely a Java alapú intelligens kártyák programozási felülete. Most vizsgáljuk meg egy kicsit részletesebben a J2ME-t! Mint az ábrán is látszik, a Java-nak ez a része két irányban is tagolt. Ez a tagoltság azért alakult ki, mert a mobil, illetve a beágyazott eszközök (a hardverek) nagyon sokfélék lehetnek, és ebben a piaci szegmensben különösen fontos (a korlátozott erőforrások miatt), hogy a hardvernek leginkább megfelelő rendszer fusson rajta. Először is meg kell értenünk, hogy mik azok a konfigurációk (configuration), hiszen ezeken alapszik a J2ME vertikális tagolása. Egy konfiguráció egy virtuális gép és osztályok egy minimális halmazának az együttese, mely a hasonló jellemzőkkel (pl. hálózati kapcsolat, memória méret) rendelkező eszközökhöz nyújt alapvető funkcionalitást. Jelenleg két konfiguráció létezik: a CDC (Connected Device Configuration) és a CLDC (Connected Limited Device Configuration). A CDC a J2ME-hez tartozó hardverek gyorsabb processzorral, több memóriával, nagyobb hálózati sávszélességgel rendelkező részét célozza meg. Ilyenek például a már említett set-top box-ok, a járművek navigációs rendszerei, vagy a csúcskategóriás PDA-k. Mint az 1. ábrán is látható, ezeken a gépeken egy teljes értékű JVM fut, amelyet a 32 bites processzor és a legalább 2MB méretű memória tesz lehetővé. 6

7 Opcionális csomagok Opcionális csomagok Opcionális csomagok Java 2 Platform, Enterprise Edition (J2EE) Java 2 Platform, Standard Edition (J2SE) Personal Profiles Personal Basis Profile Foundation Profiles Opcionális csomagok MIDP CDC CLDC Java Card JVM KVM Card VM 1. ábra A Java2 platform A CLDC az erőforrásokban szegényebb eszközökre szánt Java. Itt tipikusan 16 vagy 32 bites processzorok és KB memória a jellemző. A szűkös erőforrások miatt itt már nem a megszokott JVM-et találjuk, hanem a kisebb méretű KVM-et. A konfigurációk kiegészülnek ún. profilokkal, melyek az alkalmazások életciklusát és a felhasználói felületet definiálják, valamint elérést biztosítanak az eszközspecifikus tulajdonságokhoz. A profilok létezése jelenti a J2ME horizontális tagoltságát. A CDC legalapvetőbb profilja a Foundation Profile, mely a CDC felhasználói felület nélküli, mélyen beágyazott környezetekbe szánt, hálózati kapcsolatra képes implementációját nyújtja. A CDC következő szinten lévő profilja a Personal Profile, mely a teljes grafikus felhasználói interfésszel rendelkező, applet-ek futtatását is támogató eszközök (például csúcskategóriás PDA-k, kommunikátorok, vagy játék konzolok) profilja. Itt már megjelenik a J2SE-ből jól ismert grafikus könyvtár, az AWT. A Personal Profile része a Personal Basis Profile, mely az előzőnél kevesebb grafikus tudással rendelkezik. Ezen profil által megcélzott eszközök például a set-top box-ok, valamint a járművek navigációs rendszerei. Amint az ábrán is látható, mind a CDC, mind a CLDC legfölső szintjén szerepelhetnek opcionális csomagok, melyekkel a gyártók bővíthetik ki a készülékek tudását például olyan funkciókkal, mint a Bluetooth, a webalkalmazások, multimédia, stb. Ami a profilok felsorolásából kimaradt, az a CLDC egyetlen profilja, a MIDP (Mobile Information Device Profile). Ez a profil használható a mobiltelefonoknál, valamint a belépőszintű PDA-k esetén. A MIDP a futtató készülékek számára a következő megkötéseket teszi a hardverek terén: legalább 96x54 pixel méretű, legalább két színű kijelző, a következő beviteli lehetőségek közül legalább az egyik: egykezes billentyűzet, 7

8 kétkezes billentyűzet, érintőképernyő, a CLDC által megkövetelt 128KB nem törlődő és 32KB törlődő memóriát kiegészíti 8KB nem törlődő memóriával az alkalmazások által létrehozott adatok tárolásához, két irányú, vezeték nélküli, lehetőleg összeköttetés mentes, kis sávszélességű hálózati kapcsolat. A hardver követelmények mellett a MIDP szoftveres követelményeket is megfogalmaz: minimális kernel, mely képes a hardvert kezelni és a virtuális gépet futtatni, az alkalmazások által létrehozott adatok írásának és olvasásának biztosítása a(z előbb említett) nem törlődő memóriában, a hálózati kapcsolathoz használt csatorna írása és olvasása, a grafikus kijelző kezelése a rendelkezésre álló felhasználói inputok kezelése. A CLDC a java.io, java.lang és java.util csomagok osztályait definiálta. A MIDP az utóbbi két csomagot kibővíti néhány osztállyal és négy új csomagot is bevezet: javax.microedition.lcdui a felhasználói interfészek létrehozását biztosítja, javax.microedition.rms a perzisztens adattárolást teszi lehetővé, javax.microedition.midlet a MIDlet (a mobil készüléken futó alkalmazás) és a futtató környezet kapcsolatáért felelős, javax.microedition.io a hálózati kapcsolatfelvétel lehetőségeit bővíti ki (HTTP kapcsolattal). Mint látható, a MIDP és a CLDC együtt egy olyan környezetet ad, mely a mobil készülékek tulajdonságainak megfelelő alkalmazások fejlesztését teszi lehetővé, figyelembe véve ezen készülékek korlátozott erőforrásait. A fönt leírtak a MIDP 1.0 verziójára igazak ben megjelent a MIDP 2.0 is mely hozott néhány érdekes újítást illetve fejlesztést: a HTTPS bekerült a szabványba, aminek köszönhetően biztonságosabb kommunikációt is meg lehet valósítani, multimédia támogatás: hangokat (pl. wav fájlokat) tudunk lejátszani, továbbfejlesztett form-ok (új layout-ok, új elemek, stb.), a Game API a játékok fejlesztését teszi hatékonyabbá új grafikai megoldásokkal, RGB képek kezelése, 8

9 aláírt kódok. Az itt felsoroltakon túl, még számos újítás található a MIDP 2.0-ban. Minderről bővebben a Jonathan Knudsen által írt cikkben olvashatunk [ME03]. A MIDP 2.0 újdonságai nagy mértékben megkönnyítik a programfejlesztő munkáját, de mivel még viszonylag új a szabvány, ezért eddig csak kevés olyan készülék jelent meg, mely támogatja, és ezek is a felső árkategóriába tartoznak. Az általam fejleszteni kívánt alkalmazás nem igényli a MIDP 2.0-ban megjelent újdonságok használatát, így a fejlesztésnél maradok a MIDP 1.0-nál. Természetesen a MIDP 2.0 lefelé kompatibilis, így az elkészült alkalmazást azok a készülékek is képesek lesznek futtatni, melyek már a 2.0-s szabványt támogatják. (Ez a kompatibilitás fordított irányban természetesen nem igaz.) 2.3. Webszolgáltatások A webszolgáltatásokat Gottdank Tibor [WS01] a következőképpen definiálja: A webszolgáltatások elve az objektum-orientált szemlélet terméke. Minden webszolgáltatás egy külön objektum, amely felhasználható egy másik alkalmazás által vagy beolvasztható egy másik alkalmazásba. Ezzel lehetővé válik, hogy egy hálózatot (pl. az Internetet) roppant nagy, programkomponenseket tartalmazó könyvtárakba képezzük le, s így e könyvtárak a fejlesztők munkája által elérhetővé válhatnak. A webszolgáltatások operációs rendszertől és platformtól függetlenül létrehozhatók és alkalmazhatók. A webszolgáltatások elődjének (vagy inkább korai megjelenésének) a Hewlett-Packard által 1999-ben megjelent e-speak nevű e-szolgáltatások fejlesztését segítő termékében alkalmazott technológiát tekinthetjük ben a Microsoft már webszolgáltatásokról beszél, és azokat a.net és az internetes szoftverek elemi részének tekinti. A technológia számos szabványt felhasznált, és ugyanakkor vannak olyan technológiák is, melyek többé-kevésbé a webszolgáltatások fejlődésének köszönhetik szabvánnyá válásukat. Az első, és legfontosabb szabvány az XML 2, mely egy olyan nyelv, ami lehetővé teszi tetszőleges információk könnyen értelmezhető módon való leírását. A webalkalmazások egyrészt a kommunikáló felek közti adatcserére használják az XML-t, másrészt ezzel írják le az egyes alkalmazások tulajdonságait is (lásd: UDDI, WSDL). Tehát, mint látjuk, a webszolgáltatások világában az adatok XML dokumentumokként jutnak el az egyik kommunikáló féltől a másikig. Itt tipikusan arra kell gondolni, hogy egy kliens egy kérést küld valamely webszolgáltatásnak (tulajdonképpen meghívja annak egy metódusát), és a szolgáltatás válaszol a kérésre. A MIDlet-ek világában ez a kommunikációs folyamat általánosnak mondható, hiszen a korlátozott erőforrásokkal rendelkező mobil 2 Extensible Markup Language 9

10 készülékek nem képesek bonyolult számításokat végezni, vagy nagy mennyiségű adatot tárolni, ezért léteznie kell egy szervernek, mely a szükséges adatokat előállítja (vagy tárolja) a MIDlet számára. A MIDlet vezeték nélküli hálózaton, HTTP protokoll fölött (a MIDP 1.0-ban) tud a szerverrel kommunikálni. Az ilyen alkalmazások fejlesztésekor az egyik legnagyobb problémát az jelenti, hogy a MIDP-ben nincs eszköz az objektumok szerializálására/deszerializálására, azaz nem tudunk objektumokat átküldeni a hálózati kapcsolaton. És ez az a pont, ahol a MIDP összekapcsolódik a webszolgáltatásokkal. Mivel ez utóbbiak XML, azaz szöveges formában küldik át az üzeneteiket, és általánosnak mondható, hogy a kommunikációhoz HTTP protokollt használnak, ezért megfelelnek a MIDlet-ek kommunikációs feltételeinek, azaz miért ne alkalmaznánk a webszolgáltatásokban használt (szabványos!) üzenetküldő protokollokat a MIDlet-ek és szervereik közti kommunikációhoz? Ahhoz, hogy ezt meg tudjuk tenni, találnunk kell egy olyan eszközt, mely MIDP-s környezetben implementálja valamely üzenetküldő protokollt. Azt nem szabad elfelejtenünk, hogy a webszolgáltatások fejlesztésénél nem az volt a legfontosabb követelmény, hogy egy 128KB memóriával rendelkező, kis számítási teljesítményű hardverről is könnyedén elérhessünk bármilyen szolgáltatást. Ennek ellenére léteznek MIDlet-ekben használható implementációk. (Folytatást lásd a Kommunikáció c. alfejezetben oldal.) 2.4. Szervletek A Java szervletek a (web)kiszolgálók bővítéseként használt Java osztályok, melyek betöltése dinamikusan történik. Tehát a szervlet a kiszolgáló funkcionalitását bővíti ki azáltal, hogy annak részeként működve valamilyen feladatot lát el (szolgáltatást nyújt). Leginkább a CGI szkriptekhez lehetne hasonlítani őket, de azoknál biztonságosabbak és hordozhatóbbak, mivel a kiszolgáló JVM-jén belül futnak. További előnyük a CGI-vel szemben, hogy a kiszolgálóval szoros kapcsolatot tartanak fenn, és így olyan dolgokat is megtehetnek, melyekre a CGI nem képes (pl. saját maguk adhatják meg a MIME típusok leképezését). kliens_1 kliens_2 kliens_3 szál szál szál Szervletkonténer JVM szervlet_1 szervlet_2 2. ábra Szervletek működése és helye a konténerben A Servlet API a J2EE platform részét alkotja opcionális csomagként (lásd: 1. ábra), 10

11 tehát őrá is jellemző a Java hordozhatósága és platformfüggetlensége. A szervletek futtatását az úgynevezett szervletkonténerek végzik. Ilyen konténer lehet egy önmagában álló szervletkonténer, ami egy kiszolgáló, melybe be van építve a szervletek támogatása. Egy másik megoldás, mikor ún. beépülő konténereket használnak, melyek a meglévő kiszolgálókat egészítik ki a szervletek támogatásával beépülő modulként. Az utolsó csoportba a beágyazható szervletkonténerek tartoznak, melyek alkalmazásokba ágyazható pehelysúlyú szervlet futtató platformok. A kiszolgálón minden szervletből (legfeljebb) egy példány létezik, ha több kérés érkezik ugyanahhoz a szervlethez, akkor azokat különböző szálakban szolgálja ki. Ennek következtében a szervletek meghívása nagyon hatékony, hiszen csak a memóriában lévő példány egy metódusát kell meghívnia a kiszolgálónak egy beérkező kérés esetén. A szervletek (mivel a J2EE részei) képesek használni az egyes Java API-k által nyújtott eszközöket, mint például az adatbázis-kapcsolatok kezelését végző JDBC-t, a távoli metódushívást (RMI), vagy az Enterprise JavaBean-eket, hogy csak néhányat említsünk. Ami számunkra a legfontosabb lesz jelen alkalmazásunk fejlesztésekor, az az adatbázis kezelés, valamint az XML-elemzés lehetősége (lásd az előző alfejezetben). Az olyan MIDP alkalmazásoknál, melyeknél szükség van valamilyen szerver oldali részre is, szervleteket szokás kiszolgálóként használni. A már tárgyalt előnyökön túl lényeges, hogy a szervletek megírásához is a Java nyelvet kell ismernie a fejlesztőnek (tehát a kliens és a szerver oldal is ugyanazon nyelven készül), valamint az is létfontosságú, hogy a szervletek egy speciális csoportja (a HTTP szervletek) a HTTP protokollt használják a kommunikációhoz, csakúgy, mint a MIDP 1.0. Az elkészítendő alkalmazásban a szervletek a webszolgáltatások kiszolgálójaként jelennek meg, azaz egy szervlet kezeli le a kliens-szerver kommunikáció szerver oldali feladatait. Most tehát nem fogok saját szervletet írni, csak olyan osztály(oka)t, melyet az előbb említett szervlet használ a klienstől érkező kérések kiszolgálásához. Ennek ellenére úgy gondolom, hogy érdemes a szervletek jellemzőit, működését ismernünk, mivel így a felhasznált webszolgáltatás-kiszolgáló alapvető tulajdonságaival is tisztában leszünk (és ha esetleg az nem úgy működik, ahogy mi szeretnénk, akkor van esélyünk rá, hogy kijavítsuk) Castor A legtöbb alkalmazás (így az általam készítendő is) valamilyen adatbázist használ az adatok tárolásához. A Java a JDBC 3 API által egy olyan eszközrendszert biztosít, mellyel SQL utasításokat tudunk kiadni egy (tetszőleges) SQL adatbázis-kezelőnek. Az adatok a Java 3 Java DataBase Connectivity 11

12 programokban objektumokként vannak reprezentálva, míg az adatbázisban táblákban tárolódnak, ezért az objektumok letárolásánál az SQL parancsok elkészítéséhez az objektumokból ki kell olvasni az adattagokat, és a megfelelő tábla megfelelő sorára le kell azokat képezni. Ugyanezt a technikát kell alkalmaznunk visszafelé, mikor az objektumokat ki szeretnénk olvasni az adatbázisból, azaz az objektum adattagjait be kell állítanunk az adatbázis megfelelő rekordjának megfelelő mezőjén lévő értékekre. Ezek a műveletek jó néhány plusz sort jelentenek a forráskódunkban, aminek következtében csökken a kód átláthatósága. Java objektum Castor JDO Adatbázis 3. ábra A Castor JDO helye az alkalmazásokban Ezt a problémát igyekszik orvosolni az exolab.org 4 által fejlesztett Castor JDO 5, mely átveszi a programozótól az objektumok és az adatbázis-táblák közti konverzió feladatát. A dolgunk mindössze annyi, hogy elkészítsük az adatokat reprezentáló osztályainkat, az adatbázistáblákat, valamint egy leíró fájlt, melyben megmondjuk, hogy melyik osztály példányát mely táblára akarjuk leképezni, és hogyan (azaz mely adattagot mely oszlophoz kötjük). A leíró (vagy mapping) fájl tulajdonképpen egy XML dokumentum, így könnyen megérthető, hogy milyen leképezési szabályok is vannak benne megadva. A Castor képes kezelni az objektumok 1:1, 1:n és n:m típusú kapcsolatát, valamint azokat az eseteket is, mikor az egyik objektum valamelyik adattagja a másik objektum, vagy az egyik osztály a másiknak a kiterjesztése. Lehetőségünk van az SQL-ből ismert szekvenciák használatára az objektumok azonosítójaként, vagy akár összetett kulcsokat is alkalmazhatunk. A típusokra nem lehet panaszunk, hiszen a Castor dokumentációja az SQL minden típusához leírja, hogy milyen Java objektumot fog a rendszer hozzárendelni. Ha összetett típusokat is szeretnénk használni az osztályainkban, akkor a java.util csomag ArrayList, Hashtable, Map, Set, illetve Vector osztályai jöhetnek szóba, melyek az adatbázisban egy segédtáblában lesznek letárolva. Ha elkészítettük a megfelelő osztályokat, létrehoztuk az adatbázisban a táblákat, megírtuk a mapping fájlt és az adatbázis-elérést leíró (database.xml) fájlt, akkor a programunkban a org.exolab.castor.jdo.database interfész metódusaival (create(), update(), load(), stb.) egy-egy utasításban elintézhetjük az objektumok eltárolását, visszatöltését, stb. Természetesen a Castor-nak is vannak hibái, nehézségei, és léteznek más eszközök is, Java Data Objects 12

13 melyek a Java objektumainak adatbázisba való leképezését segítik (pl.: Hibernate 6 ), de talán a Castor az egyik legegyszerűbben használható és mégis számos funkcióval ellátott eszköz ezen a területen. A Castor használatáról egy nagyon hasznos és érthető leírást készített Jeff Lowery [CA01]

14 3. A rendszerrel szemben támasztott követelmények Mivel a rendszer nem egy külső megrendelő kérésére készül, ezért nekem kellett eldöntenem, hogy milyen követelményeket támasztok vele szemben. Ez a döntés nagy mértékben befolyásolja a rendszer használhatóságát, ezért fontos jól átgondolni, milyen feltételeket is támasztok a rendszerrel szemben Funkcionális követelmények A rendszer használati eseteit öt nagy csoportba sorolhatjuk, úgy mint: bejelentkezés, az éppen folyó előadások kezelése, a jövőbeli előadások kezelése, olyan konferenciák kezelése, melyekre jelentkezett a felhasználó, valamint az összes meghirdetett konferencia kezelése. Nézzük ezeket a csoportokat bővebben! (A rendszer use case diagramja a 4. ábrán látható. A diagram csak egyetlen aktort a felhasználót tartalmaz. Fel kellene tüntetnünk egy másikat is, nevezetesen az adatbázist, mely a felhasználóhoz hasonlóan minden használati esethez kapcsolódik, az ábra áttekinthetősége érdekében azonban ezt az aktort lehagytam.) 1. Bejelentkezés. Ebben a csoportban egyetlen használati eset szerepel, maga a rendszerbe való bejelentkezés. A bejelentkezésre azért van szükség, mert az egyes felhasználók jelentkezhetnek konferenciákra, és a rendszer megjegyzi, hogy mely felhasználó mely konferenciákra jelentkezett. A felhasználó akkor tud a mobiljáról bejelentkezni, ha előtte a webes felületen (lásd 7. fejezet) regisztrálta magát, azaz felhasználónevet és jelszót választott. Ezt a két adatot kell a felhasználónak megadnia, mikor először indítja el a mobilján az alkalmazást. A későbbiekben az alkalmazás indulásakor szintén meg fog jelenni a bejelentkezési adatokat bekérő képernyő, de a rendszer azt automatikusan kitölti az első bejelentkezéskor használt felhasználónévvel és jelszóval. Előfordulhat (bár nem tipikus), hogy más is szeretné használni a felhasználó készülékét, ezért a rendszer bejelentkező képernyőjén az előbb említett adatok bármikor módosíthatók. Ha módosítás történt, akkor a rendszer a továbbiakban az új adatokkal fogja automatikusan kitölteni a mezőket. 14

15 Bejelentkezés Mai, még el nem kezdődött előadások listájának megtekintése Előadás részleteinek megtekintése Éppen folyó előadások listájának megtekintése Olyan konferenciák listája, melyekre jelentkezett a felhasználó Konferencia adatainak megtekintése Felhasználó Jelentkezés lemondása Konferencia előadásainak listájának megtekintése A rendszerben szereplő összes konferencia listájának megtekintése Konferencia adatainak megtekintése Jelentkezés konferenciára Konferencia előadásainak listájának megtekintése 2. Az éppen folyó előadások kezelése Az ide tartozó használati esetek azok, melyek akkor állhatnak fenn, ha például éppen bent ülünk egy konferencián, és szeretnénk róla megtudni a legfontosabb információkat. 4. ábra A rendszer használati esetei 15

16 A rendszernek a bejelentkezés utáni képernyőn az éppen folyó előadások listáját kell megjelenítenie. Elég, ha ez a lista mindössze az előadások címét tartalmazza. (Figyelembe kell vennünk azt, hogy a rendszert mobil készülékekre szánjuk, amelyek viszonylag kis képernyővel rendelkeznek. Lásd a J2ME leírását a 2.2. alfejezetben!) Ha a felhasználó többet szeretne megtudni egy előadásról akkor elő kell tudnia hívni egy képernyőt, melyen megtekintheti az előadás részleteit. Ezen a képernyőn már meg kell jelenítenünk az előzőekben kiválasztott előadás címét, előadóját, időpontját (mikor kezdődött), helyét (a terem, ahol tartják), valamint annak a konferenciának a nevét, melyhez tartozik. Innen továbblépve az előadáshoz tartozó konferencia adatait, konkrétan a nevét, időpontját, helyszínét, a kiírás időpontját, a hallgatóság maximális létszámát, és a konferenciára jelentkezett hallgatók létszámát kell megjelenítenünk. A felhasználó nyilván kíváncsi lehet ennek a konferenciának a további programjára is, ezért egy következő képernyőn elérhetővé kell tennünk a konferencia előadásainak listáját is. Ha a felhasználó úgy dönt, hogy a továbbiakban nem kíván részt venni a konferencián, akkor lemondhatja a jelentkezését, mégpedig a konferencia adatait megjelenítő képernyőn. (Ha a felhasználó lemondja a jelentkezését, akkor a konferencia előadásai a továbbiakban nem fognak megjelenni sem az éppen folyó, sem a még el nem kezdődött előadások listájában.) A képernyők közötti sorrendiséget pontosan definiálni kell, ezt lásd később, a kliens oldal leírásánál (4.1. alfejezet). 3. Jövőbeli előadások kezelése Ide olyan használati esetek tartoznak, melyek az aktuális időpont után (de még az aktuális napon) kezdődő előadásokhoz kapcsolódnak. A mai, még el nem kezdődött előadások listáján időrendben kell felsorolni az előadásokat, így a felhasználó látni fogja, hogy még milyen programokra számíthat az aktuális napon. Ezen a listán fel kell tüntetni az előadások mellett azok időpontját is, hogy a felhasználó könnyebben meg tudja tervezni az időbeosztását. Az éppen folyó előadások kezeléséhez hasonlóan, itt is biztosítani kell egy következő képernyőt, melyen egy kiválasztott előadás minden adata megjelenik. (Az ez után következő, korábban tágyalt képernyőket is elérhetővé kell tenni.) 4. Azoknak a konferenciáknak a kezelése, melyekre jelentkezett a felhasználó Az egyetlen használati eset, mely csak ebbe a csoportba sorolható be, az a fent meghatározott konferenciák neveinek a felsorolása. Itt egy konferenciát 16

17 kiválasztva az éppen folyó előadások kezelésénél tárgyalt Konferencia adatainak megtekintése nevű használati esethez jutunk. 5. Az összes meghirdetett konferencia kezelése Az utolsó csoportba azok a használati esetek tartoznak, melyek a rendszerben szereplő összes (aktuálisan folyó, vagy még ezután kezdődő) olyan konferencia kezeléséhez kötődnek, melyekre a felhasználó nem jelentkezett. Ide tartozik az az eset, mikor a felhasználó az összes meghirdetett konferencia címét szeretné egy listában látni. Egy konferenciát kiválasztva a felhasználó a korábbi használati esetekhez hasonlóan megtekintheti a konferencia adatait, majd továbblépve a konferenciához tartozó összes előadás címét, időpontját és előadóját tartalmazó listát. A konferencia adatait megjelenítő képernyőn kell lehetőséget biztosítanunk, hogy a felhasználó jelentkezhessen az adott konferenciára. Meg kell fogalmaznunk további funkcionális követelményeket is, melyek részben a használati esetekből következnek: 1. A konferenciára való jelentkezés és a jelentkezés lemondása előtt megerősítést kell kérni a felhasználótól, a művelet végrehajtása után pedig egy nyugtázó üzenetet kell megjelenítenünk. 2. Minden képernyőn lehetőséget kell biztosítani arra, hogy a felhasználó az előző képernyőhöz vissza tudjon térni. 3. Azt is lehetővé kell tennünk minden (fontosabbnak ítélt) képernyőn, hogy a felhasználó kilépjen a rendszerből Nem funkcionális követelmények 1. A rendszernek illeszkednie kell a Conference rendszerhez (az ott meghatározott adatbázist kell használnia (lásd 7. fejezet)). 2. A rendszernek kezelnie kell a magyar ékezetes karaktereket. 3. Az egyes képernyőket olyan címkékkel kell ellátni, melyek egyértelműen megmondják, hogy mit is lát a felhasználó. 4. Minden olyan képernyőhöz help képernyőt kell készíteni, mely a felhasználó adatainak módosítására szolgál (ilyenek: bejelentkezés, jelentkezés konferenciára, jelentkezés lemondása). A help képernyőn le kell írni, hogy a végrehajtható művelet milyen következményekkel jár. 5. A kliens oldalon megjelenő listákat (mai, még el nem kezdődött előadások listáját, valamint 17

18 az éppen folyó előadások listáját) percenként frissíteni kell. 6. Kliens oldalon a futtató hardver rendszeridejét használjuk (például annak megállapítására, hogy egy előadás elkezdődött-e már). 7. A rendszer (kliens oldal) memóriahasználata nem haladhatja meg a CLDC 1.0 szabványban meghatározott legnagyobb memória méretét (512 KB), és lehetőségekhez képest minél alacsonyabb szinten kell azt tartani. 8. A kliens oldal méretét minél kisebbre kell csökkenteni (a maximális méret 100KB). 9. A kliens oldal csak a MIDP 1.0 és a CLDC 1.0 által nyújtott eszközöket használhatja. Ha további eszközökre is szükség van (pl. a kommunikáció megvalósításához), akkor azokat mellékelni kell (bele kell csomagolni a MIDlet JAR fájljába). (Azaz nem számíthatunk arra, hogy bizonyos MIDP 1.0-n és CLDC 1.0-n kívüli eszközök gyárilag be vannak építve a futtató hardverbe.) 10. A kliens oldalon ügyelnünk kell arra, hogy minden lehetséges előforduló hibát lekezeljünk (amit le lehet kezelni), és az ne jusson el a felhasználóhoz (ne omoljon össze a rendszer). 11. Ha a szerver oldalon, vagy a hálózati kapcsolatban fordul elő hiba, akkor ezt (naplózás után) tovább kell küldenünk a kliens oldalra (ahol azt az előbb leírtaknak megfelelően kezeljük). 12. Mivel a rendszerben az egyedüli személyes adat a felhasználói név és a jelszó, ezért a biztonságra vonatkozó követelmény mindössze annyi, hogy a jelszót a hálózati kommunikációhoz valamilyen algoritmussal titkosítani kell. (Elegendő egy egyszerű, szimmetrikus kulcsú titkosító algoritmus.) 13. A kliens és szerver oldal kommunikációját HTTP protokollon keresztül kell megvalósítani. 14. A kommunikációs meneteknél időkorlátot kell alkalmazni. Ha a kommunikáció az adott időkorláton belül nem fejeződik be, akkor meg kell szakítani, és a felhasználót tájékoztatni kell a kapcsolat lassúságáról. A megszakítás után a felhasználó kezdeményezheti a kommunikáció újbóli végrehajtását. Az időkorlátot a tesztelési fázisban kell meghatározni. 15. A felhasználó meg tudja szakítani a kommunikációt. (Például a kommunikáció alatt egy Kommunikáció folyamatban képernyőt jelenítünk meg, melyen lehetőség van a megszakításra.) 16. Mivel a felhasználó számára az egyik legjelentősebb költséget a hálózati kommunikáció jelenti, ezért a forgalmazott adatok mennyiségét a lehetőségekhez képest minimalizálni kell (csak azt kérje le a kliens a szervertől, amire szüksége van). 18

19 4. A rendszer implementációja A rendszer felépítése a tipikus háromrétegű kliens-szerver architektúrát követi, mint az az 5. ábrán is látható (az adatkezelés rétegének a Castor-t tekinthetjük). A kliensünk egy MIDlet lesz, mely a megjelenítést végzi (tehát egy vékony kliensről van szó). A kliens a kommunikációhoz a webszolgáltatások kliens oldali részét fogja használni, mely a metódushívásokat xml dokumentummá alakítva juttatja el a szerverhez (HTTP kérésben), majd az onnan (HTTP) válaszként érkező xml dokumentumból elkészíti a megfelelő objektumot. A két oldal között a kapcsolat vezeték nélküli hálózaton zajlik, HTTP protokoll fölött. Szerver oldalon a webszolgáltatás kiszolgáló részét találjuk, ami tulajdonképpen egy szervlet. Ez a szervlet fogja az általam megírt osztály(ok)hoz továbbítani a klienstől érkező kéréseket, illetve az osztály által adott választ (objektumot) xml dokumentummá alakítva eljuttatja a klienshez. Az osztályok a kérésnek megfelelően végrehajtják a szükséges adatfeldolgozási lépéseket, illetve elvégzik a kapcsolódó adatbázis-műveleteket (a Castor segítségével). Kliens (MIDlet) objektum xml HTTP (XML) objektum xml Szerver (Servlet) Castor Adatbázis 5. ábra A rendszer architektúrája Mint látható, az alkalmazott technológiák lehetővé teszik, hogy mind a MIDlet-ben, mind a szerver oldalon megírt osztályokban kizárólag objektumokkal dolgozzon a rendszer. Ez egyrészt gyorsabb fejlesztést, átláthatóbb, érthetőbb kódot jelent, másrészt bármikor megváltoztatható például az adatbázis struktúrája, vagy a két oldal összekötésére használt üzenetátviteli protokoll anélkül, hogy az üzleti logikát megvalósító kódrészletet át kellene írnunk (adat-program függetlenség). Ezek után lássuk az rendszer egyes elemeinek részletes leírását! 4.1. Kliens oldal A kliensnek tehát két feladatot kell ellátnia: egyrészt a felhasználóval kell kapcsolatot tartania (megjelenítés), másrészt a szerverrel kell kommunikálnia (adatok küldése, fogadása). A kliens és a szerver közti kommunikációt majd a 4.4. alfejezetben tárgyalom teljes részletességében, így itt most csak a megjelenítésről lesz szó. 19

20 Bejelentkezés hibás adatok else Előadás adatainak megtekintése Éppen folyó előadások listája Konferenciák, melyekre jelentkezett a felhasználó Mai, még el nem kezdődött előadások listája Minden konferencia Konferencia adatainak megtekintése Előadás adatainak megtekintése Konferencia adatainak megtekintése Konferencia előadásainak listája Jelentkezés lemondása Jelentkezés az adott konferenciára 6. ábra Aktivitás diagram Az 6. ábrán látható, hogy a felhasználó milyen műveleteket végezhet a rendszerben. Ezt a diagramot a használati esetekből kiindulva készítettem el (minden használati esetnek megfelel egy tevékenység). A nyilak azt mutatják, hogy hogyan következhetnek egymás után a műveletek. A rombuszok elágazást jelentenek a műveletek sorrendjében, ilyenkor vagy a felhasználó döntésétől, vagy valamely más feltételtől (pl. helyes-e a megadott felhasználónév és jelszó) függ a következő művelet. Látható, hogy a legtöbb műveletből vissza lehet lépni, ez a felhasználó könnyebb navigációját hivatott segíteni. Az olyan elágazásokat, ahol a rombuszból csak kifelé mutató nyíl van, a következőképpen kell értelmezni: éppen folyó előadások listájából három csúcsba juthatunk (lefelé), de mindhárom csúcsból csak lefelé mehetünk tovább, vagy visszaléphetünk az éppen folyó előadások listájához; hasonlóképpen a bal oldalon lévő Konferencia adatainak megtekintése nevű csúcsból 20