Programozás | Java, JSP » Aczél Kristóf - Adatszinkronizáció megvalósítása Java szerver és mobil kliens között

Budapesti Muszaki- és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási és Alkalmazott Informatika Tanszék Aczél Kristóf ADATSZINKRONIZÁCIÓ MEGVALÓSÍTÁSA JAVA SZERVER ÉS MOBIL KLIENS KÖZÖTT KONZULENSEK Paller Gábor Forstner Bertalan BUDAPEST, 2004 HALLGATÓI NYILATKOZAT Alulírott Aczél Kristóf, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök, stb.) használtam fel Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelmuen, a forrás megadásával megjelöltem. Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a Budapesti Muszaki- és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi intézmény saját céljaira felhasználhatja. Kelt: Budapest, 2004. 05 20 . Aczél Kristóf 2

Adatszinkronizáció megvalósítása java szerver és mobil kliens között . 1 Összefoglaló . 6 Abstract. 7 1. Feladatértelmezés, célok, indokoltsága, felépítés rövid összefoglalása. 8 2. A feladatkiírás pontosítása, részletes elemzése . 9 3. 2.1 A kliens leírása. 9 2.2 A szerver leírása. 10 A szervertechnológiák áttekintése . 12 3.1 .NET 12 Bevezeto. 12 Common Language Runtime, egy program futtatása . 13 Common Type System. 13 Metaadatok. 14 Assembly. 14 JIT Compiler . 14 User Interface . 14 3.2 JAVA J2EE. 15 Bevezeto. 15 Kliens réteg. 16 Megjelenítési réteg. 16 Business Logic réteg, EJB . 18 Adatbázis réteg. 20 Bean típusok. 20 J2EE API-k . 22 4. 5. 6. Mobil alkalmazásmodellek, tekintettel a „mostly disconnected” kritériumra 24 4.1 WAP alapú alkalmazás . 24 4.2 Web alkalmazás . 25 4.3 Java J2ME alkalmazás . 26 4.4 Natív Symbian alkalmazás. 27 A Symbian operációs rendszer. 29 5.1 Áttekintés . 29 5.2

„Mostly disconnected” alkalmazások . 32 Szinkronizációs módszerek . 34 6.1 Adatátvitel. 34 6.2 Protokoll. 35 SyncML. 35 Saját formátumok . 37 7. A felhasznált technológiák . 38 7.1 Kliens oldal . 38 7.2 Szerver oldal . 39 7.3 Szinkronizáció . 40 8. A tervezés részletes leírása. 42 8.1 Magasszintu blokkdiagram . 42 Adminisztrátori felület és szerver kapcsolata . 42 Kliens felület és szerver kapcsolata . 43 8.2 Usecase. 45 U1.1 Szerver oldal: adatfeltöltés 45 U1.2 Szerver oldal: adat megtekintés 45 U1.3 Szerver oldal: elofizeto törlése / új leolvasás kérése 46 U1.4 Kliens oldal: szinkronizáció a szerverrel 47 U1.5 Kliens oldal: gá zóra leolvasása 47 U1.6 Kliens oldal: kliens ID (irányítószám) megváltoztatása 48 8.3 Adatbázis tervek. 48 Szerver adatbázis . 48 Kliens adatbázis . 51 8.4 Az alkalmazások (szerver és kliens) felépítése. 51 Szerver alkalmazás. 51 Mobil kliens alkalmazás. 52 8.5 Szinkronizáció

. 53 Verziókezelés. 53 Protokoll. 55 8.6 User Interface . 58 Webes adminisztrátori felhasználói felület. 58 Kliens felhasználói felület. 63 9. Értékelés, továbbfejlesztési lehetoségek. 65 Értékelés. 65 Továbbfejlesztés. 65 10. Rövidítésjegyzék. 67 4 11. Irodalomjegyzék. 68 12. Függelék. 69 12.1 Egy szinkronizáció menete . 69 12.2 A Symbian alkalmazás osztálydiagramja . 71 5 Összefoglaló Napjainkban, ahogy egyre kisebb méretben készülnek a hagyományos telefonkészülékekbol kinott telefonok, másrészt az asztali gépek kis méretu utódai, a kéziszámítógépek is egyre népszerubbek, egyre nagyobb teret hódítanak a ketto ötvözésébol születo smartphone-ok. Ezen készülékek ereje abban rejlik, hogy bár sokkal kisebb tudásúak, mint egy asztali PC vagy laptop, ám mindig kéznél vannak, képesek egyszerubb számítások és munkák elvégzésére, és szinte bárhonnan képesek adatkapcsolat felvételére

más gépekkel. Ezen tulajdonságokat használja ki a „mostly disconnected” (foként kapcsolat nélkül muködo) alkalmazásmodell is. Az ilyen alkalmazások képesek egyszerubb önálló feladatok elvégzésére is külso eroforrás segítsége nélkül, a bonyolultabb feladatok megoldására pedig idorol idore felkapcsolódnak egy központi szerver gépre, amely ezen feladatokat elvégzi helyettük. A diplomaterv egy foként kapcsolat nélkül muködo alkalmazás elkészítését mutatja be. Az alkalmazás egy egyszeru gázóra-leolvasó szoftvert valósít meg, melyben a kliens önálló munkaköre az adatgyujtés, majd ezen adatokat egy szinkronizációs protokoll segítségével a szerverrel egyezteti. A leírás kiterjed mind a (mobil) kliens, mind a szerver oldali szoftver felépítésére, valamint a ketto közti kommunikáció részletes leírására. 6 Abstract Nowadays, as mobile phones, grown from standard phones, are made in smaller and smaller sizes; and

hand-sized descendants of desktop PCs, palmtops are becoming more and more popular, keeping the advantages of these two perspectives, smartphones gain more and more interest among users. The power of these machines is to be found in that, although their capabilities are limited, they are always at hand, they are still able to do moderately complex tasks, and they can connect to other machines from almost anywhere. This is where „mostly disconnected” application model shines. This kind of application is able to handle simple tasks without utilizing external resources; and to solve complex tasks, they connect to a central server from time to time, which has the computing power to do these calculations for the mobile client. This paper leads through the building of a mostly disconnected application. The application itself is a simple heat meter reader software, where the role of the client is collecting data from heat meters, then these data is negotiated with the server using a

synchronizing protocol. The paper shows the build-up of both the client-side and serverside applications, as well as the communication model between these two 7 1. Feladatértelmezés, célok, indokoltsága, felépítés rövid összefoglalása A feladat egy kliens és egy szerver oldali alkalmazás elkészítése, különös tekintettel a köztük lezajló adatszinkronizáció megvalósítására. Meg kell valósítani egy leegyszerusített gázóra- leolvasó rendszert, amely a következoképp muködik: a gázóraleolvasó házról házra járva feljegyzi a gázórák aktuális állását mobil készülékének segítségével. Ha az összes neki rendelt címet végigjárta, akkor szinkronizációt kezdeményez egy központi szerverrel, és az összegyujtött adatokat oda feltölti. A feladat tényleges megoldása elott át kell tekinteni, milyen technológiák léteznek, melyeket érdemes használni mind a kliens, mind szerver oldalon, valamint a ketto közti

szinkronizáció megvalósítására. A tervezés célja részletesen megismerkedni valamelyik jelenleg elterjedt alkalmazásszerver technológiával. Továbbá jártasságot kell szerezni a manapság mobil eszközök körében rohamosan teret hódító Symbian operációs rendszer felépítésével, muködésével. Nem utolsó sorban ki kell alakítani köztük valamilyen összeköttetést és szinkronizációs protokollt. A példa nem törekszik arra, hogy a Gázmuvek számára egy teljes funkcionalitással ellátott kész alkalmazást szállítson. A lényeg abban áll, hogy egy olyan alkalmazás készüljön el, mely jól demonstrálja a szerverrel kommunikáló mobil eszközök erejét, bemutatja, hogyan kell egy ilyen alkalmazást felépíteni, milyen veszélyekre kell ügyelni, és vázat szolgáltat, amelyre bármilyen hasonló alkalmazás is felépítheto. 8 2. A feladatkiírás pontosítása, részletes elemzése A feladat konkrét megoldása elott szemügyre

kell venni egy sor ma használatos technológiát, amelyekkel a feladatot meg lehet valósítani. Meg kell ismerkedni a szerver oldalon alkalmazott legnépszerubb szervertechnológiákkal, különös tekintettel a J2EE-re, amelyben majd az alkalmazás el fog készülni. Ezen kívül meg kell vizsgálni a Symbian operációs rendszert, amely a mai smartphone telefonok nagy részének lelke. Ebben az operációs rendszerben fog ugyanis elkészülni a kliens alkalmazás. A feladat tehát egy kliens és egy szerver oldali alkalmazás elkészítése, különös tekintettel a köztük lezajló adatszinkronizáció megvalósítására. 2.1 A kliens leírása A kliens alkalmazás a gázórák leolvasott adatainak összegyujtésére szolgál. Tárol egy listát azon elofizetokrol, akik a gázórás munkakörzetébe tartoznak, tehát akiknek gázóráját a gázórásnak le kell olvasnia. A gázórás házról házra jár, végigjárja az összes listában szereplo címet és a

leolvasott gá zóra állásokat ebbe a listába folyamatosan bevezeti. A munkakörzetet a következoképpen értelmezzük. A valós életben egy gázóraleolvasóhoz egy kisebb terület, esetleg csak pár utca tartozik, amelyekben lakó elofizetok adatait össze kell gyujteni. Mivel esetünkben nem cél, hogy a valós életben is minden változtatás nélkül, üzleti forgalomban használható program készüljön, feltesszük, hogy a gázórás munkaterülete egy irányítószám által azonosítható. Tehát egy irányítószám által kijelölt körzethez maximum egy gázórás fog tartozni. Ez ugyan nem fedi a valóságot, viszont az irányítószám olyan adat, melynek segítségével így könnyedén modellezhetjük több gázórás kliens jelenlétét anélkül, hogy különösebben foglalkoznunk kéne a munkaterületek felosztásával. Így a gá zórásnál lévo mobil készülék csak azon elofizetok adatait fogja tartozni, akik a gázórás munkakörzetébe tartoznak,

tehát egy gázórásnál lesznek a megfelelo irányítószám alatt lakó elofizetok, a többi elofizeto adatairól pedig egyáltalán nem lesz tudomása, azok nem szerepelnek az o készülékén. 9 Miután a gázórás felkereste a listájában szereplo összes elofizetot, leolvasta azok gázórájának állását, és bevezette azt az adatbázisába, szinkronizációt kezdeményez a központi szerverrel. A szinkronizáció két lépésben zajlik: § A kliens gépérol a leolvasott gázóraállások feltöltodnek a szerver adatbázisába. § A szerver adatbázisából a kliens gépére letöltodnek az elofizetok adatainak esetleges változásai a legutolsó szinkronizáció óta. A lehetséges változások a következok: elofizeto törlése, új elofizeto bevezetése, elofizeto megváltozása (ezt egy egyszeru névcserével modellezhetjük). Így frissül a kliens elofizetoket tároló listája. A kliensnek természetesen a muködéshez szüksége van arra, hogy a program

elso indításakor beállíthassa a munkakörzetét, tehát az irányítószámot, illetve ezt esetleg késobb megváltoztathassa. 2.2 A szerver leírása A szerver alkalmazás több feladatot lát el. § Tárolja az összes elofizeto címét és nevét, valamint a hozzá tartozó összes leolvasott gázóraállást is idobélyeggel ellátva. § Webes felületet nyújt az adminisztrátornak, akinek a következo lehetoségeket nyújtja: 1. Új elofizetot vehet fel 2. Egy meglévo elofizetot törölhet az adatbázisból, összes adatával és gázórájának leolvasott állásaival együtt. 3. Tulajdonosváltás esetén megváltoztathatja egy elofizeto nevét (a címet soha sem kell megváltoztatni) § Fogadja a kliens szinkronizációs kérését. Ennek során bevezeti saját adatbázisába a klienstol kapott új gázóraállás-adatokat. Ezután közli a klienssel, milyen változtatások történtek az elofizetok listájában, mióta a kliens legutoljára

csatlakozott a szerverhez. Mivel a hálózati adatforgalom drága, ezt a muveletet minél költséghatékonyabban kell végezni. (ld Szinkron protokoll) Természetesen csak azokról a változásokról értesíti a klienst, amelyek a kliens munkakörzetébe tartoznak. 10 Természetesen ahhoz, hogy az utolsó feladatot el tudja látni a szerver, nemcsak az elofizetok adatait kell megoriznie, hanem nyomon kell követnie az adatbázis változásait is, tipikus an minden egyes változtatást rögzítenie kell. Amikor a kliens szinkronizációt kezdeményez, és közli a szerverrel, hogy legutoljára mikor hajtott végre szinkronizációt, a szervernek tételesen tudnia kell, hogy azóta milyen változások mentek végbe az elofizetok adatbázisán. A változtatások listáját kell közölnie a klienssel, minél tömörebb formában. 11 3. A szervertechnológiák áttekintése 3.1 .NET Bevezeto Az internet felgyorsuló terjedése arra ösztönözte a Microsoftot és

