Remoting na platformě mobilní Javy

Transkript

1 Univerzita Hradec Králové Fakulta informatiky a managementu Remoting na platformě mobilní Javy Diplomová práce Ondřej Berger duben 2009

2 Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informatiky a kvantitativních metod Remoting na platformě mobilní Javy Diplomová práce Autor: Ondřej Berger Informační management Vedoucí práce: Mgr. Tomáš Kozel, PhD. Hronov duben 2009

3 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Hronově dne Ondřej Berger

4 Poděkování Rád bych na tomto místě poděkoval Mgr. Tomáši Kozlovi, Ph.D. za vedení této diplomové práce a doporučení, která mi poskytl. Dále bych rád poděkoval všem, kteří mě v mé práci podporovali a poskytli mi připomínky a rady.

5 Anotace Tato diplomová práce Remoting na platformě mobilní Javy se zabývá řešením komunikace a přenosu dat mezi serverem a mobilním zařízením disponujícím prostředím Jave ME. V první části přibližuje pojem remotingu, architekturu a prostředí, které se týká mobilních zařízení. Hlavní částí je zpracování a vyzkoušení jednotlivých metod, které lze v Jave ME použít, z pohledu vývojaře. Zabývá se způsobem použití technologií Burlap, Hessian, JSR 172, knihovny KSoap2, RMI a REST architektury, a dále skutečnostmi, které je třeba zvážit při jejich nasazení. Ukazuje řešení při serializaci a čtení objektů a zmiňuje i problematiku bezpečnosti. Na základě těchto informací lze rozhodnout, která metoda se jeví jako vhodná při řešení konkrétní aplikace. Součástí práce je modelová aplikace se všemi metodami a možným řešení serverové části s využitím současných technologií, jako je Spring framework. Annotation This thesis Mobile Java remoting is focused on communication and transferring data between computer server and mobile device with J2ME platform. First part is dedicated to a remoting, architecture and environment related to mobile devices. Main part of this thesis is dedicated to a developers view of working and trying remoting methods available on Java ME. It process using of Burlap, Hessian, JSR 172, KSoap2 library, RMI and REST approach. It means facts to consider their usage. Shows how to use this methods to serialize a read objects as well as security. From these facts can be decided which method of remoting is suitable solution for real application. A part of this thesis is an exemplar application that shows using of all methods as well as possible solution of server using modern technologies like Spring framework.

6 Obsah Úvod Remoting Remoting na mobilních zařízeních Mobilní zařízení Prostředky mobilních zařízení Architektura řešení s mobilním klientem Přímá komunikace serveru s klientem Komunikace s využitím middleware Java ME (J2ME) CLDC konfigurace Specifikace a API Profil MIDP Volitelné balíčky CDC konfigurace Specifikace a API Profily Volitelné balíčky Remoting na J2ME klientu Burlap Implementace J2ME Burlapu Použití Burlapu Serializace dat Obsluha vyjímek a zabezpečení Hessian Implementace Hessianu na J2ME Použití Hessianu Serializace dat Obsluha vyjímek a zabezpečení J2ME Web services (JSR 172) Webové služby SOAP zpráva Webové služby na J2ME...38

7 4.3.4 JSR 172 API subset Použití JSR Obsluha vyjímek Zabezpečení ksoap Použití ksoap Serializace a deserializace komplexních objektů RMI (JSR 66) RMI na J2ME Použití RMI RMI class loader Ošetření vyjímek Zabezpečení REST architektura J2ME REST klient Ošetření vyjímek Zabezpečení Server pro J2ME klienty Nastaveni HTTPS na Apache Tomcat Burlap a Hessian server Server pro webovou službu RMI server REST server Modelový příklad Klientská část CDC CLDC Serverová část Nastavení CLDC simulátoru Nastavení CDC simulátoru Výsledky Závěr...68 Seznam použité literatury...70 Seznam obrázků...74

8 Úvod Úvod V dnešní době je nezbytné pro většinu podnikajících firem i dalších institucí mít k dispozici informační systém, který bude podporovat její podnikové aktivity a umožní jí efektivní alokaci zdrojů, řešení administrativy a podporu rozhodování. Ne všechny operace a procesy závislé na informačním systému jsou časově kritické, nicméně v případech řešení problémů přímo v terénu může být přístup k informačnímu systému prostředkem, který značně situaci ulehčí. V drtivé většině případů je k dispozici mobilní telefon, či digitální osobní asistent v kombinaci s telefonem. Signálem mobilních sítí je pokryto prakticky celé území republiky a je tak k dispozici přístup k telefonní a zároveň i datové síti. To postačuje mobilnímu zařízení, aby se s využitím vhodné aplikace mohlo připojit k informačnímu systému firmy a svému uživateli poskytnout potřebné informace. Cílem této práce je prozkoumat možné přístupy k implementaci takového mobilního klienta a jejich použití z pohledu vývojáře systému. Bude použita platforma mobilní Javy - J2ME, což je prostředí, které je dostupné v široké škále zařízení. V první části bude stručně popsán remoting obecně. Následovat bude popis mobilních zařízení, dvě základní architektury pro řešení klienta a aplikační prostředky, které poskytuje Java ME jako platforma. Největší část práce bude věnována způsobu použití vybraných metod z pohledu vývojáře - co je nezbytné pro použití metody, jak přenášet objekty, seznamy a vyjímky, jak přenos zabezpečit a jak lze vytvořit server. Následovat bude stručný popis modelové aplikace, na které jsou metody vyzkoušeny. Součástí práce je také funkční implementace mobilního klienta, který s využitím různých metod dokáže komunikovat se serverem. 8

9 1.Remoting 1. Remoting Výklad pojmu remoting může být nejednoznačný. V této práci je remotingem myšlen způsob přenosu dat (objektů) mezi komunikujícími částmi v rámci systému, v podstatě se jedná o tzv. distribuované výpočty. Ty zahrnují hardwarové a softwarové systémy, které obsahují více prvků, procesů nebo programů, které fungují a spolupracují v rámci méně nebo více řízeného režimu.[1] Cílem je propojení prvků, jejich efektivní využívání a možné rozšiřování dostupných zdrojů. Takové řešení je pak odolnější vůči selháním a je výkonnější než samostatné počítačové systémy. Distribuované výpočty pokrývají různé softwarové i hardwarové architektury, počínaje komunikací mezi procesorovými výpočetními jednotkami (CPU). Na vyšší úrovni pak je nezbytné zajistit komunikaci mezi procesy a programy, které jsou spuštěny na těchto CPU. Řešení archtiektury distribuovaných výpočtů často spadá do jedné z následujících architektur (vybráno z [1]): Klient server, kdy klientský kód žádá o data server, a tato data zobrazuje uživateli. Tří a vícevrstvá architektura umožňuje přesunout většinu logiky klientské na další vrstvy a použít tak tenkého bezstavového klienta. Clusterování zahrnuje soustavu strojů, které úzce spolupracují a paralelně sdílí běžící proces. Proces je rozdělen na části, které řeší jednotky v clusteru a které jsou nakonec složeny do konečného výsledku. Peer-to-peer proti tomu nemá žádný centrální prvek, který by řídil správu zdrojů. Všechny komunikující prvky (peers) mají stejnou odpovědnost a mohou sloužit jako server i jako klient. 9

