Interaktivní webové aplikace

Transkript

1 Masarykova Univerzita Fakulta Informatiky Interaktivní webové aplikace Diplomová práce Bc. Martin Kopecký Brno 2009

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce doc. RNDr. Tomáš Pitner, Ph.D. 2

3 Poděkování Na této straně bych chtěl poděkovat: rodičům, doc. Tomáši Pitnerovi, vedoucímu mé diplomové práce 3

4 Shrnutí Tato práce přináší pohled na technologie interaktivních webových aplikací, poskytuje přehled a podrobnější popis jejich zástupců. Dále pak obsahuje ukázku Adobe Flex aplikace. Ta slouží jako praktický příklad interaktivní webové aplikace, která využívá služby JBI serveru. Demonstruje tak rysy interaktivních webových aplikací, a zároveň i svoji schopnost býti samostatnou aplikací 4

5 Klíčová slova Rich Internet Application, Service Oriented Architecture, Web Service Description Language, Adobe Flex, Java Business Integration, Adobe Flex Builder, interaktivní webová aplikace, ActionScript, MXML 5

6 Obsah 1.Úvod Síťové architektury z pohledu poskytování služeb Architektura klient-server Popis a struktura Třívrstvá architektura Výhody a nevýhody Architektura zaměřená na služby Popis a motivace Konceptuální model Struktura SOA z abstraktního pohledu Vlastnosti Výhody a nevýhody Srovnání SOA a architektury klient-server Webové služby Interaktivní webové aplikace Problémy RIA Vlastnosti RIA Výhody a nevýhody Ajax Objekt XMLHttpRequest Technologie zásuvných modulů Silverlight JavaFX Adobe Flex Přehled Kompilace ActionScript Actionscript Vytýčené cíle MXML Flex Builder Flex Data Services Flex Data Service Adobe Flex MXML Java Business Integration JBI architektura Komunikace prostřednictvím výměny zpráv Service Unit a životní cykly Implementace

7 6.Multifunkční interaktivní Flex aplikace Popis a návrh aplikace Realizace návrhu aplikace Klient Server Uživatelská dokumentace Dokumentace pro programátora Rozdělení funcionality Adobe Flex klient JBI server Závěr Přílohy Definice webové služby v jazyce MXML Funkce pro získání hodnoty výsledku Data provider komponenty ComboBox pro výběr měst Definice komponenty ComboBox Funkce volající konkrétní operaci webové služby Vyvolání okna s chybovou hláškou Definice regulárního výrazu pro číslo typu Float Vytvoření bodu a jeho přidání do objektu UIComponent Definování struktury menu Anotace webové služby v EJB modulu...43 Literatura

8 Kapitola 1 Úvod Klasické webové stránky po dlouhou dobu představovaly nejpoužívanější formu prohlížení obsahu Internetu. S postupem času a s rostoucími požadavky uživatelů však tato varianta přestala být pohodlným a efektivním řešením. Bylo potřeba vytvořit internetovou aplikaci, jejíž ovládání by bylo pro uživatele příjemnější, přehlednější, intuitivnější, rychlejší a efektivnější. To však také znamenalo narušit klasický synchronní model request/response. Tento model pracuje na principu, kdy klient pošle na server žádost a čeká, dokud server tuto žádost nezpracuje a nepošle klientovi odpověď. Klasické technologie, jako HTML 1 a CSS 2, však nebyly vytvořeny za účelem vývoje takovýchto aplikací, a proto skýtaly technologická omezení pro daný vývoj. Musel se tedy najít nový způsob jak vyvinout takovou aplikaci. Název RIA 3 byl poprvé použit v devadesátých letech společností Macromedia, od roku 2005 patřící společnosti Adobe Systems. Největší rozvoj však nastal až s postupným vývojem webových standardů (např. Ajax 4 nebo HTML 5) a s postupným mazáním rozdílů mezi webovými prohlížeči. K nárůstu počtu těchto aplikací přispělo i masové rozšíření technologií Java a Flash do webových prohlížečů, jelikož většina nově vytvořených interaktivních aplikací už nepotřebovala pro svůj běh instalovat další rozšíření. RIA aplikace přinášejí nové vlastnosti chování internetových aplikací. Mezi ty nejvýznamnější patří možnost obnovit pouze část stránky, což zmenší zatížení sítě, přímo editovat samotnou stránku, využívat techniku Drag&Drop nebo schopnost pracovat v offline režimu jako samostatná aplikace. V současné době máme nespočet různých technologií pro vývoj interaktivních aplikací. Do samostatné skupiny patří Ajax. Do druhé skupiny řadíme ostatní technologie, jako jsou JavaFX, Silverlight, Adobe Flex apod. Druhá kapitola poskytuje přehled o nejdůležitějších síťových architekturách, jejich principu, struktuře a výhodách a nevýhodách. Kapitola tři seznamuje už se samotnými interaktivními aplikacemi a jejich implementacemi. Ve čtvrté kapitole je podrobněji přiblížena jedna z RIA technologií - Adobe Flex. Pátá kapitola se zabývá JBI 5 technologií, která bude poskytovat služby pro Flex aplikaci. Kapitola šest je věnována popisu a implementaci zadané interaktivní webové aplikace. Závěrečná kapitola obsahuje přehled této práce a budoucnost RIA aplikací. Na přiloženém CD se nacházejí funkční zdrojové kódy vytvořené interaktivní webové aplikace 1 HyperText Markup Language 2 Cascading Style Sheets 3 Rich Internet Applications 4 Asynchronous JavaScript and XML 5 Java Business Integration 8

9 a implementace služeb na JBI serveru. 9

10 Kapitola 2 Síťové architektury z pohledu poskytování služeb Síťová architektura je z obecného hlediska struktura, zahrnující v sobě topologii sítě a určující konkrétní formu komunikace [69]. Z pohledu poskytování služeb lze na síťovou architekturu pohlížet jako na strukturu, která rozděluje služby mezi jednotlivé uzly v počítačové síti a vymezuje vztahy mezi nimi. Nejznámějšími typy z tohoto pohledu jsou architektura klientserver a stále více se uplatňující SOA Architektura klient-server Popis a struktura Tato architektura patří mezi nejrozšířenější v oblasti TCP 7 /IP 8 sítí [8]. K jejímu vzniku vedly především snahy vyřešit nedostatky původních monolitických architektur. Hlavním takovým problémem bylo zatížení sítě, jelikož u starších struktur byl výpočet zadaných úkolů prováděn na počítači uživatele [9]. Ten se pro data potřebná k výpočtu dotazoval určitého souborového úložiště. Tento problém byl vyřešen rozdělením povinností mezi dvě části architektury mezi tzv. klienta a server [8]. Hlavní myšlenka spočívala v rozhodnutí, že data by měla být zpracovávána tam, kde jsou i uložena [1]. Toto místo se nazývá server. Což je uzel v počítačové síti, který poskytuje různé služby. Například ový server, který poskytuje služby související s posíláním ových zpráv. FTP servery umožňuje sdílet soubory na síti nebo tiskové servery, které slouží k tisku dat na vzdálených zařízeních. Server je pasivní entita, čili nenabízí své služby, ale naslouchá na síti [5][6][8] a reaguje na žádosti uživatelských počítačů (klientů), které po navázání komunikace zpracuje. Druhou částí této architektury je zpravidla uživatelský počítač, zvaný klient. Ten má aktivní povahu, stará se o navázání komunikace se serverem [5][6][8], zaslání dat na něj a obdržení výsledku. Často se stává, že může být připojen na více serverů najednou. S uživatelem většinou komunikuje přímo, prostřednictvím grafického uživatelského rozhraní. Klienti se mohou dělit na dva typy, podle míry přítomnosti funkcionality. Tlustý klient obsahuje nezanedbatelnou míru aplikační logiky a je částečně nezávislý na serveru. Zároveň však klade větší nároky na hardware a software na uživatelském počítači. Oproti tomu u tenkého klienta je drtivá většina procesů vykonávána na straně serveru. To však pro změnu vyžaduje velký výkon serveru a rychlé síťové spojení obou účastnících se stran. Mezi tento typ patří například webový prohlížeč nebo terminál. Klient-server model zajišťuje především tři základní činnosti [2]. První z nich je činnost prezentační. Mezi ní obecně patří komunikace s uživatelem přes grafické rozhraní, jehož prostřednictvím se např. mohou uživateli zobrazovat výsledky jednotlivých procesů. Další službou je poskytování aplikační logiky. Jedná se o samotnou funkcionalitu poskytovaných služeb. 6 Service Oriented Architecture 7 Transmission Control Protocol 8 Internet Protocol 10