versenytársait, hogy új stratégiákat fejlesszenek ki az adatelérésre különbözo platformokon. A NET egy új megközelítés, mely a programozók számára lehetové teszi rengeteg különbözo programnyelv használatát. Bármely programnyelven fejlesztve a programot, a kód végül egy köztes nyelvre, a Common Language Runtime (CLR) nyelvre fordítódik át. Ezen a nyelven a kód, függvények, tulajdonságok a fejleszto nyelvre való tekintet nélkül megegyeznek. A .NET célja az információt ún Web Service-eken keresztül elérhetové tenni a felhasználók számára olyan alkalmazásokkal, melyek képesek az egymással való együttmuködésre. A kommunikáció az XML (eXtended Markup Language) szintaxist használja az adatok leírására, és a SOAP (Simple Object Access Protocol) protokollt, amely az alkalmazások között szállítja az adatokat. 1. ábra: a NET felépítése 12 Common Language Runtime, egy program futtatása A forráskód egy köztes nyelvre

(IL, Intermediate Language), valamint metaadatokra fordítódik át. Ez ezután kiegészíto kódot linkelnek, ha szükséges, egy ún Assembly unit-ban. Végül elkészül az EXE vagy DLL Az EXE-ben vagy DLL-ben található kód még mindig köztes nyelven van leírva, és ebben a formátumban is tárolódik a merevlemezen. Amikor a programot a felhasználó elindítja, az IL információ, valamint Base Class Library-ból a megfelelo információk a Class Loader-hez kerülnek, majd az ellenorzo egységbe, végül a JIT Compiler-hez. Ez a fordító natív kódot állít elo (managed native code), amely már ténylegesen végrehajtható a célgépen. A “managed” annyit tesz, ho gy futtató környezet gondoskodik a fordításról, végrehajtásról, biztonsági beállítások és privilégiumok betartásáról automatikusan, ahelyett, hogy csupán néhány eszközt adna a programozó kezébe, amellyel neki kell elvégeznie ugyanezeket a feladatokat. A CLR továbbá figyel a memória

lyukak kezelésére is a JAVÁ-ból már ismeros garbage collector elven muködve. 2. ábra: fordítástól a futtatásig Common Type System A nyelvek közti együttmuködés biztosítására a CLR megköveteli a CTS használatát. Ez azt jelenti, hogy az összes nyelvnek, amely CLR-re lefordítható, bizonyos alap adattípusokat kell használnia. A CTS két típust enged meg: reference típust, és value típust. A reference típus hasonló egy osztályhoz, míg a value egy struktúrához hasonlítható. A CTS-t úgy tervezték, hogy az összes nyelvek által közösen használt 13 adattípus objektumként van megvalósítva, és a System.Object-bol származik Az egész rendszer elonye, hogy nem kell a különbözo nyelvek közötti típuskonverzióval foglalkoznia a programozónak, amennyiben két nyelv között akar adatokat átadni. Metaadatok A metaadat adat az adatokról. Ez teszi lehetové, hogy például egy Visual Basic-ben megírt osztály leszármazzon egy másik

osztályból, amely akármelyik .NET által támogatott nyelven van implementálva. Megteheto ez a kód újrafordítása nélkül, akkor is, ha az alaposztály esetleg megváltozik. Assembly Az assembly egy telepítési egység, amely tartalmazhat egy vagy több modult. Ezek, a köztes nyelven vannak tárolva, mind egy-egy külön file. Ezen kívül az assembly még metaadatokat is tartalmaz, melyek szükségesek egy program futtatásához. JIT Compiler A .NET alkalmazás futtatásához az IL kódot a gép által futtatható kódra kell fordítani Erre a feladatra hivatott a JIT fordító. Kétféle fordító is található a NET-ben § Standard JIT: erosen optimalizált kódot állít elo, és tárolja azt a késobbi futtatásokhoz. Analizálja az IL kódot, lefordítja, mint egy hagyományos fordító. A fordítás lassú, de a keletkezo kód igen gyorsan fut § EconoJIT: viszonylag hatékony gépikódot állít elo, kevesebb optimalizálással, gyorsabban lefutva.

Hátránya, hogy nem tárolható, tehát minden egyes alkalommal újra elo kell állítani, ha egy programrész lefut. User Interface A .NET architektúra tetején helyezkednek el a felhasználói felületek: Windows Forms, Web Forms, Console Applications § Windows Forms: A megszokott Windows felület. Programozása könnyu, a Visual Studio-ból ismert drag-and-drop módszerrel tervezhetok meg az ablakok. § Web Forms: Böngészo alapú felület, amely drag-and-drop funkcionalitással is bír. Két részbol áll: egy template-bol, amely a HTML elrendezés információkat tartalmazza, valamint egy komponensbol, amely a logikát 14 tartalmazza, amely a felületet muködteti. A Web Forms a palmtopoktól az asztali gépekig minden .NET-et támogató eszközön helyesen meg tud jelenni. § Konzol alkalmazások: .NET alatt írhatunk hagyományos szöveges megjelenítésu alkalmazást is, amely például kötegelt feladatok megoldására használható fel. 3.2 JAVA J2EE

Bevezeto A Java eredetileg egy eros kliens oldali alkalmazás megközelítés volt a 90-es évek közepén. Hamarosan azonban egyre elfogadottabb lett, mint szilárd middle-tier eszköz, amely a web technológiákban az adatbázis és a megjelenítés közti részt foglalja magában. A Sun cég kis ido elteltével egyéb komponenseket adott middle-tier megoldásához (szervletek, EJB), míg végül 1999-ben megjelent a J2EE. A J2EE a web alkalmazások fejlesztésében négy rétegu modellre épít. 15 3. ábr a: A J2EE négyrétegu alkalmazásmodell Kliens réteg A kliens gépen futó böngészo HTML oldalakat jelenít meg, esetleg JavaScriptet futtat. A megjelenített HTML oldalt a megjelenítési rétegtol kapja. Megjelenítési réteg A megjelenítési réteg szervletekkel, valamint JSP-vel van megvalósítva, amelyek HTML oldalak dinamikus generálására képesek. A dinamikus weboldalakat tipikusan egy adatbázis alapján állítja elo a szerver. Ezen kívül a szervletek

kezelik a felhasználó által bevitt adatokat, és továbbítják oket az EJB-knek (Enterprise JavaBeans), amelyek feldolgozzák azokat. Egy Web szerveren belül futnak, és egy Java Java virtuális gép hajtja végre oket. A szervlet képes kezelni a cookie-kat, képes ellátni egyszerubb feladatokat, sot képes akár adatbázis kapcsolatra is. Mindazonáltal az utóbbi funkcionalitást általában át 16 szokták adni az EJB-knek, hogy a rétegszerkezet tiszta maradjon, és a szervlet csak a megjelenítéssel foglalkozzon. A következo szervlet egy weboldalat generál, mely üdvözli a „user” változóban tárolt felhasználót: import java.io*; import javax.servlet*; import javax.servlet*; public class WelcomeUser extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType(“text/html”); PrintWriter out = res.getWriter(); out.println(“<html>”);

out.println(“<body>”); out.println(“<H1> Welcome back,”); out.print(“String user = ”); out.println(“(String) session.getAttribute(‘user’)”); out.println(user); out.println(“</H1>”); out.println(“</body>”); out.println(“</html>”); } } Míg a szervlet egy Java alapú megoldást kínált a dinamikus weboldalak generálására, sok fejleszto nehézkesnek találta ezt a megközelítést. Olyan esetekben, amikor hosszú HTML tartalmat egy az egyben változtatás nélkül generálni kellett, a szervletnek soronként ki kellett írnia a HTML oldalt. Egyszerubb megközelítést kínál a JSP, amely az ASP vagy PHP mintájára keveri a Java és HTML elemeket egy file-on belül. A fenti példa megoldása JSP-ben: <html> <body> <%@ page language=“java” import=“” %> <H1> Welcome back, <% String user = (String) session.getAttribute(‘user’); out.println(user); %> </H1> </body>

</html> 17 Business Logic réteg, EJB A J2EE az üzleti logikát Enterprise JavaBean-ekkel (EJB) oldja meg. Ezek felelosek a számítások elvégzéséért, valamint az adatbázissal való kommunikációért. Az EJB-k az alkalmazásszerveren (EJB Container) belül futnak. Soha sem jelenítodnek meg, csak a logika részekért felelosek. Az alkalmazásszerver a következo feladatokat automatizálja, nyújtja az EJB számára: tranzakciókezelés, security, perzisztencia, conneciton pooling, üzenetkezelés, naming service. Az EJB jól definiált API segítségével érheti el ezeket a funkciókat Egy EJB megalkotásához három osztályt kell létrehozni. § Remote interface: Ez az interfész képviseli a Bean-t a kliens oldalán. A kliens azokat a metódusokat látja a bean-bol, amelyeket a Remote interface definiál. A Remote interface által megadott függvények implementációját az EJB container tölti ki akkor, amikor az EJB-t a konténerbe installáljuk (deploy). 4.

ábra: remote interface osztálydiagramja § Home interface: Ez az interfész reprezentálja a komponens életciklusával kapcsolatos teendoket (create, destroy, find). Ezeket a metódusokat szintén az EJB container implementálja. Azért nem a remote interface-be kerülnek ezek a függvények, mert ezek általánosabb, összes bean-re azonosan muködo feladatot látnak el. 5. ábra: home interface osztálydiagramja 18 § Bean osztály: Ez maga az üzleti metódusok implementációja. Az EntityBean-bol vagy SessionBean-bol származik, viszont nem implementálja sem a Home, sem a Remote interface-eket. Ennek ellenére megvannak benne a megfelelo üzleti funkciók végrehajtására szolgáló függvények (amelyeket a Remote interface definiál), valamint saját maga definiálja és implementálja a Home interface függvényeit is. 6. ábra: bean osztály osztálydiagramja Az EJB muködése kliens oldalról: A kliens eloször egy Home objektumot hoz létre, jobban mondva

megkeresi a létezo Home objektumot a JNDI segítségével (a JNDI leírását lásd késobb). A Home objektum create() metódusával létrehoz egy Remote objektumot, amelyet sajátjaként használ. A Remote objektum egyes függvényeinek meghívásakor valójában a Bean objektum megfelelo függvénye fog végrehajtódni a háttérben: Object ref; CustomerHome home; //Home interface Customer customer; //Remote interface, not the Bean class Ref=jndiContext.LookUp(”java:comp/env/ejb/Customer”); //JNDI call to retrieve the reference to Home interface Home=PortableRemoteObject.narrow(ref, CustomerHome.class); customer = home.create(customerID); //create a Bean customer.setName(someName); //call business method 19 7. ábra: a kliens és a bean kapcsolata 1 8. ábra: a kliens és a bean kapcsolata 2 Adatbázis réteg Ebben a rétegben található maga az adatbázis. Arra, hogy milyen adatbázis-kezelot használjunk, gyakorlatilag nem szab megkötést a J2EE. Annyi korlátozás

azonban mégis fennáll, hogy az adatbázist Java Database Connectivity interfészen keresztül kell elérni. Ez nem jelent túlzottan szuk keresztmetszetet, a legtöbb adatbázis-kezelohöz létezik JDBC driver. Bean típusok A bean-eknek több fajtája létezik: § Stateless Session Bean: Ez a bean lehetové teszi metódusok kontextus nélküli hívását, tehát a metódushívások között a konténer nem oriz állapotot, a kontextus csupán a hívás során létezik. A kliensprogram a bean-t a create() metódus meghívásával létrehozza, majd az így kapott bean egyeden meghív egy bean által 20 implementált metódust. A hívás során a bean egyedváltozói megorzodnek, de egyáltalán nem garantált, hogy a következo hívásnál ugyanazon a bean egyeden hajtódik végre a hívás vagy hogy közben a konténer nem adta-e oda a bean egyedet egy másik kliensnek egy másik hívásra. A bean egyedváltozói tehát nem használhatók hívások közötti állapot

tárolására. § Stateful Session Bean: A kapcsolat bean-ek másik típusa az állapottal rendelkezo kapcsolat bean. A különbség az állapot nélküli típushoz képest az, hogy a bean megorzi a klienshez rendeltségét és egyedváltozóinak állapotát két hívás között. Tehát ha van egy ilyen programrészletünk: remote.myMethod(); . remote.myMethod(); az állapot nélküli bean-nél a két hívás két külön bean-hez futhat be, amelyeknek állapotai (egyedváltozói) különbözoek lehetnek. Ha véletlenül a két hívás ugyanahhoz a bean egyedhez futna be, akkor se garantálja semmi, hogy a két hívás között egy másik kliens nem használta a bean-t. Állapottal rendelkezo bean esetén mindkét hívás azonos egyedváltozókat talál (vagy legalábbis konzisztens egyedváltozókat, hiszen a hívások meg is változtathatják azokat) és más kliens véletlenül nem használhatja ezt a bean egyedet, csak ha bean létrehozója átadta a bean referenciáját

