Možnosti využití balíčku Wireless Messaging API na platformě Java ME

Transkript

1 Rok / Year: Svazek / Volume: Číslo / Number: Možnosti využití balíčku Wireless Messaging API na platformě Java ME Possibilities of the Wireless Messaging API package for Java ME usage Lukáš Růčka rucka.lukas@phd.feec.vutbr.cz Fakulta elektrotechniky a komunikačních technologií VUT v Brně Abstrakt: Článek se zabývá problematikou využití volitelného balíčku WMA (Wireless Messaging API) na platformě Java ME (Micro Edition). Je popsána architektura platformy Java ME, bezpečnostní model platformy a vlastnosti balíčku WMA. Za pomoci zkušební implementace jsou ukázány možnosti použití a omezení balíčku WMA. Abstract: The article deals with the possibilities of usage an optional package, WMA (Wireless Messaging API) for Java ME (Micro Edition). It is described the architecture and security model of Java ME platform and features of the package WMA. On the experimental implementation are shown the possibilities and limitations of the usage of the optional package WMA.

2 MOŽNOSTI VYUŽITÍ BALÍČKU WIRELESS MESSAGING API NA PLATFORMĚ JAVA ME Ing. Lukáš Růčka. Ústav Telekomunikací Fakulta elektrotechniky a komunikačních technologií, Vysoké Učení Technické v Brně Purkyňova 118, 61200, Brno, Česká republika rucka.lukas@phd.feec.vutbr.cz Článek se zabývá problematikou využití volitelného balíčku WMA (Wireless Messaging API) na platformě Java ME (Micro Edition). Je popsána architektura platformy Java ME, bezpečnostní model platformy a vlastnosti balíčku WMA. Za pomoci zkušební implementace jsou ukázány možnosti použití a omezení balíčku WMA. JVM (Java Virtual Machine), 1. ÚVOD DO PLATFORMY JAVA MICRO EDITION aplikační programové rozhraní (Java Core Application Programming Interface), Platforma Java ME (Micro Edition) byla původně vyvíjena pro spotřební elektroniku [3]. Důvodů proč pro malá zařízení nebyla použita v té době již rozšířená Java SE (Standard Edition), je několik. Hlavním důvodem byly specifické vlastnosti zařízení, pro která je Java ME určena. A to především v oblasti výpočetního výkonu, nároků na paměť, ovládání a přístupu k uživatelskému rozhraní. Platforma Java ME klade určité minimální požadavky na zařízení, jimiž jsou například typ procesoru, velikost paměti RAM (Random-Access memory) a paměti ROM (Read-Only Memory). Splní-li zařízení požadavky, anebo je dokonce přesahuje, pak je zaručeno, že bude aplikace vytvořená pomocí Java ME, pro kterou jsou tyto splněné požadavky dostačující, fungovat korektně. Asi největší uplatnění dnes nachází platforma Java ME v mobilních zařízeních (např. mobilní telefon). Podporuje-li mobilní zařízení platformu Java ME, pak je možné díky této podpoře rozšířit vlastnosti tohoto zařízení o další funkce v podobě aplikace naprogramované v jazyce Java. Od svého uvedení na trh se platforma Java ME neustále vyvíjí, zdokonaluje a přizpůsobuje požadavkům doby. Lze říci, že dnes největší oblastí rozšíření platformy Java ME jsou mobilní telefony. Obecně platí, že všechny dnešní mobilní telefony nižší střední třídy a výše, obsahují podporu platformy Java ME, byť je tato podpora u jednotlivých mobilních telefonů rozdílná. Java je platformě nezávislý programovací jazyk. Nezávislost na platformě a na hardwaru zařízení zajišťuje způsob kompilace. Zdrojové kódy při kompilaci programu nejsou, na rozdíl od kompilovaných jazyků, překládány do strojového kódu procesoru, ale pouze předzpracovávány do tzv. bytekódu [1]. Při překladu zdrojového kódu do bytekódu jsou provedeny časově náročné fáze kompilace. Spuštěním přeloženého programu (bytekódu) napsaného v jazyce Java, je bytekód rychle převeden na strojový kód daného procesoru. Tuto činnost provádí JVM (Java Virtual Machine). Platformu Java ME představila v červnu 1999 firma Sun Microsystems, Inc. na konferenci Java-One jako mladšího bratříčka produktů Java SE a Java EE (Enterprise Edition). skupinu knihoven závisejících na použité konfiguraci, profilu a volitelných balíčcích. JVM se skládá z runtime systému, což je část realizující vazbu na hardware, a interpretu, který vykonává bytový kód. Java Core API (Application Programming Interface) je soubor základních knihoven pro psaní programů. Výhodou tohoto řešení je, že tyto knihovny nemusí být distribuovány s programem. Prakticky to znamená, že aplikace obsahují pouze kód napsaný programátorem. Proto mají přeložené aplikace relativně malou velikost 1. Hlavním elementem modulárního designu platformy Java ME je skupina knihoven závisejících na použité konfiguraci, profilu a volitelných balíčcích [8]. Díky těmto elementům je možné podporovat širokou škálu zařízení. Vlastnosti platformy Java ME jsou standardizovány pomocí JSR (Java Specification Request). Na obrázku 1 je zobrazena koncepce vrstev platformy Java ME. Nejníže leží samotný hardware zařízení. Nad ním pracuje nativní operační systém. Nad operačním systémem pracuje konfigurace, která je v podstatě složena z JVM a sady knihoven. Tyto knihovny jsou pro danou konfiguraci považovány za základní. Nad toto je postaven jeden nebo několik profilů spolu s volitelnými balíčky a specifickými třídami. Každý profil obsahuje rozšiřující sadu knihoven, jež poskytují rozhraní aplikační vrstvě. Nejvýše stojí samotná Java ME aplikace. 2. ARCHITEKTURA JAVA ME Z obecného pohledu Java ME definuje následující hlavní komponenty [4]: Obr. č. 1: Koncepce vrstev platformy Java ME 1 Ve srovnání s kompilovanými programy, které nevyužívají framework 33-1