11 Poslední činností je správa uložených dat, která zahrnuje mazání dat, jejich uchovávání a kontrolu persistence dat. Výše zmíněné tři základní služby lze podle způsobu jejich dělby mezi klienta a server vyčlenit do pěti kategorií [2]. První skupinou je distribuovaná prezentace. Ta spočívá v rozdělení prezentační činnosti mezi klienta a server, kde server generuje výstupy ve znakovém režimu do textového okna. Obsah tohoto okna je poslán klientovi, který jej zobrazuje uživateli. Jinou variantou je vzdálená prezentace. V té už oproti předchozí kategorii není prezentace rozdělena mezi klienta a server, ale zůstává plně v rukou klienta. Server se pak stará o zbytek, čili zajišťuje aplikační funkce a správu dat. Distribuovaná funkce je název dalšího typu rozdělení dělby práce. V tomto případě je prezentace zajišťována klientem a správa dat serverem. O aplikační funkce se podle situace dělí klient se serverem. Další možností je vzdálená správa dat, kdy jsou veškeré prezentační a aplikační činnosti ponechány v pravomoci klienta, zatímco server je využit ke správě dat. Posledním rozdělením je distribuovaná báze dat. U tohoto typu je server použit pouze ke správě dat, o kterou se navíc ještě dělí s klientem. Ten dále zajišťuje zbylé aplikační a prezentační funkce Třívrstvá architektura První architektura klient-server byla označována jako jednovrstvá, jelikož obsahovala server a terminál (tenký klient). Nástupcem této architektury pak byl model dvouvrstvý. Lišil se od jednovrstvého přítomností tlustého klienta. Čili část aplikační logiky byla už i na straně uživatele. Postupem času s rostoucí složitostí uživatelských aplikací začaly stoupat i nároky na výkon počítačů [7]. Kromě tohoto také začalo docházet k osamostatnění databázových strojů. Vzhledem k výše zmíněným základním službám v klient-server struktuře se jevilo praktičtější každé službě ponechat vlastní vrstvu. Proto byla dvouvrstvá architektura rozšířena přidáním aplikační vrstvy na architekturu třívrstvou. Ta spadá do kategorie tzv. architektur vícevrstvých. Nově vytvořená vrstva je zastupována aplikačním serverem [4][7][8]. Soustředěním aplikační logiky na jedno místo se usnadnilo její sdílení, správa a dostupnost. Dále pak bylo zmenšeno zatížení sítě, jelikož hlavní zatížení se přesunulo na trasu mezi aplikačním serverem a datovým zdrojem, viz obrázek [3]. To umožnilo zlepšit odezvu i u klientů s omezenou přenosovou rychlostí Výhody a nevýhody Mezi přínosy této architektury patří rozdělení úkolů mezi více počítačů, což zajišťuje lepší údržbu sítě, jelikož v případě odstávky hlavního serveru může zaskočit server záložní [7]. Vzhledem k centralizovanému ukládání dat je jednodušší kontrolovat jejich persistenci. Nesporná výhoda s ohledem na bezpečnost spočívá v tom, že je lépe kontrolovatelné a jednodušší zabezpečit samotný server proti neoprávněnému přístupu než jednotlivé klienty [5]. Velkou nevýhodou je přetěžování sítě. Úzké místo této architektury spočívá právě v serveru, který se může častými dotazy klientů přetížit. S tím souvisí i další problém - nízká robustnost. Jelikož v případě výpadku serveru se poskytované služby stanou klientům nedostupné. 11

12 Obrázek 2.1.2: Třívrstvá architektura [3] 2.2 Architektura zaměřená na služby Popis a motivace V současné době se do popředí dostává architektura známá pod zkratkou SOA. Nejedná se o nový koncept [12], ale o nový způsob pohlížení na systém, kde základní stavební jednotku tvoří služby [10], které komunikují asynchronně mezi sebou prostřednictvím zpráv, a které poskytují své prostředky určitému spotřebiteli nebo i službám samotným. Tato architektura vzniká přepracováním původního konceptu systému. Impulsem k využití této architektury byla sílící potřeba vytvořit systém, který bude snadno rozšiřitelný, začlenitelný do jiných systémů, robustní proti výpadkům, transparentní a bude nástrojem pro realizaci byznys procesů [11]. Což je posloupnost kroků, které.jsou omezeny určitými byznys pravidly a jejich realizace vede k hmotnému i nehmotnému zisku. SOA není jiný výraz pro webové služby. Ty pouze dokáží implementovat služby SOA. Webové služby jsou komponenty popsané WSDL rozhraním a přístupné prostřednictvím SOAP 9. Samotná architektura orientovaná na služby se však bez webových služeb obejde, jelikož služby mohou komunikovat i prostřednictvím jiného protokolu, než je SOAP. Existují tři typy interakcí, jak mohou služby komunikovat mezi sebou [11]. První z nich je kooperace popisující situaci, kdy pro realizaci svých funkcí služba využívá funkce jiných služeb. Druhým typem je agregace, která spočívá ve vytvoření nové služby spojením dvou nebo více služeb. Takto nově vzniklá služba může poskytovat kombinace funkcí původních služeb. Choreografie je poslední možností komunikace Zajišťuje spolupráci mezi službami napříč systémem. Souhrn těchto interakcí vytváří byznys proces Konceptuální model Tento model SOA se skládá ze tří účastníků poskytovatele služeb, 9 Simple Object Access Protocol 12

13 spotřebitele služeb a registru služeb [11], viz. obrázek [17]. Služba je popsána v jazyce WSDL 10 a zaregistrována v registru služeb, který si udržuje veřejný seznam dostupných služeb. Pokud spotřebitel požaduje danou službu, vyhledá ji ve výše zmíněném registru a získá z něho popis dané služby s informací o parametrech a jejím umístění. Poté naváže spojení přímo s poskytovatelem dané služby. Komunikace pak probíhá prostřednictvím protokolu SOAP. Prezentace a transformace samotných dat probíhá ve formátu XML 11, což zajišťuje nezávislost na použitém protokolu. Transportním protokolem bývá nejčastěji protokol HTTP 12. Obrázek 2.2.2: SOA schéma [17] Struktura SOA z abstraktního pohledu Z abstraktního pohledu můžeme tuto architekturu rozdělit do tří základních vrstev, kterými se prolínají dvě řídící vrstvy [11]. Jedna kvůli sestavení komponent a služeb do komplexnějších celků a druhá pro zajištění kvality služeb a pro správu SOA aplikací. Nejnižší základní vrstvou je tzv. vrstva komponent. Ty zajišťují udržení kvality služeb a realizaci funkčnosti služeb. Komponenty slouží jako základní stavební bloky pro tvorbu služeb. Ve druhé vrstvě se za základní jednotky považují služby, které jsou přístupné pouze přes rozhraní, obsahující popis nabízených funkcí, a slouží spolu s řídícími daty jako zdroj informací pro vyhledávání služeb a jejich komunikaci mezi sebou. Poslední a nejvyšší úrovní je vrstva byznys procesů. Ty jsou v architektuře SOA chápány jako posloupnost provedení několika služeb. Na této úrovni už tedy můžeme o byznys procesu mluvit jako o jednoduché aplikaci. 10Web Services Description Language 11eXtension Markup Language 12HyperText Transport Protocol 13

14 2.2.4 Vlastnosti Mezi základní charakteristické vlastnosti SOA patří zapouzdření služeb. To znamená, že uživatelé služeb nevidí jejich funkční logiku. Pouze k nim přistupují prostřednictvím rozhraní. Služby tak fungují jako tzv. černé skřínky. Dalším významným rysem je volné provázání služeb, což znamená, že si služby o sobě udržují málo informací nebo o sobě nic nevědí [11]. A tím je i minimalizována závislost mezi nimi. S tím souvisí i další vlastnost, a to nezávislost služeb, protože se služby chovají jako autonomní entity. Služby jsou navrženy s ohledem na service discovery, což znamená, že mohou být nalezeny přes mechanismus pro vyhledávání a využití služeb v počítačových sítích. Mezi další charakteristiky patří bezstavovost služeb, což má za následek, že se služby snaží minimalizovat množství informace mezi jednotlivými komunikačními cykly. Dále je to znovupoužitelnost služeb a jejich nezávislost na dané platformě a operačním systému [12] Výhody a nevýhody Jelikož, jak už bylo zmíněno výše, vznikají SOA vhodným rozkladem existujících systémů, stojí tvorba nové struktury systému podstatně méně, než kdyby byl vyvíjen kompletně nový systém [11]. Díky tomu, že se služby chovají jako autonomní jednotky a jsou platformově nezávislé, je velmi snadné takto navržený systém rozšiřovat. Autonomie jednotlivých služeb s sebou přináší taky zvýšenou robustnost. Další výhodou je taktéž flexibilita, která je umožněna výše zmíněnou rozšiřitelností a znovupoužitelností služeb. Znovupoužitelnost služeb, což je jedna z předností SOA, však přináší i nevýhodu. Ta spočívá ve velké náročnosti návrhu takovýchto služeb, které musí být navrhovány s ohledem na možné budoucí požadavky [11]. Předpovídat tyto požadavky je však obtížné. Další nevýhodou je nutnost pečlivě sledovat a řídit proces zavádění SOA, jelikož špatný rozklad systému může velmi lehce vést k neefektivnímu řešení Srovnání SOA a architektury klient-server Obě tyto hojně využívané architektury se liší hlavně ve vytížení sítě a rozložení zátěže [11]. Architektura klient-server je založena na principu, že server obsahuje většinu aplikační logiky a uchovává data. To způsobuje nejen kumulaci zatížení na serveru, ale i zvýšení komunikace mezi serverem a klienty. U SOA je zátěž rozložena víceméně rovnoměrně díky distribuovanému procesu zpracování požadavků [11]. Kromě toho každá služba poskytuje pouze omezenou množinu funkcí, a tak jsou kladeny menší nároky na zdroje. Výhodou oproti architektuře klient-server je také existence více služeb poskytujících stejné funkce. Uživatel si tak může vybrat službu podle jejího současného vytížení. 14