valaki másnak § Entity Bean: A kapcsolat bean-ek a klienssel való kapcsolattartásra valók, az entitás bean ezzel szemben perzisztens adatokat reprezentál. Egy entitás bean osztály kapcsolatban van a perzisztens tároló (pl. adatbázisszerver) bizonyos adatszerkezeteivel, alkalmazáslogika metódusaiban ehhez az adatszerkezethez nyújt hozzáférést. A leképezés az entitás bean adatszerkezetei és a perzisztens adatszerkezetek között lehet egyszeru vagy bonyolult, pl. egy entitás bean jelképezhet egy táblának egy sorát vagy akár több táblából vett adatok kombinációját. Mindig igaz azonban, hogy egy entitás bean osztály egyedei megtalálhatók az elsodleges kulcsuk (primary key) alapján. Az elsodleges kulcs maga is lehet egy bonyolult adatszerkezet (pl. osztály sok egyedváltozóval), de az EJB konténernek képesnek kell lennie egyértelmuen megtalálni a bean egyedet az elsodleges kulcs ismeretében. 21 § Message Driven Bean: Az EJB model

legnagyobb problémája, hogy teljesen szinkron, a kliensek kérésekkel bombázzák a konténert, mire az válaszol. Aszinkron, a konténerbol származó események kezelésére az eddigi EJB típusok nem alkalmasok. Az eseményvezérelt bean ezt a lyukat próbálja betömni Ezt a bean típust elsosorban Java Messaging Service (JMS) üzenetek kezelésére tervezték. A JMS úgy muködik, mint egy levelezolista: a JMS-ben topic-nak hívott témákra akármilyen adatstruktúrát lehet küldeni, amelyek sorba állnak, majd a témára feliratkozott alkalmazások megkapják oket. Eseményvezérelt bean lehet feliratkozva egy témára, ekkor a JMS üzenetek hatására aktivizálódik. A bean életciklusát a konténer és a beérkezo üzene tek vezérlik. Üzenet érkezésekor a konténer szerez egy szabad bean-t (gyárt egyet vagy elovesz egyet az egyedtárolóból) és odaadja az üzenetet. Minthogy a bean-t kliensek nem hívhatják meg, se vezérlo, se távoli interfésze nincsen, csak a

bean osztály. J2EE API-k A J2EE számos támogató API-t nyújt. Ezek a szoftver rétegek közti kommunikáció elosegítésére szolgálnak. § Remote Method Interface (RMI): Leginkább elosztott rendszerekben használt API. Az RMI lehetové teszi, hogy egy Java kliens egy Java szerver alkalmazással felvegye a kapcsolatot, és egy távoli objektum valamely metódusát meghívja. A Kliens kap egy referenciát a szerver objektumra, majd ezen lokális objektum metódusait hívja meg átlátszó módon, úgy, mintha az egy helyi objektum lenne. § Java Naming and Directory Interface (JNDI): Lehetové teszi a Java programok számára, hogy name és directory server-eket használva objektumokat vagy adatokat érjenek el azok nevére hivatkozva. Ez a fontos API teszi lehetové a kliens számára, hogy egy távoli szerver objektumot vagy adatot annak neve alapján megtaláljon a távoli gépen. § Java Message Service (JMS): Ez az API üzenetek hálózaton való továbbítását

segíti. Egy üzenetben küldött adat gyakran egyfajta értesítés egy bekövetkezett eseményrol. Másik gyakori használata az üzenetkezelonek a régebbi típusú (nem java) alkalmazásokkal való interakció. Ezeknek RMI vagy RPC módon esetleg bonyolult lenne elérniük egy szerver objektumot, viszont az üzenetkezelon keresztül egyszeruen és biztonságosan megtehetik ezt. 22 § Java Transaction API (JTA): Elosztott tranzakciók kezelésére szolgál. Ez annyit tesz, hogy több adatbázist kell egyszerre frissíteni, egy tranzakción belül. A feladat igen bonyolult is lehet, ha azt a programozónak kell implementálnia. Ezért az alkalmazásszerver API-jai közt megtalálható a JTA, amely ezt a terhet leveszi a programozó válláról. § Java Database Connectivity (JDBC) / SQLJ: A JDBC adatbázis-független protokollt kínál relációs adatbázisok elérésére Java-ból. Támogatja mind az adatmanipulációs utasításokat (DML), mind az adatdefiníciós

utasításokat (DDL). Az SQLJ szintúgy egy adabázis elérést nyújtó protokoll, amelyet könnyebb használni, mint a JDBC-t. Míg a JDBC-ben a valójában végrehajtott utasítások futási idoben generálódnak, az SQLJ- vel statikus SQL utasításokat fogalmazhatunk meg, amelyek fordítási idoben szintaxis ellenorzésen mennek keresztül, így elkerülhetok a futás közben fellépo hibaüzenetek. További elonye, hogy jobb optimalizációt tesz lehetové fordítási idoben. § JavaMail: Egy független levelezo platform, amely a legelterjedtebb levelezési protokollokkal képes együttmuködni (SMTP, POP3, stb). Lehetové teszi egy Java alkalmazás számára, hogy emailt küldjön különbözo levelezoszerverekhez. 23 4. Mobil alkalmazásmodellek, tekintettel a „mostly disconnected” kritériumra A mostly disconnected alkalmazás egy olyan alkalmazás, amely idejének, futásának nagy részében szerverrel való kapcsolat nélkül muködik. Tipikusan a felhasználó

valamiféle adatokat gyujt össze, azokon egyszerubb muveleteket is végezhet, esetleg kihasználhatja az adott kliens készülék speciális adottságait (fénykép készítés, hangfelvétel, stb.) Amikor a megfelelo mennyiségu adat összegyult, a kliens kapcsolatot kezdeményez a szerverrel. Ennek során összegyujtött adatait feltölti a szerverre, esetleg lekér valamilyen adatokat a szervertol, amely a további kapcsolat nélküli munkájához kellhet. Innentol kezdve megint a szerver nélkül folytatja muködését A következokben ismertetem az elterjedt mobil alkalmazásmodelleket, és tárgyalom, melyik hogyan képes teljesíteni a mostly disconnected kritériumot, mennyire alkalmas annak megvalósítására. 4.1 WAP alapú alkalmazás A WAP nagyon hasonló módon muködik, mint az internet. A WAP böngészovel rendelkezo kliens kéréseket küld a WAP szerver felé, az pedig a kérésekre választ küld. Ezt a választ a kliens böngészo megjeleníti .AWAP a valódi

internet böngészok eszközkészletének csak töredékét nyújtja, viszonylag egyszeru dolgok jeleníthetok meg. Mindez azért van, mert a WAP-ot úgy tervezték meg, hogy nagy válaszideju, lassú kommunikáció esetén is képes legyen muködni. WAP alkalmazás készítésénél két dologra kell kitérni: § Egy WAP oldal nemcsak statikus lehet, hanem dinamikus is, mint ahogy ez a web alkalmazásoknál is így van. A szokásos három- vagy négyrétegu architektúra használatával a szerver igen változatos dinamikus oldalakat hozhat létre, amelyek mindig igazodnak a pillanatnyi kérelemhez, helyzethez. Így például egy folyton változó adatbázis aktuális tartalma könnyedén lekérheto WAP segítségével. Lehetoség van a felhasználói interakcióra is a webtol megszokott formában: urlapok kitöltése segítségével. Így nemcsak adatokat lehet lekérni, de felvinni is lehet azokat 24 § A WAP oldal nemcsak a szerver oldalon tartalmazhat intelligenciát. Az

ún wap scriptek segítségével egyszerubb feladatokat el lehet végezni kliens oldalon is. Hasonló ez a JavaScript-hez, ám sokkal szegényesebb eszközökkel rendelkezik a programozó. Leginkább urlapok ellenorzésére lehet használni ezeket a scripteket. Egy WAP alapú alkalmazás bizonyos telefonokon hozzáférhet a telefon eroforrásaihoz is. Például képes lehet egy gombra kattintva telefonhívást kezdeményezni egy megadott számra, vagy hozzáférni a telefonkönyv bejegyzéseihez. Azonban ezek szintén igen szegényes eszköztárat biztosítanak komoly alkalmazás kifejlesztéséhez, arról nem is beszélve, hogy egyáltalán nem minden telefon támogatja ezeket a lehetoségeket. A WAP alkalmazás nem képes használni a telefon file-rendszerét, már csak azért sem, mert egyáltalán nem biztos, hogy az adott telefon egyáltalán rendelkezik bármilyen háttértárolóval. Ha pedig nem tud az alkalmazás adatokat hosszabb távon tárolni, akkor nemigen lehet képes

hosszabb ideig kapcsolat nélkül muködni. Idorol idore fel kell lépnie a szerverre, hogy az éppen bevitt adatokat feltöltse, mivel maga nem képes eltárolni azokat. Rövid ideig esetleg megoldható az, hogy az egymás után behozott wap oldalak lokális változók segítségével egymásnak átadják az eddig begyujtött adatokat. Ezzel a módszerrel azonban több baj is van: Nem feltétlenül biztosítható az, hogy a WAP böngészo képes olyan mennyiségu adat ideiglenes tárolására, amennyi összegyulik. Másrészt, ha a wap böngészot véletlenül kikapcsolják, kifogy az akkumulátor, vagy egyéb bármilyen hiba történik, akkor az összes odáig gyujtött adat elvész. Mindezen okok miatt a WAP alapú megközelítés kevéssé alkalmas mostly disconnected alkalmazások fejlesztésére. 4.2 Web alkalmazás A web alkalmazás jóval kényelmesebb és szebb felületet tud nyújtani, mint wapos társa. Ez azonban egyúttal sokkal nagyobb adatátvitellel is együttjár. A

HTML alapú megjelenítést nem készítették fel a szuk sávszélességre. Míg a wap oldalak erosen tömörített formában töltodnek le a kliens böngészobe, addig a web oldal ember által is olvasható, ám ettol „szószátyár” leírása sokszor annyi kB letöltését igényli. 25 Ezen kívül a web oldalakon megjelenítheto szebb felület az egér használatára van optimalizálva. Egérrel tényleg kényelmes lehet egy oldal használata A mobil telefonokon, ha egyáltalán találunk HTML böngészot, még akkor sem biztos, hogy az eszköz képes valamilyen mutató (tipikusan ceruza) kezelésére. Amennyiben nem, akkor a web alkalmazás használata igen kényelmetlen lehet. Web alkalmazások esetében ugyanúgy beszélhetünk szerver oldali és kliens oldali programozástól, mint a wap esetében. Ugyanúgy megjeleníthetok friss adatbázis adatok, és bevihet a felhasználó adatokat, amelyet a weboldal segítségével feltölt a szerverre. Hasonlóan a wapos

megoldáshoz, a web oldal sem képes adatok hosszabb ideju tárolására. Két egymást követo oldal képes átadni egymásnak valamennyi adatot (talán többet, mint wap esetében), de ha valami balul üt ki, akkor ezek az adatok ugyanúgy elvesznek, mint az elozo esetben. Látható tehát, hogy mostly disconnected alkalmazás készítésére a web alkalmazás sem használható. 4.3 Java J2ME alkalmazás A J2ME (Java2 Micro Edition) a JAVA nyelv egy jócskán leszukített változata. Nagy elonye, hogy a J2ME programok elvileg bármilyen J2ME motort tartalmazó gépen futtathatók. Mivel nemcsak a smartphone-ok, hanem a normál mobiltelefonok körében is népszeru mostanában a J2ME támogatás, ez igen nagy támogatottságot jelent. Azonban a platform függetlenség sokszor csak elvi lehetoség, mert ugyan a standard J2ME osztályok mindegyik mobiltelefonon megvannak és használhatók, sokszor csupán ezen osztályok felhasználásával igen nehéz egy kényelmesen kezelheto

alkalmazást kifejleszteni. Emiatt a gyártók igyekeztek a saját készülékeiket kiegészíto JAVA osztályokkal ellátni, amelyek nagyobb támogatást nyújtanak a programozónak, esetleg megengedik olyan eszközök használatát, amelyekre a J2ME szabvány nem tér ki (ilyen pl. a Bluetooth) Ezek a kiegészíto osztályok azonban csak egy készülékre, esetleg készülékcsoportra léteznek. Ezzel a JAVA hordozhatóság lényegében elveszett A másik probléma, hogy ha mégis sikerül megírni egy alkalmazást az alap osztályok felhasználásával, nem garantált, hogy a program másik készüléken is ugyanúgy fog megjelenni a felhasználó felé. A programozó pedig általában csak egy készülékre próbálja optimalizálni a felhasználói felületet, más készülékeken az esetleg nem nyújtja ugyanazt a használhatóságot. 26 A továbbiakban a Nokia 6600 telefon J2ME támogatását vizsgálom. Ezt azért kell kihangsúlyozni, mert más készülékek

tulajdonságai, támogatott funkciói az elobb említettek szerint jelentosen eltérhetnek a 6600 által nyújtott szolgáltatásoktól. J2ME környezetben viszonylag könnyen viszonylag tetszetos felhasználói felületeket lehet kialakítani, feltéve, hogy nem akarjuk a programot más eszközön is futtatni, ezzel elkerülve a különbözo megjelenítések okozta fejfájást. A nyelv támogatja a szerverhez való kapcsolódást, használhatunk pl. socketeket erre a célra. Tehát a mostly disconnected modell ezen része gond nélkül megvalósítható J2ME környezetben. Némi gond van azonban az adatok (átmeneti) tárolásával. A J2ME alkalmazások biztonsági okokból nem érhetik el a futtató készülék file rendszerét. Csak egy saját területet kapnak, ahol dolgozhatnak, ahova menthetik saját maguk által létrehozott állományaikat. Ez még nem lenne baj, ugyanis a mostly disconnected kritériumnak ez látszólag teljesen megfelel, hisz van hol tárolni a szerverhez