3 3. KONFIGURACE A PROFILY PLATFORMY JAVA ME Konfigurace je specifikace, která identifikuje úroveň systému zařízení. Zároveň definuje minimálně podporované rysy jazyka Java, charakteristiky a rysy JVM a charakteristiky a rysy základních knihoven. Konfigurace definuje v rámci Java ME platformy minimální požadavky na rodinu zařízení. Členové jedné rodiny mají podobné požadavky na úroveň systémových zdrojů. Díky tomu mohou vývojáři software očekávat jistou úroveň systémové podpory dostupnou pro jednu kategorii zařízení, která používá danou konfiguraci. Výrobci zařízení implementující určitý profil umožňují být dané kategorii zařízení kompatibilní s jinými zařízeními té samé kategorie. Profily specifikují rozhraní aplikační úrovně pro určitou třídu zařízení, která je specifická svými vlastnostmi (např. dotykový displej). Implementace profilu zahrnuje další sadu knihoven jazyku Java, které poskytují rozhraní aplikační vrstvě. Profil tak může teoreticky specifikovat všechny druhy funkcionalit a služeb zařízení. Typicky profil obsahuje knihovny, jež jsou mnohem více specifické pro charakteristiku kategorie daných zařízení. Aplikace, která v architektuře stojí úplně na vrcholu, může využívat pouze knihoven a tříd, jež jí poskytují pod ní ležící vrstvy (profil, volitelné balíčky, konfigurace). Profilů může být v rámci jednoho zařízení použito několik. Avšak konfigurace může být použita pouze jedna. Zjednodušeně lze říci, že konfigurace definuje minimální Java běhové prostředí (kombinace JVM a sadu API) pro určitou rodinu zařízení. Profil definuje sadu API, která jsou přidána ke konfiguraci, aby bylo lépe využito specifických vlastností daného zařízení [8], [4] CONNECTED LIMITED DEVICE CONFIGURATION Java ME v současné době definuje dvě konfigurace pro zařízení. Jsou jimi konfigurace CDC (Connected Device Configuration) a CLDC (Connected Limited Device Configuration). Hranice mezi těmito dvěmi konfiguracemi není ostrá. Díky technickému pokroku a snaze výrobců o komplexní zařízení, se bude současná hranice ještě více rozmazávat. Je možné, aby jedno zařízení podporovalo obě konfigurace. Jak ale bylo zmíněno výše v textu, v rámci jednoho zařízení může být použita pouze jedna konfigurace. Ve velice hrubém rozdělení lze říci, že určující rozdíl mezi konfiguracemi CLDC a CDC spočívá především v nutném minimálním množství paměti, kterou musí zařízení disponovat a v tom, zda je v zařízení přítomna či nepřítomna baterie a uživatelské rozhraní. Konfigurace CLDC je určena pro malá zařízení, mezi která patří mobilní telefony, pagery, PDA apod. Konfigurace CLDC byla navržena jako nejmenší společný jmenovatel, který lze nalézt u mnoha různých zařízení. U konfigurace CLDC neexistují žádné volitelné rysy. To znamená, že v zařízení, které podporuje CLDC konfiguraci, lze využít vše, co specifikace této konfigurace poskytuje. Konfigurace CLDC existuje ve dvou verzích. A to, jako CLDC 1.0 (JSR 30) a CLDC 1.1 (JSR 139). Téměř všechny dnes dostupné mobilní zařízení podporují konfiguraci CLDC 1.1. Verze konfigurace CLDC 1.1 je plně kompatibilní s konfigurací CLDC 1.0 a navazuje na ni. Konfigurace CLDC 1.1 předpokládá, že paměťové nároky JVM, velikost konfigurační knihovny, knihovny profilů a samotné aplikace nepřesáhnou celkově 512 kb. Konfigurace CLDC 1.1 zahrnuje zařízení, u kterých se předpokládají tyto vlastnosti [10]: nejméně 192 kb celkové velikosti paměti dostupné pro Java platformu, min. 160 kb stálé paměti (např. ROM při vypnutí zařízení musí zůstat data zachována) dostupné pro JVM a CLDC knihovny, min. 32 kb dočasné paměti pro běh JVM (např. pro heap objekty), 16 nebo 32 bitový procesor s minimální taktovací frekvencí 25MHz, zařízení je primárně napájeno z baterie (nízká spotřeba energie). Je třeba brát zřetel, že z důvodu omezených systémových zdrojů existují určitá omezení u zařízení podporující konfiguraci CLDC MOBILE INFORMATION DEVICE PROFILE Jak již bylo uvedeno výše, profily doplňují konfiguraci tak, že je výsledná aplikace lépe přizpůsobena vlastnostem dané skupiny zařízení. Protože je konfigurace CLDC určena pro velmi rozmanitou škálu zařízení, existuje zde velký potenciál pro vytvoření specifických profilů pro každou kategorii zařízení. Dnes populárním profilem je MIDP (Mobile Information Device Profile), který je určen pro mobilní telefony a pagery. Profil MIDP je klíčový element platformy Java ME. Profil MIDP v kombinaci s konfigurací CLDC poskytuje standardizované běhové prostředí pro mobilní zařízení. Bohatá sada Java API a standardizované běhové prostředí, poskytují jádro pro funkci mobilních aplikací platformy Java ME. Díky tomu stačí při vývoji aplikaci napsat pouze jednou a poté ji lze velice rychle nasadit na velké množství různých mobilních zařízení. Profil MIDP byl celosvětově akceptován jako platforma pro aplikace v mobilních telefonech. V současné době existují specifikace profilu MIDP 1.0 (JSR 37), MIDP 2.0 respektive jeho revize MIDP 2.1 (JSR 118) a MIDP 3.0 (JSR 271). Profil MIDP vyžaduje pro zaručení správné funkčnosti referenční implementaci konfigurace CLDC [16], [17], [13]. Profil MIDP 1.0 definuje mobilní zařízení, jako druh zařízení s následujícími minimální vlastnostmi: displej minimální rozlišení pixelů, minimální bitová hloubka barev 1 bit, poměr stran obrazu přibližně 1:1, 33-2