10 1.Remoting K zajištění spolupráce se užívá některé z technik mezi-procesové komunikace, pomocí které se vyměňují data mezi procesy.([1]) Pokud procesy běží na počítačích, které jsou spojeny počítačovou sítí, užívá se často model tzv. vzdáleného volání procedur (Remote Procedure Call RPC), který umožňuje klientské straně volat metody rozhraní serveru, předávat data a získat odpověď. Existuje více způsobů komunikace, některé z nich jsou platformě nezávislé a je možné tedy komunikovat po síti mezi aplikacemi, které jsou napsané v různých jazycích jako je Java,.NET, Flash nebo třeba i JavaScript. Mezi takové patří dle [2] např.: Common Object Request Broker Architecture (CORBA), XML RPC, webové služby nad SOAP protokolem, nebo Unixové sockety. Dále existují i řešení, která nejsou interoperabilní a váží se na konkrétní platformu příp. programovací jazyk. Mezi ně patří mj.: Java Remote Method Invocation (RMI), Component Object Model (COM) od Microsoftu, resp. Distributed Component Object Model (DCOM),.NET remoting, a některé další. K řešení komunikace mezi počítači je tak k dispozici poměrně velké množství postupů a na ně vázaných protokolů. Některé z těchto metod (jako např. webové služby nebo RMI) jsou dostupné pro systémy, které vyžadují existenci i mobilních klientů, tedy prvků systému, které nejsou pevně svázány s počítačovou sítí a slouží uživatelům i pro práci v terénu. Jejich prostředky jsou omezenější a k zajištění komunikace je tak nutné řešit některé specifické otázky. 10

11 2.Remoting na mobilních zařízeních 2. Remoting na mobilních zařízeních 2.1 Mobilní zařízení Pod pojmem mobilní zařízení jsou v této práci rozuměna přenosná zařízení [3] s hardwarovými a softwarovými prostředky umožňujícím svým uživatelům zejména hlasovou komunikaci s okolím prostřednictvím bezdrátové sítě. Jedná se hlavně o mobilní telefony a kombinace mobilního telefonu s digitálním asistentem (PDA). Prakticky všechna současná zařízení zvládají kromě hlasových přenosů i přenos dat. Datové přenosy se využívají např. k procházení Internetu a odesílání ů využitím aplikací nabízených zařízením. Tyto přenosy jsou však dostupné i pro aplikace třetích stran, které lze do zařízení doinstalovávat. Nezáleží na platformě, kterou zařízení disponuje. S využitím odpovídajících vývojových prostředků je možné datově komunikovat z Windows Mobile, OS Symbian, Palm OS a také z platformy Java ME (Java Micro Edition), která je často dostupná i v zařízeních bez vlastního operačního systému. Java aplikace mohou podstatně rozšířit schopnosti zařízení a umožnit například jeho proměnu v klienta informačního systému Prostředky mobilních zařízení Mobilní zařízení nejsou plnohodnotné počítače a tedy ani plnohodnotná klientská zařízení. Prostředky, které jsou na nich k dispozici jsou např. v porovnání s notebooky (které lze v jistém smyslu také považovat za mobilní zařízení) mnohem skromnější. Komunikace s uživatelem Mobilní zařízení obvykle obsahují LCD displej s rozlišením QVGA (320x240 px 1 ),v lepším případně VGA (640x480 px). Tomuto aspektu je nutné věnovat pozornost při návrhu ovládání a zobrazení grafických prvků. Je nutné rozlišovat i způsob ovládání zařízení a tomu přizpůsobit uživatelské rozhraní. Některá zařízení disponují pouze numerickou klávesnicí doplněnou několika funkčními tlačítky. To je případ většiny současných mobilních telefonů, bez ohledu na výrobce nebo model. 1 Pixel zobrazovací bod 11

12 2.Remoting na mobilních zařízeních Zařízení vyšších tříd pro manažery, která jsou určena k častější práci v terénu mimo kancelář, pak někdy obsahují zmenšeninu QWERTY klávesnice, dotykový displej, případně oba tyto prvky. Jsou tak lépe připravena pro časté používání, jsou pohodlnější na ovládání a protože se u nich předpokládá i náročnější využití, jsou lépe vybavena po stránce hardwarové. Je zde výkonnější procesor, větší množství využitelné paměti a také lepší propojitelnost s okolím (nejen GSM sítě, ale také např. bezdrátové Bluetooth a Wi-Fi sítě). Komunikace s okolím Aby bylo možné zařízení využívat např. jako aplikačního klienta, nebo i k procházení webových stránek, je nutná podpora datových přenosů a jejich dostupnost aplikaci. Komunikace samotná probíhá v závislosti na poskytovateli služeb a možnostech zařízení. Komunikačním médiem je např. vytáčené CSD spojení, paketová data GPRS nebo EDGE, v případě pokrytí pak i sítě dalších generací 3G nebo 4G. V případě zařízení vyšších tříd je možné využít i dostupné Wi-Fi sítě. Výkon zařízení Pro vývojáře mobilních aplikací jsou, kromě způsobu ovládání a komunikace, důležité i prostředky, které zařízení nabízí a které lze v aplikaci používat. Jedná se hlavně o procesor (jeho rychlost) a dostupnou paměť. Oba tyto aspekty je při vývoji vždy nutné zohlednit a co nejefektivněji využívat. To přirozeně platí i v případě aplikací pro běžné počítače, ale v mobilních zařízeních je tento fakt mnohem kritičtější. 2.2 Architektura řešení s mobilním klientem Na rozdíl od klasického remotingu, který se užívá i k peer-to-peer spojení a řešení distribuované architektury, v prostředí mobilních zařízení je nejčastějším modelem klientserver, nebo vícevrstvé řešení. Mobilní zařízení zde vystupuje v roli klienta, který zasílá požadavky na server s mobilním rozhraním, a zobrazuje výsledky uživateli. 12