való kapcsolódásig az adatokat. Attól függoen, hogy milyen mostly disconnected alkalmazásról van szó, felmerül a kérdés, hogy miféle adatokat kell tárolni, azok hogyan változhatnak az ido folyamán, és mindezt mennyire hatékonyan lehet megvalósítani egy egyszeru file kezelo megoldással. Felmerülhet az igény az adatok adatbázisban való tárolására Ezt azonban sem a J2ME, sem a 6600 kiegészíto osztályai nem teszik lehetové. A diplomamunkában elkészített alkalmazás épít az adatbázis-kezelo szolgáltatásaira, ezért nem javasolt egy ilyen rendszert J2ME környezetben elkészíteni. 4.4 Natív Symbian alkalmazás A ma kapható smartphone-ok jelentos részén található Symbian operációs rendszer. Ez a hagyományos mobil telefonoktól nem megszokott módon muködik, inkább egy asztali számítógép vagy egy PDA muködéséhez hasonlítható a felület. Új programokat telepíthetünk a rendszerbe és távolíthatunk el, a programok a rendszer

legapróbb tulajdonságait vezérelhetik, kommunikálhatnak a már meglévo alkalmazásokkal is. A Symbian operációs rendszerre C++ nyelvu programok készíthetok. Ezek a programok mérsékelten bonyolult muveletek elvégzésére is alkalmasak. A gép képes tehát adatokat részben vagy teljes egészében helyben feldolgozni. Elméletileg igen komoly programok 27 futtatása is lehetséges lenne, ennek azonban határt szab egyrészt a gép sebessége, másrészt a rendelkezésre álló memória valamint tároló kapacitás. A jelenleg forgalomban levo Symbian alapú mobiltelefonok 100-150MHz-es sebesség körül futnak. Memóriakapacitásuk változó lehet, 4MB-tól 16MB- ig mozog általában A merevlemezt helyettesíto nem felejto memória mérete legtöbbször bovítheto, tipikus mérete 16-32MB. A Symbian alkalmazások a rendszer szinte minden lehetoségét kiaknázhatják. Így képesek helyben mérsékelten bonyolult számítások elvégzésére, képesek az eredmények

hosszabb távú tárolására a háttértárolón, hiszen hozzáférhetnek ahhoz (szemben a WAP vagy web applikációk megközelítésével). Képesek továbbá a rendszer mobiltelefonoktól kapott örökségét kihasználva hálózati kapcsolat létrehozására is, így például egy szerverrel való kommunikációra is. Mindezeket a tulajdonságokat figyelembe véve látható, hogy a Symbian környezet igen alkalmas mostly disconnected alkalmazások elkészítésére. 28 5. A Symbian operációs rendszer 5.1 Áttekintés A Symbian egy fejlett, nyitott operációs rendszer, melyet a világ vezeto mobiltelefon gyártó cégei licenszelnek. A rendszer kombinálja a számítási teljesítményt azzal, hogy a mobiltelefonok bárhonnan képesek kapcsolatot létrehozni, mégpedig igen sokféleképpen (SMS, TCP, MMS, Bluetooth, stb.) Így egy egyedülálló együttest mutat be. A rendszer lehetové teszi a mobiltelefonok számára, hogy operációs rendszerként viselkedve új

alkalmazásokat installálhassunk rájuk, amelyek a rendszer számtalan lehetoségét kiaknázhatják. A rendszer jellemzoi közt találhatjuk a multitaszkot megvalósító kernelt, middlewaret a kommunikációk kezelésére, adatkezelési rutinokat, valamint grafikus megjelenítést. A jelenleg kapható Smartphone-ok nagy részén Symbian 6.1 vagy 70 operációs rendszer található. A két rendszer nem tér el jelentosen egymástól, a továbbiakban a 70 verzió tulajdonságait ismertetem eloször csak tételesen, majd kitérve a mostly disconnected alkalmazásokra. Connectivity Framework Application protocols App licati on Servi ces Connectivity plugins Application Messaging engines Application framework Narrow band protocols Wap brows Web brows Wap stack Web stack Multimedia Graphics JavaPhone Java runtime Bluetooth Infra Networking Comms infrastructure Security Connectivity link Serial Comm Telephony 9. ábra: A Symbian operációs rendszer szerkezete 29

Base Az ábrán a rendszer felépítése látható, és az, ahogy a rendszer moduljai egymásra épülnek. A magasabban elhelyezkedo modulok kihasználják az alattuk levo rétegekben található modulok által nyújtott szolgáltatásokat. A modulok a következok: § Base: az alap rendszer és alacsony szintu biztonsági szolgáltatások. Részei: - Kernel library: a kernel védett módban fut, felügyeli az illesztoprogramokat valamint az energiagazdálkodást. Gondoskodik a memóriafoglalásokról mind maga, mind a nem védett (user) módú processek számára. - User library: szolgáltatásokat nyújt a felhasználói programok számára: § Process, szál, program és memória menedzsment § Hibakezelés és cleanup framework (futási hiba esetén gondoskodik a hibát okozó program által foglalt eroforrások felszabadításáról) § Descriptorok: bináris adatok és stringek tárolására használt hatékony tárolási mechanizmus § Konténer osztályok: listák

és tömbök template-szeru megvalósítása § Active object-ek: eseményvezérelt multi- tasking megvalósítására szolgáló objektumok, amelyek leveszik a programozó válláról a többszálúság okozta nehézségeket § Kliens-szerver architektúra: egyszeru de hatékony kommunikáció megvalósítás processzek között § Hardware Abstraction Layer: egységes felületet nyújt a különbözo hardver eszközök kezelésére - Base peripherals: a File szerver, amely VFAT, ROM és Flash File System kezelésére képes. - Security: biztonsági lehetoségeket nyújt, úgy mint kriptográfia és tanúsítvány kezelés § Application framework: Hatékony újrahasznosítható könyvtárakat nyújt adatok kezelésére, szövegek és grafikus elemek megjelenítésére. - Relációs adatbáziskezelo, tranzakció és visszagörgetés kezeléssel, megosztás támogatásával, C++ API valamint SQL parancsok segítségével - Vágólap kezelés - Grafikus objektumok

kezelése - Nyomtatás - Ablakozó rendszer a képernyo, billentyuk és mutatóeszköz megosztására az alkalmazások között 30 - Rich text támogatása - Nemzetközi karakterkészlet támogatás - UIKON framework a user interface egységesítésére és a programok egyöntetu megjelenítésére § Media: a média szerver aud io felvételt és lejátszást, valamint képkezelési funkciókat nyújt (pl. codec-ek, képformátumok támogatása) § Kommunikációs infrastruktúra és network stack-ek: - Hálózatkezelés: TCP/IP stack az internetes kapcsolatok egyszeruvé tételére: TCP, UDP, Domain Name Server szolgáltatások, socket támogatás, dial- up lehetoségek, FTP és telnet motor, stb. - GSM kommunikációs szolgáltatások: GSM hang és adattovábbítás támogatása a mobil környezetbol természetesen adódó formátumok igénybevételével: SMS, GPRS, CSD, stb. - WAP stack: wap elérés programozását elosegíto funkcionalitás - Bluetooth

stack: bluetooth szolgáltatások igénybevételét lehetové tevo szolgáltatás - Infrared IrDA stack: infravörös kommunikáció megvalósítását segíto funkcionalitás § Messaging: fejlett üzenetkezelés, SMS, email Browsing: webes és wapos böngészést megvalósító komponensek, szolgáltatások, programok § Alkalmazás protokollok, szolgáltatások és motorok: olyan modulok, melyek gyakran szükségesek különbözo programok megvalósításához, ezért a rendszer alaptámogatásként tartalmazza ezeket a funkcionalitásokat. - - Alkalmazás motorok § Naptárkezelés § Névjegykártyák kezelése § Táblázatkezelo § Nyelvi ellenorzés § Súgó motor Szolgáltatások: § Ütemezo: alkalmazások futását, idozített indítását, valamint leállás utáni hibaellenorzését végzi 31 § Rendszer ágens: információt nyújt a mobiltelefon jelenlegi státuszáról (térero, akkumulátor állapota, stb.) § § Log motor:

események, hibák feljegyzésére szolgál Java: A Symbian OS 6.x és 70 verziójában egy Java motort is építettek Viszonylag bonyolult Java alkalmazások készíthetok, amelyek ha nem is az összes, de a készülék számos szolgáltatását ki tudják használni. § Csatlakoztatás: PC-vel való kapcsolódást segíto komponensek, konverterek, csatlakozás menedzser 5.2 „Mostly disconnected” alkalmazások Az elozo alfejezet pontokba szedett áttekintést kívánt nyújtani a Symbian operációs rendszer sokoldalúságáról, szolgáltatásainak hosszú listájáról. Most pedig szemügyre vesszük a rendszert abból a szempontból, hogy a fenti tulajdonságok hogyan támasztják alá mostly disconnected alkalmazások készítését. A Symbian alkalmazások a rendszer ablakozó rendszerére épülve igen tetszetos felhasználói felület megjelenítésére képesek. A mobiltelefonok user interface osztályait (SeriesX, UIQ, stb.) használva viszonylag egyszeruen

hozhatók létre bonyolultabb felületek is. Így tehát például egy web alapú megjelenítésnél összehasonlíthatatlanul gyorsabb, szebb és bonyolultabb fukcionalitással bíró felületet is tervezhetünk. A rendszer háttértárral rendelkezik, amelyet a Symbian alapú programok el is tudnak érni. Ezt azért kell kihangsúlyozni, mert például a web alkalmazások erre nem képesek, annak ellenére, hogy ugyanazon a gépen futnak. A háttértár megléte a mostly disconnected modell egyik legjelentosebb kritériumának tesz eleget. A mostly disconnected alkalmazás így képes eltárolni az adatokat, késobb elovenni azokat, dolgozni rajtuk, majd az összegyujtött információt elküldeni a szervernek. A rendszer tartalmaz egy relációs adatbázis-kezelot. Igaz, ennek funkcionalitása nem éri el egy PC-n futó kezelo képességeit (például JOIN muveletekre nem képes), mégis nagy támogatást jelent az, hogy nem a programozónak kell megvalósítania az adattárolás

módját. A Symbian rendkívül sokoldalú kommunikációs architektúrát valósít meg. A mobiltelefon összes kommunikációs lehetoségét módjában áll az alkalmazásnak kihasználni. A szerverrel való szinkronizációra tehát számos mód adódik, csaknem 32 több, mint egy Laptop gépet használva (gondoljunk az SMS-re, Bluetooth-ra, amelyek a laptopok esetében nem mindig alapszolgáltatások) A kommunikáció titkosságát és megbízhatóságát segítik elo a titkosító eljárások és tanúsítványok. Ez ugyan nem feltétlenül kritériuma a mostly disconnected alkalmazásmodellnek, de nem árt tudni, hogy erre is van lehetoség. A rendszer magja pedig rendkívül sokrétu lehetoségeket nyújt az alkalmazás idozítési tulajdonságai tekintetében. Egy alkalmazás elindulhat egy bizonyos idopontban, kezdeményezhet szinkronizációt a szerverrel például éjszaka. Megoldható továbbá, hogy olyankor végezzen hosszabb lefutású számításokat,

amikor a készülék nincs jelentos CPU terhelés alatt (tipikusan amikor a felhasználó nem használja a szó hagyományos értelmében, tehát nem indít telefonhívásokat és nem futtat egyéb alkalmazásokat), illetve ezek a számítások végezhetok a háttérben, míg más programok ténylegesen futnak. Mindezekbol látszik, hogy a Symbian operációs rendszer megfelelo platform mostly disconnected alkalmazások készítésére. 33 6. Szinkronizációs módszerek 6.1 Adatátvitel A korszeru mobil készülékek rengeteg fajta kapcsolódási módot képesek megvalósítani, hiszen ebben rejlik legnagyobb erejük, ebben versenyképesek. A kapcsolatokat természetesen programozói szemmel nézve különbözoképpen kell létrehozni, viszont sok esetben a létrehozás után maga az adatátvitel már történhet egységes módon, pl. socketek felhasználásával. Egy rövid felsorolás és leírás a ma elterjedt adatátviteli protokollokról: § Circuit Switched Data (CSD):

A GSM hálózatokban legrégebben használt kapcsolattípus. Az adathívás a kapcsolatteremtéstol a lebontásig tart, eközben egyfolytában fennáll a kapcsolat a mobil készülék és a kiszolgáló között, akkor is, ha valójában nem történik adatátvitel. Elonye, hogy megbízhatóan muködo összeköttetést nyújt. Hátránya, hogy áltlalában nem jó a kihasználtsága, hiszen mindig vannak olyan idoszakok, amikor nem küldünk vagy fogadunk adatot, viszont ezt az idot is meg kell fizetni. A CSD sebessége 96kBit/sec § GPRS (General Packet Radio Service): Újabban elterjedo kapcsolattípus. Muködése eltér a CSD-tol, itt nem áll fent folytonos kapcsolat a mobil készülék és a kiszolgáló között, hanem adatátvitelkor épül fel minden alkalommal, és amint az adatátvitel megtörtént, a kapcsolat lebomlik. A sávkihasználás tehát sokkal jobb, mint a CSD esetében. Itt természetesen nem lehet kapcsolat hosszáról beszélni, fizetni általában az