15 2.2.7 Webové služby Webové služby patří mezi nejrozšířenější implementace SOA [11]. Podle definice W3 konsorcia je webová služba systém podporující komunikaci dvou zařízení v počítačové síti a obsahuje rozhraní, které je definováno v jazyce WSDL [13]. Samotná komunikace pak probíhá výměnou zpráv prostřednictvím protokolu SOAP v XML formátu, což zajišťuje nezávislost na prostředí. Web Services Description Language Tento jazyk, založený na XML, se používá pro popis rozhraní, např. u webových služeb [12]. Definuje metody, které daná služba nabízí, jejich parametry, chybová hlášení a formát odpovědi. V dnešní době se používá verze 2.0 [15]. WSDL dokument definuje elementy Service, jako kolekci podobných koncových bodů, Port, což je jednoduchý koncový bod, popsaný jako kombinace tzv. Binding a síťové adresy. Dále pak už výše zmíněný konkrétní protokol a specifikace datového formátu pro Port type - Binding. Port type, který je abstraktní množinou operací, podporovanou koncovými body. Element Operation, který popisuje akce vykonávané službou. Abstraktní typová definice přenášených dat je definována ve WSDL dokumentu jako element Message. Posledním elementem je Types, sloužící jako kontejner pro datové typy. WSDL rozhraní se nachází u poskytovatele služeb a v registru služeb třetí strany, která jej zveřejňuje uživatelům služeb [14][16]. Simple Object Access Protocol SOAP byl vytvořen v roce 1998 s podporou Microsoftu [12]. Tento protokol využívá nejen protokoly HTTP a UDP pro přenos zpráv, vytvořených v jazyce XML [11], zvoleným pro svou přenositelnost a rozšíření, ale také umožňuje využít protokol HTTPS pro ověření identity komunikujících stran. Předávání zpráv nejčastěji probíhá jako RPC 13 [29], což je rozhraní, ve kterém program pošle zprávu jinému programu na vzdáleném počítači. Na něm je zpráva zpracována a výsledek poslán zpět do programu startujícím tuto akci. RPC mechanismus umožňuje klientovi ovládat službu na vzdáleném zařízení. Nevýhodou protokolu SOAP je délka XML zpráv, která může zpomalit zpracování zprávy. Kromě toho hodně jeho implementací nastavuje limit pro množství poslaných dat. I přes tyto nevýhody se protokol SOAP jeví jako jedno z vhodných řešení pro práci s objekty. 13Remote Procedure Call 15

16 Kapitola 3 Interaktivní webové aplikace Tyto aplikace, známé pod zkratkou RIA [20], neboli Rich Internet Application, přinášejí nový koncept kombinující vlastnosti desktopových [18], čili aplikací spouštěných lokálně v systému, a webových aplikací. Anglické slovo rich v tomto případě zastupuje bohaté uživatelské rozhraní, ve kterém má uživatel možnost přetahovat jednotlivé položky, používat nápovědu apod [22]. Čili dělat věci charakteristické pro klasické aplikace. Často se o těchto aplikacích mluví (hlavně u technologie Ajax) jako o novém přístupu k webu, čili jako o realizaci Web 2.0 [25][66], což je další fáze ve vývoji webu. Vývoj RIA byl podmíněn požadavky, které by měly webové aplikace splňovat. Jednalo se především o komplexnost grafického rozhraní, uživatelsky přívětivého chování a komfortu blížícím se používání klasických aplikací. Implementace interaktivních webových aplikací lze rozdělit do dvou skupin. V první se nalézá Ajax [21]. Ten využívá klasické webové technologie, jako jsou JavaScript, CSS, HTML a XML, pro realizaci bohatých webových aplikací [68]. Je vhodné ho použít v případech, kdy tvoříme převážně prezentační stránky s jednoduchou aplikační logikou, jednoduché formuláře a aplikace, a nebo pokud požadujeme běh těchto aplikací bez nutnosti instalace doplňků. Do druhé skupiny se řadí ostatní implementace. Pro jejich běh je nutná přítomnost specifického zásuvného modulu, neboli pluginu, v internetovém prohlížeči [21]. Hodí se pro tvorbu komplikovaných a intranetových aplikací. Také se využívá v případech, kdy klademe důraz na výkon, jelikož při tvorbě dynamických stránek jsou tyto tzv. technologie zásuvných modulů výkonnější než JavaScript, používaný implementací Ajax. Nejdůležitějším a nejpoužívanějším zástupcem je Adobe Flex, kterému bude věnována samostatná kapitola. Kromě toho zde patří i méně známé technologie, jako je např. Silverlight nebo JavaFX. 3.1 Problémy RIA Prvním ze dvou problémů, se kterými se aplikace musí vypořádat, je spolupráce s protokolem HTTP a jeho modelem request/response [20]. U klasických webových stránek se při jakékoliv změně obsahu stránky zažádá server o stažení této stránky HTTP GET zprávou. Na ni server odpoví vrácením celé stránky. Tato komunikace probíhá synchronně. Interaktivní webové aplikace však pro dosažení lepší spolupráce s uživatelem vyžadují asynchronní komunikaci, která by umožnila měnit části stránky bez nutnosti jejího celého stažení. Tento problém se řeší prostřednictvím Rich Client Presentation Tier, což je prezentační vrstva, která obsahuje mechanismus asynchronního zasílání zpráv, a tím umožňuje jednotlivým částem aplikace komunikovat se serverem nezávisle na sobě. Tato vrstva, rozšiřující internetový prohlížeč, poskytuje událostmi řízený model, díky kterému se 16

17 nemusí generovat specifické HTML pro každou odpověď. Druhou nepříjemností je technologické omezení HTML a CSS pro lepší grafická rozhraní [20]. Jelikož byl tento značkovací jazyk vytvořen především pro zobrazování textu ve webovém prohlížeči, má pro vytvoření grafických uživatelských rozhraní omezené možnosti. Toto se většinou řeší pomocí RIA implementací, které využívají pro tvorbu rozhraní nově vytvořené jazyky. Například Adobe Flex používá značkovací jazyk MXML. 3.2 Vlastnosti RIA Mezi charakteristické znaky patří propojení těchto desktopově se tvářících aplikací s internetem. Kromě toho je pro bohaté aplikace typická rychlá odezva, Drag&Drop technika, klávesové zkratky apod [21]. Čili napodobují chování klasických desktopových aplikací. Také rychlost spuštění aplikace se přibližuje zobrazení webové stránky. To znamená, že daná aplikace má jen velmi zanedbatelný instalační proces nebo nemá žádný. Velmi důležitým faktorem je i výrazně menší zatížení sítě a serveru [26][67], jelikož samotný klient poskytuje mnohem více aplikační logiky, než webový prohlížeč. 3.3 Výhody a nevýhody Mezi společné výhody, nezávislé na použitých implementacích (kromě Ajax), patří plugin pocházející od jednoho autoritativního výrobce. To znamená, že odpadá nutnost ladění aplikací pro konkrétní prohlížeč. Jelikož tyto technologie nejsou závislé na klasických technologiích, jako jsou HTML, CSS a JavaScript, nemají omezení pro tvorbu rozmanitějších aplikací a navíc poskytují vyšší výkon. Další velkou výhodou je podpora nástrojů a vývojových prostředí pro vývoj těchto aplikací. To umožňuje kontrola syntaxe, debugging apod [21]. Oproti Ajax mají ostatní technologie nevýhodu v potřebě přítomnosti pluginu, který umožňuje běh jejich aplikací. Kromě toho je také diskutovaným problémem odklon od uživatelských zvyklostí, jelikož aplikace vypadá jako webová stránka, avšak chováním se blíží desktopovým aplikacím. Uživatel, zvyklý na klasické ovládání v prohlížeči, nemůže využívat klávesových zkratek prohlížeče. Klasickou ukázkou odlišnosti od webových stránek je akce tlačítka Zpět, pro kterou musí být aplikace speciálně ošetřena. Dalšími nepříjemnosti je nepamatování si hesel, nebo posílání nezašifrovaných dat přes HTTP, i když se aplikace tváří, že jsou data posílána přes HTTPS [21]. Tyto nevýhody jsou také důvodem, proč společnost Google dává přednost vývoji Ajax před technologiemi zásuvných modulů. 3.4 Ajax Ajax není konkrétní softwarový produkt, ale jedná se o obecné označení technologií, určených pro tvorbu interaktivních webových aplikací, které, jak už bylo zmíněno výše, mohou měnit obsah svých stránek bez zažádání serveru o celé jejich stažení. 17

18 I když se techniky pro asynchronní přenos dat objevily už v polovině devadesátých let, do povědomí se dostala až v roce 2005 technika a architektura Ajax [19]. Záhy došlo k jejímu masovému rozšíření. A to hlavně díky společnosti Google, která ji začala používat v aplikacích Gmail nebo Google Maps. Ajax se také brzo dočkal své první specifikace. Tu v roce 2006 vydalo W3C 14 za účelem vytvoření webového standardu. Tento obecný koncept využívá pro realizaci interaktivních webových aplikací v zásadě tři skupiny technologií. Do první skupiny spadá platformově a jazykově neutrální reprezentace XML a HTML souboru, zvaná Document Object Model (DOM) [20][24]. Jedná se vlastně o API 15, které umožňuje přístup a následnou změnu obsahu dokumentu nebo kterékoliv jeho části. K dokumentu se prostřednictvím DOM přistupuje jako ke stromové struktuře [27]. Tento přístup však vyžaduje přenesení celého dokumentu do paměti, což však zpomaluje zpracování příkazu. Proto se tato technika používá pouze v případech, kdy je zřejmé, že se k jednotlivým elementům souboru bude přistupovat opakovaně nebo v náhodném pořadí. Pro případ, kdy je potřeba postupného nebo jednorázového zpracování částí dokumentu, existuje sekvenční alternativa k DOM SAX 16. Do druhé skupiny řadíme klasické webové technologie HTML, CSS apod.. HTML slouží hlavně pro tvorbu samotné kostry webových stránek, pro přidávání jednotlivých elementů. Kromě toho poskytuje i omezené formátování textu a struktur webových stránek, jako jsou tabulky, nebo seznamy [21]. V současné době se pro formátování HTML kódu využívá kaskádových stylů, neboli zkráceně CSS. Většinou jsou importovány do webové stránky z externího souboru a umožňují formátovat jakoukoliv část HTML dokumentu. Dnes existuje tento jazyk pro úpravu stylů HTML, XHTML a XML souborů ve dvou úrovních specifikací. A to CSS1 a CSS2. JavaScript je jazyk, který je použit pro rozšíření využití webových stránek. Program v tomto jazyce bývá zapisován přímo do kódu HTML nebo může být importován z externího souboru. Patří do kategorie klientských skriptů, což znamená že napsaný program se interpretuje až v prohlížeči uživatele. Z toho plynou bezpečnostní omezení tohoto jazyka, např. nemožnost pracovat se soubory kvůli možnému ohrožení soukromí klienta [21]. Poslední skupina zahrnuje techniku používání objektu XMLHttpRequest, který umožňuje asynchronní volání serveru. Což je základní vlastnost, která dává Ajax výhodu oproti klasickému webovému modelu. Tato výhoda umožňuje díky XMLHttpRequest objektu přenášet pouze části webové stránky, a tím snížit zátěž serveru, který nemusí sestavovat pro každý požadavek celý HTML dokument. Klasickou nevýhodou je ztráta významu webových stránek, jako posloupnosti stránek, 14World Wide Web Consortium 15Application Programming Interface 16Simple API for XML 18