13 2.Remoting na mobilních zařízeních K výše zmíněným omezením mobilních zařízení je nutno přihlížet již při návrhu celého architektonického řešení. Nejvíce limitující je skutečnost, že mobilní zařízení disponují omezeným množstvím paměti. Druhým omezením, které souvisí s přenosem dat do mobilního přístroje, je nepředvídatelnost rychlosti, ale i dostupnosti připojení a tedy neznámý čas, který přenos zabere. Mobilní přístroj se nemusí nacházet v oblasti s pokrytím rychlými daty mobilních sítí (Wi-Fi, 3G), mohou být dostupná pouze paketová data s využitím GPRS, nebo dokonce pouze vytáčená připojení (CSD). I přenos malého množství dat tak může trvat poměrně dlouhou dobu. Oba tyto aspekty (omezenou paměť a nepredikovatelnou rychlost řádově spíše v jednotkách kb) je nutno brát v úvahu při návrhu rozhraní, které bude dostupné mobilním klientům. Bez ohledu na dva možné způsoby řešení přístupu je žádoucí maximálně omezit přenášená data. Toho lze docílit například i využitím některých z níže uvedených postupů: Zavedením zvláštních DTO 2 objektů pro komunikaci s klientem, které obsahují pouze nezbytně nutná data. Návrhem rozhraní, které umožní načítání objektů až v okamžiku potřeby na klientu (například načítání agregovaných objektů pro rodičovský objekt). Přenos s využitím protokolu, který má minimální režii při přenosu, tedy upřednostnit, je-li to možné, binární protokol před XML apod. Využitím komprese přenášených dat. Některé přístupy (např. komprese) jsou závislé na platformě, pro kterou je klient vyvíjen, a to samozřejmě ovlivní i konečný návrh. Výše zmíněné řešení komunikace mezi počítačem a mobilním přístrojem platí i pro možné architektury, které lze aplikovat při budování informačního systému s mobilním klientem. Mohou nastat v zásadě tři situace: vývoj nového systému, přidání mobilních klientů k systému existujícímu s využitím rozhraní pro jiné (nemobilní) vzdálené klienty, 2 Data Transfer Object 13

14 2.Remoting na mobilních zařízeních přidání mobilních klientů k systému, který žádné vzdáleně přistupující klienty nemá. První případ je ideální a umožňuje již v počátku návrhu počítat s limity mobilních klientů a přizpůsobit tomu celý návrh. V druhém případě je možné i bez invazivního zásahu do stávajícího systému vytvořit middleware server, který bude překládat požadavky mezi mobilním klientem a rozhraním serveru, které je připraveno pro plnohodnotné aplikační klienty. Bez nutnosti zásahu do kódu je tak možné rozšířit přístup do stávajícího sytému. V posledním případě, kdy není vystaveno žádné vzdáleně přístupné rozhraní je nutné provést úpravu stávající aplikace tak, aby zpřístupnila buď přímo odlehčené mobilní rozhraní, nebo rozhraní pro middleware Přímá komunikace serveru s klientem Toto řešení je možné snadno realizovat pouze v případě, kdy se s mobilním klientem počítá již při návrhu nového systému. Pro mobilní klienty je navrženo specializované, odlehčené, vzdáleně dostupné rozhraní a již ve fázi návrhu bussines logiky systému se připraví podmínky pro jeho využívání. Mohou zde být metody a postupy pro konverzi doménových objektů do menších transportních, řešení komprese apod. Obrázek 1: Přímá komunikace klienta a serveru Mobilní zařízení, klient, pak komunikuje přímo se serverem, bez dalších konverzí a překladů dat na cestě, zde ale mohou nastat problémy v případě vysoké zátěže serveru a je nutné zvážit i bezpečnostní hledisko tohoto přístupu. 14

15 2.Remoting na mobilních zařízeních Komunikace s využitím middleware Architekturu s využitím middleware komponent je možné realizovat jak v případě návrhu nového systému, tak i při integraci mobilních klientů do systému stávajícího, který umožňuje vzdálený přístup pro běžné aplikační klienty. Obrázek 2: Komunikace klienta s využitím middleware serveru Middleware server přebírá část zátěže způsobenou mobilními klienty a na server zasílá standardní požadavky (závisející na zvolené metodě komunikace) jako ostatní klienti. Nedochází tak k redukci zátěže co do počtu klientů, resp. požadavků, ale dochází k rozložení zátěže v oblasti konverze, kterou řeší middleware místo aplikačního serveru. 15

16 3.Java ME (J2ME) 3. Java ME (J2ME) Java Micro Edition (Java ME) je soubor specifikací a technologií, které mohou být kombinovány za účelem vytvoření platformy splňující požadavky kladené na mobilní zařízení jako jsou mobilní telefony, zabudovaná zařízení a spotřební produkty. [4] Platforma mobilní Javy (též Java Mobile, Java ME) je založena na třech elementech: konfigurace (configuration) obsahuje základní knihovny, které poskytuje JVM (Java Virtual Machine) pro co nejširší základnu zařízení, profil (profile) zahrnuje množinu API (Application Programming Interface) pro užší skupinu zařízení, a volitelné balíčky (optional packages), které poskytují API pro specifické technologie. Celá Java ME je rozdělena do dvou základních konfigurací, jednu pro potřeby malých mobilních zařízení jako jsou mobilní telefony, a druhou, která je zaměřena na výkonnější přístroje jako PDA či set-top boxy. Obrázek 3: Komponenty J2ME (převzato ze [4]) 16

17 3.1 CLDC konfigurace 3.Java ME (J2ME) Conection Limited Device Configuration (CLDC) je základní částí platformy Java ME. Zaměřuje se na standardizování vysoce přenosných zařízení s omezenými zdroji. Vývoj platformy se řídí tzv. JCP (Java Comunity Process), do kterého je zapojeno přes 500 výrobců zařízení, mobilních operátorů, dodavatelů softwaru a dalších subjektů. Mezi typická zařízení patří mobilní telefony, PDA apod. CLDC je konfigurace (viz. elemety platformy výše). Podporovaným (a prakticky jediným) profilem je tzv. MIDP - Mobile Information Device Profile. Volitelné balíčky rozšiřující funkčnost, jsou pak závislé na schopnostech konkrétního zařízení a na jeho výrobci.[5] Specifikace a API Specifikace CLDC 1.0 platformy byla schválena v srpnu 1999, a vydána jako JSR Novější verzí je CLDC 1.1, která přináší rozšíření pro novější zařízení a přidává nové funkce, zejména pak pro aritmetiku v plovoucí desetinné čárce (typy float a double). Byla vydána roku 2002 jako JSR 139 a je dostupná na většině současných zařízení. Každá Java aplikace,bez ohledu na to zda je mobilní či serverová, potřebuje ke svému běhu virtuální stroj JVM. V případě konfigurace CLDC se používají dvě varianty JVM: KVM (Kilobyte Virtual Machine) je původní, starší verze, HotSpot Implementation VM je nověji implementovaná verze virtuálního stroje, která přináší několikanásobně vyšší výkon díky částečné předkompilaci kódu. API, které nabízí CLDC 1.1 konfigurace pro vývojáře, zahrnuje úzkou podmnožinu balíčků a tříd, které nabízí J2SE 1.3 [6]: java.io Je základním balíčkem, který poskytuje třídy pro obsloužení vstupu a výstupu dat s využitím tzv. streamů (proudů). Potomci abstraktních tříd InputStream a OutputStream umožňují práci s primitivními datovými typy, děděním z tříd Reader a Writer jsou odvozeny třídy pro práci s řetězcovými proudy. Zahrnuta je i hiearchie vyjímek související se vstupem a výstupem dat (např. IOException) 3 Java Specification Request popisy jednotlivých specifikací pro celou Java platformu (nejen Java ME) 17