adatforgalom után kell. A GPRS-t támogató készülékek egyszerre több rádió sávot is képesek kihasználni adatátvitelre. Így a kapcsolat sebessége attól függ, hogy a mobil készülék hány sávot kezel egyszerre. A tipikus értékek 30-40kBit/sec körül mozognak § High Speed Circuit Switched Data (HSCSD): A CSD modell továbbfejlesztése. Muködése hasonló elodjéhez, ám kiegészítve azzal, hogy ez a kapcsolattípus már képes egyszerre több rádiósávot lefoglalni adatátvitelre. Számlázása a CSD- hez hasonlóan szintén ido alapon történik. Sebessége 3040kBit/sec § Bluetooth: Kis hatótávolságon (~10m) belül muködo rádióhullám (de nem GSM) alapú kapcsolattípus. A Bluetooth eszközök bizonyos szolgáltatásokat 34 nyújtanak a világ felé (pl. soros port emuláció, file megosztás, internet megosztás), amelyek egy másik bluetooth eszköz igénybe vehet. A bluetooth szabvány biztonsági és autentikációs mechanizmusokat

is támogat, így a szolgáltatások igénybevétele csak a megfelelo azonosítás után történhet meg. Tipikus sebesssége mobil eszközöknél 100-150kBit/sec körül mozog, ez függ a két bluetooth eszköz távolságától is. § Infravörös kapcsolat: A bluetooth-nál egyszerubb szabvány, nem tartalmaz azonosítást, titkosítást. Egyszeru mód két készülék összekapcsolására infravörös fény segítségével. Sebessége általában 115kBit/sec 6.2 Protokoll SyncML A SyncML egy szinkronizációs protokoll, jobban mondva egy ajánlás, amely segít egy program szinkronizációs protokolljának megalkotásában. Kifejezetten mobil eszközökre lett kifejlesztve, a mobil eszközök tulajdonságait, korlátait és plusz képességeit kihasználva. A SyncML legfobb tulajdonságai: § Adattípus függetlenség: nemcsak elore definiált adattípusokat lehet szinkronizálni protokoll segítségével, hane m definiálhatók saját bonyolult adattípusok is. §

Hálózat függetlenség: szinte akármilyen hálózaton átvihetok a SyncML csomagok, nincs elore meghatározva, melyiken kell muködnie a rendszernek. § Önállóság: minden SyncML csomag önálló egész, külön-külön is értelmezheto rész. § XML: a SyncML az XML technológiára épít, a SyncML csomagok XML formátumban vannak megfogalmazva. Ez a kompatibilitást segíti elo, mivel az XML széles körben ismert és elterjedt. § Kis eroforrásigény: a protokoll úgy lett kifejlesztve, hogy megküzd a mobil eszközök szuk kommunikációs korlátaival (sávszélesség, stb.) anélkül, hogy ezáltal korlátozná a saját képességeit. A SyncML több komponensbol áll: § SyncML reprezentációs protokoll: A szinkronizáció csomagok átvitelével van megvalósítva, ahol egy csomag egy vagy több üzenetbol állhat. A reprezentációs protokoll írja le egy ilyen üzenet felépítését, mégpedig XML nyelven. Egy 35 üzenet feljécbol és testbol áll. A

fejléc session (viszony), rootolási és biztonsági információkat tartalmaz az adott csomagról, míg a test néhány parancs sorozata. A parancsok a szinkronizáció eszközei, lehetnek hozzáadási, törlési vagy felülírási parancsok egy adatbázisra vonatkoztatva. Oket végrehajtva a cél az, hogy két adatbázis adatai konzisztenssé váljanak. Bonyolultabb szinkronizációk esetén kiválasztható egy adatbázisnak egy részlete, amelyre külön végrehajtható szinkronizáció, valamint tranzakció jellegu parancskötegek is megadhatók, amelyek hatása csak akkor érvényesül, ha minden parancsot sikerült végrehajtani. A kis sávszélesség áthidalására a SyncML megengedi az XML szöveges formátuma helyett a bináris leképzést, amely hasonló a WAP oldalak adatreprezentációjához. Így egy XML üzenet sokkal kisebb méretuvé tömörítheto. § SyncML szinkronizációs protokoll: ez a protokoll írja le a továbbított csomagok végrehajtási sorrendjét,

hogy a szinkronizáció sikeresen hajtódjon végre. A SyncML kliens és szerver szerepeket definiál Nincs arra vonatkozó korlátozás, hogy a szerver csak szuperszámítógép lehet, a kliens pedig csak mobil eszköz, lehet fordítva is. A megkülönböztetés azért fontos, mert mindig a szerver gép az, aki a két különbözo adatbázis összehasonlítását elvégzi, soha sem a kliens. Támogatott a kétirányú és a csak egy irányú szinkronizáció is Utóbbi akkor lehet fontos, ha a felhasználó csak elmenteni kívánja az általa létrehozott adatokat, de pillanatnyilag nem érdeklik a szerver adatbázisának esetleges változásai. A szinkronizációt általában a kliens kezdeményezi, azonban elképzelheto fordított eset is. Az is lehetsége s, hogy a szerver csak egy értesítot küld a kliensnek (mondjuk SMS-ben) arról, hogy egy szinkronizálás szükséges volna. Ezután már a kliensen áll, hogy kezdeményezze a kapcsolatot § SyncML Transport Bindings: Bár a

SyncML hordozó közeg független, az interoperabilitás miatt szükség van annak a leírására, hogy a különbözo közegfajtákat hogyan lehet használni SyncML üzenetek továbbítására. Ez biztosítja, hogy a közeg használata alatt nem merülnek fel használati problémák. (pl. címzési gondok) A SyncML 10 három hordozó közeget vizsgál: HTTP, amely szélesen elterjedt, és tuzfalakon keresztül is használható; WSP (Wireless Session Protocol), amely a WAP szabvány része, és így lehetové teszi a mobiltelefonok SyncML támogatását; valamint OBEX (Object Exchange 36 protocol), amely a rövid hatótávú kapcsolatokat támogatja (infra, bluetooth, USB) § SyncML objektum reprezentációk: ez a rész leírja a leggyakrabban használt adatformátumokat (pl. vCalendar, vCard) Bármely program implementációnak, amely SyncML kompatibilisnek mo ndja magát, ezeket a reprezentációkat kell használnia az adatcseréhez. Saját formátumok A SyncML segítségével

igen bonyolult szinkronizációs folyamatok könnyebben kezelhetok. Azonban a SyncML-t támogató eszköznek egy sor szabályt be kell tartania ahhoz, hogy valóban SyncML kompatibilisnek nevezhesse magát. Elofordulhat azonban, hogy valamely alkalmazás által lebonyolított szinkronizáció sokkal egyszerubben is leírható. Ilyenkor megfontolandó a SyncML használatának mellozése és saját protokoll kifejlesztése. A diplomamunkában megvalósított rendszer nem tartalmaz annyira bonyolult szinkronizációs üzeneteket, amelyek indokolnák a SyncML technológia használatát. Ráadásul a Symbian nyelvnek nem beépített eleme az XML üzenetek parszolása, amely viszont a SyncML használatához elengedhetetlen. Mivel a SyncML támogatás aránytalanul nagy idoráfordítást igényelt volna a fejlesztésnél, és a program szinkronizáció bonyolultsági foka sem indokolja feltétlenül a SyncML támogatást, ezért a diplomamunkában a kliens és szerver kommunikációja

saját egyszeru protokoll kifejlesztésével lett megoldva. 37 7. A felhasznált technológiák 7.1 Kliens oldal Kliens oldalon, mint láttuk, több választási lehetoség is adódik a feladat megoldására: § Wap alapú megoldás: talán ez a legkézenfekvobb megoldás egy mobil kliens gépre gondolva. Ebben a modellben a gázórásnak gyakorlatilag nincs szüksége a kliens gépen programra, csupán a wap böngészojét kell használnia. Minden egyes gázóra leolvasása után a megadott wap oldalon fel kéne vinnie az épp leolvasott adatot a szerver adatbázisába. Szerver oldalon pedig egy wap szervert kell implementálni, amely a bevitt adatokat továbbítja az adatbázisnak. A gázórás azt is a wapon olvashatná el, hogy melyek azok a címek, melyeket végig kell látogatnia. Mindez implementálás szempontjából könnyebbség, legalábbis kliens oldalon. Ám a küldöttfogadott adatmennyiség jóval nagyobb így, mint abban az esetben, ha csak a gázórák

leolvasása, az adatok összegyujtése után egy csomagban küldjük el a szervernek az összes információt. Ezen kívül a wap felület nem túl kényelmes gyakori használatra, saját kliens alkalmazás esetén ennél sokkal felhasználóbarátabb megoldást lehet készíteni. § A Web alapú megoldás hasonló gondokkal küszködik, mint a wap. Bár a web felület szebb, és esetleg jobban használható is lehet, itt méginkább belép a képbe a hatalmas adatforgalom, amely a gázórák leolvasása során keletkezik. Míg a wap a mobil készülékekre van optimalizálva, a web ennél nagyobb adatforgalommal muködik. § J2ME (JAVA): A mobil eszközökben teret hódító JAVA nyelv adatforgalom szempontjából már sokkal optimálisabb megoldást nyújt a feladat megvalósítására. Itt már lehet mostly disconnected alkalmazásról beszélni, amely adatokat gyujt, és azokat egyszerre küldi el a szervernek. Felhasználói felület szempontjából se lehet okunk panaszra,

J2ME környezetben már jóval kifinomultabb alkalmazást készíthetünk. § Symbian: A feladathoz legjobban fekvo megoldás azonban mobil eszköz natív nyelve, a Symbian. Ezen a nyelven készíthetok a leggyorsabb alkalmazások. A Symbian (C++) nyelvu programok sokkal nagyobb 38 támogatottságot is élveznek, több rendszereszközhöz engednek hozzáférést, jobban személyre szabható a program. Végül, de nem utolsósorban a Symbian alatt fejlesztett programok külsore hasonlítanak a Symbian alapú telefonok többi telepített alkalmazásához, amely segíti a program használatát. Az alkalmazás Symbian 61 környezetben készül Ezt azért fontos hangsúlyozni, mert ma már néhány telefon a Symbian rendszer 7.0 verzióját használja. Nem lenne azonban egyelore tanácsos kihasználni ezen rendszer nyújtotta elonyöket (pl. http stack), mert így az alkalmazás nem lenne futtatható az összes telefonon. 7.2 Szerver oldal Szerver oldalon szintén több lehetoség

kínálkozik az alkalmazás fejlesztésére. Ezt az alkalmazást már valóban meg lehetne írni többféle platformon is (pl. NET, Java EJB) Mivel a szerver muködése nem túl bonyolult, nem igényel hatalmas eroforrásokat, ezért a techno lógiák közti esetleges sebességeltérés jelenleg nem sokat nyom a latba. A diplomamunka keretében a rendszer Java nyelven készült el, így nemcsak Windows-t futtató gépeken használható. Az alkalmazás logikája az EJB modellre épít. Ebben a modellben kényelmesen lehet adatbázis-muveleteket végezni. Az adminisztrátori felületet egy szervlet nyújtja, amely segítségével könnyedén lehet dinamikus html oldalakat készíteni. Ez a szervlet használja az EJB-ben elkészült alkalmazás logika által nyújtott funkciókat. Valójában a feladat megoldása EJB rész nélkül is teljes értéku lehetne, mivel az alkalmazás logika nem olyan bonyolult, hogy ne lehessen egy szervletben elhelyezni. A diplomamunka témája viszont

lehetové teszi, hogy minél több technológiával ismerkedjek meg. Így könnyebb lehet késobb egy bonyolultabb szerver megírása, ahol már komoly szükség van az EJB modell nyújtotta elonyökre. Az EJB és szervlet környezetét a Jboss rendszer szolgáltatja. Léteznek más alkalmazásszerverek is (Borland Enterprise Server, Tomcat stb). A Jboss elonye, hogy viszonylag kis méretu, ingyenes, valamint a fejlesztés során könnyu és gyors az újrafordított alkalmazás beillesztése az alkalmazásszerverbe (A Tomcat-et például sokszor teljesen újra kell indítani ehhez) 39 Adatbázisszerverként a mySQL szolgál. A mySQL tudása kisebb, mint drága kereskedelmi társaié (pl. Oracle), jónéhány dolgot, lekérdezést nem támogat, nem is annyira gyors. Viszont elonye, hogy ingyenesen használható Mivel a diplomamunka keretében nincs szükség túlzottan bonyolult lekérdezések megvalósítására, ezért a célnak a mySQL tökéletesen megfelel. 7.3

Szinkronizáció Mivel a szerver a külvilág felé egy szervlettel kapcsolódik (adminisztrátori felület), ezt kihasználva a kommunikáció is lehet HTTP alapú. Ennek a döntésnek két következménye van § Mivel a Symbian 6.1 környezet nem támogatja a http hívásokat, ezért ezt külön implementálni kell. Mivel azonban nincs szükség bonyolult http hívásokra, ez viszonylag egyszeru. § Szerver oldalon viszont szinte semmi különleges teendo nincsen. Mivel a szervlet amúgy is http alapú, http kéréseket fogad, és http válaszokat küld, ezért a http alapú szinkronizáció teljesen jól illeszkedik a képbe. A kliens egy HTTP POST kérés formájában küldi el a szervernek a leolvasott gázórák adatait, a szerver pedig egy HTTP vá lasz formájában küldi vissza az esetleges adatbázis változásokat. A SyncML protokoll több gép közti adatszinkronizáció megoldására jött létre. Olyan esetekre lett kitalálva, amikor a szinkronizáció igen

