Firemní aplikace v hrsti

CIO a IT manažeři zpravidla usilují o to, aby byla podniková data vždy a všude dostupná těm, kteří je potřebují pr...


CIO a IT manažeři zpravidla usilují o to, aby byla podniková data vždy a všude
dostupná těm, kteří je potřebují pro zajištění běhu obchodních aktivit. Ovšem
například v případě obchodních zástupců nebo častěji cestujících manažerů to
znamená poměrně velký závazek. Ti by při práci mohli ideálně využívat ta
zařízení, která už s sebou tak jako tak běžně berou jako třeba PDA a mobilní
telefony.
S pomocí těchto přístrojů pak lze s kolegy či firemním back-endem komunikovat
prostřednictvím instant messagingu nebo datových terminálů, které jim mohou
poskytnout informace o zákaznících nebo zadat objednávku. Bohužel však existují
velmi zásadní rozdíly mezi různými typy na první pohled podobných zařízení
(jako jsou počítače Pocket PC s operačním systémem Windows CE, PDA na
platformách Palm OS nebo Linux či mobilní telefony se systémem Symbian OS), a
ty působí vývojářům firemních aplikací nemalé problémy.
Dokonce i různé telefony jediného výrobce se obvykle výrazně liší, ať už co do
typu procesoru, kapacity paměti nebo rozměrů a rozlišení displeje. Navíc se
zhruba každých 6-9 měsíců objevují další modely přístrojů do dlaně se zcela
novými funkcemi, jako jsou vestavěné fotoaparáty či podpora komunikace přes
Bluetooth.
Hlavním zájmem IT manažerů je, aby aplikace běžící dnes na zařízení A mohla
zítra pracovat na zařízení B, a z těchto důvodů může být dobrou volbou vývojové
platformy J2ME (Java 2 Micro Edition), zeštíhlená verze Javy šitá na míru pro
nasazení v oblasti embedded systémů a mobilních přístrojů. Většina výrobců
handsetů do nich v současnosti implementuje svoji vlastní Java VM (Virtual
Machine) a virtuální stroje třetích stran pak obvykle poskytují podporu Javy v
zařízeních typu Palm nebo Pocket PC. J2ME tak nabízí vysoký stupeň bezpečnosti
a portability aplikací pro velmi široké rozpětí starších, současných i
budoucích kapesních přístrojů ovšem nikoliv bez určitých nedostatků.

Java v pískovišti
Jako všechny edice Javy byla i J2ME vytvořena, aby poskytovala kontrolovaný
přístup k programovým zdrojům. Run-time architektura používá princip "sandbox"
(v překladu pískoviště), při němž vykonávaný program běží v oddělené, chráněné
oblasti paměti. Takto lze zabránit tomu, aby případná selhání kódu/aplikace
negativně ovlivňovala nebo poškozovala ostatní kritické komponenty run-time
prostředí. Navíc program nemá neomezený přístup k hardwarovým zdrojům nižší
úrovně nebo zdrojům vně tohoto sandboxu. Namísto toho jsou veškeré operace
daného zařízení prováděny prostřednictvím volání J2ME API.
Je možné uvést mnoho dobrých důvodů, proč izolovat program od mnoha jiných
funkcí, například mobilního telefonu. Na desktopovém PC může pád programu
zasáhnout například session editace textu. Mobilní telefon je ale v podstatě
dvoucestné zařízení pro bezdrátový přenos signálu (tj. rádio). Státní orgány
přitom nemívají rády nepatřičné využívání rádiových vysílačů, a to bez ohledu
na viníka ať je jím v našem případě vlastník telefonu nebo škodlivý program.
Navíc málokterého uživatele by potěšil program typu trojský kůň "volající domů"
a předávající jeho osobní informace hackerovi. Protože navíc "poskytování
vzduchem" uživatelům umožňuje také stahovat nové aplikace, je role
zabezpečeného sandboxu o to důležitější.
Nicméně i toto schéma ochrany má své nevýhody. Jednoduše řečeno, jestliže pro
určitou hardwarovou funkčnost handsetu není definováno odpovídající API,
vývojář takové funkce nemůže využít. Kupříkladu telefony jako Sony Ericsson
T610 nabízejí spoustu zajímavých funkcí Bluetooth komunikaci, infračervený port
i sériové propojení nebo vestavěný digitální fotoaparát. Avšak v současnosti
dostupná javová API v implementaci J2ME pro T610 tyto možnosti nevyužívají. Lze
k nim tedy přistupovat pouze použitím C++ v operačním systému Symbian OS (který
se ovšem nachází až pod abstrakčními vrstvami J2ME).
Většina výrobců tyto nedostatky obchází tak, že poskytují speciální Java API
navržená pro přístup k proprietárním funkcím. Nicméně takto každý z nich
navrhne svoji vlastní specifickou sadu API pro zajištění jinak velmi podobných
funkcí. A právě tato nekompatibilní API brání tomu, aby J2ME mohla v plné šíři
splnit svoji primární úlohu tedy přinést abstraktní platformu s konzistentním
rozhraním, které zpřístupňuje dostupné funkce v plné šíři u všech typů
zařízení. Použití API specifických pro určitého výrobce tak svazuje aplikaci s
určitým konkrétním typem mobilního zařízení, což komplikuje možnosti nasazení
aplikace pokud možno v rámci celého podniku (bez programátorských úprav tedy
nemusí být její nasazení na více typech přístrojů možné).