19 mezi nimiž lze přepínat pomocí tlačítek Zpět a Další, jelikož se tyto webové stránky chovají jako plnohodnotná aplikace s vnitřní logikou [21]. V současné době však lze tento nedostatek částečně odstranit prostřednictvím adres za znakem # nebo neviditelným IFRAMEs. Pokud aplikace nesignalizuje, že zpracovává požadavek, může být častým problémem také síťová latence. Jelikož pak se uživatel může nesprávně domnívat, že jeho příkaz byl ignorován. Nutností je používat moderní webové prohlížeče, které podporují všechny potřebné technologie k bezproblémovému chodu aplikace Objekt XMLHttpRequest V tradičním webovém modelu jakýkoliv požadavek na změnu stavu má za následek načtení celé stránky ze serveru. To však zbytečně zatěžuje síťové cesty, jelikož kvůli relativně malé změně musí být přeposláno celé uživatelské rozhraní s příslušnými daty. Ajax nabízí řešení v podobě XMLHttpRequest objektu [20], který umožňuje vyvolání libovolného počtu nezávislých požadavků, které mohou změnit pouze část webové stránky bez nutnosti jejího celého obnovení, viz. obrázek [20], na kterém je logika obsluhující XmlHttpRequest objekt znázorněna jako Ajax Engine. Konsorcium W3 se snaží tento objekt standardizovat. Momentálně už existuje pracovní návrh specifikace. Jeho nejnovější verzi lze shlédnout na oficiálních stránkách W3C na [28]. Vytvoření tohoto objektu, volaného nejčastěji JavaScriptem, se liší podle toho, zda ho ho generujeme v prohlížeči Mozilla nebo Internet Explorer. Ve druhém zmiňovaném prohlížeči pro verzi 6 a nižší musí být tento objekt vytvořen jako ActiveX komponenta [28][67]. Dalším krokem je inicializace HTTP požadavku. K tomu slouží metoda open, ve které můžeme specifikovat metodu odeslání (POST nebo GET), adresu, na kterou je požadavek zasílán, a další nepovinné parametry. Jako jsou proměnná async, která učuje, zda je volání asynchronní, a user a password pro určení uživatelského jména a hesla kvůli autentizaci. Po inicializaci objektu následuje nepovinné nastavení HTTP hlavičky, což se provádí prostřednictvím metody setrequestheader. U ní se jako parametr zadává jméno hlavičky a její hodnota. Po těchto procedurách je požadavek připraven k odeslání. To se provádí metodou send. Důležitou proměnnou XMLHttpRequest je readystate, která umožňuje zjišťovat, v jakém stavu se tento objekt nachází. ReadyState může nabývat pěti hodnot [28]: a) 0 (UNSENT ) objekt byl vytvořen, ale ještě nebyla volána metoda open b) 1 (OPENED ) metoda open byla již zavolána, ne však metoda send c) 2 (HEADERS_RECEIVED ) metoda send již byla zavolána, ale ještě není k dispozici tělo odpovědi. Pouze byly přijaty hlavičky odpovědi d) 3 (LOADING ) tělo odpovědi s příslušnými daty již bylo přijato e) 4 (DONE ) všechna data již byla přijata a všechny operace byly dokončeny. Tato konstanta obsahuje příznak, který signalizuje, zda přenos dat skončil chybou, nebo proběhl správně. Odpověď ze serveru můžeme přijmout ve dvou formátech. Jako textový řetězec nebo 19

20 jako DOM XML dokument. Pro jejich přenesení k uživateli slouží dvě proměnné - responsetext a responsexml. Prováděnou operaci také máme možnost zrušit, a to prostřednictvím metody abort. Obrázek 3.4.1: Porovnání klasického webového modelu a modelu Ajax [20] 3.5 Technologie zásuvných modulů Silverlight Tento plugin byl vytvořen společností Microsoft pro tvorbu webových aplikací. Je postaven na technologii.net Framework 3.0 a WPF 17, která protřednictvím jazyka XAML 18 umožňuje vytvořit bohaté uživatelské rozhraní [21]. Tento jazyk zajišťuje oddělení funkční a prezentační vrstvy aplikace. Mezi hlavní výhody technologie Silverlight oproti Adobe Flex, hlavnímu zástupci těchto technologií zásuvných modulů, patří možnost vyvíjet aplikace v několika jazycích. Na výběr jsou jazyky C#, Visual Basic, Ruby, Python a PHP. Podpora OOP 19 konceptu je na vyšší úrovni, než u jazyka ActionScript, používaný v Adobe Flex. Také vývoj na straně serveru i klienta může probíhat na základě znalosti pouze jednoho programovacího modelu a jazyka. Silverlight je platformově nezávislý a je určen do prohlížečů Internet Explorer, Firefox a Safari. Microsoft přímo podporuje systémy Microsoft Windows a Mac OS. Kromě toho je možné Silverlight používat i v systému Linux. A to jako software pod jménem Moonlight, vydaným společností Novel. Silverlight se využívá hlavně pro přehrávaní videa v HD kvalitě. Také je podporován VC-1 kodek, který je využíván technologiemi HD DVD a Blu-ray. V současné době Silverlight existuje ve dvou verzích. Verze 1 používá pro tvorbu apli- 17Windows Presentation Foundation 18Extensible Application Markup Language 19Object-Oriented Programming 20

21 kační logiky JavaScript. Oproti tomu verze 2, vydána v listopadu 2007, nabízí použití i jiných programovacích jazyků, jako jsou IronPython, C# nebo VB.NET. Přináší také nové komponenty. Například tlačítko, zaškrtávací pole, panel nebo plátno JavaFX Pomocí Javy appletů se daly vytvářet první uživatelsky bohaté aplikace. Časem si však Java applety vybudovaly špatnou pověst, a to díky velké instalaci, chvilkovým zamrznutím prohlížeče při startu aplikace, nekompatibilitou JVM 20 mezi společnostmi Sun a Microsoft, a také nepříliš přitažlivým grafickým uživatelským rozhraním [21]. Proto Sun začal vyvíjet technologii nazvanou JavaFX. Aplikace je v této technologii napsána v deklarativním jazyce, zvaném JavaFX Script. Ten usnadňuje vytvoření uživatelsky přívětivého grafického rozhraní. Kromě toho může programátor využít jakoukoliv základní knihovnu jazyka Java [68]. JavaFX je plně integrovaná s JRE 21. Důsledkem toho jsou aplikace vytvořené prostřednictvím této technologie platformově nezávislé, a dokonce mohou být, díky JavaFX Mobile, snadno propojeny s aplikacemi naprogramovanými v Java ME 22, což pro tuto technologii otevírá příležitost velkého rozšíření do mobilních zařízení. V únoru 2009 byla vydána nejnovější verze JavaFX 1.1, jejíž součástí je již výše zmiňovaná technologie JavaFX Mobile [30]. 20Java Virtual Machine 21Java Runtime Environment 22Java Micro Edition 21

22 Kapitola 4 Adobe Flex 4.1 Přehled Adobe Flex je open source framework pro vytváření interaktivních webových aplikací [47]. Slouží jako alternativa k HTML, CSS a Ajax [31]. Oproti těmto technologiím je pro běh Flex aplikací nutná přítomnost specifického pluginu ve webovém prohlížeči. V tomto případě je nutné mít nainstalovaný Flash Player, který slouží jako běhové prostředí dané Flex aplikace. Tato technologie je určená primárně pro běh aplikace na straně klienta, a proto nevyžaduje přítomnost specifického serveru. Vývojářský model je podobný kombinaci HTML a Javascriptu. Jako alternativa HTML pro rozvržení komponent a tvorbu uživatelského rozhraní je zde značkovací jazyk MXML [31]. Naopak roli Javascriptu zde přebírá procedurální jazyk Actionscript 3.0, prostřednictvím kterého se definuje funkční logika aplikace. Actionscript v dnešní době existuje ve třech verzích [36]: 1. Actionscript 1.0 je to jeho nejranější, a také nejjednodušší forma. Stále je použí vána v některých verzích přehrávače Flash Lite Player. 2. Actionscript 2.0 Flash Player provádí kód napsaný v této verzi pomaleji než ve verzi 3.0. Je odvozen od specifikace ECMAScript, ale nevyhovuje ji úplně. Je kompatibilní s dřívější verzí. Využívá se pro aplikace, které nevyžadují velký výpo četní výkon. 3. Actionscript 3.0 nejnovější verze, jejíž kód se provádí nejrychleji ze všech svých verzí. Nespornou výhodou je podpora podmnožiny CSS vlastností. Jediný rozdíl spočívá ve vypuštění pomlčky v názvu dané vlastnosti a jejím zápisem Camel Case stylem. CSS vlastnosti lze zadávat přímo u elementů, nebo je můžeme definovat v externím CSS souboru, který je následně přilinkován k MXML souboru [31] Kompilace Oproti klasické HTML aplikaci je program, vytvořený v Adobe Flex, nutné zkompilovat. Tímto postupem je vytvořen binární soubor, který má menší velikost než textový soubor. Dochází také ke zvětšení výkonu aplikace, jelikož se zdrojový kód nemusí při každém požadavku překládat. Adobe Flex nabízí tři způsoby, jak provést kompilaci programu [31]: 22