4 vstupní zařízení tlačítková nebo dotyková klávesnice, paměť 32 kb dynamické paměti pro práci Javy, 128 kb statické paměti pro komponenty MIDP, 8 kb statické paměti pro ukládání perzistentních dat z aplikací, páce v síti obousměrný (i přerušovaný) síťový provoz, s omezenou šířkou pásma. Profil MIDP se zaměřuje na následující oblasti, jež konfigurace CLDC řešila obecně: správa průběhu aplikací, uživatelské rozhraní a události, připojitelnost k síti, ukládání dat v zařízeních. U profilu MIDP 2.0 je zachována zpětná kompatibilita. Profil MIDP 2.0 je rozšíření předešlé specifikace (obsahuje stejné třídy jako profil MIDP 1.0), přičemž přidává některé vylepšení a novinky. Evolucí několika vlastností vznikla verze profilu MIDP 2.1. Obě verze jsou specifikovány v JSR 118. Proti profilu MIDP 1.0 doznaly nároky na minimální vlastnosti těchto změn [17]: paměť 128 kb dynamické paměti pro práci Javy, 256 kb statické paměti pro komponenty profilu MIDP, zvuk schopnost přehrávat tóny, ať už hardwarově či softwarově. Nové vlastnosti profilu MIDP 2.0 jsou především: podpora HTTPS (Hypertext Transfer Protocol Secure), možnost práce s multimédii, vylepšené uživatelské rozhraní, zjednodušení vývoje herního obsahu (Game API), podpora práce s RGB obrázky, ověřování důvěryhodnosti MIDletu, Push architektura, sdílené úložiště dat mezi MIDlety (MIDP 1.0 neumožňovalo MIDletu číst data jiného MIDletu), O-T-A (Over The Air). V prosinci roku 2009 byl schválen finální návrh profilu MIDP 3.0 [13]. Z pohledu výrobců mobilních zařízení se jedná teprve o nedávné schválení, a tak bude ještě několik měsíců trvat, než budou na trhu dostupná zařízení, s podporou tohoto profilu. Profil MIDP 3.0 je opět zpětně kompatibilní se staršími aplikacemi. Avšak změny uvedené ve specifikaci MIDP 3.0 jsou poměrně zásadní a snaží se reflektovat požadavky dnešní doby na moderní aplikace. Specifikace profilu MIDP 3.0 přináší řádné chování souběžně běžících MIDletů (aplikací) v oblasti přístupu k běhovému prostředí, korektní oddělení souběhu MIDletů, správně fungující správu životního cyklu MIDletu. Dále pak umožňuje běh MIDletu na pozadí bez nutnosti uživatelského rozhraní (např. MIDlet jako služba), automatické spuštění MIDletu během startu zařízení, komunikaci mezi MIDlety, buď jako přímou komunikaci mezi současně běžícími MIDlety, nebo i v podobě nepřímé komunikace, za použití zpráv. Další novinku je použití sdílených knihoven mezi MIDlety (tzv. LIBlety). Profil MIDP 3.0 také přináší rozšiřitelnost zařízení externími moduly, lepší podporu zařízení s velkým displejem, možnost vykreslování MIDletu na sekundární displej, zlepšenou správu pro perzistentní úložiště, možnost zabezpečeného perzistentního úložiště, možnost připojení vzdáleného nebo přenosného perzistentního úložiště, podporu protokolu IPv6, nové funkcionality v oblasti uživatelského rozhraní (spash obrazovky, animované obrázky, spořiče) a mnoho dalšího. Díky tomu se objevily i zvýšené požadavky v oblasti nároků na hardware. Proti profilu MIDP 2.0 doznaly nároky na minimální vlastnosti u MIDP 3.0 těchto změn: displej minimální rozlišení pixelů, minimální bitová hloubka barev 16 bitů, poměr stran obrazu přibližně 1:1, vstupní zařízení jeden nebo více z následujících vstupních mechanizmů telefonní tlačítková klávesnice, qwerty tlačítková klávesnice, dotykový displej nebo skrolovací kolečko, paměť 1 MB dynamické paměti pro práci Javy, 1 MB statické paměti pro komponenty profilu MIDP, 512 kb statické paměti pro ukládání perzistentních dat z aplikací, páce v síti jedno nebo více logických síťových rozhraní, možnost bezdrátového připojení. 4. APPLICATION MANAGEMENT SYSTEM Běh aplikace a její přechod mezi jednotlivými stavy řídí AMS (Application Management Software), někdy také označován jako (MIDlet management software). AMS je na MIDP zařízeních předinstalovaný program, který je zodpovědný za životní cyklus každé aplikace. Aplikační manažer běží neustále v systému MIDletů. Vypnutí aplikačního manažeru nastane pouze tehdy, když je vypnut celý JVM. Konkrétně je manažer aplikací zodpovědný za [19]: instalaci MIDletů, aktualizaci MIDletů, odstranění MIDletů, spuštění MIDletů, zobrazení informací o MIDletech, aktualizaci nastavení MIDletů. Manažer aplikací musí pro všechny MIDlety poskytovat provozní správu. Ta je požadována specifikací profilu MIDP. Dnes nejrozšířenější profil MIDP 2.0 požaduje: řízení aplikací interakci s uživatelem k řízení aplikací nainstalovaných na zařízení, odinstalátor interakci s uživatelem pro odinstalování aplikací (někdy je tato funkce součástí řízení aplikací), grafický instalátor umožnění interakce s uživatelem při instalaci aplikací, zjištění aplikací umožňuje uživateli zjistit pomocí O-T-A, že jsou k dispozici nové aplikace a automaticky vyvolat grafický instalátor, v případě uživatelova rozhodnutí, že si aplikaci stáhne, persistentní úložiště uložení aplikací a jejich dat napříč mnohonásobnému užití zařízení, MIDP běhové prostředí běh instalovaných MIDletů (což je v podstatě zajišťuje JVM). 33-3

