Integrace mobilního klienta do IS přes webovou službu

Integrace mobilního klienta do IS přes webovou službu Ondřej Berger Univerzita Hradec Králové Fakulta informatiky a managementu KIKM Hradecká 1249/6, Hradec Králové (ondrej.berger@uhk.cz) Abstrakt: Webové služby patří k populárním aplikačním komponentám pro tvorbu systémů. Následující článek se zaměřuje na srovnání a náhled na použití dvou technologií pro komunikaci s webovými službami z prostředí mobilních zařízení disponujících platformou Java pro mobilní zařízení (J2ME). Dnešní zařízení již disponují dostatečným výkonem pro zpracování XML formátu, potažmo SOAP zpráv a lze je tak využít jako klienta webové služby. Relativně snadno je pak lze integrovat do již existujícího informačního systému společnosti. V prostředí J2ME lze k tomuto účelu využít buď standardu Web Services for Mobile Devices, případně knihovny třetí strany ksoap2. Následující text je zaměřen přiblížení odlišných přístupů těchto řešení a nastiňuje základní principy použití a také srovnání řešení z pohledu náročnosti vývoje. Dále přibližuje i způsob jak řešit klienta pro REST řešení webové služby. Klíčová slova: Webové služby, J2ME, SOAP, XML, ksoap2, JSR 172, REST Abstract: Web services are popular components in information systems design. This paper will show us comparsion of two technologies from mobile devices using Java Mobile Edition. Today devices are capable of processing XML data or its application SOAP. So these devices can be used as web service clients. Their integration in existing information system is not so difficult as it used to be. For this integration can be used either Web services for Mobile Devices standard JSR 172 or third-party library ksoap2. These paper is focused on different approaches of these two technologies and shows their main usage principles. It also compares their difficulty from development point of view. Also it shows solution for REST webservice client. Keywords: Web services, J2ME, SOAP, XML, ksoap2, JSR 172, REST 1. Úvod Webové služby jsou často využívané komponenty pro umožnění vzájemné komunikace komponent informačních systémů, které navzájem spolupracují v rámci jedné organizace. Daleko častější je ovšem využití webové služby jako rozhraní, které mohou využívat jiné subjekty. Webová služba se tak stává řešením přenosu služby samotné, kterou poskytuje organizace svým klientům. Tato služba samozřejmě může být placená, zdarma či kombinací těchto možností (testovací provoz zdarma, ostrý provoz již placený apod.). V následujícím textu je pojmem webová služba míněna Webservice, tak jak ji definuje konsorcium W3C, tedy RPC model komunikace mezi aplikačními komponentami. Samostatná část je poté věnována dalšímu možnému přístupu REST. Webové služby oproti jiným metodám komunikace a výměny dat mají nespornou výhodu, kterou je otevřenost. Technologie, které mimo jiné daly i webovým službám název disponují veřejně dostupnou dokumentací a implementacemi pro různé platformy a prostředí. Patří sem zejména protokol HTTP, využívaný 114