Záležitost profilu
J2ME omezuje podporu hardwarových funkcí specifických pro jednotlivé výrobce,
aby vyhovovala jejich různým obměnám mezi přístroji. S rozdíly v hardwarovém
provedení přístrojů se J2ME dokáže vypořádat dvěma způsoby. Zaprvé, J2ME
definuje abstrakční vrstvu známou jako Configuration (konfigurace), která
popisuje minimální požadavky na hardware potřebný pro implementaci Javy v
embedded či mobilním zařízení. Pro zařízení s omezenými hardwarovými zdroji,
jako jsou mobilní telefony a low-endová PDA, je určena J2ME konfigurace CLDC
(Connected Limited Device Configuration).
Zadruhé, J2ME definuje druhou abstrakční vrstvu, označovanou jako profil, která
popisuje hardwarové funkce i možnosti přístroje a popisuje API, která k nim
zajišťují přístup. Jinými slovy, profily rozšiřují konfiguraci, aby bylo možné
adresovat specifické hardwarové charakteristiky určitých zařízení.
V současnosti J2ME definuje jediný profil pro CLDC zařízení, a to MIDP (Mobile
Information Device Profile). Kromě specifikace základních hardwarových
požadavků MIDP navíc implementuje API používaná pro přístup k hardwaru.
Důležité je pochopit, že J2ME zařízení může mít pouze jedinou konfiguraci,
která popisuje jádro hardwaru. Nicméně je povoleno několik profilů včetně MIDP
a profilů výrobců pro podporu funkcí specifických pro určitý přístroj. Výrobce
tak může J2ME rychle adaptovat pro nová zařízení tím, že pro ně napíše nezbytné
profily.
Vedle rozhraní popisuje MIDP i charakteristiky J2ME aplikací označovaných jako
midlety. Ty jsou taxonomicky podobné javovým appletům, přičemž hlavním rozdílem
je to, že midlet je během spojení schopen stahovat data, ovšem nikoliv
dodatečný kód. Konečný výsledek je, že midlet je potenciálně schopen běžet beze
změn na jakémkoliv přístroji s podporou J2ME. Navíc protože J2ME profily
definují rozhraní, vzhled a chování midletu na různých přístrojích mohou být
téměř identické. J2ME má proto šanci stát se univerzálním front-endem pro
klientské aplikace běžící na jakémkoliv mobilním zařízení.