5 Manažer aplikací poskytuje pro instalátor také služby jako jsou autentizace a autorizace digitálně podepsaných aplikací (podepsaných pomocí certifikátů X.509), instalační služby (parsování Java Application Descriptor souborů, extrakce informací z Java Application Descriptor souborů, extrakce zdrojů z Java Archive souborů, srovnávání informací z Java Application Descriptor a Java Archive souborů, porovnávání verzí MIDletů během aktualizace), uložení MIDletů do persistentního úložiště, automatickou inicializaci MIDletů (tzv. Push Registry), automatické testy PUSH REGISTRY Mechanizmy známé jako Push umožňují přijmout příchozí informaci asynchronně. Na rozdíl od technik synchronního dotazování, dovolují Push mechanizmy zareagovat na tuto informaci, jakmile je dostupná. Push mechanizmy jsou také proti synchronnímu dotazování méně náročné na zdroje zařízení (spotřeba akumulátoru, datové přenosy atd.), a umožňují snížit zpoždění při předání informace. Profil MIDP 2.0 přidal k ruční možnosti spuštění pomocí AMS, která existovala u profilu MIDP 1.0, další dva nové způsoby definované v knihovní třídě javax.microedition.io.pushregistry. První možností je spuštění MIDletu ve stanovený čas, druhou pak spuštění MIDletu při příchozím datovém spojení. Toto chování je v MIDP 2.0 označováno jako Push Registry [5] [6]. Profil MIDP 2.0 přinesl integraci Push Registrů nejen do AMS, ale i jejich začlenění do GCF (Generic Connection Framework). Díky tomu dostává AMS zprávy od GCF, že došlo k přijetí spojení. Po obdržení informace o příchozím spojení provede AMS kontrolu, zda parametry spojení vyhovují pravidlům, která jsou nastaveny v Push Registrech. Pokud pravidlům vyhoví, AMS spustí k pravidlům přidružený MIDlet, který se již postará o obsloužení spojení sám. Důsledkem tohoto je, že Java ME aplikace má šanci obsloužit spojení dříve, než jeho obsluhu provede nativní operační systém zařízení. Pravidla pro Push Registry můžeme rozdělit na statická a dynamická [12]. Statická pravidla pro Push Registry jsou nastavována systémem AMS při instalaci programu a jsou získávána z JAD (Java Application Descriptor) nebo JAR (Java Archive) souborů během instalace MIDletu. Statické pravidlo lze zrušit pouze odinstalováním příslušného MIDletu. Dynamická pravidla pro Push Registry jsou zapsány uvnitř kódu MIDletu, za pomoci metody PushRegistry.registryConnection(). Díky tomuto řešení lze hodnoty Push Registrů registrovat či měnit za běhu programu. Pravidlo lze také za běhu programu zrušit PushRegistry.unregisterConnection() metodou. U MIDletů spuštěných pomocí Push Registrů ve stanovený čas je možno registrovat pouze jedno Push Registry pravidlo. Z toho vyplývá, že využití statického pravidla u časově spouštěných Push Registrů nemá velký význam, neboť bychom byli omezeni pouze jedním nastaveným pravidlem, které by se zavedlo při instalaci MIDletu. Z předešlého textu vyplývá, že význam mají pouze pravidla, která jsou dynamická. Ta umožňují při spuštění MIDletu změnit parametry tohoto pravidla. Nastavení pravidel u časově spouštěných Push Registrů se provádí pomocí metody PushRegistry.registerAlarm() [6]. 5. BEZPEČNOSTNÍ MODEL PLATFORMY JAVA ME Platforma Java ME obecně klade velký důraz na bezpečnost, která je řešena na třech úrovních, kterými jsou nízkoúrovňová bezpečnost, bezpečnost typu koneckonec (end-to-end) a bezpečnost na úrovni aplikace [2]. Nízkoúrovňová bezpečnost je zajišťována na úrovni JVM, respektive jako celku v rámci konfigurace CLDC. Díky ní je zaručeno, že budou spuštěny pouze MIDety se správnou sémantikou, takže nemohou poškodit zařízení. To je zaručeno tím, že je MIDlet při překladu do bytekódu preverifikován a výsledek je uložen. Během spouštění MIDletu je tato preverifikace ověřována a pokud neodpovídá uložené skutečnosti nebo úplně chybí, je spuštění MIDletu odmítnuto. Bezpečností typu konec-konec (end-to-end) je myšleno zabezpečení komunikace (transakcí) mezi komunikujícími koncovými uzly (např. mezi klientem v podobě MIDletu a serverem umístěném mimo zařízení). Je součástí profilu MIDP 2.0, ve kterém bylo přidán typ spojení typu HTTPS. Profil MIDP 1.0 bezpečnost typu konec-konec nepodporuje [12]. Bezpečnost na úrovni aplikace je zajištěna pomocí možností, jež mají běžící MIDlety. MIDlety totiž běží v omezeném prostředí (tzv. sandbox), jehož hranice nemohou překročit. Takto se vývojáři platformy Java ME snažili chránit uživatele proti vnějším hrozbám. K jakémukoli MIDletu je přistupováno jako k nedůvěryhodnému (tzv. nedůvěryhodná doména). Toto omezené prostředí splňuje následující nároky [2]: soubory.class jsou správně verifikovány, stažení, instalace a provoz MIDletu zajišťuje standardní mechanismus (AMS), jež nemůže programátor aplikace nijak ovlivnit, aplikace může používat pouze knihovny konfigurace CLDC, profilu MIDP a OEM knihovny přidané výrobcem zařízení, sada nativních funkcí přístupná JVM je uzavřená, systémové knihovny jsou chráněny a aplikace je nesmí předefinovat, ani do nich přidávat nové třídy, aplikace může kromě standardních knihoven používat jen třídy, ze svého JAR souboru a odnikud jinud BEZPEČNOSTNÍ MODEL MIDP 2.0 Druhým bezpečnostním prvkem MIDP 2.0 na aplikační úrovni je tzv. důvěryhodnost MIDletů. Snahou 33-4

6 bezpečnostních modelů je ochránit uživatele před škodlivým softwarem. Toho je dosaženo tak, že MIDlety jsou kontrolovány v přístupu k rozhraním, jež jsou považována za citlivá, a jejich přístup k nim je řízen pomocí bezpečnostních domén. Bezpečnostní model profilu MIDP 2.0 je zpětně kompatibilní s profilem MIDP 1.0, ale oproti němu přináší možnost přesunout MIDlet z nedůvěryhodné domény do domény důvěryhodné. Toto je možno digitálním podepsání MIDletu pomocí X.509 certifikátu. Pokud takto podepsaný MIDlet při instalaci projde v pořádku všechny ověřovací mechanizmy a mobilní zařízení má zařazenu certifikační autoritu, jež vydala certifikát, jako důvěryhodnou, je MIDlet přesunut do důvěryhodné domény. Na základě domény, do které MIDlet přísluší, je poté rozhodováno, jak AMS reaguje na požadavky MIDletu při přístupu ke kontrolovaným rozhraním. Profil MIDP 2.0 definuje otevřený systém přístupových práv [14] BEZPEČNOSTNÍ DOMÉNY Bezpečnost v profilu MIDP 2.0 je složena ze dvou částí. První část obsahuje přístupová práva, která jsou MIDletu garantována a přístupová práva, která musí být konzultována s uživatelem. Druhou částí bezpečnosti v profilu MIDP 2.0 jsou kritéria nutná pro zařazení do konkrétní bezpečnostní domény. Každému MIDletu je při instalaci přidělena některá z následujících bezpečnostních domén: výrobce telefonu (manufacturer), operátor (operator), důvěryhodná doména (trusted 3rd party), nedůvěryhodná doména (untrusted 3rd party). Každé bezpečnostní doméně přísluší určitá úroveň přístupových práv ke kontrolovaným rozhraním. Například v doméně výrobce telefonu mohou být práva k určitému kontrolovanému rozhraní nastavena na vždy povoleno, kdežto v nedůvěryhodné doméně může být přístup k tomuto rozhraní zakázán. Přístupová práva jsou seskupena ve funkčních skupinách [15]. V mnoha případech, lze po digitálním podpisu MIDletu certifikátem, který mobilní zařízení zná, dosáhnout toho, že bude MIDlet spadat do důvěryhodné domény. MIDlet pak bude méně omezován v přístupu ke kontrolovaným rozhraním TYPY PŘÍSTUPOVÝCH PRÁV Podle definované politiky bezpečnostní domény v zařízení, může být nastaveno jedno z následujících přístupových práv [15]: vždy povolit (Always allow / Blanket access), zeptat se poprvé / zeptat se jednou za spuštění (Ask first time / Ask once per session), zeptat se vždy (Ask every time), bez přístupu (Not allowed). Každá z bezpečnostních domén obsahuje pro určité akce přístupová práva, která jsou vždy povolena (není tedy třeba zásahu uživatele), a přístupová práva, která musí být konzultována s uživatelem. S uživatelem konzultovaná přístupová práva existují ve třech variantách, a liší se délkou jejich trvání (v JSR nazývány jako módy interakce). Poté co se MIDlet uživatele zeptá zda povolit či zakázat úkon, má uživatel možnost vybrat z následujících variant délky doby platnosti: jednorázové povolení (oneshot) MIDP implementace si výsledek rozhodnutí uživatele nikde neukládá a ptá se kdykoli je třeba udělit povolení, povolení pro sezení (session) MIDP implementace si výsledek uživatelova rozhodnutí pamatuje, dokud není MIDlet ukončen, trvalé povolení (blanket) MIDP implementace si výsledek uživatelova rozhodnutí pamatuje trvale a je platné, dokud není MIDlet odinstalován. Na obrázku 2 je ukázán dotaz, který zobrazil emulátor programu Sun Java Wireless Toolkit for CLDC pro MIDlet, jež chce komunikovat pomocí http (Hypertext Transfer Protocol) spojení. MIDlet není podepsán žádným digitálním certifikátem, a tak spadá do nedůvěryhodné domény. Obr. č. 2: Dotaz k uživateli na udělení přístupových práv Uživatel má možnost připojení povolit, anebo zakázat. V případě, že uživatel povolí přístup, pokračuje MIDlet normálně v běhu programu podle programového kódu. V případě, že uživatel odepře přístup, programový kód způsobí výjimku SecurityException. Tuto výjimku lze v programovém kódu odchytit a zpracovat tak, aby nedošlo k narušení stability MIDletu a jeho případném ukončení v důsledku této výjimky. Následující tabulky ukazují rozdílná přístupová práva mezi jednotlivými kontrolovanými rozhraními. Stav pro nedůvěryhodnou doménu ukazuje tabulka 1, pro důvěryhodnou doménu tabulka 2. Po nainstalování MIDletu do zařízení, platí pro přístup ke kontrolovaným rozhraním sloupec, který je v tabulce označen jako stav implicitně [7]. V AMS lze tento stav změnit pouze na 33-5