23 1. prostřednictvím command-line kompilátoru, obsaženého v Adobe Flex SDK 23 [35] 2. prostřednictvím kompilátoru, integrovaném ve vývojovém prostředí Flex Builder. 3. prostřednictvím kompilátoru implementovaného v Javě. Ten usnadňuje spolupráci se systémy Maven, Ant apod. Po kompilaci vznikne SWF soubor, který je stejný jako vygenerované Flash soubory. Do takto zkompilovaného souboru mohou být vloženy obrázky, hudba, videa, a dokonce i další SWF soubory. A to buď přímo do zdrojového kódu nebo přilinkováním. 4.2 ActionScript Tento objektově orientovaný jazyk byl vydán v roce 2006, je založen na mezinárodním standardizovaném skriptovacím jazyce ECMAScript 4 a plně podporuje ECMA XML skriptovací standard E4X [31][35][36]. Flex aplikace je tak kompatibilní se všemi HTTP servery, verzovacími systémy a serverovými programovacími jazyky. Pro vykonání příkazů tohoto jazyka slouží ActionScript Virtual Machine (AVM), který je integrován s Flash Playerem. Výkonnostní limity první verze AVM1 přestaly časem stačit. Proto byla vyvinuta další verze AVM2, která umožňuje provádět ActionScript 3.0 desetkrát rychleji, než původní verze AVM. Tato nejnovější verze AVM je součástí Flash Playeru 9. ActionScript se skladá ze dvou oblastí z jádra jazyka a z Flash Player API. Jádro jazyka definuje základní stavební jednotky programovacího jazyka, jako jsou cykly, podmíněné příkazy, přiřazení hodnoty nebo datové typy proměnných. Flash Player API je kolekcí tříd, které reprezentují a poskytují přístup ke specifickým funkcím Flash Playeru Actionscript 3.0 Oproti předchozí verzi 2.0, přináší Actionscript 3.0 řadu vylepšení [36]. Ve starších verzích byly runtime výjimky opomíjeny, aby Flash Player nečekaně nezobrazoval dialogová okna. Tento způsob propouštění výjimek však zvyšoval obtížnost ladění programu. Ve verzi 3.0 jsou proto zavedeny tyto runtime výjimky, které umožňují zjistit umístění a zdroj chyb. Dříve byly typy přiřazovány k hodnotám v době běhu programu dynamicky. V nejnovější verzi se v době běhu typ proměnných nemění a za účelem zlepšení systémové bezpečnosti se provádí typová kontrola, prováděná aplikací Flash Player. Actionscript 3.0 zavadí nový koncept tzv. zapečetěných tříd. Tyto třídy obsahují pevný počet atributů a metod, které jsou definovány během kompilace. To umožňuje důkladnější kontrolu programu během kompilace, s tím spojenou jeho vyšší robustnost a lepší využití paměti. Poslední novinkou 23Software Development Kit 23

24 jsou tzv. method closures, které poskytují vestavěné předávání událostí a zajišťují zapamatování si objektu, ze kterého je metoda volána Vytýčené cíle Actionscript byl navržen pro znázornění nového programového modelu, srozumitelného všem vývojářům se základními znalostmi objektově orientovaného programování. Od tohoto jazyka je požadováno dosažení čtyř hlavních cílových oblastí [36]: 1. Bezpečnost dosažení typového zabezpečení pro tvorbu jednoznačného a lehce udržovatelného kódu. 2. Jednoduchost dosažení snadného pochopení programu bez nutnosti neustálého nahlížení do dokumentace. 3. Výkon dosažení možnosti vytvořit komplexní účinný program 4. Kompatibilita dosažení zpětné a dopředné kompatibility a dodržení standardů 4.3 MXML Tento značkovací jazyk, v Adobe Flex 3 ve verzi 2006, byl vytvořen společností Adobe Systems pro tvorbu uživatelského rozhraní Adobe Flex aplikací [33]. Jelikož je založen na jazyce XML, není omezen počtem tagů, jak je tomu u HTML. Ale umožňuje vytvářet si tagy vlastní. Jak už bylo zmíněno výše, aplikaci lze celou napsat v jazyce Actionscript. MXML se liší od něho pouze kratší a přehlednější syntaxí, viz. příklad 4.3a a 4.3b [31], která se používá pro snadnější tvorbu grafického prostředí a rozvržení komponent. Při kompilaci se MXML kód převede na Actionscript a ten se teprve zkompiluje do SWF souboru. <mx:button label="name"/> Příklad 4.3a: MXML zápis Button komponenty [31] var b : Button = new Button(); b.label = "Name"; Příklad 4.3b: Actionscript zápis Button komponenty [31] Jelikož je MXML založen na značkovacím jazyce, vygeneruje Flex Builder při tvorbě nové aplikace následující kód, podobný definci XML souboru, viz. příklad 4.3c [34]. <?xml version="1.0" encoding="utf-8"?> 24

25 [34] <mx:application xmlns:mx=" mxml" layout="absolute"> </mx:application> Příklad 4.3c: Základní definice aplikace ve Flex Builderu První tag specifikuje verzi XML a typ kódování dokumentu [34]. Tag Application definuje tělo samotné aplikace. Jeho atribut xmlns specifikuje jmenný prostor, což je kolekce typů elementů a jmen atributů. A to takových, že jsou jedinečně identifikovány v rámci jmenného prostoru, kterého jsou součástí. Posledním atributem je deklarace rozvržení komponent. Základní hodnota je Absolute. To znamená, že jednotlivé objekty v dané aplikaci budou umístěny podle svých x/y souřadnic. Další možné hodnoty jsou Vertical a Horizontal. Do MXML kódu je možné vkládat Actionscript kód, viz. příklad 4.3d [34][68]. [68] <mx:script><![cdata[... ]]></mx:script> Příklad 4.3d: MXML kód pro vložení Actionscript kódu [34] Obsah tagu CDATA signalizuje MXML parseru, že s tímto obsahem by neměl zacházet jako s kódem napsaným ve značkovacím jazyce [34]. Tento způsob tvorby aplikaci je podobný s tvorbou webových stránek, kde tvorbu prezentační vrstvu aplikace obstarává HTML, zde MXML, a funkční logiku zajišťuje jazyk Javascript, zde Actionscript. 4.4 Flex Builder Flex Builder, nyní ve verzi 3 [23][35], je integrované vývojářské prostředí, určené pro vývoj interaktivních webových aplikací [32]. Je založený na Java IDE 24 Eclipse. Proto může být použit buď jako jeho plugin, a nebo jako samostatný program. Uživatelské rozhraní obsahuje dvě pracovní prostředí source mód a design mód. Source mód slouží k psaní kódu programu v jazycích MXML a Actionscript. K rychlejší tvorbě kódu přispívá zabudovaná nápověda, tzv. code hinting, která umožňuje rychlé doplňování klíčových slov. Design mód slouží k vizuálnímu způsobu tvorby aplikace. Uživatel přetahuje komponenty na pracovní plochu, a tak postupně vytváří celou aplikaci. Přidáním každé komponenty se vygeneruje příslušný kód v source módu. To dělá z Flex Builderu tzv. WYSIWYG 25 editor. Což znamená, že v takovém editoru se změny v jednom módu reflektují do módu druhého. 24Integrated Development Environment 25What You See Is What You Get 25

26 Flex Builder 3 je dostupný ve dvou variantách, a to Standard a Professional. Obě verze obsahují Adobe Flex SDK, čili zpřístupňují kompletní framework Flex, všechny kompilátory, překladače a knihovny komponent. Professional navíc obsahuje např. schopnost vizualizace dat, novou rozšířenou datovou mřížku (Advanced DataGrid) nebo profilovací programy pro sledování paměti a výkonu. Adobe Flex SDK také umožňuje použít technologie Flex a Ajax spolu, a to prostřednictvím Flex-Ajax Bridge [46]. Což je malá knihovna obsahující kód, který lze vložit do Flex aplikace a umožnit její skriptování ve webovém prohlížeči. Flex Builder 3 je velice populárním a účinným, avšak placeným nástrojem, určeným pro tvorbu Flex aplikací. Pro vyzkoušení je dostupná bezplatná šedesáti denní zkušební verze, dostupná na adrese Flex Data Services I když je technologie Flex určena primárně pro tvorbu aplikací na straně klienta, lze ji použít i pro tvorbu služeb obstarávajících výměnu zpráv na serveru, k vytváření přístupů k datům uloženým na něm nebo ke umožnění sdílení souborů jiným klientům [35]. Toto rozšíření Flex frameworku se nazývá Flex Data Services (nově jako LifeCycle Data Services,) a poskytuje nástroje pro realizaci výše zmíněných služeb. V komerčních aplikacích klienti v prezentační vrstvě přistupují k datům přes byznys vrstvu Jelikož je Flex technologie fungující na prezentační vrstvě, musí umět komunikovat s byznys vrstvou, která může poskytovat následující služby - Web service, HTTP service a přístup ke vzdáleným Java objektům. Web service se zpřístupňuje prostřednictvím rozhraní popsaným WSDL souborem. HTTP service se volá přes URL 26 a data se přenáší ve XML formátu. Spojení se vzdáleným objektem se navazuje přes classpath ve Flex aplikaci [37]. Flex Data Services umožňuje využít programový model Data Management Service [38][41], který propojuje sítě, klienty a servery za účelem umožnění přístupu Flex aplikace k distribuovaným datům a zajištění synchronizace dat mezi klientem a serverem. Pokud aplikace vyžaduje, aby data byla uchovávána v paměti serveru krátkodobě, použije v něm Flex aplikace Data Management Service adaptér. Naproti tomu Data management Service Java adaptér má za úkol pracovat s daty uloženými trvale. Výše zmíněné adaptéry mohou být rozhraní nebo dodaný adaptér, který přímo pracuje se standardní perzistentní vrstvou, jako je například SQL nebo Hibernate. Tento programový model podporuje doménové modely, stránkování velkých kolekcí dat na požádání, okamžité automatické načtení odkazovaných objektů, jakmile jsou přístupné a offline ukládání dat do vyrovnávací paměti. K dostání je také open source verze Flex Data Services, zvaná BlazeDS [42]. Umožňuje vytvářet interaktivní webové aplikace buď přímo technologií Flex, 26Uniform Resource Locator 26