Integrace mobilního klienta do IS přes webovou službu v dnešním Internetovém prostředí jako transport pro nejrozšířenější Internetovou službu WWW. Pomocí tohoto transportního protokolu se pak mezi komunikujícími prvky přenášejí samotná data. Ta jsou zapouzdřena do nějakého vhodného formátu, který umožňuje vyjádřit jednotlivé komunikační elementy jako je volaná metoda, její parametry, ošetření chybových stavů atd. Často se zde využívá protokol SOAP (Simple Object Acces Protocol), který je vystavěn nad známým formátem XML. Využívá tedy značkovací jazyk do značné míry čitelný i pro uživatele bez speciálních nástrojů a zároveň i se širokou podporou pro strojové zpracování. Z tohoto pohledu jsou tedy webové služby univerzální komponenty, které umožňují propojit různé heterogenní celky prostřednictvím jednotných, všude zastoupených technologií. V dnešní době nabývá na významu mobilita a využití mobilních technologií a zařízení pro řešení systémů. Jedním z klasických příkladů může být systém s mobilními klienty v podobě telefonů, či PDA, který využívají manažeři či obchodní zástupci při cestách za klienty. Díky mobilnímu zařízení má uživatel okamžitý přístup do zbytku systému, vidí aktuální data a může s nimi provádět žádoucí operace. Při otázce řešení takovéhoto systému je nezbytné uvažovat, jakým způsobem bude řešena komunikace mezi klientem a zbývající částí systému. Protože webové služby jsou (lépe řečeno většinou jsou, samozřejmě je možné využít i jiné technologie) vystavěny s využitím známých technologií, nabízí se možnost využití webových služeb k řešení mobilního spojení klienta a serveru a zároveň využití tohoto rozhraní pro ostatní (nemobilní) klienty. Kromě klasických webových služeb se v poslední době dostává i více prostoru řešení webové služby nikoliv RPC modelem (viz dále), ale pomocí zcela odlišné architektury, tzv. REST. Nabízí další možnosti, které je vhodné zvážit při uvažování o nasazení webových služeb jako komunikačního prostředku. Předmětem tohoto článku je představení řešení webových služeb v prostředí přenosných zařízení. Jako platforma mobilního klienta je uvažována mobilní verze platformy Java Java for Mobile Devices (J2ME či Java ME). Ta se nabízí zejména z důvodu vysoké zastoupenosti v současných příručních zařízeních a to bez ohledu na to, zda se jedná o zařízení s OS Symbian, hloupý telefon bez operačního systému, či výkonné zařízení s Windows Mobile nebo Android. Pod pojmem mobilní klient je tedy míněna aplikace, přistupující k serverové části aplikačního systému, která je spuštěna v prostředí mobilního zařízení. Je tedy schopna práce v terénu na všech místech s přístupem k datové síti. 2. Mobilní platforma Java Bez ohledu na využitý operační systém, či zařízení, je nutné uvažovat aspekty společné pro všechny vyvíjené mobilní aplikace (nejen v mobilní Javě). Přenosná zařízení (telefony, PDA, MDA) nejsou a nemohou s ohledem na svoje rozměry a primární určení, soupeřit s prostředími osobních počítačů a jejich možnostmi. Je nutné u nich počítat s několika základními omezeními: Výpočetní výkon není zdaleka takový jako u osobních počítačů a zpracování větších objemů dat se tak může stát dlouhotrvající operací. 115