7 stav, u kterého je uvedena hodnota ano. Stav, u kterého je uvedeno ne, nelze nastavit. bez přístupu zeptat se vždy zeptat se poprvé vždy povolit Internet ano ano implicitně ne SMS ano implicitně ne ne Push Registry ano ano implicitně ne Propojitelnost ano ne implicitně ano Multimédia ano implicitně ano ne Čtení uživ. dat ano implicitně ne ne Edit. uživ. dat ano implicitně ne ne Tab. č. 1: Přístupová práva ke kontrolovaným rozhraním pro nedůvěryhodnou doménu profilu MIDP 2.0 Při porovnání obou tabulek zjistíme, že při podepsání MIDletu certifikační autoritou, což způsobí přesun MIDletu z nedůvěryhodné domény do domény důvěryhodné, se téměř ve všech případech zlepší možnosti přístupu ke kontrolovaným rozhraním [12]. V praxi to znamená, že není například nutné neustále potvrzovat snahu MIDletu se připojit na Internet, ale můžeme MIDletu udělit trvalé povolení. bez přístupu zeptat se vždy zeptat se poprvé vždy povolit Internet ano ano implicitně ano SMS ano implicitně ne ne Push Registry ano ano implicitně ano Propojitelnost ano ne implicitně ano Multimédia ne ne implicitně ano Čtení uživ. dat ano implicitně ano Edit. uživ. dat ano implicitně ano ano ano Tab. č. 2:Přístupová práva ke kontrolovaným rozhraním pro důvěryhodnou doménu profilu MIDP PLATFORMA JAVA ME A VOLITELNÉ BALÍČKY Původně platforma Java ME ve své koncepci vrstev počítala pouze s konfigurací a profilem. Jak již bylo uvedeno konfigurace definuje minimální běhové prostředí (kombinace JVM a sada API) pro určitou rodinu zařízení (CDC nebo CLDC). Profil definuje sadu API, které je přidáno ke konfiguraci, aby bylo lépe využito vlastností daného zařízení. Postupným vývojem platformy Java ME, byla do koncepce vrstev začleněna třetí kategorii Java ME komponent tzv. volitelné balíčky (Optional Packages). Java ME specifikace JSR 68 definuje ve svém návrhu jako možné vrstvy konfiguraci, profily a volitelné balíčky [22]. Cílem schválení této specifikace, byla snaha předejít vytváření různých vzájemně nekompatibilních balíčků, v jejichž důsledku by aplikace přestaly být přenositelné. Volitelný balíček je vždy použit ve spojení s konfigurací, anebo profilem. Nikdy ne samostatně. Volitelné balíčky rozšiřují běhové prostředí o podporu vlastností zařízení, které nejsou dostatečně univerzální, aby byly definovány v profilu, anebo které potřebují být sdíleny různými profily. Protože jsou volitelné balíčky specifikovány skrze JCP (Java Community Process), každý má svou RI (reference implementation) a soubor nástrojů TCK (test compatibility toolkit) pro test kompatibility. Díky RI a TCK je zabezpečeno, že implementace balíčku je korektní, a nezáleží na jakém zařízení je používána. Volitelných balíčků existuje velké množství. Jako příklady volitelných balíčků lze uvést WMA (Wireless Messaging API) definované JSR 120 a JSR 205, MMAPI (Mobile Media API) definované JSR 135, Java APIs for Bluetooth definované JSR 82 a další (více viz stránky jcp.org/en/jsr). Při vývoji MIDletu se s volitelným balíčkem pracuje stejně, jako s jakoukoli jinou sadou Java tříd. Samozřejmě, že při vytvoření MIDletu, nejsou třídy z volitelných balíčků zabaleny s aplikací, protože zařízení, které podporuje dané balíčky, je již obsahuje ve svém běhovém prostředí. Tím je zaručeno, že mají MIDlety minimální velikost WIRELESS MESSAGING API WMA je volitelný balíček, který doplňuje strukturu GCF o funkcionalitu bezdrátového sdělení radiogramu. Funkcionalita radiogramu v GSM (Global System for Mobile Communications) síti se nazývá SMS (Short Message Service). Radiogram umožňuje asynchronní komunikaci podobně jako datagram v IP (Internet Protocol) síti. Balíček WMA je především učen pro zařízení podporující CLDC nebo CDC profil, jež umožňují odesílat a přijímat SMS zprávy. Rámec GCF byl definován v konfiguraci CLDC 1.0 a poskytuje širokou podporu typů připojení pro aplikační rozhraní platformy Java ME. Jedná se například o HTTP či HTTPS spojení, UDP (User Datagram Protocol) datagramové spojení, socketové spojení a další [18]. Rámec GCF je založen na zcela novém způsobu abstrakce. Výsledkem této abstrakce je, že rámec GCF neposkytuje přímo implementaci pro jednotlivé protokoly. Důležitou roli v rámci GCF představuje URI (Uniform Resource Identifier) specifikovaný v RFC URI popisuje za použití hierarchické notace umístění a přístupovou metodu zdroje v prostředí Internetu. V rámci GCF identifikuje URI koncové body a typ připojení. URI se skládá ze tří částí: schématu, adresy a volitelně seznamu parametrů. Obecný zápis URI je následující: <schéma>:<adresa>;<parametry>. Schéma identifikuje přístupovou metodu protokolu. V rámci GCF URI popisuje typ použitého připojení (socket, http, file, datagram, sms atd.). Adresa identifikuje cílovou adresu (neboli cestu ke zdroji). Formát a interpretace závisí na schématu (např. soubor.txt atd.) Adresa může volitelně definovat parametry. Parametry identifikují další informace pro sestavení spojení v závislosti na požadavcích protokolu (např. přenosovou rychlost). Balíček WMA v současné době existuje ve třech specifikacích. Jsou to specifikace WMA 1.0 (vydán v roce 2002 pod označením JSR 120), WMA 1.1 (vydána v roce 33-6

8 2003 pod označením JSR 120 Final Release 2) jež upravuje původní WMA 1.0 zahrnutím změn, které vznikly na základě schválení architektury profilu MIDP 2.0. Změny přinesly novou verzi bezpečnostního rámce a Push Registry mechanismy. Obě tyto verze umožňovaly příjem a posílání SMS zpráv a CBS (Cell Broadcast Service) zpráv v textovém, anebo binárním tvaru. K adresování bylo použito řetězců dle specifikace URI. Otevření spojení je možné buď v klientském (odesílání zpráv), anebo serverovém módu (příjem zpráv) [20]. Třetí specifikací je verze WMA 2.0 (schválena v roce 2004 pod označením JSR 205). Je rozšířením verze WMA 1.1 především o SMS zprávy složené z více částí a dále o multimediální zprávy MMS (Multimedia Messaging Service) [21]. Struktura balíčku WMA a jeho návaznost na rámec GCF, je znázorněna na obrázku 3. Jak je vidět z obrázku, rozhraní bázové konfigurace rámce GCF jsou doplňovány rozšiřujícími rozhraními profilů a volitelných balíčků. Všechny komponenty WMA jsou obsaženy v jednom balíčku javax.wireless.messaging, který definuje sadu rozhraní, které obsahují metody pro všechny požadované operace se zprávami. implementuje rozhraní MesageListener a nechá sám sebe zaregistrovat na specifickém portu jako posluchače tohoto portu. Tímto je vytvořena instance MessageConnection a lze přijímat a odesílat zprávy [11]. Balíček WMA také určuje zapouzdření zpráv, které je definováno v základním rozhraní Message. Toto rozhraní definuje metody pro nastavení a získání informací z hlavičky zpráv (nastavení cílové adresy, získání adresy z přijaté zprávy, zjištění časového razítka odeslání zprávy). Zpráva může být vytvořena za použití jednoho ze tří odvozených rozhraní: TextMessage textová zpráva, BinaryMessage binární zpráva, MultipartMessage MMS zpráva. Rozhraní TextMessage má za úkol reprezentovat textovou zprávu. V postatě pouze získává, anebo nastavuje textový řetězec ve zprávě. Instance objektů implementujících toto rozhraní jsou pouze kontejnery pro uživatelská data. Aplikace, jež nastavuje řetězec ve správě je zodpovědná za správnou délku dat ve zprávě. V případě, že je délka dat delší než jedna zpráva, je také zodpovědná za správné rozdělení do více zpráv. Pro případ, že by délka dat neodpovídala, nastala by při pokusu o odeslání zprávy pomocí metody send() výjimka IllegalArgumentException. Obr. č. 3: Struktura Wireless Messaging API Pro odesílání zpráv je použita třída Connector, jež slouží k vytvoření objektů typu Connection. Balíček WMA využívá třídu Connector pro otevření spojení, uzavření spojení a k odesílání dat přes toto spojení. Balíček WMA definuje rozšiřující rozhraní k rozhraní rámce GCF. Tyto rozšiřující rozhraní jsou nazývány MessageConnection a definují základy pro příjem SMS přes rozhraní Connection. Obsahuje metody pro příjem a posílání zpráv, a také metodu pro vytvoření nového objektu typu Message. Stav počáteční instance MesageConnection závisí na tom, zda aplikace zprávy přijímá (tzv. serverový mód), anebo zprávy odesílá (tzv. klientský mód). Chce-li být MIDlet upozorněn na příchozí zprávu pomocí Push Registů, musí nejdříve zaregistrovat sám sebe jako příjemce zpráv. Aby toto dosáhl, PODPORA BALÍČKU WMA VÝROBCI ZAŘÍZENÍ Nyní bude uveden výsledek průzkumu trhu, který se týká podpory balíčku WMA od výrobců mobilních telefonů, jež neobsahují otevřený operační systém, a které zároveň podporují platformu Java ME. Do průzkumu trhu byli zahrnuti tito výrobci mobilních telefonů: Nokia, Mototrola, Samsung, Sony Ericsson, LG Electronics. A to z toho důvodu, že procentuelně obsazují největší podíl na evropském trhu s mobilními telefony. Obecně lze říci, že pokud mobilní telefon disponuje platformou Java ME a podporuje profil MIDP 2.0, pak je ve většině případů zahrnut do specifikací mobilního telefonu také balíček WMA minimálně ve verzi 1.1 (JSR 120). A to bez ohledu na to, zda je podporována konfigurace CLDC 1.0 nebo CLDC 1.1. V případě, že specifikace mobilního telefonu obsahují kombinaci konfigurace CLDC 1.1 a profilu MIDP 2.0 nebo MIDP 2.1, je ve většině případů podporován balíček WMA 2.0 (JSR 205). Pokud mobilní telefon podporuje pouze profil MIDP 1.0 v kombinaci s konfigurací CLDC 1.0, pak v drtivé většině případů podpora balíčku WMA (JSR 120) zahrnuta není. 7. ZKUŠEBNÍ IMPLEMENTACE Pro ověření možností, které poskytuje volitelný balíček WMA, bylo navrženo řešení, které je využitelné pro příjem a odesílání SMS zpráv. Toto řešení mělo umožňovat hlasování pomocí SMS zpráv s možností automatické odpovědi hlasovacího serveru na příchozí zprávu. Z informací uvedených v předešlém textu plyne, že aby bylo možno pomocí Java ME aplikace přijmout SMS zprávu, musí tato přijímaná SMS zpráva obsahovat číslo portu. MIDlet sloužící pro příjem SMS zpráv musí na tomto portu naslouchat a v případě, že dojde takováto SMS zpráva, je MIDlet pomocí AMS na příchod upozorněn.