18 3.Java ME (J2ME) java.lang, java.lang.ref Tento balíček obsahuje objektové wrappery pro primitivní datové typy a třídy pro práci s řetězci (String, StringBuffer). Kromě toho je zde podpora pro vlákna, implementací rozhraní Runnable, nebo děděním od třídy Thread. Dále jsou zahrnuty známé vyjímky jako NullPointerException, ClassCastException a další. java.util Zahrnuje třídy pro práci s časem (Date, Calendar) a práci s kolekcemi (Vector). javax.microedition.io Tento balíček zahrnuje tzv. Generic Connection framework, tedy utility poskytující komunikaci nejčastěji prostřednictvím sítě. Jedná se o sadu rozhraní definující druh spojení (InputConnection, DatagramConnection atd.) a třídu Connector, která s využitím návrhového vzoru factory umožňuje vytvářet jednotlivé druhy spojení Profil MIDP Nad konfiguracemi stojí další rozšiřující sady knihoven a API, tzv. profily. Jak bylo zmíněno výše, v zásadě jediným profilem pro CLDC je Mobile Information Device Profile (MIDP). Profil MIDP existuje ve dvou verzích. Verze 1.0 je definována v JSR 37. Verze 2.0 (JSR 118) přináší oproti verzi 1.0 vylepšení a nové vlastnosti do oblasti multimédií a her, komunikační vylepšení a dokonalejší uživatelské rozhraní. Zachovává přitom zpětnou kompatibilitu s verzí 1.0. Tedy aplikace pro verzi 1.0 je možné spustit i v prostředí verze 2.0. Poslední zveřejněnou verzí je MIDP 2.1, která upravuje chování některých tříd, zejména třídy Canvas a některých dalších zobrazovacích a ovládacích prvků proti verzi 2.0. V API [7] profilu MIDP jsou zahrnuty i balíčky z CLDC konfigurace, které jsou v některých případech doplněny o nové třídy a rozhraní. Následující stručný přehled vybírá některé balíčky z verze

19 3.Java ME (J2ME) javax.microedition.io Tento balíček obsahuje další rozhraní, která rozšiřují možnosti připojení z CLDC balíčku. Jedná se např. o SocketConnesion, HttpConnection i zabezpečené varianty jako HttpsConnection. javax.microedition.lcdui Zde jsou obsaženy třídy pro tvorbu uživatelského rozhraní a jednotlivé vysokoúrovňové komponenty, které poskytuje přímo MIDP 2.0 a jsou dostupné bez ohledu na výrobce zařízení. (TextField, Canvas, Image). Záleží na konkrétním řešení přístroje, jak jsou komponenty implementovány. V podbalíčku game se nachází podpůrné třídy pro tvorbu her jako GameCanvas nebo Sprite, které implementují některou základní funkčnost požadovanou ve hrách jako např. animace. javax.microedition.media Balíček zahrnuje technologie a třídy přímo kompatibilní s JSR 135, tzv. Mobile Media API (MMAPI). Dodává podporu pro multimédia, audio, video. javax.microedition.midlet Jediná třída obsažená v tomto balíčku - MIDlet, definuje aplikaci pro MIDP profil, a zajišťuje interakci mezi aplikací a prostředím ve kterém běží. javax.microedition.rms Zde jsou obsaženy třídy, rozhraní a vyjímky pro zajištění perzistence dat. Třída RecordStore obsahuje kolekci uložených záznamů v podobě polí bajtů, která zůstává dostupná i přes více spuštění MIDletu. Jedná se v podstatě o jednoduchou databázi, kterou lze použít k ukládání nastavení aplikace apod. javax.microedition.pki Rozhraní Certificate a CertificateException se vztahují k mechanismům komunikace s využitím zabezpečených spojení jako je HttpsConnection nebo SecureConnection. 19

20 3.Java ME (J2ME) Volitelné balíčky Doplňující funkčnost a rozšíření konfigurace a profilů do celé J2ME platformy přinášejí tzv. optional packages, volitelné balíčky. V každém z těchto balíčků je dostupná jiná funkcionalita, kterou lze využít při vývoji mobilní aplikace. Ovšem využití může omezovat přenositelnost aplikace, protože ne všechna zařízení, která obsahují Javu, obsahují i všechny balíčky. Např. aplikace využívající Bluetooth nebude moci fungovat na zařízení bez této technologie. Zde následuje seznam některých balíčků dle [8], které jsou dostupné na CLDC. Java APIs for Bluetooth (JSR 82) Content Handler API (JSR 211) Mobile Media API (JSR 135) J2ME Web Services API (JSR 172) Security and Trust Services APIs (JSR 177) 3.2 CDC konfigurace Conected Device Configuration (CDC) zahrnuje druhou konfigurací v rámci J2ME platformy. Je cílena na spotřební zařízení jako set-top boxy, navigace, výkonná PDA apod. Pro tuto konfiguraci jsou dostupné tři profily. Základní tzv. Foundation profile, doplňující Personal Basis Profile a Personal Profile. Na rozdíl od MIDP profilu u CLDC, nenabízí Foundation profile žádné uživatelské rozhraní, pouze poskytuje sadu základních API Specifikace a API Oproti CLDC je dle [9] (kap. 7.1) zaměřena na výkonnější zařízení, která mají 32bitový procesor a min. 2MB paměti dostupné pro Java VM. Disponují obvykle také trvalým síťovým připojením do TCP/IP prostředí Intranetu nebo Internetu. 20