Nemalé naděje
Ne náhodou se v předchozím odstavci vyskytovala slova "potenciálně" či "téměř".
Je třeba přiznat, že je zde několik omezení, která zatím ještě brání
bezproblémové přenositelnosti aplikací. Především jde o to, že i nepatrné
rozdíly v implementacích J2ME jednotlivých výrobců mohou způsobit výraznou
nekompatibilitu.
Dalším problémem je, že jestliže pro určitou funkci přístroje neexistuje
odpovídající API, pak ji vůbec nemůžete využít. J2ME nespecifikuje volitelné
standardy, jako je MMAPI (Mobile Media API), který poskytuje podporu playbacku
audia či streamingu videa. Bohužel tak vývojáři nemohou spoléhat na možnosti
dalších standardů běžně dostupných v každém zařízení.
Nicméně samotná J2ME prochází neustálým vývojem, aby mohla podobným zájmům
vyjít vstříc. Už v listopadu 2002 Java Community Process (JCP) uvolnil
důležitou revizi MIDP specifikace. MIDP 2.0 přidává některá kriticky důležitá
API, která například podporují bezpečná síťová propojení (přes HTTPS), a
implementuje oprávnění přístupu pomocí digitálního podpisu za účelem podpory
důvěryhodného kódu. Specifikace rovněž nabízí zdokonalené elementy
uživatelského rozhraní, jež poskytují vylepšený layout formulářů pro obchodní
aplikace.
Oproti volitelným standardům musejí přístroje, které využívají MIDP 2.0,
implementovat všechna API, jež popisuje, aby tak byla zaručena jejich
dostupnost pro některý program, jenž je v budoucnu možná bude potřebovat.
Handsety s podporou specifikace MIDP 2.0 se už pomalu začaly objevovat na trhu.
Výhledově JCP počítá s využitím specifikace JTWI (Java Technology for the
Wireless Industry). V JTWI se několik volitelných J2ME API (jako třeba MMAPI a
WMA, tj. Wireless Messaging API) stává vyžadovanými službami.
Už při současném stavu nabízí J2ME vývojářům možnost napsat obchodní aplikaci
jedenkrát a nasadit ji na širokém rozpětí běžně používaných bezdrátových
zařízení. Abstrakční vrstvy J2ME dále poskytují ochranu proti možným snahám
výrobců o zavedení ryze proprietárních technologií a současně pomáhají
vypořádat se s rychlými změnami, k nimž neustále dochází v oblasti bezdrátových
zařízení. Vývojáři sice možná budou muset vytvářet rozhraní midletů tak, aby
vyhovovala možnostem nejhorších parametrů například u používaných displejů, to
je však přijatelný kompromis v porovnání s nutností psát kompletní speciální
klientské aplikace pro každý typ mobilního zařízení, který daná firma vlastní.

Nástrahy vývoje v J2ME
J2ME nabízí při prosazování portability aplikací napříč širokou paletou
embedded či handheldových zařízení mnohé výhody. Avšak některá ze specifik
"mikroedice" Javy jsou natolik nekonkrétní, že jednotlivé implementace každého
výrobce mohou určité klíčové části kódu zpracovávat různými způsoby. To má za
následek nutnost tvorby několika variací, které myšlenku přenositelnosti
aplikací poněkud komplikují. Podívejme se na některé záludnosti, s nimiž se lze
při vývoji v J2ME setkat.
MIDP specifikace nezaručuje, že třída Display (objekt, který slouží jako
rozhraní pro obrazovku) bude dostupná dokud nebude v midletu provedena metoda
startApp(). Výsledkem je, že některé implementace bezpečně povolí vytvoření
instance třídy Display v konstruktoru midletu, zatímco jiné bez varování
"vyhodí" výjimku, která midlet ukončí.
Mnohé ze současných telefonů disponují pamětí RAM o kapacitě 1 MB i více, čímž
přesahují 512 KB specifikovaných v profilu CLDC. Nicméně některé J2ME
implementace stále předepisují omezené množství paměti, jež může midlet
využívat a maximální kapacita dostupná pro midlet se navíc také může lišit. To
znamená, že midlet, který lze natáhnout a spustit v jednom zařízení, nemusí na
jiném vůbec fungovat.
Různí dodavatelé používají odlišné druhy písma pro zobrazení řetězců ve
zprávách midletu, jeho menu a tlačítcích v uživatelském rozhraní. Výsledkem je
to, že i pečlivě navržený obchodní formulář s ovládacími prvky může na jednom
přístroji vypadat dobře, zatímco na dalším headsetu bude téměř nečitelný.
Vývojáři píší J2ME aplikace pomocí javových nástrojů na stolních počítačích.
Vzhledem k tomu, že odpovídající headset může existovat jen v omezeném počtu
prototypů (pokud vůbec), obvykle při testování a ladění midletů spoléhají na
simulátor běžící na PC. Simulátor přitom pro provádění javového programu
využívá vlastní J2SE (Java 2 Standard Edition) implementaci na PC, a je zde
tedy riziko, že tu a tam bude příliš spoléhat právě na možnosti J2SE. Výsledkem
by pak mohlo být to, že midlet běží bezchybně při simulaci na desktopu, nikoliv
však na cílovém zařízení.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.