bonyolult is lehet, többszörös visszahatásokkal, inkonzisztencia kezelo mechanizmusokkal. Jóllehet a SyncML maga nem ad ajánlásokat arra, hogy konkrétan mit tegyünk, ha konfliktus lép fel, ám rengeteg segédeszközt (üzenettípust) nyújt, amelyeket a konfliktusok feloldásánál a programozó igénybe vehet. A diplomamunkában csak viszonylag egyszerubb szinkronizálási lépések kerülnek megvalósításra. Például a kliens által gyujtött adatok (gázórák leolvasott állása) és a szerveren idoközben módosuló adatok (új elofizeto hozzáadása) nem lehetnek hatással egymásra, nem kell tehát igazán komoly konfliktusok feloldásával foglalkozni. Ez nem azt jelenti, hogy egyáltalán nem alakulhat ki konfliktushelyzet. (Erre példa, amikor a kliens egy olyan elofizeto gázórájának állását tölti fel a szervernek, amely elofizetot közben törölték. Ekkor az adott információval a szerver nem tud mit kezdeni, ezért egyszeruen lenyeli) Ám jelen

egyszerubb esetben nem láttam indokoltnak a SyncML 40 alkalmazását. Habár néhány hasznos tulajdonságot a szinkron protokoll örököl a SyncML-tol, a szinkronizációs üzenetekre saját egyszerubb protokoll készült, amely jobban illeszkedik a feladathoz. Az üzeneteket szöveges formában küldi át egymásnak a két fél. 41 8. A tervezés részletes leírása 8.1 Magasszintu blokkdiagram Adminisztrátori felület és szerver kapcsolata Az adminisztrátori felület, valamint az azt kiszolgáló szerver oldali program kapcsolata a következoképpen képzelheto el: 10. ábra: admin felület és szerver kapcsolatának magasszintu blokkdiagramja 1 11. ábra: admin felület és szerver kapcsolatának magasszintu blokkdiagramja 2 Az adminisztrátor egy webes felület segítségével végezheti az adatbázis karbantartását. Ehhez csak egy böngészovel és internetkapcsolattal rendelkezo számítógépre van szüksége. Az adatátvitel tehát itt HTTP protokollon

keresztül HTML alapon történik 42 A szerver oldalon a befutó kéréseket egy szervlet fogadja. A kérésen néhány elozetes feldolgozást elvégez, majd kapcsolatba lép az EJB-vel. A kéréstol függoen meghívja az EJB megfelelo me tódusát, amely majd a választ fogja szolgáltatni. Az EJB-nek a válasz generálásához kapcsolatba kell lépnie az adatbázissal. Miután ez megtörtént, kiolvassa onnan, vagy beírja oda a megfelelo adatokat, majd a feldolgozás eredményét visszaküldi a szervletnek. A szervet pedig továbbítja az adatokat a kérést kezdeményezo böngészo felé. Fontos megemlíteni, hogy bár a 10. ábra alapján úgy tunhet, hogy a szervlet és az EJB, valamint az adatbázis is mind egy gépen fut. Ez nem feltétlenül van így, hiszen a J2EE egyik alaptulajdonsága, hogy képes a terhelés elosztására, tehát képes a feladatokat több számítógépre lebontani. Természetesen az adatbázisnak sem kell ugyanazon a gépen futnia, mint az EJB-nek.

Kliens felület és szerver kapcsolata Az kliens felület, valamint az azt kiszolgáló szerver oldali program kapcsolata a következoképpen képzelheto el: 12. ábra: kliens-szerver kapcsolat magasszintu blokkdiagramja 1 43 13. ábra: kliens-szerver kapcsolat magasszintu blokkdiagramja 12 Hasonlóan az adminisztátori felülethez, a gázóra- leolvasó kliens is HTTP protokollon keresztül kapcsolódik a szerverhez, azon belül is a szervlethez. Fontos azonban megemlíteni az alapveto különbséget: Míg az admin felület böngészoje HTML formátumú csomagok formájában kommunkiált a szerverrel, addig a kliens esetében ez nem így van. A kliens saját protokollt használ a szerverrel való kommunikáció lebonyolítására. Ennek részleteit lásd a 55- ik oldalon A kliens a saját protokoll formátuma szerint összeállítja a szerver felé elküldendo adatcsomagot. HTTP protokollon keresztül elküldi a szerver felé A szerveren a szervlet fogadja a bejövo csomagot,

azonban tudja, hogy annak tartalmát speciálisan kell értelmezni. A csomagban foglalt adatokat továbbítja az EJB- nek, amely az adatbázishoz kapcsolódik, és elvégzi rajta a szükséges módosításokat, valamint kiolvassa a kliens fele visszaküldendo adatokat. Ebbol a kliens számára értelmezheto adatcsomagot formál, majd a szervletnek ezt elküldi, az pedig továbbítja a kliens felé a csomagot (amely szintén nem HTML formátumú). 44 8.2 Usecase Eset U1.1 Szerver oldal: adatfeltöltés Aktor Adminisztrátor Elofeltételek A szerver oldali alkalmazás muködoképes, és élo internetkapcsolattal rendelkezik a külvilág felé Leírás Az Adminisztrátor HTML fe lületen keresztül új elofizetot vesz fel az adatábázisba (név, cím, irányítószám). Az új elofizeto SUBSCRIBERS bekerül táblába a a szerver megadott adatbázisba név, cím a és irányítószám adattal. A SUBSCRIBERS tábla változásának ténye bekerül a CHANGELIST

táblába, és a szerver adatbázis verziószáma eggyel megno. Kivétel A megadott címen elofizeto már szerepel a szerver adatbázisban Utófeltételek Eset U1.2 Szerver oldal: adat megtekintés Aktor Adminisztrátor Elofeltételek A szerver oldali alkalmazás muködoképes, és élo internetkapcsolattal rendelkezik a külvilág felé Leírás Az Adminisztrátor a megfelelo dinamikus HTML oldal segítségével lekérdezi az adatbázisban szereplo elofizetok adatait és gázórájuknak eddig összegyujtött állás értékeit, megfelelo szurofeltételek segítségével. A kért szurofeltételeknek megfelelo adatok (elofizeto neve, címe, irányítószáma, gázóra leolvasásainak ideje és gázóra állása) megjelennek a képernyon Kivétel Utófeltételek 45 Eset U1.3 Szerver oldal: elofizeto törlése / új leolvasás kérése Aktor Adminisztrátor Elofeltételek A szerver oldali alkalmazás muködoképes, internetkapcsolattal rendelkezik a

adminisztrátor elozoleg külvilág listát kért és élo felé. Az tetszoleges szurofeltétellel a gázórák adatairól Leírás Az Adminisztrátor a HTML oldalon egy elofizetot minden tárolt adatával együtt töröl a Törlés gombra kattintva, vagy az elofizeto nevét megváltoztatja a Módosít gombbal. A szerver adatbázis frissül a fenti muveletnek megfeleloen: Törlés esetén az elofizetovel kapcsolatos minden információ törlodik az adatbázisból, Módisítás esetén az adatbázisban tárolt elofizeto név megváltozik. A SUBSCRIBERS tábla ezen változásának ténye bekerül a CHANGELIST táblába, és a szerver adatbázis verziószáma eggyel megno. Kivétel Utófeltételek Az adatbázis a módosított állapotot tükrözi. 46 Eset U1.4 Kliens oldal: szinkronizáció a szerverrel Aktor Kliens Elofeltételek A szerver oldali alkalmazás muködoképes, és élo internetkapcsolattal rendelkezik a külvilág felé. A kliens

szintén élo internetkapcsolattal rendelkezik. Leírás A kliens a mobil eszközön elindítja a szinkronizációt a szerverrel. A kliens program csatlakozik a szerverhez, megadva saját azonosítóját (irányítószámát) és adatbázisának verziószámát. A kliens adatbázisában tárolt új (state!=0) gázóra állások feltöltodnek a szerver adatbázisba a HEATSTATES táblába. Ezután a szerver adatbázisból a kliens adatbázisba letöltodnek a SUBSCRIBERS tábla legutolsó szinkronizálás óta született (kliens irányítószámával azonosított munkaterületére vonatkozó) esetleges változásai, és ennek segítségével a kliens cím adatbázisa szinkronba kerül a szerverével. Végül a kliens adatbázisában található összes gázóraállás nullázódik, azaz újbóli leolvasást igényel (tipikusan következo hónapban). Kivétel Utófeltételek A kliens és szerver címadatbázisa megfelel egymásnak. Eset U1.5 Kliens oldal: gázóra leolvasása

Aktor Kliens Elofeltételek Van legalább egy leolvasandó (state==0) gázóra a kliens mobil eszközének adatbázisában Leírás A kliens egy tetszoleges leolva sandó gázóra állását bejegyzi készülékébe. A kliens gépének adatbázisa frissül az új adattal. Kivétel Utófeltételek 47 Eset U1.6 Kliens oldal: kliens ID (irányítószám) megváltoztatása Aktor Kliens Elofeltételek Leírás A kliens a készülékben beállítások fül alatt megváltoztatja az irányítószámot (munkakörzetet). Ekkor a teljes adatbázisa (az összes tárolt gázóra állás, valamint az összes tárolt elofizeto adat) törlodik, valamint az adatbázisának verziószáma 0-ra áll. Kivétel Utófeltételek 8.3 A kliens adatbázisa üres, adatbázisának verziószáma 0. Adatbázis tervek Szerver adatbázis A szerver adatbázis három táblából áll: SUBSCRIBERS HEATSTATES CHANGELIST subs id name address zipcode subs id date of state state subs id event

version 14. ábra: A szerver adatbázis felépítése 1. SUBSCRIBERS: ebben a táblában tárolódnak az elofizetok hosszú távon változatlan adatai. Létrehozása: CREATE TABLE subscribers(name VARCHAR(63) NOT NULL, address VARCHAR(255) NOT NULL, zipcode VARCHAR(255) NOT NULL, subs id INTEGER UNSIGNED AUTO INCREMENT NOT NULL, PRIMARY KEY (subs id)); 48 Name Address ZIPcode Subs id Kiss józsef Budapest, Tanya u. 1125 1 3525 2 2040 4 8. Nagy Gáspár Miskolc, Egyetem 2. Benedek Elek Budaörs, Fo út 100. Az irányítószámot a valóságközelibb leírás érdekében vesszük külön. Ez alapján fogjuk a leolvasó kliensekhe z hozzárendelni a címtartományokat. Egy kliens ugyanis nem a teljes terület összes címéért felelos a valóságvan, hanem csak egy részéért, egy utca csoportért. Ez persze a igazából általában kisebb, mint egy irányítószám által lefedett terület, de az egysze ru implementálás kedvéért most az

irányítószámot fogom használni a kliensek területének kijelölésére. A subs id elsodleges kulcs, minden elofizetohöz más subs id tartozik. Ennek nemcsak a szerveren belüli adatbázismuveleteknél, join-oknál lesz jelentosége, hanem késobb a szinkronizációnál is. A kliens tábláiban ugyanis ugyanazokhoz az elofizetokhöz ugyanaz a subs id fog tartozni, ezzel megkönnyítve a szinkronizációt. Így pl egy elofizeto törlésekor elég annyit mondani a kliensnek: „Törölték a 6-os elofizetot”. Ez rövidebb, mintha azt mondanánk: „Törölték az elofizetot a következo címrol: 1125, Budapest, Béla király ú 13/b fsz.2” 2. HEATSTATES: ebbe a táblába kerülnek be az elofizetokhöz tartozó gázóraállás adatok, és bejegyzésük dátuma is. Létrehozása: CREATE TABLE heatstates(subs id INTEGER UNSIGNED NOT NULL REFERENCES subscribers(subs id), date of state NULL, state INTEGER UNSIGNED NOT NULL); 49 DATE NOT Subs id Date of state State 1

2004.0105 32874 2 2004.0106 42546 2 2004.0205 44563 3 2004.0103 13423 1 2004.0206 36734 3 2004.0201 14523 2 2004.0310 45734 3. CHANGELIST: ebben a táblában tároljuk az adatbázis változásait, követjük a verzióinak alakulását. Minden alkalommal, amikor az adminisztrátor a SUBSCRIBERS tábla egy adatát megváltoztatja (módosít egy címhez tartozó nevet, töröl egy elofizetot), a változás ténye bekerül a CHANGELIST táblába, és az adatbázis verziószáma eggyel megno. Ennek segítségével lehet majd szinkronizálni a kliens és a szerver adatbázist. CREATE TABLE AUTO INCREMENT subs id changelist(version NOT INTEGER NULL, event UNSIGNED INTEGER VARCHAR(100) NOT NULL UNSIGNED NOT NULL, REFERENCES subscribers(subs id), PRIMARY KEY (version)); Version Event Subs id 23 RENAME 2 24 RENAME 2 25 DELETE 3 26 ADDNEW 1 Látszik, ho gy már a verziókezelo táblában optimalizálva szerepelnek az adatok. Például nem