9 Po upozornění je MIDletu SMS zpráva předána, načež může proběhnout její zpracování. V případě, že přijímaná SMS zpráva nemá určeno číslo portu (např. běžně zaslaná SMS zpráva z mobilního telefonu nebo SMS brány), anebo je číslo portu jiné, než na jakém MIDlet přijímající SMS zprávy naslouchá, je takováto SMS zpráva MIDletem ignorována. O přijetí takovéto zprávy se postará nativní aplikace mobilního telefonu, jež je součástí firmware telefonu. Z výše uvedeného plyne, že SMS zprávy odeslané z nativních aplikací obsažených v mobilním telefonu, není možno pomocí platformy Java ME přijmout, ani s nimi jakkoli pracovat. Aby bylo možno pomocí platformy Java ME zprávu SMS přijmout, musí být SMS zprávě při odeslání dodáno číslo portu. Tohoto lze docílit s pomocí MIDletu, který pracuje v tzv. klientském módu (odesílá SMS zprávy) a používá k odesílání SMS zpráv následující URI schéma: sms://<telefonní číslo >:<číslo portu>. Proto bylo rozhodnuto, že řešení v rámci zkušební implementace bude rozděleno do několika aplikací, což zobrazuje obrázek 4. Hlavním jádrem řešení byl MIDlet SMSka, který plnil funkci hlasovacího SMS serveru. Tento MIDlet přijaté SMS zprávy zpracoval, uložil a případně na ně reagoval odesláním SMS zprávy. MIDlet byl určen pro provoz na mobilním zařízení podporující platformu Java ME a volitelný balíček WMA 2.0. MIDlet SMSka byl svázán jako sada MIDletů s MIDletem Synchronizace. Ten umožňoval spojení pomocí Internetu s ovládací aplikací SMSkaServer, jež byla vytvořena za použití platformy Java SE. Aplikace SMSkaServer umožňovala ovlivnění chování MIDletu, získání dat z MIDletu SMSka, a jednoduché zpracování dat uložených tímto MIDletem. Poslední částí řešení byl MIDlet SMSkaHlas, který využíval volitelného balíčku WMA 2.0 pro odesílání SMS zpráv (v tzv. klientském módu) s určeným číslem portu. MIDlet SMSkaHlas umožňoval hlasujícím účastníkům zasílat SMS zprávy v podobě hlasů skrze síť GSM. Tyto SMS zprávy zpracovával MIDlet SMSka [11]. SMSkaHlas GSM SMSka Synchronizace Internet možnost příjmu a automatického odesílání SMS zpráv skrze GSM síť, možnost perzistentního uložení přijatých dat v mobilním zařízení s využitím systém pro správu záznamů RMS (Record Management System), spolehlivé spojení hlasovacího SMS serveru s ovládacím rozhraním provozovaným na počítače (pomocí Internetu), přístup ovládacího rozhraním k perzistentním úložištím hlasovacího SMS serveru pomocí Internetu, vzdálené ovládání vlastností hlasovacího SMS serveru pomocí Internetu, vytvoření jednoduchého aplikačního protokolu typu dotaz-odpověď pro komunikaci mezi ovládacím rozhraním a hlasovacím SMS serverem, možnost generování jednoduché statistiky o výsledcích hlasování. Pro vývoj aplikací bylo použito integrované vývojové prostředí NetBeans IDE s podporou Mobility pack pro vývoj aplikací pro CLDC zařízení, které značně zjednodušuje vývoj aplikací pro platformu Java ME. Dále pak simulační nástroj Sun Java Wireless Toolkit for CLDC ÚSKALÍ IMPLEMENTACE A NASAZENÍ ŘEŠENÍ Balíček WMA spadá v bezpečnostním modelu platformy Java ME mezi kontrolovaná rozhraní. Chování platformy Java ME k těmto rozhraním bylo podrobně probráno v kapitole Důsledkem tohoto chování je, že v případě, kdy se rozhraní MessageConnection balíčku WMA, pokusí zavolat metodu open (otevření spojení) nebo metodu send (odeslání zprávy), je nutno s uživatelem konzultovat přístupová práva tohoto rozhraní. Tato konzultace je realizována pomocí vyvolání obrazovky, ve které je položen dotaz, a kde jsou také uvedeny možné odpovědi, což ukazuje obrázek 5. V každém MIDletu se o zobrazování a především interakci s uživatelem stará vlákno implementující rozhraní CommandListener. Tomuto vláknu se také říká hlavní nebo systémové vlákno. SMSkaServer hlasující účastník obsluha serverů Obr. č. 4: Vizualizace vztahů ve zkušební implementaci Následuje výpis nejdůležitějších vlastností zkušební implementace: rozdělení na serverovou, mobilní a uživatelskou aplikaci, Obr. č. 5: Přístup ke kontrolovaného rozhraní WMA balíčku - pokus odeslat SMS zprávu Zobrazení této obrazovky a čekání na potvrzení volby může v systémovém vláknu způsobit uváznutí 33-8