27 nebo její kombinací s technologií Ajax, viz obrázek 4.5 [24], čímž snižuje náklady na údržbu těchto aplikací. BlazeDS je dostupný např. na adrese Obrázek 4.5: Flex+Ajax model webových aplikací [24] Flex Data Service 2 Nová verze Flex Data Service, je J2EE 27 aplikace používaná pro datově řízené webové aplikace. A je dostupná ke stažení na Podporuje automatickou synchronizaci dat mezi klientem a serverem (Data Synchronization), rychlý přenos dat mezi nimi a platformovou nezávislost. Podporuje systémy Windows, UNIX i Linux. [39]. Dále poskytuje stránkování dat (Data Paging), nevyžádaný přenos dat ze serveru ke klientovi (Data Push), řešení občasného připojení klienta (Occasionally Connected Client), systém vydávání a podepisování zpráv (Publish and Subscribe Messaging) a kontextovou spolupráci (In-Context Collaboration) [38]. Occasionally Connected Client (OCC) zajišťuje spolehlivé doručení dat oběma směry a umožňuje automatické ošetření dočasných výpadků sítě, které by mohly vést ke ztrátě dat a k vynucenému restartování komunikace mezi aplikací a serverem. Stránkování dat uspokojuje potřebu aplikací po velkých objemech dat, 27Java 2 Platform Enterprise Edition 27

28 jelikož nahrává do paměti větší množství stránek než je potřeba, což snižuje dobu reakce aplikace. Nevyžádaný přenos dat ze serveru ke klientovi znamená, že server může poslat data klientské aplikaci, aniž by o ně zažádala. Tato technika zlepšuje request/response model, u kterého aplikace musela server požádat o aktualizaci svých dat. Takto může server rozeslat data tisícům uživatelům. To se hodí zejména u aplikací, kde se vyžadují aktuální data. Synchronizace dat poskytuje robustní a vysoce výkonný synchronizační mechanismus mezi klientem a serverem. To dává uživatelům Flex aplikací možnost pracovat na lokální kopii dat, což zvětšuje nezávislost dané aplikace na připojení a snižuje rychlost její odezvy. Kontextovou spolupráci realizuje Flex Messaging Service, která zajišťuje klientským aplikacím sdílení dat s ostatními klienty nebo servery. To otevírá také možnost využívat konceptu zvaného co-browsing, který spočívá v tom, že uživatelé sdílejí svoje zkušenosti s ostatními uživateli a spolupracují s nimi v reálném čase. Systém vydávání a podepisování zpráv poskytuje prostředí pro předávání zpráv v reálném čase mezi klientskými aplikacemi a servery. Kromě toho je možné tento systém integrovat s už existujícími systémy na předávání zpráv, jako je například JMS 28. Předávání zpráv tak může dosáhnout stejné spolehlivosti, škálovatelnosti a kvality služeb jako u klasických klientských aplikací. 4.6 Adobe Flex 4 V červenci roku 2008 oznámila společnost Adobe vývoj nové verze Adobe Flex s kódovým označením Gumbo, který bude podporovat novou verzi Adobe Flash 10 [40][43]. Tato verze je dostupná na Gumbo přináší tři základní novinky Design in Mind, Developer Productivity a Framework Evolution [44]. Design in Mind poskytuje framework, umožňující plynulou spolupráci mezi návrhářem a vývojářem. Každá Flex aplikace je svým vzhledem podobná jiné. Je to způsobeno tím, že většina vývojářů využívá Flex vlastnost zvanou Look and Feel pro model komponent (Halo). Přesto je dost těch, kteří si podobu aplikace upravují podle sebe. Nová verze Flex proto přichází s usnadněním vytváření vlastního vzhledu aplikace. Design in Mind tak přináší nové komponenty, které vyhovují modelu pro snadnou úpravu vzhledu, nové efekty, nový model rozvržení komponent, novou syntaxi, rozhraní grafických tříd, novou verzi jazyka MXML a FXG 29. Ten umožňuje převést grafické objekty vytvořené v Adobe Flash do prostředí Flex. Počítá se s tím, že Gumbo bude zpětně kompatibilní s Adobe Flex 3, a že Halo a novým Gumbo komponentám bude umožněno existovat v rámci jednoho MXML souboru. 28Java Message Service 29Flex Graphics 28

29 Další novinkou je tzv. Developer Productivity. Motivací této vlastnosti je snaha poskytnout zákazníkům rysy, na které jsou zvyklí v ostatních programovacích jazycích, a dosáhnout co největší kompatibility se stávajícími normami. Tato snaha přináší výkonný kompilátor, obousměrnou vazbu komponent, zdokonalení využití CSS a automatickou podporu v Adobe AIR 30. Což je platformově nezávislé běhové prostředí, které umožňuje vytvoření bohatých webových aplikací, určených pro stolní počítače, a jejich spouštění jako běžných aplikací. Poslední novým rysem je Framework Evolution. Ten přináší podporu obousměrného textu a rozložení komponent. Využívá nové možnosti Adobe Flash Player 10 a přináší nové video komponenty MXML 2009 Verze Gumbo je postavena na novém jazyku MXML 2009 [45]. Od své starší verze, jazyku MXML 2006, používaného v Adobe Flex 2 a 3, se liší v několika aspektech. Obsahuje několik nových základních tagů. A to tagy Declarations, Definitions, DesignLayer, Library, Private a Reparent, přinášející nové vlastnosti. Například tag Private slouží ke skladování aplikačně specifických informací, které jsou kompilátorem ignorovány. MXML 2009 definuje nový jmenný prostor s prefixem fx. Jelikož je Gumbo zpětně kompatibilní s Flex 3, je zřejmé, že tomu tak bude i u jazyka MXML. Proto nově každý MXML soubor musí mít ve svém kořenovém tagu definovaný pouze jeden jazykový jmenný prostor. V případě nesplnění tohoto požadavku nebude takový soubor validní a kompilátor ohlásí chybu. Pokud bude chtít programátor přidat do již existující Flex 3 aplikace nové Gumbo komponenty, musí u původního MXML dokumentu definovat jmenný prostor, určený pro verzi MXML Pak už může provést požadovaný úkon. Od nové verze Adobe Flex si vývojáři slibují lepší výkon a umožnění větší kreativity při stylování komponent. Vydání verze Adobe Flex 4.0 se předpokládá na konci roku Současně se počítá i s verzí 4.1, která by se měla objevit přibližně v polovině roku Adobe Integrated Runtime 29

30 Kapitola 5 Java Business Integration Java Business Integration je specifikace vytvořená v rámci JCP 31 jako koncept umožňující implementaci SOA. První verze specifikace JBI 1.0 (JSR ) byla přijata v roce 2005 [48][59] a je dostupná ke stažení na oficiálních stránkách JCP na webové adrese O dva roky později, tedy v roce 2007 byl zahájen vývoj specifikace JBI 2.0 (JSR 312). 5.1 JBI architektura JBI poskytuje prostředí pro zásuvné komponenty, které komunikují s danou službou. Ta je popsána jazykem WSDL 2.0 [50]. Komponenty v JBI prostředí se rozdělují na dva typy. Na tzv. Service Engines (SE) a Binding Components (BC) [48][51]. Oba dva typy mohou vystupovat jako poskytovatelé nebo spotřebitelé služeb. Service Engines zpracovávají zprávy v rámci JBI prostředí. Pracují tedy pouze s tzv. NormalizedMessage formátem zpráv [48]. V některých případech nemusíme vytvářet nové SE, jelikož existuje spousta už přednastavených typů této komponenty. Mezi nejznámější patří například XSLT 33 transformace zpráv, nebo SE využívající BPEL 34, POJO 35 a další. Druhým typem jsou komponenty, které zprostředkovávají komunikaci mezi JBI kontejnerem a vnějším prostředím. Ty se nazývají Binding Components. Slouží jako konvertory zpráv z formátu NormalizedMessage do formátu daného vnějším prostředím. Toto zjednodušuje komunikaci mezi různými SOA systémy, jelikož není třeba další prostředník pro přeměnu zprávy do příslušného formátu. Stejně jako u SE existuje řada předpřipravených Binding Components, především pro běžně používané protokoly. Proto není překvapením, že mezi nejpoužívanější typy patří BC pro HTTP nebo pro souborové systémy, které umožňují ze zpráv generovat soubory ukládané na disk, nebo naopak umožňují vyzvedávat soubory z adresáře [58]. Podle specifikace JBI, by minimálně jedna BC měla implementovat WS-I Basic Profile 1.1 [60], což je specifikace vydaná v roce 2006 konsorciem WS-I 36, která umožňuje součinnost mezi webovými službami přes SOAP, WSDL a UDDI 37. Jak už bylo zmíněno výše, komponenty v JBI kontejneru mohou 31Java Community Process 32Java Specification Request 33eXtensible Stylesheet Language Transformation 34Business Process Execution Language 35Plain Old Java Object 36Web Services Interoperability 37Universal Description, Discovery and Integration 30