lényeges, hogy a 23-as és 24-es verzióban is megváltoztatták az elofizeto nevét, hiszen úgyis csak az számít, hogy végül milyen név tartozik az adott elofizetohöz. Nem kell külön tárolni tehát, hogy milyen névre változott az elofizeto, az egy join muvelettel kiderítheto, mégpedig mindig a legfrissebb, aktuális adatot fogjuk így megkapni. A törlés muveletnél pedig azért elegendo az elofizeto ID tárolása, mert bár a szerver 50 adatbázisában az elofizeto adatai a törlés következtében már nem szerepelnek, viszont az ID a kliens gépen egyértelmuen azonosítja az elofizetot. Ilyen módon a kliens csak az ID alapján el tudja dönteni, a szinkronizáció során, hogy melyik elofizeto az, akit töröltek. Errol részletesebben a szikron protokollnál Kliens adatbázis SUBSCRIBERS: ez az egyetlen tábla, ebben tárolódnak az elofizetok adatai: elofizeto id, név, cím, gázóra állása. Ha egy gázóra leolvasásra vár, akkor state attribútuma 0

A subs id attribútum minden elofizetonél megegyezik a szerver ugyanazon elofizetohöz tartozó subs id attribútumával. Ez megkönnyíti és meggyorsítja a szinkronizáció lépését, hiszen nem kell minden elofizetot a címével azonosítani, ezzel értékes sávszélességet pazarolva. (Elvileg persze a cím is egyértelmuen azonosítana egy elofizetot, viszont törekedni kell a hálózat használatának minimalizálására) CREATE TABLE subscribers(subs id INTEGER UNSIGNED NOT NULL, name VARCHAR(63) NOT NULL, address VARCHAR(255) NOT NULL, state INTEGER UNSIGNED, PRIMARY KEY (subs id)); 8.4 Az alkalmazások (szerver és kliens) felépítése Szerver alkalmazás A szerver alkalmazás felépítése a J2EE-ben megszokott 4 rétegu modellel írható le. A muködés szempontjából leglényegesebb a középso két réteg, amelyek együtt alkotják az üzleti logikát. A böngészobol érkezo kéréseket a szervlet fogadja. Ez nem végez komoly feladatokat, inkább csak a bejövo

kérések adatait ellenorzi, hogy minden paraméter megfelelo-e, nem hiányzik-e adat a további sikeres muködéshez. Amennyiben valami problémát észlel, akkor válaszként egy HTML oldalt generál, amelyben figyelmezteteti a felhasználót a hiba okára. Ha mindent rendben talál, akkor kapcsolatba lép az EJB- vel, és a böngészotol érkezo kérés függvényében annak egy metódusát meghívja, átadva neki a böngészotol kapott paramétereket. Az EJB végzi a tulajdonképpeni munkát. Muködése során kapcsolatba lép az adatbázissal, és oda beír, illetve onnan kiolvas adatokat, ezekbol esetleg utólag 51 szelektál, összegzéseket végez, a konkrét feladattól függoen. Eredményként egy stringet ad vissza a szervletnek, amely tulajdonképpen egy HTML forrást tartalmaz. Ebben a forrásban vagy a felhasználó kérésére adott válasz található, vagy pedig egy hibaüzenet, ha valami nem volt rendben az EJB futása során. A HTML forrást a szervlet

egyszeruen továbbítja a böngészo felé. A szervlet nem csak böngészotol, hanem mobil klienstol, tehát gázóra-leolvasó mobil eszköztol is kaphat kérést. A két kérést a jelenlegi rendszerben az különbözteti meg egymástól, hogy míg a böngészo esetében a HTTP GET parancsot használja a rendszer, addig a második esetben HTTP POST parancsot kap a szervlet. Természetesen ezt máshogy is meg lehet oldani, de így egyszeru. A kérést a szervlet ismét ellenorizni hibák szempontjából. Ha hibát talál, akkor „Error” üzenetet küld vissza a kliensnek, amely a kliens gépen hibaüzenetet ad a felhasználónak. Ha a szervlet mindent rendben talál, akkor megint csak továbbítja a kérést az EJB felé, amely elvégzi a munka további részét. Az EJB válasza a szervlet felé ezúttal viszont nem HTML alapú, hanem a saját protokollt használja, amelyet a 8.5 fejezet részletez. Természetesen ha hiba történik (pl nem tud kapcsolatot teremteni az

adatbázissal), akkor az EJB is hibaüzenetet küld a szervlet felé vissza. Mobil kliens alkalmazás A gázóra- leolvasó ember kezében futó alkalmazás egy Symbian program, mégpedig a Nokia által licenszelt Series60 felhasználói felületet használó Symbian program. A Symbian rendszer felépítését az 5. fejezet részletezi A Series 60 UI lényegében a Model-View-Controller sémát követi, kis változtatással: § Modell: Ez a rész gondoskodik az adatok gondozásáról, betöltésérol, mentésérol, manipulálásának végrehajtásáról. Létrehoz, ha még nem létezik, és kezel egy adatbázist, amelyben a leolvasott gázórák állása tárolódik. Szinkronizáció esetén összeállítja a protokoll által megkövetelt formátumú adatcsomagot, és kapcsolatba lép a szerverrel. Ezután fogadja a szervertol kapott adatokat, és frissíti az adatbázist azokkal. § View: Ez a rész felelos a megjelenítésért, kirajzolja a listaablakokat, felbukkanó ablakokat,

gombokat. Teszi mindezt a modelltol elkért adatok alapján Fontos, hogy a view maga nem tárol semmilyen modellel kapcsolatos információt. Ha a modellben valami megváltozik, akkor a view-t újra ki kell rajzolni. 52 § Controller: a felhasználó inputját (tipikusan billentyuleütéseket) fogadó rész. Értelmezi az inputot, és parancsok formájában továbbítja a modell felé. A modell ekkor végrehajtja az adatbázison a szükséges változtatásokat, majd értesíti a view-t errol, amelynek hatására az újrarajzolja a felületet. A Symbian-ban a Modell- View-Controller sémához képest annyi a különbség, hogy a View és a Controller egybeolvad. Így kapjuk a Document-View architektúrát, ahol a Modellbol Document, a View-bol és a controllerbol egyszeru View lesz. Output Input View Controller Model Input/Output View Document 15. ábra: a modell-view-controller és a document-view struktúra kapcsolata 8.5 Szinkronizáció Verziókezelés A

verziókezelés a következoképpen történik: Minden alkalommal, amikor az adminisztrátor egy elofizeto adatait megváltoztatja vagy törli az elofizetot, ennek a változtatásnak a ténye rögzítésre kerül a CHANGELIST táblában. A tábla tárolja a módosítás jellegét, és a jelenlegi adatbázis-verziószámot egy rekordban. Ezután az adatbázis verziója eggyel megno. Szinkronizáláskor a klienshez letöltodnek a legutolsó szinkronizálás óta történt változások idosorrendben, és ezek alapján a kliens frissíti saját adatbázisát, lényegében gyorsítva lejátssza a szerver oldalon történo eseményeket. Azonban nem szükséges minden változásról értesíteni a klienst (pl. ha egy elofizeto nevét kétszer változtatták meg, akkor elegendo a legutolsó állapotot átküldeni). A szerver tehát optimalizálja a változtatások küldését: § Ha egy elofizeto nevét többször megváltoztatták, akkor a kliensnek elég csak az utolsó nevet elküldeni. 53

§ Ha egy elo fizetot töröltek, akkor csak ezt a tényt kell elküldeni, azt nem, hogy elotte hányszor változott az elofizetohöz tartozó név. § Új elofizeto esetén, ha annak nevét a felvétel után megváltoztatták, akkor csak a legújabb nevet érdemes elküldeni. § Ha új elofizetot vett fel az adminisztrátor, de késobb törölte, akkor egyáltalán semmit nem kell a kliens fele küldeni. Ezen megfontolások alapján a szerver a következoképpen intézi a változások kliens fele továbbítását: 1. Megkeresi az összes (kliens verziószámánál nagyobb verziószámú) ADDNEW utasítást a CHANGELIST táblában, és illeszti a SUBSCRIBERS táblával (CHANGELIST.subs id=SUBSCRIBERSsubs id) Ha egy sor nem található a SUBSCRIBERS táblában, akkor azt azóta törölték, nem kell elküldeni. Errol az SQL természetes illesztés magától gondoskodik Ha az adott elofizeto nevét közben megváltoztatták, akkor pedig úgyis a legfrissebb adatot kapjuk az

adatbázis szerkezetébol következoen. SELECT * FROM changelist, subscribers WHERE changelist.subs id=subscriberssubs id AND event="ADDNEW" AND version>? AND zipcode=? 2. Megkeresi az összes (kliens verziószámánál nagyobb verziószámú) DELETE utasítást a CHANGELIST táblában. A kliens oldali törléshez elég a törlendo elofizeto subs id azonosítóját átküldeni a kliensnek. Nem kell átküldeni azon DELETE sorokat, amelyekhez tartozó elofizetot a kliens legutóbbi csatlakozása után hoztak létre, hiszen eszerint a kliens eddig nem tudott az elofizeto létezésérol, ha pedig közben ezt az elofizetot létrehozták, de le is törölték, akkor a kliens szempontjából lényeges változás nem történt. SELECT * FROM changelist t1 LEFT OUTER JOIN changelist t2 ON t1.subs id=t2subs id AND t2version>? AND t2.event="ADDNEW" WHERE t1event=”DELETE xxxx” AND t1.version>? 54 3. Megkeresi az összes (kliens verziószámáná l nagyobb

verziószámú) RENAME utasítást a CHANGELIST táblában, és illeszti a SUBSCRIBERS táblával (CHANGELIST.subs id=SUBSCRIBERSsubs id) § Ebbol az eredménybol az illesztés miatt automatikusan kimaradnak azon sorok, amelyeket azóta töröltek. § Azokra sincs szükség, amelyeket a kliens legutolsó csatlakozása óta hoztak létre, hisz azokat már egyszer átküldtük. § Nem kellenek továbbá azon RENAME sorok, melyek elofizetoit azóta törölték az adatbázisból. § Végezetül, csak egy elofizetohöz tartozó legutolsó RENAME utasításra vagyunk kíváncsiak. SELECT * FROM subscribers, (changelist t1 LEFT OUTER JOIN changelist t2 ON t1.subs id=t2subs id AND t2.version>? AND (t2version>t1version OR (t2.version<t1version AND t2event="ADDNEW"))) WHERE subscribers.subs id=t1subs id AND t1event="RENAME" AND zipcode=? AND t1.version>? 4. Az elozo pontok eredményeibol természetesen csak azokat küldjük át, amelyek irányítószáma

megegyezik a kliens irányítószámával, és csak a kliens adatbázis verziószámától fölfele vesszük figyelembe a változásokat. Protokoll A szinkronizáció HTTP protokollon keresztül zajlik. Ez a megoldás kézenfekvo, mivel a szerver szervleteket könnyen képes futtatni, tehát szerver oldalon nem szükséges extra lépéseket tenni a szállító protokoll implementálására. A szerver oldalon tehát elég a változások megkeresése a fentebb bemutatott módon, és az eredményt az alkalmazásszerver becsomagolja HTTP keretbe. A kliens gépnél komplikáltabb a helyzet. Symbian 61 környezetben nincsen HTTP támogatás. Ezt tehát implementálni kell A kommunikáció a következoképpen zajlik: a kliens a szerverhez kapcsolódik: egy socketet nyit a szerver 8080-as portja felé. Ezen a porton érheto el a JBoss szervleteket futtató felülete. A socketen keresztül történik a kommunikáció. 55 Az adatcsere két lépésben zajlik: 1. A kliens közli a szerverrel

a saját verziószámát, majd feltölti a szervernek az általa újonnan leolvasott gázórák adatait. Ehhez HTTP request adatformátumot használ: POST /gaz/app HTTP/1.0¶ User-agent: HeatMeterClient¶ Content-Type: text/plain¶ Content-Length: 1230¶ ¶ <client ver>¶<client id>¶<state1>¶<state2>¶.¶ <stateX> <client id> string a kliens azonosítója (irányítószáma) <client ver> string a kliens címadatbázis verziója <state1> <subs id>¶<heat state> egy gázóraállás leírása <subs id> string egy elofizeto azonosítója <heat state> string a gázóra mért adata 2. A szerver a HTTP csomagból kibontja a számára hasznos információt Összehasonlítja a kliens verziószámát a saját adatbázisának aktuális verziószámával. Amennyiben ez különbözik, akkor el kell küldeni a két verzió közti változtatások listáját a kliens felé. Amennyiben azonos a két verziószám,

akkor csak üres (Content-Length=0) üzenetet küld a szerver a kliensnek. HTTP/1.0 200 OK¶ Date: Thu, 06 Aug 1998 12:00:15 GMT¶ Server: Apache/1.30 (Unix) ¶ 56 Content-Length: 6821¶ Connection: close¶ Content-type: text/plain¶ ¶ <server ver>¶<change1>¶<change2>¶.¶<changeX>¶¶ <server ver> string a szerver adatbázis verziószáma <changeX> <change descr> egy változás leírása <change descr> “DELETE <subs id>” | “RENAME <subs id> <length> <name>” | “ADDNEW <subs id> <length> <addr> <length> <name>” string, amely a változás tényét leírja <subs id> string egy elofizeto azonosítója <addr> string az elofizeto címe <name> string az elofizeto neve Mivel a szerver a socketet nem feltétlenül bontja le a válasz megküldése után, a kliensnek valahogyan érzékelnie kell, hogy az adatcsere lebonyolódott. A szerver