Ondřej Berger Volná paměť je patrně nejdůležitějším aspektem celého řešení mobilních aplikací, velké paměťové struktury jako objektové hierarchie se do paměti vůbec nemusí vejít. Zobrazovací a vstupní prostředky malé displeje s nízkým rozlišením a relativně nepohodlné možnosti vstupu ať už přes klávesnici či dotykové displeje. Pokud pomineme poslední bod, protože grafické uživatelské rozhraní lze poměrně dobře přizpůsobit, jsou základními aspekty výkon a paměť, které ovlivní návrh a konečné řešení. Platforma mobilní Javy je úzkou podmnožinou standardní Javy (Java SE), tak jak je známá z prostředí osobních počítačů. V úplném základu lze Java ME rozdělit do dvou tzv. konfigurací. Každé zařízení s mobilní Javou pak disponuje jednou konfigurací, která udává základní možnosti dostupné pro aplikaci a specifikuje volnou paměť dostupnou pro každou aplikaci [1]. Určuje tak základní aplikační rozhraní (API), které může aplikace využívat. Nad konfigurací jsou vystavěné profily, které blíže definují zaměření a rozšiřují dostupné možnosti a API. Posledním prvkem jsou volitelné balíčky API, které v zařízení mohou a nemusí být přítomny a rozšiřují další možnosti aplikací například o využití rozhraní Bluetooth, GPS modulu či přístupu k adresáři s kontakty v telefonu. Java ME se tedy skládá ze dvou konfigurací: Conected Device Configuration (CDC) je zastoupena zejména ve výkonných PDA, často s prostředím Windows Mobile, a její možnosti se blíží Java SE. Conection Limited Device Configuration (CLDC) se vyskytuje ve většině ostatních zařízení (mobilních telefonů zejména) a poskytuje velice omezené základní systémové API, které je rozšířeno profilem Mobile Device Information Profile (MIDP) v současnosti ve verzích 2.0 či 2.1. Následující tabulka ukazuje některá zařízení a software, se kterými se lze setkat u mobilních telefonů. Zařízení Operační systém Java prostředí Nokia E66 Symbian S60 3rd CLDC 1.1, MIDP 2.0 HTC Touch 2 Mega Windows Mobile 6.5 CLDC 1.1, MIDP 2.0 Software Operační systém Java prostředí WebSphere Everyplace Micro Environment [2] Windows Mobile CLDC 1.1, MIDP 2.0 CDC 1.0, FP 1.0 Mysaifu JVM [3] Windows Mobile J2SE Tabulka 1: Java prostředí dostupná v mobilních zařízeních Další informace ohledně platformy Java ME a rozdělení do konfigurací, profilů a balíčků lze nalézt na oficiálních stránkách Sun Microsystems Inc. (http://java.sun.com/javame). Možnosti a schopnosti konkrétních zařízení (podporované specifikace JSR) lze nalézt např. na [4]. Pro oblast výzkumu a tohoto 116

Integrace mobilního klienta do IS přes webovou službu článku je nezbytné pouze sdělení, že celá platforma (tedy obě konfigurace) je schopná komunikace s webovou službou v kombinaci HTTP+SOAP. Tato vlastnost je umožněna díky existenci volitelného balíčku JSR 172, který definuje J2ME Web Services API (WSA). Tento balíček je dostupný pro obě konfigurace. Druhým možným řešením komunikace s webovou službou je uživatelská knihovna ksoap2. Následuje stručné zhodnocení a použití těchto knihoven včetně srovnání. 2.1 JSR 172 Volitelný balíček Web Services API je definován pomocí Java Specification Request, což je soustava popisů a specifikací jednotlivých součástí celého Java prostředí [5]. Jsou zde zpracovány prakticky všechny prvky pomocí chování tak, aby byla zjištěna možnost přenosu aplikace mezi jednotlivými operačními systémy a prostředími. Do procesu specifikace jsou zapojeni různí výrobci HW, SW a samozřejmě také společnost Sun Microsystems, nyní Oracle. Ve specifikaci č. 172 je tak popsáno API volitelného balíčku pro komunikaci s webovými službami v prostředí J2ME. Celé API je založené na podmnožině JAX- RPC 1.1 (Java API for XML RPC), tedy standardu pro volání procedur (Remote Procedure Call) s využitím formátu XML. K parsování a tvorbě XML zprávy využívá podmnožinu knihovny SAX2 (Simple API for XML). Jak bylo zmíněno výše, toto JSR využívá pouze podmnožinu celého prostředí oproti osobním počítačům, resp. oproti J2SE. Z toho vyplývají určitá omezení a vlastnosti, které celý tento volitelný balíček má: Podporuje profil WS-I Basic. Umožňuje komunikovat pouze protokolem SOAP verze 1.1. Nepodporuje SOAP zprávy s přílohami. Mobilní zařízení neumožňuje vytvořit endpoint nemůže sloužit jako server webové služby, pouze jako klient. Z těchto omezení (kompletní seznam lze nalézt na [5]) vyplývá mj. to, že mobilního klienta ve smyslu aplikace běžící na mobilním zařízení, není možné vytvořit pro všechny webové služby, ale pouze pro ty, které splňují tyto požadavky. Což je problematické pro tvorbu klienta k serveru, který není pod kontrolou vývojářů, nicméně tato situace příliš často nenastává. U vývoje interního systému je možné rozhraní uzpůsobit tak, aby vyhovovalo. Celé schéma fungování aplikace s využitím JSR 172 je uvedeno na následujícím obrázku. 117

Ondřej Berger Obrázek 1: Schéma použití webových služeb na J2ME (převzato z [3]) Aplikace mobilního klienta využívá JSR 172 API, konkrétně vygenerovanou stub třídu. Tento zástupný objekt poskytuje rozhraní pro komunikaci se serverem a deleguje svá volání na implementaci webových služeb, kterou poskytuje mobilní zařízení prostřednictvím volitelného balíčku. Komunikace pak probíhá skrze bezdrátovou síť (GSM, Wi-Fi, 3G,...) a Internet k poskytovateli služby (Service producer na obrázku). 2.1.1 Použití WSA Vývoj takovéto aplikace je relativně rychlý, pokud definované rozhraní služby splňuje všechny požadavky kladené WSA. Jak vyplývá z profilu WS-I Basics [5], je webová služba popsána tzv. WSDL dokumentem, který ve formátu XML popisuje celé rozhraní, jeho procedury s parametry a návratovými hodnotami. Tato metadata umožňují generování klientské části (přesněji části zdrojového kódu). To platí jak v případě standardní Javy, tak i J2ME. Vznikne tak výše zmíněná stub třída a pomocné třídy odpovídající jednotlivým XML elementům ve WSDL. K tvorbě stubu lze dobře využít nástrojů z vývojářské sady Wireless Toolkit (WTK). V něm je možné stub třídu vygenerovat pomocí WSDL dokumentu. Z tohoto pohledu možnosti generování se využití webových služeb jeví jako velice zajímavá možnost. V ideálním případě postačuje napsat serverovou logiku, k ní vygenerovat webovou službu (včetně WSDL), a klientskou logiku vyžadující komunikaci také vygenerovat pomocí WTK. To samozřejmě je možné, nicméně to přináší dvě základní oblasti, které je nutné vyřešit, zejména z pohledu technologického. První oblast se týká serveru webové služby, resp. vytvoření rozhraní tak, aby splňovalo omezené podmínky dané WSA. Ze zkušenosti lze říci, že toto omezení je relativně malé. Tvorba webové služby může probíhat i opačným způsobem, než-li je generování rozhraní z existujícího Java kódu (případně jiné platformy či jazyka). Je tedy možné sepsat WSDL dokument splňující WSA požadavky a na jeho základě pak vytvořit logiku serveru. Případně oba postupy vhodně kombinovat a vyzkoušet při implementaci. Tento přístup samozřejmě není možný v případě, kdy vývojáři nemají přístup k serveru služby. Možným řešením této situace je vytvoření prostředníka, serveru, který na jedné straně komunikuje s originální webovou 118

Integrace mobilního klienta do IS přes webovou službu službou a nabízí přitom pro mobilní klienty rozhraní se stejnou (či maximálně podobnou) funkcionalitou, ovšem podléhající a splňující WSA požadavky. Otázka či oblast druhá je závažnější a týká se výběru koncových zařízení. Tedy klientů služby. Ze specifikace JSR 172 vyplývá, že se jedná o volitelný balíček. To v konečném důsledku znamená, že v konečném zařízení může, ale nemusí být přítomen. Z pohledu technologie, či vývoje, to je tedy skutečnost, že neobsahuje potřebné Java třídy a balíky. Na Internetu lze sice nalézt jakýsi návod [6], jak tento balíček doplnit i do zařízení, kde není přítomen, ovšem ten nemůže fungovat již ze samotné podstaty platformy. 1 2.2 ksoap2 Při integraci klientů pro přenosná zařízení typu mobilních telefonů, která ovšem neobsahují zmíněný volitelný balíček, nelze využít JSR 172. Jedná se především o jednodušší mobilní telefony u kterých se například běžně nepředpokládá jejich náročnější využití, ovšem z nějakého důvodu nasazeny být musí např. neobsahují fotoaparát, který může být v některých organizacích zakázán z důvodů špionáže. Dalším důvodem může být skutečnost, že webová služba pracuje s protokolem SOAP verze 1.2 a nelze vytvořit výše zmíněný překladový server. V těchto situacích je možné uvažovat nad nasazením knihovny ksoap2 [7]. Tato knihovna je uživatelská a její využití je tak možné ve všech zařízeních (i těch, které nedisponují JSR 172). Ovšem daní za možnost využívat ji prakticky ve všech zařízeních je v praxi poněkud náročnější vývoj. Tato knihovna je daleko více nízkoúrovňová oproti JSR 172 a vyžaduje vyřešit přechod mezi XML zprávou ve formátu SOAP a Java objekty. Je také nezbytné řešit režijní záležitosti ohledně správy spojení. Již tento stručný popis naznačuje větší pracnost oproti JSR 172, kde jedinou prací pro komunikaci se serverem bylo zavolání příslušné metody na vygenerovaném zástupném objektu. Tato třída společně s balíčkem zajišťuje všechny potřebné úkony. 2.2.1 Použití ksoap2 Obecný postup při využívání knihovny ksoap2 je následující: 1. Vytvoření potřebných komunikačních objektů v aplikaci a předání převodníku. 2. Předání ksoap2 objektů vytvořených z aplikačních objektů knihovně ksoap2. 3. Volání serveru knihovnou ksoap2. 1 JSR 172 obsahuje i třídy, které doplňují základní java balíky java a java.lang. Do těchto balíků z bezpečnostních důvodů nemohou aplikace žádné třídy umisťovat. Pokud tedy třídy v těchto (a některých dalších) balíčcích neobsahuje přímo Java Virtual Machnie v době spouštění aplikace, nemohou být doplňeny samotnou aplikací a dojde k bezpečnostní vyjímce.v prostředí J2SE lze toto obejít ručním zásahem do instalovaného Java prostředí, to je ovšem nereálné u mobilního zařízení. Navíc v případě, že volitelný balíček komunikuje např. přes Bluetooth a neobsahuje příslušný hardware, je takovýto postup nesmyslný. 119

Ondřej Berger 4. Přijetí příchozí zprávy. 5. Předání ksoap2 objektů převodníku. 6. Vrácení aplikačních objektů. Obrázek 2: Obecné schéma použití knihovny ksoap2. Zdaleka nejdůležitější v tomto postupu je převedení, či vytvoření, objektů a tříd, které vnitřní mechanismus knihovny dokáže zpracovat a převést do podoby odchozí SOAP zprávy. (Případně pak zpětně naparsovat z XML do Java objektů.) Jedná se tedy o druhý element zleva ve výše uvedeném schématu. Tomuto procesu se bude i dále ve větší míře věnovat následující text. Pro přenosy jednodušších struktur či primitivních datových typů je možné využívat třídy dostupné přímo z knihovny. Objekty tříd SoapObject a SoapPrimitive pokrývají základní požadavky pro přenosy řetězců, čísel či jednodušších objektových struktur. Jednou z cest k řešení aplikace postavené nad ksoap2 je proto převod doménového modelu do soustavy objektů tříd SoapObject (SoapPrimitive). Zásadní výhodou tohoto postupu je neinvazivnost do stávajícího kódu. Lze aplikovat konverzní pomocné objekty, které na vstupu dostanou doménový objekt a na výstupu vrátí jeho reprezentaci dle ksoap2. Zdaleka zásadní nevýhodou tohoto přístupu je fakt, že neumožňuje přenášet seznam objektů (v podobě pole, či objektu Vector). V závislosti na stylu WSDL dokumentu se seznam Java objektů (pole) vrací jako sada XML elementů se stejným názvem. Standardní ksoap2 parser tyto objekty přepisuje do jednoho atributu Java třídy. Výsledkem je skutečnost, že z původně zaslaného pole je dostupný pouze poslední prvek resp. prvek, který byl v XML zpracován jako poslední. Daleko komplexnější a mocnější použití knihovny tedy nabízí využití rozhraní KvmSerializable, které ksoap2 poskytuje. Toto rozhraní je základním kamenem celé knihovny (je implementováno i výše zmíněnými třídami SoapObject a SoapPrimitive). Poskytuje možnost ručně psané atributové reflexe, tedy možnost přistoupení (získání i zapsání) k hodnotám atributů tříd bez znalosti jejich jmen. K tomuto využívá číselné indexy a příslušné metody zmíněného rozhraní. Díky tomuto přístupu lze řešit i přenos polí objektů, jak popisuje jeden z mála dostupných zdrojů o ksoap2([8]). Princip spočívá ve vytvoření vlastní implementace KvmSerializable, která u příslušné vlastnosti objektu bude naparsované objekty ukládat do pole či listu. Problém s přenosem polí a seznamů v SOAP je v tom, že prvky seznamu se přenášejí jako XML elementy se stejným názvem. Standardně tak parser nahrazuje příslušný atribut Java třídy vždy novou a novou hodnotou místo toho, aby je ukládal. Tomu lze zabránit právě vlastní třídou a vytvořením příslušného mechanismu pro ukládání do pole či seznamu. Knihovna ksoap2 poskytuje poměrně široké možnosti při komunikaci s webovými službami, na rozdíl od JSR 172 se neomezuje pouze na SOAP 1.1, je lépe přenositelná apod. Ovšem základním nedostatků je skutečnost, že je minimálně 120

Integrace mobilního klienta do IS přes webovou službu dokumentovaná a žádá i komplexnější odladění při převodu mezi Javou a XML. Je nezbytné se orientovat ve WSDL, znát přesná jména XML elementů, jejich jmenné prostory, vzájemné vztahy apod. 3. REST V souvislosti s knihovnami JSR 172 a ksoap2 je nezbytné zmínit i jednu z metod, která je mezi webové služby řazena, nicméně se jedná o zcela jiný architektonický styl celé aplikace. Tímto přístupem je tzv. REST neboli Representational State Transfer. Klasické webové služby oproti tomu stojí na principu vzdáleného volání procedur (RPC). Návrh RESTu popsal ve své disertační práci ([9]) Roy Fielding, mj. jeden ze spoluautorů protokolu HTTP. Princip RESTu je ve své podstatě jednoduchý. Celá architektura stojí na čtyřech základních pojmech se kterými operuje. Nejzákladnější z celého je zdroj. Zdrojem je abstrakce, která zapouzdřuje stav, nebo chování systému. Příkladem může být kniha v knihovně, student ve škole nebo vlak v systému jízdních řádů. Každý zdroj je možné vyjádřit nějaké reprezentaci. Údaje o knize mohou být ve formátu XML, textovém souboru, či obrázku. Důležité je tady zmínit, že každý zdroj může mít několik různých reprezentací, které ale v důsledku představují stále stejný zdroj. Tuto skutečnost lze dobře využít v prostředí přenosných přístrojů (viz dále). Každý zdroj také musí (mimo reprezentací) mít jednoznačně určenou adresu, která jej umožní lokalizovat v rámci systému. Typickým příkladem, který je i v praxi hojně využíván, je adresa URL. Posledním prvkem architektury REST je operace. Ta vyjadřuje, co lze provádět se zdrojem. Na rozdíl od klasického RPC, kde operace představují jednotlivé metody na rozhraní služby, zde jsou možné pouze maximálně 4 základní operace s každým zdrojem. Jedná se o tzv. CRUD operace, známé z prostředí relačních databází. Zdroj lze vytvořit, změnit, smazat a samozřejmě získat. K provádění těchto operací slouží různé reprezentace zdroje. Tedy změna zdroje s obrázkovou reprezentací způsobí pouze změnu obrázku, nikoliv dat apod. 3.1 REST v J2ME Velice často se REST webová služba staví nad protokolem HTTP. Ten slouží jako transportní prvek, který již obsahuje dva zásadní prvky architektury. Jednak URL adresu, a také metody (GET, PUT,...), které lze navázat na operace. Jednoduchým příkladem může být knihovna. Její zdroj seznam knih, adresovaný jako http://knihovna.cz/knihy s využitím metody GET vrátí seznam všech dostupných knih. Pomocí metody POST na stejném zdroji lze novou knihu přidat tak, že její reprezentace bude obsažena v těle požadavku. Získat jednotlivou knihu lze pomocí operace GET na zdroji http://knihovna.cz/knihy/crichton/koule. Záleží na serveru (či požadavku klienta) v jaké podobě (reprezentaci) požadovanou knihu vrátí. Tuto skutečnost lze popsat například definicí hlaviček protokolu Accept-Type a Conent-type. Obdobným způsobem jako získání lze zdroj i smazat na stejné adrese, ovšem využitím HTTP metody DELETE, která může představovat operaci smazání. 121

Ondřej Berger Zejména v podobě různých reprezentací zdrojů pak architektura přináší rozsáhlé možnosti do mobilních zařízení. Pro všechny klienty (mobilní i nemobilní) lze vystavit jednotné rozhraní, ovšem v závislosti na identifikaci klienta (hlavičkou požadavku, parametrem adresy), může server stejný zdroj vyjádřit různými způsoby. Například v XML formátu pro běžné PC a v podobě neformátovaného textu pro mobilní zařízení. Stejně tak obrázek může být pro přenosné zařízení s malým displejem zmenšen aby se celý vešel bez nutnosti rolování atd. V prostředí Java ME existují základní prostředky pro práci s HTTP protokolem, který je častou volbou pro řešení RESTu. Bez nutnosti vyvíjení dalších aplikačních prvků je možné ihned zdroj adresovat a posílat a číst jeho reprezentaci. Jediným nutným řešením je převod doménové reprezentace zdroje (Java objektu) do vhodné reprezentace (XML, JSON, text). Není vyžadována žádná doplňující knihovna, či volitelný balíček API. Nicméně v aktuálně nejrozšířenější mobilní Javě (CLDC 1.1 a MIDP 2.0) jsou omezeny metody volání HTTP protokolu pouze na metody GET, POST a CONNECT. Další (PUT, DELETE) je nutné doprogramovat ručně využitím socketového spojení, vypsáním hlavičky HTTP požadavku do výstupu a čtením odpovědi. Jedná se sice o nepohodlnou záležitost, ale řešitelnou. Nejvíce pracnou částí celé aplikace tak bude převod mezi doménovým modelem Java objektů a vhodnou reprezentací zdrojů. Dostačujícím pro většinu použití může být například JSON notace, která umožňuje reprezentovat i složité datové struktury úsporněji než například XML [10]. 4. Srovnání přístupů Všechna řešení, která jsou dostupná na J2ME platformě umožňují rozšíření klientů webových služeb i na mobilní zařízení. Při srovnání a implementaci zkušební aplikace všech přístupů se ukazují jejich výhody a nevýhody. Nyní shrnu pouze ty dle mého názoru nejdůležitější. Ve prospěch JSR 172 hovoří rychlost vývoje a snadnost použití. Celý komunikační kód lze vygenerovat do podoby běžné Java třídy, která se použije v aplikaci. Nevýhody balíčku WSA jsou dvě hlavní. Za prvé služba je omezena pouze na SOAP protokol verze 1.1, a nepodporuje jeho novější specifikaci 1.2. Zde se otvírá prostor pro další průzkum ohledně zastoupení jednotlivých verzí protokolu mezi aktuálními webovými službami. Druhým, zásadnějším omezením je nepřenositelnost řešení mezi různými zařízeními, pokud nemají WSA již od výrobce implementován. V případě nasazení uvnitř větší společnosti nejde o zásadní problém. Častým benefitem bývá vybavení zaměstnance mobilním telefonem a výběr lze přizpůsobit požadavkům. V případě jednoho typu zařízení také odpadají i další komplikace při vývoji mobilní aplikace a to zejména tvorba a ladění uživatelského rozhraní pro různá zařízení a různé displeje apod. Naproti výše zmíněnému je knihovna ksoap2 přenosná mezi všemi zařízeními s mobilní Javou, pokud podporují profil alespoň MIDP 2.0. To zahrnuje většinu všech stávajících zařízení a je tak možné aplikaci nasadit i v heterogenním prostředí různých přístrojů. Daní za tuto přenositelnost je pak komplikovanější vývoj, spočívající v nízkoúrovňovějším přístupu k webové službě v podobě přímé tvorby XML zpráv a jejich zpracování. 122

Integrace mobilního klienta do IS přes webovou službu Zcela na opačné straně stojí architektonický styl REST, který na rozdíl od klasických webových služeb nevyužívá model RPC, ale jde zcela jiným směrem. Tato odlišnost má za následek dvě oblasti, které mohou bránit jeho většímu rozšíření, alespoň prozatím. První skutečností je, že v případě nejčastější varianty architektury s využitím protokolu HTTP je nutné vyvinout vlastní implementaci nedostupných metod. To ovšem přebíjí skutečnost, že při vhodném návrhu stačí tento krok provést pouze jednou a pak dále využívat již jednou hotové řešení. Zpracovat tak je nezbytné pouze převod mezi reprezentací zdrojů a Java objekty. Druhým aspektem je zcela odlišný přístup k návrhu celé aplikace, a to nejen klienta ale i serveru je nezbytné myslet ve zdrojích, což je sice předpoklad objektového návrhu, ovšem stále častým problémem je návrh a implementace tzv. anemického modelu. Aplikační logika v něm není rozdělena mezi jednotlivé objekty, ale z větší části se soustřeďuje do tzv. manager či service objektů, které zajišťují její vykonání (viz http://www.martinfowler.com/bliki/anemicdomainmodel.htm). I přes tyto problematické oblasti je ovšem REST architektura dobrou volbou pro nasazení při řešení mobilního klienta. Zejména její možnost různých reprezentací, která umožňuje volit vhodné reprezentace jednoho zdroje v závislosti na klientu přináší úsporu prostředků a času při vývoji komunikačního rozhraní. Zároveň si tento přístup na klientovi vystačí pouze se základním API a nevyžaduje žádné dodatečné knihovny. Tím se obrovským způsobem zvyšuje přenositelnost celé aplikace mezi různými zařízeními. 5. Závěr V článku byly nastíněny jednotlivé metody, které lze v prostředí Java ME použít pro vytvoření klienta IS s využitím webové služby. Byly zmíněny tři nejznámější přístupy k webové službě v mobilním zařízení. Článek poukazuje na jednotlivé, zejména technologické aspekty, které provázejí nasazení jednotlivých přístupů. Každé řešení má své výhody i nevýhody, které je nezbytné zvážit. JSR 172 umožňuje v ideálním případě klienta celého vygenerovat, ovšem API není vždy dostupné v mobilním zařízení. Použít knihovnu ksoap2 je pracnější použít díky minimální dokumentaci i nízkoúrovňovějšímu přístupu a vazbě mezi XML a Javou. Ovšem je možné jej využít kdekoliv, protože knihovna je přenosná. REST implementace nad HTTP protokolem sice naráží na nutnost vyjádření reprezentace a doplnění neimplementovaných metod HTTP spojení, ovšem její nespornou výhodou je nezávislost na dalších knihovnách a úspora zdrojů při tvorbě serverového rozhraní, které mohou využívat různí klienti. Je proto otázkou vždy zvážit, které řešení je v dané situaci nejvhodnější s ohledem na plánovaný čas, zdroje. Případně zda úplně webové služby neopustit a podívat se po jiném, alternativním řešení. Zdroje [1] Topley, Kim. J2ME in a nutshell. [s.l.] : O'Reilly, 2003. 478 s. March 2003. ISBN 0-596-00253-X. 123

Ondřej Berger [2] IBM. IBM [online]. 2010 [cit. 2011-09-20]. WebSphere Everyplace Micro Environment. Dostupné z WWW: <http://www- 01.ibm.com/software/wireless/weme/>. [3] freebeans. A free Java Virtual Machine for Windows Mobile [online]. Mar. 05, 2010 [cit. 2010-02-20]. Mysaifu JVM. Dostupné z WWW: <http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html>. [4] JAVAVERFIED.COM. Table of supported devices [online]. 2009 [cit. 2010-01-05]. Dostupný z WWW: <http://javaverified.com/files/table_of_supported_devices_1.26.2.pdf>. [5] ORTIZ, C. Enrique. Introduction to J2ME Web Services [online]. 2004 [cit. 2010-01-3]. Dostupný z WWW: <http://developers.sun.com/mobility/apis/articles/wsa/>. [6] Embedded interaction [online]. 2007 [cit. 2010-02-21]. Using JSR-172 on any J2ME-enabled mobile phone. Dostupné z WWW: <http://www.hcilab.org/documents/tutorials/jsr172/jsr172.html>. [7] KSOAP2 [online]. 2006, 2006-10-23 [cit. 2010-01-03]. Dostupný z WWW: <http://ksoap2.sourceforge.net/index.shtml>. [8] KSOAP2 WIKI [online]. 1999-2009, Oct 1, 2008 [cit. 2010-01-03]. Dostupný z WWW: <http://ksoap2.wiki.sourceforge.net/>. [9] Fielding, Roy. Architectural Styles and the Design of Network-based Software Architectures. [s.l.], 2000. 180 s. Dizertační práce. Dostupný z WWW: <http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>. [10] Dobric, Damir. Developers.de [online]. Dec 27 2008 [cit. 2010-01-10]. Performance Comparison: SOAP vs. JSON (WCF-Implementation). Dostupné z WWW: <http://developers.de/blogs/damir_dobric/archive/2008/12/27/ performance-comparison-soap-vs-json-wcf-implementation.aspx>. 124