31 vystupovat jako poskytovatel nebo spotřebitel služeb [49]. Komponenta plnící úlohu poskytovatele má za úkol aktivovat svůj koncový bod, obsahující jméno služby a jméno koncového bodu. Přes něj je daná služba přístupná. Dále komponenta poskytuje popis nabízené služby ve formátu WSDL 2.0 a provádí zpracování požadavků. V neposlední řadě pak komponenta vykonává akce související s danou službou. Posílání zpráv mezi spotřebitelem a poskytovatelem probíhá podle vzoru výměny zpráv. Tyto vzory jsou známy pod zkratkou MEP 38. JBI komponenta, která zastupuje roli spotřebitele služeb, vyhledává dané služby. Neboli přesněji vyhledává WSDL dokument, který je uložen v registru služeb, popisující danou službu, její akce, parametry, umístění na serveru atd. Pokud je služba dostupná dané aplikaci po celý čas jejího běhu, mluvíme o statické závislosti na službě. Dynamická závislost zase umožňuje najít požadovanou službu za běhu aplikace. Takto nalezená služba nemusí být dostupná po celou dobu běhu aplikace. Kromě tohoto vyhledávání spotřebitel vyvolává akce spojené s určitou službou a komunikuje s poskytovatelem podle MEP [49] Komunikace prostřednictvím výměny zpráv Uvnitř JBI kontejneru nekomunikují komponenty přímo se sebou, ale jsou propojeny doručovacími kanály s Normalized Message Router (NMR) [58], což je centrální doručovací mechanismus, který využívá popis služby prostřednictvím WSDL dokumentu a zajišťuje spolehlivé směrování a doručování zpráv. Interakce probíhá výměnou zpráv. JBI zprostředkovává pro tento typ komunikace infrastrukturu předávání zpráv. Ta se skládá ze tří základních elementů [49]: 1. NormalizedMessage - definuje interní formát zpráv, určených pro interakci přes NMR. Takováto zpráva by se měla skládat z obsahu (payload) ve formátu XML, metadat, určených pro autentizaci, transakce atd, a příloh. Ty se využívají typicky pro binární data. 2. MessageExchange - slouží jako kontejner pro zprávy a stavy související s voláním dané služby. 3. Dellivery Channel (DC) - neboli už výše zmíněný doručovací kanál což je obousměrná spojnice mezi JBI komponentami a NMR. Jelikož každá komponenta má pouze jeden DC, musí jeho implementace podporovat souběžné využití tohoto kanálu pro vícevláknové procesy. Zajištění QoS 39 u NMR může být rozděleno do třech úrovní. První je Best effort, kdy zpráva může být zahozena nebo doručena vícekrát. Úroveň At least once zajišťuje, že zpráva nemůže být zahozena, a zároveň můžou být 38Message Exchange Pattern 39Quality of Service 31

32 doručeny její duplikáty. Poslední je Once and only once zaručující, že zpráva je poslána právě jednou. Komunikace komponent s NMR probíhá na základě dvojího typu interakce. Komponenta zahajuje komunikaci vytvořením MessageExchange instance, kterou předá NMR. Druhým typem je naopak akceptování MessageExchange instance, kterou dané komponentě doručí NMR. JBI využívá tzv. pull model, kdy si komponenta zprávu z NMR vyzvedne, až je připravena. Opačným modelem je tzv. push model, kdy je zpráva doručená bez ohledu na to, zda je komponenta nachystána na příjem. Komponenty si zprávy přes NMR střídavě vyměňují do té doby, než jedna z nich pošle instanci zprávu s nastavenou hodnotou done nebo error. Přijímající tuto zprávu převezme, odešle odpověď, akceptující tento stav, a interakci ukončí. Jakým stylem bude probíhat komunikace výměnou zpráv, rozhoduje použití jednoho ze čtyř vzorů [49]. Prvním z nich je vzor zvaný In-Only. Jedná se o standardní jednosměrnou výměnu zpráv, během které spotřebitel posílá zprávu poskytovateli služeb, který jako reakci na tuto zprávu odešle informaci o stavu, viz. obrázek [49]. Druhý vzor je rozšířením předcházejícího a je známý jako Robust In-Only. Přidává oproti prvnímu vzoru spolehlivé jednosměrné doručování zpráv. Při výskytu chyby poskytovatel místo statusu odešle odpověď s nastavenou fault hodnotou. Spotřebitel přijme tuto odpověď a uzavře spojení odesláním done statusu. In-Out je standardní obousměrný vzor, kdy spotřebitel zahajuje komunikaci posláním zprávy, na kterou poskytovatel služby odpoví buď normální nebo chybovou zprávou. Na to spotřebitel zareaguje odesláním příslušného statusu. In Optional-Out je vylepšení předchozího vzoru, kdy je poskytovateli umožněno zvolit vhodnou odezvu, a tedy odpovědí může být normální zpráva, chybová zpráva nebo ukončující zpráva s done hodnotou. Každá instance MessageExchange má svůj vlastní životní cyklus, který se odráží i v hodnotě jejího statusu. Pokud tedy instance byla právě vytvořena, pak je ve stavu ExchangeStatus.ACTIVE. V něm přetrvává do té doby, než je komponentou, která ji vlastní, donucena přejít do stavu ExchangeStatus.DONE. Do tohoto stavu přejde bez ohledu na to, zda je komunikace ukončena normální nebo chybovou zprávou. Může se však stát, že u komponenty vlastnící instanci nastanou technické problémy, které ji znemožní normálně odeslat zprávu. V takovém případě však komunikace může být okamžitě ukončena přechodem instance do stavu ExchangeStatus.ERROR. Takto může být interakce mezi komponentami kdykoliv ukončena ještě před přechodem do stavu DONE. 32

33 Obrázek 5.1.1: Schéma In-Only vzoru [49] Service Unit a životní cykly Service Unit, neboli zkráceně SU, je základní stavební jednotkou pro vývojáře JBI systémů [48][49]. Jedná se v podstatě o specifický obal nastavení JBI komponent a určení jejich činností. Komponenty SE i BC bez SU prakticky nic nevykonávají. Teprve uložení Service Unit na JBI server způsobí, že jsou tyto komponenty aktivovány a je jim umožněno poskytovat své služby. SU je určena svými atributy. Mezi ně patří Description, který obsahuje popis dané SU. Atribut Name vyjadřuje její jméno v rámci Service Assemblies (SA), což je sada Service Unit, která se jako celek nahrává na server [51]. Zbývajícími atributy jsou Target, vyjadřující jméno JBI komponenty, vázané na danou SU, a Status. Ten odráží aktuální stav SU během jejího životního cyklu. Status může nabývat hodnot deployed, shutdown, started nebo stopped, viz. obrázek [49]. 33

34 Obrázek 5.1.2: Přechody mezi stavy životní cyklu Service Unit [49] Také komponenty mají svůj standardní životní cyklus, definovaný JBI [49]. Komponenta začíná v tzv. prázdném stavu. V němž se může nacházet pouze tehdy, pokud nebyla ještě nainstalovaná, nebo naopak, pokud už byla odinstalovaná. Pokud je komponenta ve stavu Started, pak je nabízející nebo přijímající službu. Ve stavu Stopped je naopak komponenta neaktivní, čili neprovádí žádné operace týkající se služeb. Avšak jsou pořád alokovány zdroje pro tuto komponentu. Posledním stavem životního cyklu je Shutdown. Ten je praktický stejný jako stav Stopped. Akorát s tím rozdílem, že zdroje pro tuto komponentu jsou už uvolněny. Tento poslední stav většinou předchází úplnému vypnutí JBI systému nebo odinstalaci dané komponenty. 5.2 Implementace Mezi nejznámější implementace JBI patří Open ESB [52], ServiceMix a PetALS [48]. Open ESB byla vyvinuta společností Sun jako open source implementace ESB 40 se zabudovanou podporou JBI [53]. Je to podniková sběrnice služeb, pod licencí CDDL 41 [52][56], jejíž součástí je i běhové prostředí pro BPEL. Je založena na otevřených standardech, což znemožňuje společnostem prohlásit ji za svůj majetek. S Open ESB lze pracovat ve vývojovém prostředí NetBeans. V jeho verzi je Open ESB už přímo součástí aplikačního serveru GlassFish. Nejnovější verze GlassFish Open ESB v.2 je dostupná ke stažení na adrese Druhou implementací je ServiceMix od Apache Software Foundation pod licencí Apache License 2.0 [57], vydanou v lednu 2004 [54]. Stejně jako u Open ESB, i zde se jedná o open source produkt. Je to distribuovaná ESB 40Enterprise Service Bus 41Common Development and Distribution License 34

35 založená na JBI specifikaci JSR 208 [55] a zahrnuje kompletní JBI kontejner, což znamená, že podporuje všechny části JBI specifikace [59]. Jako jsou NMR atd. ServiceMix lze vyvíjet ve více vývojových prostředí, například v Eclipse IDE. Poslední verze 3.3 byla uvolněna ke stažení na adrese Poslední implementací je PetALS od OW2 42 konsorcia. Jedná se o open source rozšiřitelnou ESB pod licencí GNU LGPL 43. Oproti předchozím implementacím umožňuje nejen pracovat v distribuovaných prostředích a spravovat rozsáhlé architektury, ale také poskytuje framework pro vývoj JBI komponent. Nejnovější verze distribuce je dostupná ke stažení na adrese 42ObjectWeb 43Lesser General Public License 35