21 3.Java ME (J2ME) Tato konfigurace obsahuje tzv. CVM virtuální stroj. Původně akronym pro Compact Virtual Machine, ovšem nyní písmeno C neznačí nic. Schopnosti a možnosti CVM jsou blízké Java 2 Standard Edition (J2SE) 1.3. Základní rozdíly se dle [10] týkají zejména velikosti paměti a zobrazovacích možností. Konfigurace je nyní (leden 2009) ve verzi a je specifikována v JSR 218. Předchozí verze 1.0 je specifikována v JSR 36. Samotná konfigurace je zpětně kompatibilní s CLDC 1.1, nabízí tedy i stejnou strukturu balíčků. Ty jsou doplněny o některé další a také jsou v určitých případech doplněny třídy do balíčků stávajících. Následuje seznam několika vybraných balíčků, které se v CLDC nenachází.(z [11]) java.lang.reflect Přidává podporu pro reflexi v jazyce Java. Tedy možnost pracovat s třídami, metodami, atributy jako objekty, které jsou instancemi tříd Class, Method, Field atd. java.net CDC jako jedna část J2ME platformy poskytuje trvalé připojení do sítě, a v tomto balíčku se nachází třídy pro podporu komunikace. Třídy URL, Socket, Inet4Address podstatně rozšiřují možnosti CLDC konfigurace, která je jinak poměrně omezená. Přidána je také podpora IPv6 protokolu (Inet6Addres). java.security, java.security.cert Tento balíček obsahuje podporu pro zabezpečení, práci s certifikáty (pomocí tříd Certficate), hashovací algoritmy MD5 nebo SHA s využitím MessageDigest tříd. java.util, java.util.jar, java.util.zip Oproti CLDC nabízí již konfigurace CDC i podporu prakticky celého Collecion Frameworku. Přidává tak rozhraní List a jeho implementace jako ArrayList, LinkedList. Dále je doplněno i několik implementací asociativních polí s využitím rozhraní Map (HashMap, TreeMap). 21

22 3.Java ME (J2ME) Je dostupná i sada tříd pro práci se ZIP archivy (ZipFile, ZipInputStream) a také pro manipulaci s JAR soubory, což jsou aplikační balíčky a knihovny platformy Java vycházející z formátu ZIP Profily Na rozdíl od CLDC, kde existuje pouze jediný profil, na CDC jsou dostupné tři. První z nich, Foundation Profile slouží jako základ pro zbývající dva profily Personal Profile a Personal Basis Profile. Foundation Profile (JSR 219) V kombinaci s CDC konfigurací přináší tento profil kompletní prostředí pro aplikace na omezených zařízeních, která nemají a nevyžadují standardizovaný systém pro GUI 4. Může se jednat o tvorbu aplikací pro síťové tiskárny, routery, nebo enterprise aplikace. Profil má několik základních charakteristik: [12] Je založen na vyzkoušeném J2SE API, se kterým je seznámeno mnoho vývojářů, kteří tak mohou znalosti a zkušenosti s platformou znovu použít při vývoji produktů pro J2ME. Profil je připraven a laděn pro zařízení s minimem prostředků. Nemá podporu pro GUI, protože zařízení, pro která je určen, často tuto podporu nevyžadují. Pro tvorbu GUI v tomto profilu může být použito např. webové rozhraní, nebo proprietární systém, který je začleněn přímo do aplikačního prostředí (např. LCD displej). Do konfigurace CDC doplňuje některé další balíčky a třídy (vybráno z [13]) : java.io V tomto balíčku jsou doplněny zejména třídy pro práci se vstupem a výstupem řetězců. Jedná se např. o třídy CharArrayReader, StringWriter apod. 4 GUI Graphic User Interface, grafické uživatelské rozhraní 22

23 3.Java ME (J2ME) java.net Balíček pro práci se sítí je ve foundation profilu rozšířen zejména o možnost vytvoření serveru s využitím třídy ServerSocket, a dalších souvisejících tříd. java.security a podbalíčky Bezpečnostní mechanismy a třídy jsou rozšířeny o podporu přístupových seznamů (ACL Acces Control List) a mechanismy pro práci s digitálními podpisy DSA 5 a asymetrické šifrování s privátním/veřejným klíčem RSA 6. java.util a podbalíčky Tento balíček rozšiřuje dostupné API např. o implementaci návrhového vzoru observer 7 s využitím třídy Observeable a rozhraní Observer. Další doplnění se týkají např. práce s komprimačním formátem GZIP. javax.microedition.io Obdobně jako balíček z CLDC obsahuje i tento různé druhy spojení jako HttpConnection, SocketConnection a jejich zabezpečené varianty. Navíc je zde pro potřeby serverů možné instanciovat implementaci ServerSocketConnetion rozhraní a vytvořit tak aplikaci naslouchající na určitém portu. Personal Basis Profile (JSR 217) Tento profil staví nad základním profilem a přidává mu zejména podporu pro standardizované uživatelské rozhraní v podobě základních prvků AWT 8. Nezahrnuje ovšem komplexní komponenty jako jsou tlačítka, panely apod. K dispozici je pouze rámec (Frame), který je možné využít k vykreslování GUI. Využití tohoto profilu je v prostředích, kde není nutná podpora všech AWT komponent jako např. u interaktivní televize. Nabízí několik základních vlastností: [14] GUI framework pro tvorbu jednoduchých nástrojů a podporu pro tvorbu tzv. Xletů obdoba Java apletů, běžící uvnitř kontejneru AWT framework pro tvorbu GUI 23

24 3.Java ME (J2ME) Seznam některých vybraných balíčků z [15] zahrnuje: java.awt a podbalíčky Tento balíček poskytuje základní prvky pro tvorbu GUI jako je rámec (třída Frame), okno (Window), nebo grafický kontext Graphic, který poskytuje služby pro vykreslování obrázků, jejich transformace apod. java.rmi a podbalíčky Zde je zahrnuto zejména rozhraní Remote, které označuje rozhraní, jehož metody mohou být volány vzdáleně. Při chybě ve volání dochází k vyvolaní zde definované RemoteException. javax.microedition.xlet a podbalíčky V tomto balíčku a podbalíčcích jsou obsaženy třídy a rozhraní (Xlet) pro vytváření Xletů a další podpůrné třídy jako omezení (IxcPermission), nebo IxcRegistry pro zajištění komunikace mezi Xlety. Personal Profile (JSR 216) V tomto profilu je již implementováno plné AWT, které jej předurčuje do zařízení, kde je nezbytná podpora všech komponent. Tento profil je založen na Foundation profilu a zahrnuje i Personal Basis profil. Aplikace napsané pro tento profil jsou i dopředně kompatibilní s J2SE ([16], kap. General requirements). Nabízí tři druhy aplikačních modelů (způsobů vytváření a spouštění aplikací) applety, Xlety a užití metody public static void main(string []). Balíčky dostupné v tomto profilu jsou v zásadě shodné s těmi v Personal Basis profilu, ovšem jsou doplněny o nové třídy a komponenty, které zajišťují plnou podporu pro AWT (např. třída java.awt.button). Doplněny jsou navíc pouze balíčky (z [16]): java.applet Poskytuje podporu pro aplikační model appletu. Tedy třídu Applet, což je panel, který může být vložen např. do webové stránky. Informace nezbytné pro řízení appletu zajišťuje rozhraní AppletContext. 24