válasza TCP csomagokra bomlik A kliens folyamatosan kapja a TCP csomagokat a szervertol, de nem tudhatja, hogy melyik csomag az utolsó. A csomagok tartalmát összeilleszti. Vizsgálhatná a „Content-Length: xxxx” sorban megadott értéket, és ennek alapján tudhatná, hogy már elegendo adat érkezett-e. De ehhez azt is folyamatosan vizsgálni kéne, hogy a „Content-Length” sor egyáltalán már megérkezett-e. Lényegesen egyszerubb az a megoldás, hogy forgalomvég-jelzot helyezünk el a válaszüzenet végén. A kliensnek így csak annyit kell megvizsgálnia, hogy az épp megérkezo TCP csomag végén ott van-e a forgalomvég jelzo. 57 Mivel feltöltés irányban az alkalmazás szerver a fenti problémát magától kezeli, ott nincs szükség ilyen trükk bevetésére. 8.6 User Interface Webes adminisztrátori felhasználói felület A szerveren az elofizetok adatainak változtatását, illetve a beérkezett adatok megtekintését egy adminisztrátor végezheti.

Az o számára HTML felület áll rendelkezésre, amelyen a módosításokat, lekérdezéseket végrehajthatja. 58 Bejelentkezo lap A bejelentkezo lap egy statikus HTML oldal, melyen az adminisztrátor két feladatot végezhet el: § Kereshet a szerver adatbázisában: Meghatározott szurofeltételek segítségével (elofizeto neve, irányítószám, címe, gázóraállás leolvasásának dátuma) kilistázhatja az adatbázis tartalmát (lásd lekérdezo lap) a List gombra kattintva. § Új elofizetot vehet fel: Kitöltve az elofizeto nevét, irányítószámát és címét, új elofizetot vezethet be a szerver adatbázisba az Add New gombra kattintva. 16. ábra: Admin felület, keresés 59 17. ábra: Admin felület, új elofizeto felvétele 60 Lekérdezo lap A lekérdezo lap egy keresés eredményét tartalmazza. A lap tetején a felhasznált szurofeltételek láthatók, alatta pedig a feltételeknek megfelelo gázóraállások, elofizeto szerint csoportosítva,

azon belül dátum alapján rendezve. A lekérdezo lapon az adminisztrátor kezdeményezheti egy elofizeto adatainak megváltoztatását vagy az elofizeto törlését az adatbázisból a Change gomb megnyomásával. 61 Adatmódosító lap Az adatmódosító lapon az adminisztrátor két teendot láthat el: § Megváltoztathatja egy címhez tartozó elofizeto nevét (tulajdonoscsere esetén) a Rename gomb használatával. § Törölheti a címet és az összes hozzá tartozó gázóraállást az adatbázisból (gáz szolgáltatás beszüntetése esetén) a DELETE gomb használatával. 62 Kliens felhasználói felület Elofizeto lista Ez az alapképernyo fogadja a felhasználót a program indítása után. A képernyo egy listát tartalmaz a kliens adatbázisában tárolt elofizetok nevérol és címérol. A lista egy sorában felül található a cím, alul az elofizeto neve, és jobb oldalon pipa jelzi, ha az illeto gázórája legutolsó szinkronizálás óta már le

lett olvasva. § Options: az Options képernyo felhozatala § Back: kilépés a programból Opciók § Edit Value: A felhasználónak lehetosége van egy elofizeto gázóraállását bevinni a kliens adatbázisába § Start Synchronising: A szerverrel való adat- szinkronizálás megkezdése. § Settings: Beállítások képernyojének behozatala. Gázóraállás bevitele Ezen a képernyon a felhasználó bevezethet egy leolvasott gázóraállást a kliens adatbázisba. 63 Szinkronizálás A fomenü Start Synchronising menüpontját választva elindul a szinkronizálás. A felbukkanó ablak akkor tunik el, amikor a szinkronizálás befejezodött. Beállítások A kliens munkakörzetének (irányítószám) beállítása A szerver IP címének beállítása 64 9. Értékelés, továbbfejlesztési lehetoségek Értékelés A feladat alapvetoen a különbözo technológiákkal való megismerkedést szolgálta, amelyek a következok voltak: Java2 Enterprise

Edition: Enterprise JavaBeans, Servletek; a Symbian operációs rendszer; valamint e két teljesen különbözo világ közti kapcsolódási lehetoségek. Nem volt cél tehát a Gázmuvek számára egy teljes funkcionalitású, muködo rendszert szolgáltatni. Az elkészült rendszer egy jól muködo vázat nyújt hasonló alkalmazások számára, amelyek ugyanezekkel a technológiákkal kívánnak valamilyen funkcionalitást megvalósítani. Látható, hogy a megvalósított rendszer skeleton-jára rengeteg féle applikáció felépítheto. Mivel a rendszer viszonylag egyszeru adattípusokkal dolgozik, valamint a szinkronizációs lépések is viszonylag egyszeruek, nem volt érdemes a SyncML ajánlásokat használni, tekintve foként azt, hogy ehhez még egy teljes XML parsert is meg kellett volna valósítani. A kommunkiáció lebonyolításához itt a saját protokoll, és a szöveg alapú megközelítés is elegendo volt. Bonyolultabb adattípusoknál

megfondolandó az XML alapú leírás, csakúgy, mint ahogy bonyolultabb szinkronizálási folyamatok ábrázolásánál megfontolandó a SyncML használata. Továbbfejlesztés A feladat továbbfejlesztését több oldalról is meg lehet közelíteni: Elsosorban boven lehet fejleszteni, ha azt akarjuk, hogy a valóságot jobban modellezze. Valójában nagyságrendekkel bonyolultabb modellt kéne ahhoz alkotni, hogy egy valós rendszer minden részletét le tudja fedni. Egy valós rendszerben például nem elég irányítószám szerint szétosztani a feladatot, hanem valahogyan utcacsoportokat kell egy-egy leolvasóhoz rendelni. Másrészt lehet magát a technológiát fejleszteni, amely egyébként a modell fejlesztése után elengedhetetlenné is válik. Legkézenfekvobb fejlesztési terület a szinkronizáció SyncML kompatibilissé tétele. Ez mindkét oldalon megnöveli a szoftver bonyolultságát, legalábbis a szinkronizációs részt nézve, viszont bonyolultabb

szinkronizációs muveletekhez nagy segítséget is jelent het a SyncML bevezetése. 65 Természetesen egy valódi rendszerben az adatokat bizalmasan kellene kezelni. Ez vonatkozik mind a szinkronizáció lépésére, mind pedig a leolvasott adatok szerveren való tárolására. Jelenleg a bizalmasság nem volt cél, így az adatok bárki által olvasható formában tárolódnak és továbbítódnak szinkronizációkor. Az adminisztrációt lehetové tevo felület is ad lehetoséget a fejlesztésre. Létrehozhatunk változatosabb lekérdezéseket, vagy lehetne egyszerre manipulálni elofizetok egy csoportjának adatait is. Igaz, a diplomamunkának ez a része tulajdonképpen kiegészíto jellegu, lazábban kapcsolódik csak a témához, valójában csak azért szükséges, hogy a rendszer muködését be lehessen mutatni. 66 10. Rövidítésjegyzék A dokumentumban szereplo rövidítések feloldása a következo: HTML HTTP IDE J2EE J2ME SQL UI PDA EJB ASP PHP XML SOAP CLR IL

JIT CTS API JNDI JDBC JMS RMI JTA SMTP POP3 WAP MMS GSM GPRS CSD IrDA Hypertext Markup Language Hypertext Transfer Protocol Integrated Developing Environment Java 2, Enterprise Edition Java 2, Micro Edition Structured Query Language User Interface Personal Digital Assistant Enterprise JavaBeans Active Server Pages PHP Hypertext Preprocessor eXtended Markup Language Simple Object Access Protocol Common Language Runtime Intermediate Language Just In Time Common Type System Advanced Programming Interface Java Naming and Directory Interface Java DataBase Connectivity Java Messaging Service Remote Method Interface Java Transaction API Simple Mail Transfer Protocol Post Office Protocol 3 Wireless Application Protocol Multimedia Messaging Service Global System for Mobile telecommunications General Packet Radio Service Curcuit Switched Data Infrared Data Association 67 11. Irodalomjegyzék [1] DIGIA Inc. - Programming for the Series 60 Platform and Symbian OS, Wiley, 2002 Fejlesztoi

kézikönyv, Symbian programozás kifejezetten Series 60 platformra [2] Michael J. Jipping – Symbian OS Communications Programming, Wiley Fejlesztoi kézikönyv, Symbian kommunikációs programozás [2] http://javasite.bmehu/dokument/servlets/ Szervletek programozása [3] http://www.elementkcom/downloads/ms net dev overpdf .NET átfogó ismerteto [4] www.syncmlorg SyncML specifikáció 68 12. Függelék 12.1 Egy szinkronizáció menete Ez a függelék egy példa a szinkronizáció menete alatt folyó adatforgalomra a mobil kliens és a szerver között. Kliens ⇒ Szerver 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. POST /gaz/gaz HTTP/1.0 Content-Type: text/plain; charset=UTF-8 Content-Length: 81 -------Itt kezdodik a content------1 1125 2 1423 3 1345 4 2623 6 1734 7 1432 8 1632 11 1642 16 1462 17 2453 18 1542 Az elso sor a http kérést tartalmazza. Ez határozza meg, hogy a csomag a

szervlethez kerüljön. A második sor jelöli, hogy szöveges formátumról van szó, valamint azon belül is UTF-8 kódolású szöveget viszünk majd át. A harmadik sor megadja a content hosszúságát byte-okban. 69 A 4- ik sor elválasztja a headert a content-tol. A content-ben minden elso sor egy elofizeto ID-t tartalmaz, minden második pedig az elofizetohöz tartozó gázóra leolvasott állását. Szerver ⇒ Kliens 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 200 OK Content-Type: text/plain; charset=UTF-8 Content-Length: 195 -------Itt kezdodik a content------32 ADDNEW 20 17 Városkúti út 13/b 11 Kiss Gézáné ADDNEW 21 19 Dagydiófa utca 13/b 10 Nagy Lajos ADDNEW 20 17 Városkúti út 13/b 11 Kiss Gézáné DELETE 13 DELETE 15 DELETE 16 DELETE 18 RENAME 2 14 Herczeg Ferenc RENAME 3 12 Iczók Eszter RENAME 6 11 Révay Tamás Az elso sor a sikeres HTTP tranzakciót jelöli. A 2-4 sor jelentése ugyanaz, mint az elozo esetben. Az 5. sor a

szerver jelenlegi verziószámát tartalmazza Az 6-8 sorokban az olvasható, hogy három új elofizetot adtak az adatbázishoz legutolsó szinkronizálá s óta. A következo 4 sor jelentése, hogy négy elofizetot töröltek az adatbázisból. Végül három elofizeto átnevezését is jelzi az adatfolyam 70 12.2 A Symbian alkalmazás osztálydiagramja Az itt feltüntetett osztályok a Symbian alkalmazás szerkezetét mutatják be. Helyhiány miatt nincs jelölve minden osztály összes függvénye és tagváltozója, csak a lényeges elemek. CHeatMeter2App: public CAknApplication CEikAppUi* CreateDocume ntL (); CHeatMeter2Document: public CAknDocument CEikAppUi* CreateAppUiL(); CHeatMeter2AppUi: public CAknAppUi CHeatMeter2View* view1; CSettingListbox *iListBox; void HandleCommandL(TInt aCommand); virtual TKeyResponse HandleKeyEventL(TKeyEvent& aKeyEvent,TEventCode aType); CSettingListBox: public CAknSettingItemList TInt* iZip; TInetAddr* iServer; void SetData(TInt*

aZip, TInetAddr* aServer); CHeatMeter2View: publicCAknView MContainerObserver CHeatMeter2Container* iContainer; virtual void SynchReady(); virtual void SynchFailed(); void HandleCommandL(TInt aCommand); void DoSettings(); CHeatMeter2Container: public CCoeControl, MCoeControlObserver, MContainerObserver CDataBase *iHeatMeterDatabase; TInetAddr iServerAddr; CArrayFixFlat<TInt> *iValues; CArrayFixFlat<TInt> *iIDs; CDesCArray* iItemArray; MDbObserver void Synch(); void EditCurrentValue(); void SynchReady(); void SynchFailed(); Virtual void ResponseReceived(TDesC8 &aResponse); CDataBase: public MDbObserver TInt iClientID; CGprsClient *iGprsClient; MContainerObserver *iCallBack; void UpdateItemValue(TInt aID, TInt aState); void Synch(TInetAddr& aIpAddress, TDesC& aPath); void FillArrays(CDesCArray* aListBoxArray, CArrayFixFlat<TInt> aValues, CArrayFixFlat<TInt> *aIDs); void ResponseReceived(TDesC8 &aResponse); CGprsClient: public CActive

MDbObserver *iCallb; TBool IsConnected(); TBool IsBusy(); void SendL(TInetAddr &iIpAddress, const TDesC8& aDesc); 71