36 Kapitola 6 Multifunkční interaktivní Flex aplikace 6.1 Popis a návrh aplikace Tato aplikace má za úkol demonstrovat rysy technologie Adobe Flex a názorně předvést skutečnou interaktivní webovou aplikaci v praxi. Aplikace poskytuje několik funkcí. A to zjištění času v jednom z několika definovaných měst v rozdílných časových pásech, určení data svátku podle jména, zprostředkování funkce kalkulačky a určení souřadnic daného bodu. Kromě poslední zmíněné, jsou ostatní služby poskytovány a implementovány na JBI serveru. Funkce určení souřadnic není vykonávána interakcí se vzdáleným serverem, ale demonstruje schopnost Flex aplikace být soběstačnou lokální aplikací, která by měla splňovat následující požadavky: 1. přehledný a moderní vzhled 2. jednoduché použití 3. funkce volající webovou službu a měnící pouze část aplikace 4. funkce demonstrující soběstačnost aplikace 5. bezproblémový běh v nejpoužívanějších webových prohlížečích Popis použití aplikace, vytvořené na základě těchto požadavků, je přiblížen prostřednictvím Use Case Diagramu, viz. obrázek 6.1, což je diagram, který slouží k zobrazení dynamické struktury aplikace z pohledu uživatele. Také je určen pro definici chování aplikace, aniž by odhaloval její vnitřní strukturu. Po spuštění se uživateli zobrazí v prohlížeči okno s aplikací. Grafické uživatelské rozhraní Flex aplikace bude navrženo tak, aby poskytlo uživateli moderní a přehledný design, blížící se podobě klasických aplikací. Ve vrchní části okna aplikace bude umístěno menu a pracovní plocha aplikace bude rozdělena horizontální čárou na dvě části. V první se budou nacházet služby pro určení času a zjištění data svátku. Určení času uživatel bude ovládat výběrem položky v komponentě ComboBox. U zjištění svátku uživatel zadá požadované jméno do textového pole a klávesou Enter odešle požadavek na server. Ve druhé části pod horizontální čárou bude umístěna kalkulačka a funkce pro určení souřadnic, která bude sloužit jako demonstrace schopnosti Flex aplikace být aplikací nezávislou na podpoře serveru. Komponenta Canvas zde poslouží pro zakreslení souřadnic kurzoru myši. Pro opakované vyprázdnění této komponenty a uvedení funkce do počátečního stavu zde bude komponenta Button. 36

37 6.2 Realizace návrhu aplikace Klient Obrázek 6.1: Use Case Diagram Klient byl vyvíjen v prostředí Adobe Flex Builder 3, který je volně dostupný ke stažení jako zkušební šedesáti denní verze na adrese Grafická podoba aplikace byla vyvíjena v design módu, umožňující technikou Drag&Drop vytvořit layout jednoduché aplikace. Díky přítomnému rozhraní vlastností komponent a možnosti využití CSS lze snadno domodelovat vzhled a chování komponent, a tak dát aplikaci specifickou podobu. V source módu bylo doprogramováno chování aplikace a ošetřeny případy uživatelova chybného zadání vstupních hodnot. U funkcí využívajících služeb JBI serveru je většina funkční logiky implementována na serveru. Na straně klienta se pak nachází pouze jednoduché výpočty a úpravy vstupních i výstupních dat. Aplikace obsahuje v adresáři /Nazev_Projektu/src dva zdrojové kódy: 1. MenuAplikace.mxml hlavní soubor obsahující celou aplikaci 37

38 2. Styles.css obsahuje styly pro jednotlivé komponenty aplikace MenuAplikace.mxml je hlavním, a zároveň spouštěcím souborem aplikace. Jak už bylo zmíněno výše, grafická podoba byla vytvořena v design módu v prostředí Flex Builder 3. Tato tvorba byla současně v source módu reflektována generováním MXML kódu, který tvoří podstatnou část zdrojového kódu aplikace. Do MXML je vložen ActionScript kód, který obsahuje definice funkcí, volajících služby na JBI serveru a umožňujících rozpohybovat jednotlivé komponenty. Aplikace je vyzkoušená ve většině dnešních používaných prohlížečích, a to konkrétně ve verzích Mozilla FireFox , Microsoft Internet Explorer 6.0, Opera 9.26, Google Chrome a Safari 4 Beta Server Implementace JBI serveru probíhala ve vývojovém prostředí NetBeans 6.0.1, poskytujícím Open ESB. Pro zprostředkování daných služeb posloužil integrovaný aplikační server GlassFish verze 2. Pro přehlednost je každá služba vytvořena jako samostatná kompozitní aplikace, což je aplikace složená z různých služeb uvnitř servisně orientované architektury. Do této aplikace je pak v našem případě importován EJB modul (jako soubor JAR, vytvořený po kompilaci modulu), který poskytuje aplikační logiku služby,. Na JBI serveru v jazyce Java byly tímto způsobem implementovány tři služby určení času, zjištění svátku a zajištění výpočetních operací pro funkci kalkulačky. V adresářích /Nazev_EJBModulu/src/java/Nazev_Baliku jsou uloženy zdrojové kódy jednotlivých služeb: 1. TimWebService.java 2. CalendarWebService.java 3.CalculatorService.java Jejich WSDL popisy společně s XML schématy jsou uloženy v adresářích /Nazev_KompozitniAplikace/src/jbiasa: 1. Tim.wsdl 2. Calendar.wsdl 3. Calcul.wsdl 6.3 Uživatelská dokumentace V této dokumentaci je uživateli přiblíženo ovládání této interaktivní Flex aplikace, její chování a vzhled. Samotná funkcionalita služeb zde nebude uváděna. Po spuštění se v prohlížeči zobrazí okno aplikace s pevně danými 38

39 rozměry, které je vycentrované na střed prohlížeče. Okno se skládá ze dvou hlavních částí: 1) Menu 2) Pracovní plocha Menu obsahuje dvě hlavní položky Nový a Nápověda. Položka Nový obsahuje pět podpoložek, viz. obrázek 6.3a, a to: 1) Světový čas 2) Kalkulačka 3) Kalendář 4) Souřadnice 5) Reset První čtyři slouží pro povolení nebo zakázání přístupu k jedné ze čtyř definovaných služeb, což se provede kliknutím na danou podpoložku, u které se toto projeví označením zaškrtávacího pole. Pokud není zaškrtávací pole u podpoložky označeno, je příslušná služba zakázána, viz. obrázek 6.3a. Poslední podpoložkou je volba Reset, která uvede aplikaci do počátečního stavu, jak je vidět na obrázku 6.3b. Položka Nápověda pak obsahuje pouze jedinou podpoložku O programu. Po jejím výběru je vyvoláno modální okno s informacemi o Flex aplikaci. 6.3a: Zakázání služby Kalendář 39

40 6.3b: Flex aplikace v počátečním stavu Pracovní plocha je rozdělena horizontální čárou na dvě části. V první z nich se nachází služby pro určení světového času a data svátku. Služba určení času se zadává výběrem města v komponentě ComboBox. Nad ní se v textovém poli zobrazí aktuální čas příslušného časového pásma, a to ve dvanácti hodinovém formátu s anglickým určením dopolední nebo odpolední doby. Služba určení svátku se spouští zadáním jména do textového pole se štítkem Jméno a odesláním na server klávesou Enter. První písmeno musí být ve jméně velké, zbytek malý, jinak aplikace zobrazí chybovou hlášku. Pokud vše proběhne v pořádku, zobrazí se uživateli ve druhém textovém poli přesné datum svátku ve formátu den:měsíc a vlevo od tohoto textového pole se v prázdném čtverci zobrazí příslušné roční období. Ve druhé části pracovní plochy se nachází funkce určení souřadnic a integrovaná kalkulačka, která se ovládá klikáním myši na jednotlivá tlačítka. Pro stisk jednotlivých tlačítek se nedá použít vstup z klávesnice. Při špatně zadaném prvním nebo druhém operandu zobrazí aplikace okno s příslušnou chybovou hláškou. Totéž nastane, pokud uživatel bude dělit nulou. Kalkulačka obsahuje klasické možnosti ovládání, např. zadání čísel, základní operátory nebo možnost nastavit zápornost čísla. Zmáčknutím tlačítka se symbolem = se zadaná čísla a operátor odešlou k výpočtu na JBI server a výsledek se zobrazí na displeji kalkulačky. Počáteční stav kalkulačky se obnoví tlačítkem C. Poslední funkcí aplikace je určení souřadnic, která se ovládá kliknutím tlačítka myši na zvolené místo na bílou plochu, která je tvořena komponentou Canvas. Potom se na daném místě vykreslí oranžový bod, viz. obrázek 6.3c, 40

41 a u nápisu Osa X a Osa Y se zobrazí souřadnice bodu. Tuto funkci lze uvést do počátečního stavu tlačítkem Smaž. Obrázek 6.3c: Vykreslení bodu se zobrazením souřadnic 6.4 Dokumentace pro programátora Rozdělení funcionality Tato dokumentace je rozdělena na dvě části. V první z nich je popisována funkcionalita a implementace klienta, který je zde realizován jako Adobe Flex aplikace. Zde je podrobněji přiblížen postup, jakým byla tato interaktivní webová aplikace vytvořena. Jsou zde zmíněny a popsány komponenty a jejich atributy, které zajistily aplikaci bohaté uživatelské rozhraní pro implementované služby. Ve druhé části je popisována implementace samotných služeb na JBI serveru. Je zde přiblížen postup vytváření WSDL dokumentu, jako popisu služby, v rámci kompozitní aplikace v NetBeans prostředí. Dále pak je přiblížen postup vzniku a naprogramovaní webové služby v jazyce Java jako EJB modulu Adobe Flex klient Služba určení času První funkcí je určení světového času podle vybraného města, která je implementována jako webová služba, určená Webservice tagem, viz. příloha 8.1. Na daném příkladě je v tagu webová služba definována svým id atributem. Dále obsahuje adresu WSDL dokumentu, který popisuje danou službu a její parametry. Tento dokument si Flex aplikace stáhne a uloží 41