10 (tzv. deadlock). Řešení tohoto problému je relativně jednoduché. Stačí koncepci programu upravit tak, aby systémové vlákno a ostatní výkonné části kódu programu běžely každé v samostatném programovém vlákně. Takto akce, které nastanou ve výkonné části kódu, nemohou zablokovat systémové vlákno [11]. S chováním MIDletu při pokusu o odeslání SMS zpráv (zavoláním metody send) souvisí i jedno z velkých omezení, které komplikuje použití balíčku WMA k automatizovanému odesílání SMS zpráv. Tím je právě nutnost konzultace přístupových práv s uživatelem. V praxi to znamená, že aby došlo k odeslání SMS zprávy, musí uživatel každý pokus o odeslání SMS zprávy schválit potvrzením příslušné volby. Bez potvrzení této volby není zpráva odeslána. Řešení tohoto problému je však teoreticky možné díky profilu MIDP 2.1. Profil MIDP 2.1 totiž upravuje chování při odesílání SMS zpráv. V případě důvěryhodné domény [23]. Přístupová práva pro SMS zprávy jsou zobrazeny v tabulce 3. Bohužel funkčnost tohoto řešení nebylo možnost prakticky ověřit, z důvodu vysokých nákladů pro certifikaci aplikace. bez přístupu zeptat se vždy zeptat se poprvé vždy povolit SMS ano implicitně ano ano Tab. č. 3: Přístupová práva ke kontrolovaným rozhraním pro důvěryhodnou doménu profilu MIDP 2.1 Po odladění aplikace pomocí simulačních nástrojů bylo možné přistoupit k testování na skutečných zařízeních. K přenosu MIDletů na zařízení, bylo využíváno možností instalace MIDletů pomocí O-T-A. Díky testování a vyladění funkce aplikací v simulátoru, kde byla ověřena správná funkčnost, a bezchybnost řešení, se předpokládalo, že nasazení na reálné zařízení velice jednoduché a rychlé. Ve skutečnosti ovšem díky rozdílnosti vlastností jednotlivých zařízení (tzv. device fragmentation) a některým chybám v implementaci platformy Java ME v zařízeních, docházelo k chybám a nekompatibilitám programu. Tyto chyby byly odhalovány díky možnosti některých zařízení použít technologii ladění na zařízení (debug on device) [11]. Z tohoto plyne závěr, že pro zaručení bezchybné funkce aplikací na konkrétním zařízení, je v ideálním případě potřeba provést testy na každém reálném zařízení, na kterém se počítá s nasazením aplikace SHRNUTÍ Během praktického testování byly realizované aplikace mírně upraveny tak, aby bylo možné jejich nasazení na co největším počtu mobilních zařízení. Současně byly určeny minimální požadavky, při jejichž splnění je pravděpodobné, že aplikace půjde na konkrétním zařízení spustit a bude správně plnit svou funkci. Funkčnost automatizovaného SMS serveru je omezena pouze na přijímání a zpracování SMS zpráv. Realizace automatické odpovědi pomocí SMS zpráv je prakticky nemožné, z důvodu nutnosti interakce uživatele. 8. ZÁVĚR Tento článek se zaměřoval na seznámení s platformou Java ME a možnostmi příjmu a odesílání SMS zpráv na této platformě. V článku je podrobně objasněna architektura platformy Java ME, a to především s ohledem na zařízení s omezenými zdroji. Je zde také ukázána a vysvětlena modularita této platformy. Podrobně jsou vysvětleny jednotlivé vztahy mezi konfiguracemi, profily a volitelnými balíčky v rámci této platformy. V článku je také zmíněna správa běhu aplikací AMS (Application Management Software) a její návaznost na Push Registy. Podrobně je v článku diskutován bezpečnostní model platformy Java ME a profilu MIDP 2.0. V článku je ukázáno chování bezpečnostního modelu při přístupu aplikací ke kontrolovaným rozhraním. Dále jsou v článku rozebrány možnosti, vlastnosti a práce s volitelným balíčkem WMA (Wireless Messaging API), který umožňuje příjem a odesílání SMS zpráv na této platformě. Je vysvětleno začlenění balíčku WMA do modulární koncepce platformy Java ME. V článku je také diskutována podpora tohoto balíčku mezi výrobci mobilních telefonů s uzavřeným operačním systémem. Za pomoci zkušební implementace byly nastíněny možnosti použití volitelného balíčku, a také odhaleny nedostatky, které omezují použití balíčku WMA. Z článku plyne, že nutnou podmínkou pro příjem SMS zpráv pomocí Java ME aplikace, s využitím volitelného balíčku WMA, je, aby přijímaná SMS zpráva obsahovala určení portu, na který přichází, a aby přijímací aplikace na tomto portu naslouchala. Dále z článku vyplývá, že bezpečnostní model profilu MIDP 2.0 je značně omezující pro použití balíčku WMA k odesílání SMS zpráv. Tyto omezení ovšem za určitých předpokladů dokáže odstranit profil MIDP 2.1 spolu s certifikací aplikace. Prohlášení: Tento článek vznikl za podpory výzkumného projektu MSM Elektronické komunikační systémy a technologie nových generací. SEZNAM ZKRATEK A POJMŮ: API Application Programming Interface CDC Connected Device Configuration CLDC Connected Limited Device Configuration GCF Generic Connection Framework GSM Global System for Mobile Communications HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IP Internet Protocol JAD Java Application Descriptor JAR Java Archive Java EE Java Enterprise Edition Java ME Java Micro Edition 33-9