25 java.awt.datatransfer 3.Java ME (J2ME) V tomto balíčku je navíc doplněna zejména podpora pro schránku s využitím třídy Clipboard Volitelné balíčky Obdobně jako pro CLDC konfiguraci, i pro CDC jsou dostupné volitelné balíčky, které rozšiřují možnosti pro vývojáře přidáváním dalších funkcí. CDC RMI (JSR 66) Volitelný balíček pro Remote Method Invocation (RMI), dodává do CDC podporu pro komunikaci mezi dvěma Javovskými virtuálními stroji, které jsou navzájem dostupné po síti. Tento balíček je jedním z předmětů této diplomové práce a jedná se o metodu remotingu, která je dále vyzkoušena a popsána. CDC JDBC (JSR 169) Java Database Conectivity (JDBC) je sada definovaných rozhraní, která poskytují přístup k relačním databázím, resp. datovým zdrojům. Konkrétní implementace těchto rozhraní poskytují jednotliví dodavatelé a vývojáři databází. JDBC vrstva je tedy určitou abstrakcí nad konkrétním úložištěm, a výměnu databáze (např. PostgreSQL za DB2) lze vyřešit pouze změnou ovladače, bez nutnosti zásahu do zbývajícího kódu aplikace. 9 Tento volitelný balíček je poměrně striktně omezen. Podmnožina balíčků a tříd, která vychází z J2SE JDBC API, je tak ochuzena o některé funkce, jako je třeba connection pooling, nebo se liší ve způsobu vytváření přístupu do databáze.[17] 9 Platí pokud nejsou využívány funkce, které jiná databáze neposkytuje (např. specifické SQL dotazy) 25

26 4.Remoting na J2ME klientu 4. Remoting na J2ME klientu Cílem této kapitoly je seznámit s metodami, které lze pro remoting použít na platformě Java ME. Budou rozebrány vybrané metody, ukázány možnosti a řešení některých situací, které tyto metody a protokoly přináší z pohledu vývojáře. Výběr konkrétní metody remotingu je pak závislý na konkrétním problému, uvažovaném systému a možnostech, které jsou k dispozici, zejména v oblasti klientských zařízení. Uvedený příklad, ke kterému se vztahují ukázky kódu a konfigurací je detailněji popsán v kapitole č. 6 zabývající se modelovou aplikací. Jeho architektura a objektová struktura je založena zejména na potřebách modelového řešení, na kterém by bylo možné realizovat více možností remotingu při zachování jednoho doménového modelu objektů. Při řešení ostré aplikace by návrh probíhal s jiným cílem a tudíž i jinou výslednou architekturou, která by nezahrnovala další konverzi z přenesených objektů do doménových apod. Tato kapitola se bude zabývat řešením klientské části, možné řešení serveru bude zmíněno dále. 4.1 Burlap Burlap (doslovný překlad znamená hrubé plátno, plachtovinu nebo jutu) je jednoduchý protokol založený na XML, který lze použít pro komunikaci s webovými službami. Jedná se o malý protokol, který lze snadno používat i v prostředí J2ME, konkrétně i na CLDC konfiguraci určené např. pro mobilní telefony. [18] Za vývojem tohoto protokolu stojí společnost Caucho 10, která vyvíjí i mj. open-source aplikační server Resin, nebo implementaci jazyka PHP napsanou v Javě (projekt Quercus). Burlap jako protokol byl vytvořen, aby umožnil i nejavovským klientům a serverům možnost spolupracovat s Enterprise Java Beans (EJB). Při návrhu tohoto protokolu bylo určeno několik hlavních cílů, které nový protokol musel splnit (vybráno z [19],[20]): Dostatečně pokrýt potřeby pro podporu EJB. Používat co nejmenší možnou podmnožinu z XML

27 4.Remoting na J2ME klientu Nevyžadovat žádné externí definice schématu nebo IDL 11. Java služba by měla být dostupná jako servlet. Musí být jednoduchý a snadno testovatelný. Musí být co nejrychlejší. Vše, co je tedy potřeba řešit v tomto ohledu, je serializace a deserializace libovolných Java objektů. To zahrnuje následující požadavky: Serializace primitivních datových typů. Podpora null hodnoty. Sdílené a cyklické datové struktury. Podpora objektů, polí, seznamů a asociativních polí (map). Deserializace složených objektů. Podpora ukazatelů na vzdálené objekty (odkazy na EJBHome a EJBObject). Protokol je založen na tzv. SML (Simple Markup Language). SML je omezená podmnožina XML. Například neumožňuje používat zápis prázdného XML elementu pomocí <tag/>. Jsou povoleny pouze elementy a znaková data. Nepoužívají se atributy elementů, jmenné prostory, komentáře a další komplikovanější záležitosti jako tzv. mixed content, nebo-li smíšený obsah, kdy element obsahuje znaková data a zároveň další elementy. Element smí obsahovat buď pouze další element, nebo znaková data, nikoliv však oboje najednou. Podrobnosti a kompletní specifikaci protokolu Burlap, včetně ukázkových serializací dat, lze nalézt na [19]. Dále se tato podkapitola bude věnovat použití tohoto protokolu na J2ME platformě, konkrétně na CLDC konfiguraci Implementace J2ME Burlapu Jak vyplývá ze specifikace protokolu, je to protokol relativně jednoduchý a nenáročný a přitom s dostatečnými možnostmi. Tyto vlastnosti ho dovolují použít i v CLDC konfiguraci. 11 Interface Definiton Language popis rozhraní poskytovaného komponentou bez vazby na konkrétní jazyk, ve kterém je komponenta napsána. Např. WSDL dokumenty pro webové služby. 27

28 4.Remoting na J2ME klientu Je založen na tzv. RPC Remote Procedure Call, neboli vzdáleném volání metody. To je architektonické řešení, kdy server na veřejném rozhraní vystavuje jednotlivé funkce a metody, které lze volat, předávat jim parametry a přebírat návratovou hodnotu. Všechna volání, a předávání hodnot jsou zapouzdřena a vyjádřena pomocí vybraného protokolu, v tomto případě Burlapu. Společnost Caucho nabízí vlastní implementaci Burlap protokolu pro J2ME, která je dostupná v JAR archivu s desktopovou verzí Hessian a Burlap protokolu. Verze použitá v této práci je ke stažení na adrese %20Implementations/Download a dostupná je pod Apache licencí. Pro Java ME se jedná o balíček com.caucho.burlap.client, ze kterého stačí vyextrahovat následující třídy 12 : MicroBurlapInput MicroBurlapOutput BurlapRemote BurlapServiceException BurlapProtocolException V těchto třídách je obsažena kompletní implementace, kterou lze v J2ME používat. Burlap je protokol pro serializaci/deserializaci a implementace používá pro vstup a výstup standardní Java streamy (proudy). To umožňuje použít Burlap jak pro komunikaci přes síť, tak i pro pouhou serializaci například do textového souboru. Nejčastěji je ovšem řešena komunikace prostřednictvím sítě, proto se všechny příklady budou vztahovat pouze k ní. Jak použít serializaci do souboru, je uvedeno např. v [18], v sekci Burlap Serialization Použití Burlapu Pro vytvoření třídy MicroBurlapOutput, která zajistí serializaci objektu (případně MicroBurlapInput pro deserializaci), je nutné nejprve získat instanci příslušného streamu, který bude použit jako transport. V prostředí J2ME je často užíván protokol HTTP, který je přístupný prostřednictvím Generic connection frameworku z balíčku javax.microedition.io. 12 Je nutné použít zdrojovou distribuci JAR archivu, která obsahuje zdrojové kódy a ty zkompilovat s aplikací. Třídy z binárního archivu nelze použít na Java ME, protože jsou kompilovány pod J2SE JDK. 28