11 Java SE Java Standard Edition JCP Java Community Process JSR Java Specification Request JVM Java Virtual Machine MIDlet - Java ME aplikace pro profil MIDP MIDP Mobile Information Device Profile MMS Multimedia Messaging Service O-T-A Over The Air PDAP Personal Digital Assistant Profile RAM Random-Access Memory RI Referenční Implementaci ROM Read-Only Memory SMS Short Message Service TCK Test Compatibility Toolkit UDP User Datagram Protocol URI Uniform Resource Identifier WMA Wireless Messaging API LITERATURA [1] Sun Microsystems, Inc. Java Security Domains [online]. Poslední aktualizace [cit ]. Dostupné z URL: < ed/intro/definition.html>. [2] Bittnerová, L. J2ME a bezpečnost [online]. Poslední aktualizace leden [cit ]. Dostupné z URL: < [3] Byous, J. JAVA TECHNOLOGY: THE EARLY YEARS [online]. Poslední aktualizace duben [cit ]. Dostupné z URL: < tml>. [4] MAHMOUD, Qusay, H. Naučte se JAVA 2 Micro Edition. Praha: Grada Publishing a.s., s. ISBN [5] Marejka, R. How can a MIDlet be launched automatically? [online]. Poslední aktualizace červen [cit ]. Dostupné z URL: < ns/pushregistry/>. [6] ORTIZ, E. The MIDP 2.0 Push Registry [online]. Poslední aktualizace leden [cit ]. Dostupné z URL: < /pushreg/>. [7] Nokia. MIDP 2.0 API access rights [online]. Poslední aktualizace [cit ]. Dostupné z URL: < API_access_rights>. [8] PIROUMIAN, V. Wireless J2ME Platform Programming. USA: Prentice Hall PTR, s. ISBN [9] Sun Microsystems, Inc. JSR J2ME(TM) Connected, Limited Device Configuration Specification 1.0a Final Release [online]. Poslední aktualizace [cit ]. Dostupné z URL: /jsr030/index.html>. [10] Sun Microsystems, Inc. JSR J2ME(TM) Connected, Limited Device Configuration Specification 1.1 Final Release [online]. Poslední aktualizace březen [cit ]. Dostupné z URL: /jsr139/index.html>. [11] Růčka, L. Příjem a posílání SMS zpráv pomocí aplikace určené pro platformu JavaME. Brno, s., 1. příl. Diplomová práce na fakultě Elektrotechniky a komunikačních technologií Vysokého učení technického v Brně na ústavu Telekomunikací. Vedoucí diplomové práce Ing. Petr Kovář. [12] Kubina, T. Rozhraní pro skupinové odesílání SMS v JavaME. Brno, s., 1. příl. Diplomová práce na fakultě Elektrotechniky a komunikačních technologií Vysokého učení technického v Brně na ústavu Telekomunikací. Vedoucí diplomové práce Ing. Petr Kovář. [13] Sun Microsystems, Inc. JSR Mobile Information Device Profile Specification 3 Final Release [online]. Poslední aktualizace [cit ]. Dostupné z URL: /jsr271/index.html>. [14] KNUDSEN, J. Understanding MIDP 2.0's Security Architecture [online]. Poslední aktualizace únor [cit ]. Dostupné z URL: < /permissions/>. [15] Nokia. Java Security Domains [online]. Poslední aktualizace [cit ]. Dostupné z URL: < rity_domains>. [16] Sun Microsystems, Inc. JSR Mobile Information Device Profile (MIDP) Specification 1.0a Final Release [online]. Poslední aktualizace [cit ]. Dostupné z URL: /jsr037/index.html>. [17] Sun Microsystems, Inc. JSR Mobile Information Device Profile Specification 2.0 Final Release [online]. Poslední aktualizace [cit ]. Dostupné z URL: /jsr118/index.html>

12 [18] ORTIZ, E. The Generic Connection Framework [online]. Poslední aktualizace srpen [cit ]. Dostupné z URL: < dp/articles/genericframework/>. [19] Sun Microsystems, Inc. Porting Guide, Sun Java Wireless Client Software 2.0, Java Platform, Micro Edition [online]. Poslední aktualizace květen [cit ]. Dostupné z URL: < 2.0-web/docs/PortingGuide-html/index.html>. [20] Sun Microsystems, Inc. JSR Java Wireless Messaging API Specification 1.0 Final Release [online]. c2002. [cit ]. Dostupné z URL: /jsr120>. [21] Sun Microsystems, Inc. Wireless Messaging API 2.0 Specification 2.0 Final Release [online]. Poslední aktualizace [cit ]. Dostupné z URL: /jsr205/index.html>. [22] GIGUERE, E. J2ME Optional Packages [online]. Poslední aktualizace prosinec [cit ]. Dostupné z URL: < dp/articles/optional/>. [23] Nokia. MIDP 2.1 API access rights [online]. Poslední aktualizace [cit ]. Dostupné z URL: < API_access_rights>