29 4.Remoting na J2ME klientu Připojení lze docílit např. následujícím fragmentem kódu, který je převzat ze vzorové aplikace, konkrétně třídy cz.berger.blog.client.impl.caucho.microburlapclient, která slouží jako abstrakce pro zjednodušení volání Burlap serveru: HttpConnection httpconn; OutputStream os; MicroBurlapOutput output; String serverurl = ;... httpconn = (HttpConnection) Connector.open(serverUrl); httpconn.setrequestmethod(httpconnection.post); os = httpconn.openoutputstream(); output = new MicroBurlapOutput(os); Nezbytné je nastavení HTTP metody na POST, protože požadavek na server (určený parametrem serverurl) je posílán v těle požadavku, a není součástí URL jako v případě metody GET. Nyní je k dispozici instance třídy MicroBurlapOutput, kterou lze využít k zaslání požadavku na server. K zaslání požadavku je nezbytné pouze vyvolání jedné metody: output.call( login, new Object[] { user, password ); První parametr udává jméno volané metody, druhý parametr je pole objektů, které volaná metoda očekává jako svoje parametry. V poli musí být argumenty volané metody v tom pořadí, v jakém jsou uvedeny v hlavičce. V daném pořadí budou deserializovány na serveru a s využitím reflexe pak předány do příslušné metody na serverovém bussines objektu. Vrací-li volaná metoda nějakou návratovou hodnotu, lze ji přečíst, a to opět v Burlap formátu. K tomu je nutné po zaslání požadavku instanciovat objekt třídy MicroBurlapInput nad vstupním streamem příslušného HTTP spojení: InputStream is; MicroBurlapInput input; 29

30 4.Remoting na J2ME klientu is = httpconn.openinputstream(); input = new MicroBurlapInput(is); Object result = input.readreply(expectedclass); V objektu result je přečtená návratová hodnota, kterou zaslal server jako odpověď na volání metody. Parametr expectedclass je objekt třídy Class, která specifikuje druh třídy, která se očekává jako výsledek volání. Bude se jednat o primitivní datové typy, případně Vector.class pro vrácený seznam, nebo Hashtable.class pro vracené obecné objekty Serializace dat Protože konfigurace CLDC nenabízí možnosti reflexivního 13 programování, jsou při serializaci nebo deserializaci jistá omezení, se kterými je nutno počítat. V případě primitivních datových typů jako jsou čísla, řetězce, nebo i např. datum je možné do parametrů metody call na třídě MicroBurlapOutput zapsat přímo tyto objekty (u primitivních datových typů je nutné použít jejich objektové wrapper třídy). Složitější situace nastává v případě komponovaných objektů (jako jsou např. instace třídy Post, z modelového příkladu). Ty obsahují více atributů, jako je nadpis, tělo příspěvku nebo seznam komentářů dalších objektů. V případě serverové strany (uvažována je opět Java, edice alespoň J2SE), která komunikuje s využitím Burlapu, je vše automatické. Příslušná třída zodpovědná za serializaci zpracuje instanci třídy Post pomocí tzv. reflexe. Projde jednotlivé atributy a do výsledného proudu zapíše objekt příspěvku jako asociativní pole mapu. Tedy vždy dvojici jména atributu a jeho hodnotu v příslušném formátu, který je dán protokolem (viz. [19]). Pokud je na klientské straně také J2SE, je opět pomocí reflexe vše vyřešeno. Pomocí zvláštního elementu v přenesené zprávě je získáno jméno třídy, kterou mapa reprezentuje. Ta je instanciována a její atributy naplněny hodnotami (v případě, že přenášené třídy splňují konvence tzv. Java Beans, tedy zejména bezparametrický konstruktor a gettery a settery pro atributy). 13 Možnosti Javy pracovat např. s objekty, atributy a metodami jako instancemi tříd Class, Field a Method. Podrobněji např. 30

31 4.Remoting na J2ME klientu U CLDC prostředí je ovšem situace jiná, reflexe zde není dostupná. Všechny objekty je nutné ručně převést na instance třídy Hashtable 14 a zpět. Hashtable je asociativní pole, obdobně jako mapa (rozhraní Map) v J2SE. Zapouzdřuje dvojice klíč-hodnota. S hodnotou lze pracovat s využitím jejího unikátního klíče. Pokud nějaký objekt obsahuje další objekty (nebo seznam objektů), i tyto samozřejmě musí být převedeny na Hashtable. V modelové aplikaci je pro tyto účely implementována třída cz.berger.blog.client.impl.caucho.basichashtableserializer. Pomocí této implementace se jednotlivé doménové objekty převádějí na Hashtable a zpět (a to včetně agregovaných objektů a jejich seznamů). V případě implementace Burlapu společnosti Caucho, použité v této práci, bylo nutné pro správné serializování objektů na server upravit zdrojové kódy třídy MicroBurlapOutput. Konkrétně na řádcích došlo k úpravě tak, aby ze zdrojové Hashtable byl zpracován zvláštní klíč (pod přidanou konstantou MicroBurlapOutput.TYPE_KEY ve zdrojové mapě), ve kterém je uloženo jméno třídy, která se serializuje. Toto jméno je pak při odesílání mapy zapsáno do odpovídajícího elementu dle specifikace protokolu Burlap. V původní implementaci se jméno třídy vůbec neserializuje a to na straně serveru přináší problémy. Objekty byly v některých případech (konkrétně třída Comment, agregovaná v třídě Post jako seznam příspěvků) instanciovány jako Hashtable, nikoliv jako třída Comment. Serializace polí, nebo seznamů objektů je v případě Burlapu bezproblémová. Jednotlivé prvky v seznamech jsou předávány do instance třídy Vector, ve které jsou pak vráceny. Pokud se jedná o obecné objekty, jsou ve výsledném seznamu opět asociativní pole (Hastable) Obsluha vyjímek a zabezpečení Při práci s třídami MicroBurlapInput a MicroBurlapOutput je nutné ošetřit i vyjímky. V případě vyjímek IOException se jedná o chybu při přenosu dat, která nesouvisí s protokolem, a většinou ji nelze ovlivnit (například výpadek spojení)

32 4.Remoting na J2ME klientu Pokud metoda na serveru, resp. na bussines objektu vygeneruje vyjímku, dojde k serializaci této vyjímky a metoda readreply vyvolá BurlapServiceException. Tato třída umožňuje získat detaily o vyjímce, ke které na serveru došlo. Konkrétně pomocí svých metod getdetail(), getcode() a getmessage() lze získat potřebné informace a náležitě vyjímku zpracovat (např. zobrazením chybové zprávy uživateli). Dalším aspektem použití protokolu Burlap je bezpečnost. Protokol sám o sobě je snadno čitelný a neobsahuje žádné šifrovací mechanizmy. Počítačovou sítí prochází jako čistý text a je snadno odposlechutelný. V případě praktického nasazení je proto nutné zajistit přenos dat skrze stream, který je již šifrovaný (eventuelně i autentizovaný vhodným mechanizmem např. HTTP basic autentizací jejíž ukázka je dostupná na Pro šifrování obsahu je na MIDP profilu dostupná implementace protokolu HTTPS (Secured Hyper Text Transfer Protocol), což je varianta HTTP, která je zabezpečená pomocí certifikátů a principů asymetrické kryptografie. Použití je velice snadné a prakticky se neliší od výše uvedené nezabezpečené varianty. Místo rozhraní HttpConnection je použito přetypování na jeho potomka HttpsConnection, které navíc poskytuje i některé informace o certifikátu a zabezpečeném spojení obecně. Toto typování ovšem není nutné. I pro HTTPS lze použít přetypování na HttpConnection. Při zadávání URL serveru je pouze nutné uvést protokol místo Jak doplnit certifikát a umožnit HTTPS pro servletový kontejner Tomcat je uvedeno v kapitole č.5, která se zabývá tvorbou serveru. Následující kód ukazuje vytvoření HttpsConnection. Další práce (získání streamů apod.) s tímto rozhraním je pak stejná jako s jeho nezabezpečenou variantou. HttpsConnection httpsconn; String serverurl = ;... httpsconn = (HttpsConnection) Connector.open(serverUrl); 32

33 4.2 Hessian 4.Remoting na J2ME klientu Stejně jako protokol Burlap, pochází i Hessian od společnosti Caucho. Na rozdíl od Burlapu je to protokol binární, ovšem slouží ke stejným účelům a to zajištění komunikace služeb s klienty. Stejně jako Burlap je i tento protokol možné použít pro tzv. RPC volání, ovšem od verze 2.0 Hessian přichází i s podporou tzv. messagingu (zasílání zpráv). Tato komunikace je asynchronní, na rozdíl od RPC, která je synchronní. Zasílání zpráv není závislé na architektuře klient-server, ani na volání metod. Na zprávy může a nemusí být zasílána odpověď a Hessian slouží pouze jako formát pro výměnu dat. Návrh celého protokolu byl podřízen obdobným požadavkům jako návrh Burlapu [21]. Jak již bylo zmíněno, protokol Hessian je binární a tedy není tak snadno čitelný pro uživatele, tak jako protokoly založené na XML. V Hessianu je možné serializovat následující data: Primitivní datové typy (String v UTF8, integer, long, double, boolean, datum v milisekundách a surová binární data), hodnotu null, pole (seznam) a asociativní pole (mapu), obecný objekt, odkaz pro sdílené objekty. Kompletní seznam, a popis serializace dat lze nalézt na [22] Implementace Hessianu na J2ME Obdobně jako v případě Burlapu, i u Hessianu 1.0 existuje řešení, která je dostupné i v prostředí CLDC zařízení. Vlastnosti protokol předurčují k obdobnému použití jako u Burlapu, ovšem protože je protokol binární, je zde menší režijní přenos a přenesená data jsou vyjádřena úsporněji. Obdobná je také realizace serveru, v podobě servletu. Na tento servlet přicházejí požadavky, které jsou zpracovávány opět ve stylu RPC. 33

34 4.Remoting na J2ME klientu Od společnosti Caucho je opět dostupná implementace pro Java ME, kterou lze stáhnout opět v jednom JAR archivu s oběma protokoly (viz. Burlap). I zde k použití stačí pouze několik tříd. Ty lze nalézt v následujících balíčcích: com.caucho.hessian.io HessianProtocolException HessianRemote HessianServiceException com.caucho.hessian.micro MicroHessianInput MicroHessianOutput Stejně jako v případě Burlapu je nutné zkompilovat tyto třídy spolu s aplikací a nepoužívat třídy již kompilované Použití Hessianu Logika tříd je obdobná jako v případě a vytvoření MicroHessianInput a MicroHessianOutput instancí je opět závislé na získání streamu. V příkladu je opět použit protokol HTTP. (Ukázky pocházejí z třídy cz.berger.blog.client.impl.caucho.abstracthessianclient). HttpConnection httpconn; OutputStream os; MicroHessianOutput output; String serverurl = ;... httpconn = (HttpConnection) Connector.open(serverUrl); httpconn.setrequestmethod(httpconnection.post); os = httpconn.openoutputstream(); output = new MicroHessianOutput(os); 34

35 4.Remoting na J2ME klientu V zásadě je zde situace stejná jako v případě Burlapu. Ovšem zaslání požadavku již s využitím implementace od Caucha není tak jednoduché. Je proto vhodné vytvořit nějakou abstrakci nad komunikačními třídami, která vývojáře odstíní od opakujících se částí kódu. Na MicroHessianOutput již není dostupná zjednodušující metoda call jako u Burlapu. Třídy týkající se Hessianu se zdají v porovnání s Burlapem nedokončené a v posledních několika vydáních se měnily pouze nepatrně. Pro vyvolání metody a předání parametrů se použije následující kód: output.startcall(methodname); output.writeobject(object); output.completecall(); Tím se na server zapíše zahájení volání metody s daným jménem, zapíše se jeden parametr a volání se dokončí. Metoda writeobject detekuje třídu zapisovaného objektu a zapíše jej tak ve správném formátu. Akceptuje i předání null hodnoty. Pro čtení odpovědi je nutné instanciovat MicroHessianInput nad příslušným vstupním proudem. InputStream is; MicroHessianInput input;... is = httpconn.openinputstream(); input = new MicroHessianInput(is); Čtení je potom opět podobné jako zápis, tedy zahájení čtení odpovědi, přečtení vráceného objektu a ukončení čtení odpovědi. input.startreply(); Object reply = input.readobject(expectedclass); input.completereply(); Jako parametr metody readobject se předává třída, která je očekávána jako vracená. 35