Integrace aplikací v prostředí cloud

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA INFORMAČNÍCH TECHNOLOGIÍ KATEDRA SOFTWAROVÉHO INŽENÝRSTVÍ

Diplomová práce

Integrace aplikací v prostředí cloud Bc. Jáchym Culka

Vedoucí práce: Ing. Vojtěch Knězů 9. května 2012

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 9. 5. 2012

........................................................

iii

Poděkování Tímto bych rád poděkoval svému vedoucímu Ing. Vojtěchovi Knězů za vedení, pomoc a věcné připomínky, které mi pomohly při tvorbě této práce. Nesmím také opomenout mojí rodinu, které vděčím za morální a hmotnou podporu, bez které by tato práce nikdy nevznikla. V neposlední řadě bych také rád poděkoval vývojářům Switchyard ESB, kteří byli neúmorní při zodpovídání mých dotazů a nápomocni při řešení nastalých problémů.

v

Abstract This thesis deals with various aspects of integration of Internet applications in cloudpowered infrastructure with respect to principles of service oriented architecture. Design and implementation part is focused on creating application based on values of software architecture mentioned above, along with respecting constrains resulting from usage of specific deployment platform. Application is built on top of the chosen enterprise service bus platform – Switchyard ESB – and it’s designed to embrace and take advantage of its possibilities and provided features. Target platform for the application is built as a cluster in cloud infrastructure provided by Amazon Elastic Compute Cloud and it’s configured to enable reliable platform for deploying Switchyard-based applications.

Abstrakt Práce pojednává o specifikách integrace Internetových aplikací v prostředí cloudové infrastruktury za použití principů a technik architektury orientované na služby. Praktická část se zaměřuje na návrh a implementaci aplikace, která odpovída principům výše zmíněné softwarové architektury a její struktura je postavena na základech daných zvolenou podnikovou běrnicí služeb – Switchyard ESB. Takto vystavěná aplikace je pak nasazena na serverový cluster, který byl vytvořen v cloudové infrastruktuře Amazon Elastic Compute Cloud.

vii

Seznam tabulek Tabulka 2.1 – Přehled nejvyužívanějších komerčních ESB ................................................ 19 Tabulka 3.1 – Typy instancí na EC2 (Převzato z [4] a platné k 22. 4. 2012)..................... 37 Tabulka 3.2 – Nastavení Bezpečnostní skupiny instancí.................................................... 45 Tabulka 5.1 – Data ze zátěžového testu............................................................................. 70

ix

Seznam obrázků Obrázek 2.1 – Ilustrace přímo (point-to-point) propojených aplikací ................................. 6 Obrázek 2.2 – Ilustrace architektury Hub-and-Spoke ......................................................... 9 Obrázek 2.3 – Ilustrace architektury se sběrnicí................................................................. 10 Obrázek 2.4 – Ilustrace kompozice služeb v SOA (s úpravami převzato z [1]) ................... 12 Obrázek 2.5 – Ukázka BPMN procesu ............................................................................. 16 Obrázek 2.6 – Ilustrace SCA ............................................................................................. 23 Obrázek 2.7 – Ilustrace vzniku pojmu Cloud .................................................................... 25 Obrázek 2.8 – Ilustrace clusteru s vyvažováním zátěže ....................................................... 31 Obrázek 2.9 – Ilustrace clusteru kombinujícího výše uvedené přístupy ............................. 32 Obrázek 3.1 – Schéma jedné instance ............................................................................... 43 Obrázek 3.2 – Topologie nasazeného systému .................................................................. 44 Obrázek 4.1 – Globální pohled na služby v aplikaci .......................................................... 52 Obrázek 4.2 – Schéma komponent a jazyků jejich implementace ...................................... 58 Obrázek 4.3 – Ukázka vizuální reprezentace Store File komponenty implementované v BPMN 2.0.............................................................................................. 60 Obrázek 4.4 – Diagram propojení komponent v detailu na službu Dropbox Sync ............ 62 Obrázek 5.1 – Diagram testovacího prostředí ................................................................... 69

xi

Obsah Prohlášení .......................................................................................................................... iii Poděkování ..........................................................................................................................v Abstract ............................................................................................................................ vii Abstrakt ............................................................................................................................ vii Seznam tabulek ...................................................................................................................ix Seznam obrázků ..................................................................................................................xi Obsah .............................................................................................................................. xiii Kapitola 1

Úvod........................................................................................................... 1

1. 1.

Motivace ............................................................................................................. 1

1. 2.

Cíle práce ............................................................................................................ 1

Kapitola 2 2. 1.

Rozbor problému a zasazení do kontextu .................................................... 3

Aplikační integrace.............................................................................................. 3

2.1.1.

Historický přehled ...................................................................................... 3

2.1.2.

Integrace podle vrstev.................................................................................. 4

2.1.3.

EAI ............................................................................................................. 7

2.1.4.

SOA.......................................................................................................... 11

2.1.5.

ESB........................................................................................................... 17

2.1.6.

Přehled a výběr ESB .................................................................................. 18

2.1.7.

SCA – Software Component Architecture................................................. 23

2. 2.

Cloud computing.............................................................................................. 25

2.2.1.

IaaS ........................................................................................................... 26

2.2.2.

PaaS .......................................................................................................... 28

2.2.3.

SaaS .......................................................................................................... 29

2. 3.

Clustering ......................................................................................................... 31

2.3.1.

Cluster ...................................................................................................... 31

xiii

2.3.2.

Vyvažování zátěže ......................................................................................31

2.3.3.

Failover......................................................................................................33

2.3.4.

Clusterování v cloudu ................................................................................33

Kapitola 3

Nasazení systému .......................................................................................35

3. 1.

Infrastruktura ....................................................................................................35

3.1.1.

Amazon EC2 .............................................................................................35

3.1.2.

Amazon Elastic Load Balancer ...................................................................39

3.1.3.

Amazon Elastic IP......................................................................................39

3.1.4.

Omezení ....................................................................................................39

3. 2.

Operační systém ................................................................................................40

3. 3.

Aplikační platforma ...........................................................................................41

3.3.1.

Nasazení JBoss AS 7 ..................................................................................41

3.3.2.

Nasazení Switchyard ESB ..........................................................................42

3. 4.

Topologie systému .............................................................................................43

3.4.1.

Bezpečnostní politika .................................................................................44

3.4.2.

Komunikace klienta se systémem s ELB .....................................................45

Kapitola 4

Integrace služeb .........................................................................................47

4. 1.

Integrační scénář ................................................................................................47

4.1.1. 4. 2.

Přehled vhodných služeb............................................................................48

Návrh a implementace .......................................................................................50

4.2.1.

Formalizace požadavků ..............................................................................50

4.2.2.

Návrh služeb a komponent ........................................................................51

4.2.3.

Implementace komponent .........................................................................57

4. 3.

Specifika vývoje .................................................................................................63

4.3.1.

REST a SOAP WS ....................................................................................64

4.3.2.

OAuth .......................................................................................................64

4.3.3.

Maven a Jar hell .........................................................................................64

4.3.4.

Transformery .............................................................................................65

4.3.5.

Vývoj na rozvíjející se opensource platformě ..............................................65

4. 4.

Rozšíření nástroje pro podporu a správu ............................................................66

xiv

Kapitola 5

Nasazení aplikace a testování ..................................................................... 67

5. 1.

Specifické unit testování.................................................................................... 67

5. 2.

Nasazení a škálování systému ............................................................................ 68

5. 3.

Metodika testování............................................................................................ 68

5. 4.

Výsledky testování ............................................................................................ 70

Kapitola 6

Závěr ........................................................................................................ 73

Kapitola 7

Použitá literatura ....................................................................................... 75

Příloha A Konfigurace MOM .......................................................................................... 78 Příloha B Služby a přístupové údaje ................................................................................. 79 Příloha C Uživatelský návod ............................................................................................ 80 Příloha D Obsah CD ....................................................................................................... 81 Příloha F Seznam použitých zkratek ................................................................................. 82

xv

Kapitola 1 Úvod 1. 1. Motivace Cloud computing je trend, který ač dnes je jeho podstata mnohdy ukryta pod povrchními marketingovými nálepkami, nastoluje v současné době stejnou revoluci, jakou provedly IBM s Microsoftem v osmdesátých letech s osobními počítači. Podobně jako u ní se nebude jednat o přerod ze dne na den, ovšem jako zatím u každé zásadní změny v IT její zásah bude mít větší dopad, než ten předcházející. Cloud computing není vlak, co právě vyjíždí ze stanice, ale rychlík, který neustále zrychluje a je jen na nás, kdy naskočíme, čím déle však budeme čekat, tím obtížnější to bude. Podobně důležitý je fenomén, který posunuje vývoj softwaru zase o stupínek výše v abstrakci, kde celé webové aplikace jsou dnes již stavěny jako kompozice hotových aplikačních bloků, kde přidaná hodnota je pouze v chytrém volení a propojování stavebních kostek. Tak jako si dnes již jen málokdo dovolí přepych nevyužívat aplikační knihovny, když zpracovává XML, podobně se bude v budoucnu, ale lze to vidět již dnes, přistupovat k celým aplikačním komponentám, pouze tam, kde je dnes omezení stejné platformy bude „omezení“ globálního Internetu. Motivace této práce je tedy více než zřejmá, uchopit příležitosti, které oba tyto technologické trendy nabízejí a pokusit se v jejich kombinaci nalézt způsob vývoje software, který bude v následujícím desetiletí živit celé nové odvětví softwarového vývoje.

1. 2. Cíle práce Popišme faktické cíle, které se skrývají za obecnějším úvodem i názvem této práce „Integrace aplikací v prostředí cloudu“. Logickou dekompozicí názvu na jednotlivé pojmy nám naznačuje kostru problému, jehož části je nezbytné v průběhu práce prozkoumat. Co je a jakými způsoby lze řešit integrace aplikací? Co představují cloudové aplikace a jaké jsou možnosti pro jejich integraci? Jakým obtíže přinese nasazení integračního systému 1

Kapitola 1

Úvod

2

v cloudové infrastruktuře? Co se vlastně skrývá za pojmem cloudu a má tento přístup k integraci nějaký přínos? Práce se ovšem nezabývá jen analýzou řešení vytyčeného problému, ale také implementací řešení ukázkové instance takového problému. Implementací ukázkového řešení spočívá z konfigurace a nasazení zvolené integrační platformy, ESB Switchyard, do cloudové infrastruktury s podporou jejího clusterování pro škálovatelnost a vyšší spolehlivost. Vytvoření modulu pro tuto zvolenou integrační platformu, který umožní snadnou integraci zvolené množiny cloudových aplikací SaaS využitím jejich webových služeb. Upravení existujícího nástroje pro vývojovou platformu Eclipse, pro zjednodušení integraci zvolených aplikací, které jsou v modulu podporovány. A implementace vzorových integrujících aplikací, které využijí výše uvedené dílčí části, a jejich otestování v cloudově nasazené integrační platformě.

Kapitola 2 Rozbor problému a zasazení do kontextu V této kapitole bude vystavěna a popsána hierarchie principů a technologií, které je nezbytné obsáhnout a pochopit pro jejich následné využití při ve vlastním procesu integrace aplikací v prostředí cloud computingu. Jak již samotné zadání této práce naznačuje, jde o skloubení dvou na první pohled možná nesouvisejících informatických oborů, tedy Cloud computingu a aplikační integrace, nicméně tato a následující kapitoly ukážou, že jsou si tyto obory velmi blízké a jejich vzájemná propojení či spolupráce, je cesta kterou se s největší pravděpodobností bude ubírat softwarový vývoj v tomto či dalších desetiletích.

2. 1. Aplikační integrace 2.1.1. Historický přehled1 Integrace aplikací je obor softwarového inženýrství, jehož historie není zas tak daleká. První podnikové aplikace sice běžely již v 60. letech minulého století, nicméně byly vázány buďto na výrobce hardware či vlastní vývojovými týmy a software byl ve své podstatě pouze zakázkově napsaný pro konkrétní sálový počítač a podnik. Teprve rozvoj osobních počítačů, jež se staly záhy komoditou, jejíž cena byla stačována velkým množstvím výrobců a následným vytvořením široké platformy, která přilákala i výrobce software, dal vzniknout prostředí, pro běh softwaru od vícera výrobců a tím i prvním pokusům o jejich integraci. Přes první „naivní“ propojování systémů, které ústily v kvadraticky rostoucí složitost s každým dalším integrovaným systémem, se kolem roku 1998 objevil koncept Enterprise application integration (EAI), který přináší do komunikace každého s každým další softwarovou vrstvu, která obstarává řízení komunikace mezi jednotlivými aplikačními komponentami a tím snižuje počet komunikačních kanálů i složitost návrhu takového systému.

1

Čerpáno z [17], [21]

3

Kapitola 2

Rozbor problému a zasazení do kontextu

4

Rozvinutím konceptu EAI a mohutnou expanzí webových technologii na počátku 21. století vzniká zatím poslední milník aplikační integrace, architektura orientovaná na služby (Service oriented architecture, SOA), softwarový vzor pro tvorbu aplikací, který stírá rozdíly mezi integrací a vlastními aplikacemi, respektive mění původní smysl slova aplikace jako kompaktního softwarového celku. V následujících podkapitolách budou podrobněji rozebrány různé přístupy pro integraci aplikací včetně těch uvedených v předešlém historickém přehledu. Ačkoliv zdaleka ne všechny popsané přístupy jsou pak v implementační části aplikovány, bude zajímavé popsat jejích vývoj a společné či rozdílné rysy.

2.1.2. Integrace podle vrstev 2 2.1.2.1.

Integrace na datové úrovni

Patrně historicky nejmladším způsobem propojování aplikací je integrace pomocí datové vrstvy. Tento způsob staví na skutečnosti, že většina aplikací funguje tak, že konzumují a produkují data, která se následně ukládají do nějaké, například relační, databáze. Vnitřní struktura aplikace je tedy pro integrátory nedůležitá a mohou s ní pracovat jako s černou skříňkou, což eliminuje nutnost studovat technickou dokumentaci a umožňuje integraci i pro aplikace které nedisponují definovaným externím API anebo nemají přístupné zdrojové kódy.

Vlastní sdílení datové vrstvy pak může být realizováno několika způsoby.

2

•

Sdílení databáze mezi aplikacemi

•

Replikace databází tak, že každá aplikace využívá vlastní a ty se vzájemně synchronizují

Čerpáno z [17], [21]

Kapitola 2 •


5

Výměna souborů obsahující celou nebo část databáze a jejích následný import

Ač se tento přístup k integraci jeví jako poměrně dobrý a i v dnešní době najde své využití, vyvstávají při realizaci tohoto systému úskalí, která především při větším množství integrovaných aplikací představují značné problémy. Mezi největší jistě patří fakt, že velmi často je integrita dat kontrolována nejen na databázové úrovni, ale i v obchodní logice, proto pokud je umožněno více aplikacím měnit data uložená ve sdílené datové vrstvě, může dojít k porušení celistvosti dat. Omezení agility systému, tj. schopnosti přizpůsobení vyžadovaným změnám, takto propojených aplikací je dalším problémem ústícím ze závislosti všech zúčastněných aplikací na jednom databázovém schématu, jehož jakákoliv změna má za následek její distribuci do všech dotčených aplikací, obdobný problém nastává při změně dodavatele vlastní databáze kvůli různým dialektům dotazovacího jazyka.

2.1.2.2.

Integrace na úrovni obchodní logiky

Postoupíme v hierarchii klasické aplikace o úroveň výš k obchodní logice. Integrace na této vrstvě se jeví jako logický způsob, kdy můžeme využít celé softwarové komponenty jiných aplikací a tím se například vyvarovat problémům s datovou integritou popsaných výše. Nicméně i tento způsob má pro obecné využití značné nedostatky.

Je víceméně nezbytné mít zevrubnou znalost struktury všech integrovaných aplikací, které by navíc měly být dopředu připraveny na tento úkon a poskytnout „rozumná“ aplikační rozhraní. Například v případě aplikací, kde se smývají rozdíly mezi vrstvou obchodní logiky a logikou uživatelského rozhraní, jde toto realizovat velmi obtížně nebo za cenu velkých změn v aplikaci, které bývají nežádoucí. Problém taky nastává v zavedení velmi těsných závislostí mezi aplikacemi, které opět snižuje agilitu celého systému, kde změna v jedné aplikaci je promítnuta do nutné úpravy všech ostatních, které jsou se zasaženou „propojeny“. S těsnou závislostí (coupling) také vyvstává problém kriticky rostoucí složitostí celého systému, kdy v extrémním případě je pro n

Kapitola 2


6

aplikací nutné spravovat 𝑛 ∗ (𝑛 − 1)/2 spojů, což představuje počet hran v úplném grafu s n uzly.

Obrázek 2.1 – Ilustrace přímo (point-to-point) propojených aplikací

V neposlední řadě dochází problémům v případě integrování aplikací, stavěných nad různými platformami, jako například .NET a Java, kde se navíc musí řešit vzájemné interakce skrze platformě nezávislou nebo společnou technologii, případně nový mezilehlý prvek, což do již tak spletitého systému vnáší další složitosti.

2.1.2.3.

Integrace na úrovni uživatelského rozhraní

Pro úplnost uveďme poslední ze tří vrstev obvykle využívaných při návrhu aplikací je vrstva uživatelského rozhraní a i tato vrstva může být využita k aplikační integraci, i když intuitivně je tento způsob nejvíce problémový. Nicméně existují případy, kdy nám tento přístup může zajistit požadované cíle. Například při integraci takzvaných „legacy“ aplikací (tj. historicky nasazené a udržované aplikace, často bez podpory původního dodavatele), které jsou spravovány a fungují, ale jakýkoli zásah či jejich změna není možná, například z důvodu, že již není podporována výrobcem, neexistují k ní zdrojové kódy nebo není k dispozici programátor, jež by ovládal jazyk, ve kterém je aplikace napsána.

Kapitola 2


7

K integraci takové aplikace nás například může vést zautomatizování vyplňování formulářů nebo jiné repetitivní činnosti. S nástupem webových aplikací dostal tento způsob integrace druhý dech, kde metodou screen-scrapingu (metoda extrakce informací z aplikace způsobem, který využívá pouze funkcí určených a přístupných pro samotné koncové uživatele – typicky parsování HTML stránek) můžeme omezeně integrovat aplikace, které nedisponují možnosti přístupu skrze webové API nebo je tato možnost omezená a lze ji takto obejít. Obtíže spojené s tímto druhem integrace jsou evidentní. Jakákoliv změna aplikace a to i uživatelského rozhraní vede k selhání takového systému, navíc jsme odkázáni pouze na funkcionalitu, která je zprostředkovaná skrze ono uživatelské rozhraní a musíme čelit problémům například se stránkováním obsahu, kterým v ostatních výše zmiňovaných metodách vyhneme.

2.1.3. EAI Pojem Enterprise application integration, tedy integrace podnikových aplikací, není ani v odborné literatuře úplně přesně definován nebo se spíše liší autor od autora. Samotný název je možné chápat i velmi široce, popisuje vlastně celou disciplínu aplikační integrace, ale v této práci pod tímto pojmem myslíme to, co následně popsáno v této kapitole. V předchozí podkapitole byly nastíněny některé přímočaré postupy, které byly a stále jsou pro některé použití vhodné a adekvátní. Nicméně pro obecné použití obsahují příliš mnoho zásadních nedostatků. Právě tyto nedostatky se snaží adresovat množina postupů a návrhových vzorů, technologií či celých softwarových řešení, které se formálně ukrývají právě za zkratkou EAI. Motivace EAI podle Wikipedie 3 je následující:

3

[28]

Kapitola 2


8

EAI je proces vzájemného propojování podnikových aplikací v rámci jedné organizace, za účelem zjednodušení a zautomatizování podnikových procesů v největším možném rozsahu, za podmínky vyhnutí se hlubokým zásahům do existujících aplikací nebo datových struktur. Uveďme také známý nebo alespoň zajímavý výrok, který je přisuzován britskému informatikovi Davidu Wheelerovi: „All problems in computer science can be solved by another level of indirection… Except for the problem of too many layers of indirection.“ 4 Tento princip, tedy zavedení další vrstvy software mezi aplikace, označovaný také jako middleware, je pro EAI klíčový. Jako příklady topologie middlewaru používaného pro EAI uveďme dvě krajní řešení označovaná jako hub-and-spoke a messaging bus, nicméně tyto přístupy jsou si ve svém jádru velmi podobné a v praxi se můžeme setkat s kombinováním těchto principů.

2.1.3.1.

Hub-and-Spoke

Topologie hub and spoke nebo také broker má za motivaci snížit kvadratickou složitost při integraci aplikací stylem každý s každým, který je uveden v předchozích podkapitolách. Dociluje toho tak, že veškerá komunikace mezi aplikacemi prochází přes jeden centrální prvek označovaný jako hub, případně broker. Jeden z hlavních cílu tohoto přístupu byl postaven na minimalizaci změn v integrovaných aplikacích a tudíž se veškeré zpracování komunikace provádí v centrálním bodě. Tam dochází k procesům, jako je transformace zpráv, validace, směrování nebo asynchronní doručení zpráv a v neposlední řadě i logování či audit zpráv.

4

[29]

Kapitola 2


9

Obrázek 2.2 – Ilustrace architektury Hub-and-Spoke

Výhody tohoto přístupu jsou snížení propojení mezi aplikacemi z 𝑂(𝑛2 ) na 𝑂(𝑛), s tím související jednodušší nahrazení jednotlivé aplikace v rámci systému a možnost centralizované správy a konfigurace nebo logování zpráv. Mezi nevýhody patří zavedení místa, jehož selhání způsobí selhání celého systému. S tímto souvisí také vysoké nároky na výkonnost tohoto bodu, protože se může snadno stát úzkým hrdlem celého systému. Tento fakt se dá částečně eliminovat federalizací těchto hubů, tj. rozdělení jednoho centrálního prvku do topologie několika, podobně jako je to běžné u směrovačů v ethernetových sítích, a tím rozložení zátěže mezi několik prvků. Další zásadní problém těchto řešení byl fakt, že byly historicky nabízeny jako monolitické a velmi drahé systémy, které pracovaly s proprietárními protokoly a technologiemi a pro podniky nasazující tyto systémy pak představovaly takzvaný vendor-lock-in problém, tedy nemožnost změnit dodavatele bez nutnosti drastických změn celého systému.

2.1.3.2.

Message Bus

Protějškem centralizované topologie Hub-and-Spoke je analogie systémové sběrnice uvnitř počítačů, kde jsou počítačové komponenty připojeny ke komunikačnímu médiu, které samo o sobě nedisponuje žádnou řídící logikou. Podobně tak jsou aplikace připojeny k logické sběrnici, která bývá realizována jako Message Queue – fronta zpráv, tedy softwarová komponenta podporující asynchronní zasílání zpráv, která umožňuje být distribuována v rámci širší podnikové infrastruktury.

Kapitola 2


10

Obrázek 2.3 – Ilustrace architektury se sběrnicí

Oproti centralizovanému hubu, kde komunikační logika jako transformace, validace nebo směrování probíhalo centrálně, musí mít v tomto konceptu aplikace tyto procesy obsaženy jako adaptéry ve vlastní struktuře. Také v těchto adapterech funguje překlad mezi obdrženými zprávami a jejich mapováním na vlastní funkce aplikace. Tedy v podstatě podobné řešení jako jsou současné API webový služeb, ovšem postavené na proprietárních technologiích. Tím, že jsou tyto zprávy spravovávány samotnými aplikacemi, dochází k distribuci zátěže, která byla v Hub-and-Spoke topologii soustředěna na jednom místě.

2.1.3.3.

Shrnutí EAI

Obě zmíněné krajní metody nastiňují obecnou podobu EAI, tedy zavedení autonomní softwarové vrstvy, která umožní komunikaci mezi jednotlivými aplikačními systémy s únosnou složitostí. Kromě umožnění tohoto prvotního cíle, však přináší i významné výhody, které plynou především z možnosti kontrolovat, spravovat a monitorovat dění v rámci celého systému v jedné specializované a jasně ohraničené softwarové vrstvě. Na principu kombinace obou předchozích přístupu vzniklo velké množství komplexních systémů, které umožňují nejen zprostředkovat komunikaci mezi podnikovými aplikacemi – Mediation, ale i zprostředkovat globální přístup ke kompozicím několika aplikací a realizovat tak nějaký business proces přesahující funkcionalitu několika aplikací – Federalization. Rozhraní, které bylo označováno jako adaptér v minulé podkapitole (2.1.3.2), pak vzniká kolem existující aplikace, tedy postupem „Zdola nahoru“. Vlastní aplikace se tedy snažíme více či méně ohýbat či jim přidávat navíc funkcionalitu, která neimplementuje žádnou obchodní logiku a slouží jen pro zpřístupnění dílčích částí aplikace pro následnou integraci. Zároveň zdůrazněme pro srovnání s následující kapitolou, která se bude týkat SOA – architektury zaměřené na služby, že posláním EAI je integrace monolitických aplikací, které jsou postaveny podle tradiční vrstevnaté architektury (datový model, obchodní logika, a

Kapitola 2


11

uživatelské rozhraní). Tento typ aplikací se také často označuje jako Informační sila nebo Ostrovy automatizace (v aj. Information silos, islands of automation), především z důvodu, že pro přístup k jejím procesům či datům je pro ostatní aplikace nerovný či omezený ve srovnání s mateřskou aplikací, což se zdá být logické a nezbytný, ale jak uvidíme v další kapitole, není pro integraci podnikových aplikací nevyhnutelný.

2.1.4. SOA 5 Tato podkapitola má za cíl vymezit pojem SOA a jejích důsledků. Uveďme také, že podle principů zde popsaných je navržena a vystavěna vlastní implementační část práce a proto tomuto tématu bude věnován větší prostor. SOA, tedy Service Oriented Architecture – architektura zaměřená na služby, je architektonický vzor pro tvorbu softwarových informačních systému, který staví služby jako základní stavební prvky celého systému. Služby jsou nezávislé softwarové komponenty, které obsahují funkcionalitu pro dosažení nějakého strategického cíle, kterou poskytují externím programům skrze jasně dané a neměnné rozhraní, označované jako kontrakty služeb. Komplexní funkcionalita, představující automatizaci nějakého obchodního procesu, tak jak je implementována v monolitických aplikacích (viz předchozí podkapitola), je realizována kompozicí jednotlivých služeb, které mohou být sdíleny mezi vícero takto komponovaných procesů. Taková kompozice služeb pak představuje složenou službu, kterou můžeme opět znovu využít při realizaci dalších procesů. Veškeré služby v rámci podnikového systému se pak nachází v registru služeb (z angl. servicy registry), který shromažduje veškeré služby, které jsou v podniku využitelné. Může se jednat o ryze virtuální kolekci, která slouží jako podklad při návrhu a kompozici procesů tak i softwarové řešení, nad kterým se lze dotazovat či hledat služby podle vybraných kritérií.

5

Čerpáno převážně z [1]

Kapitola 2


12

Obrázek 2.4 – Ilustrace kompozice služeb v SOA (s úpravami převzato z [1])

2.1.4.1.

Kontrakt

Kontrakt nebo smlouva je základní prvek každé služby, který ji reprezentuje v rámci systému. Skládá se jak z technického popisu rozhraní a jednoho či více dokumentů popisujících službu. Technický popis rozhraní a jeho detailní specifikace popisující jaké metody služba poskytuje, či jaké datové struktury se používají při komunikaci, což v technologiích webových služeb odpovídá WSDL a XML schéma dokumentům. Také jsou zde popsány pravidla týkající se například bezpečnosti či podpory transakcí. V netechnických dokumentech je pak prostor pro detailní popis služeb, podmínky provozu a zaručené spolehlivosti. Takzvané SLA – Service level agreement.

2.1.4.2.

Vlastnosti služeb v SOA

•

Standardizovaný kontrakt služby – Tato vlastnost je základním kamenem každé služby. Zaručuje, že služba pracuje podle specifikací popsaných v kontraktu. Dále pak že funkce popsané v kontraktu odpovídají konvencím zavedených v podniku a formát dat definovaných pro komunikaci je v rámci systému společný. Brání tak nutnosti neustálých transformací formátu popisující jednu faktickou entitu.

•

Volné spojení (loose coupling) – Kontrakt služby nesmí být závislý na její vlastní implementaci služby a musí umožňovat její změnu či úplnou náhradu, pokud bude zachována veškerá funkcionalita specifikována kontraktem.

Kapitola 2


13

•

Abstrakce služby – Veškerá implementační specifika by měla být skryta za kontraktem služby, procesy využívající službu nesmí být ovlivňovány vlastní implementací.

•

Znovu využitelnost služby – Služba musí být navrhována tak, aby byla umožněna a podpořena její opakované použití.

•

Autonomie služeb – Služba by měla mít kontrolu nad prostředím, v němž je nasazená a neměla by být ovlivňována jejím použitím v rámci procesů. Změna běhového procesu nasazením například do pobočky by nemělo záviset na ničem jiném než na službě samotné.

•

Granularita služby – Služba by měla poskytovat takovou funkcionalitu, která je pro systém ideálně použitelná. Není například žádoucí vytvářet služby tak atomární, že jejich využití bude podmíněno vždy stejnou kompozicí několika primitivních služeb. Na druhé straně, nesmí být služba ta specializovaná, aby to vedlo omezení její znovu využitelnost.

•

Bezstavovost služby – Služba by měla být bezstavová, pokud není nezbytně nutné, aby tomu bylo jinak. Snižují se tak výpočetní nároky a zvyšuje se možnost škálování služby.

•

Skládání služeb – Služby musí být schopny zapojení do kompozitních procesů nezávisle na jejich počtu, velikosti a složitosti.

2.1.4.3.

Druhy služeb

Služby v rámci SOA můžeme rozčlenit na 3 kategorie [1] podle několika základních vlastností služeb jako znovuvyužitelnost nebo druh logiky reprezentující v systému.

Entity services Pod tento typ se řadí služby realizující vlastní obchodní logiku celého systému. Tato logika je rozdělena mezi služby tak, že jsou jednotlivé funkce seskupeny pomocí vztahu k jednotlivým obchodním entitám. Jako příklad můžeme uvést entitu faktura, které reprezentována jako Entity service může obsahovat funkce jako aktualizovatCenu nebo odstranit. Funkcionalita v těchto službách bývá velice dobře znovuvyužitelná.

Task services Typ Task services zastupuje služby, které reprezentují komplexní kompozice ostatních služeb za účelem realizování nějakého obchodního procesu. Tyto procesy pak představují funkcionalitu obdobnou té, kterou obstarávají monolitické aplikace. Skládání těchto služeb za účelem realizace procesu se nazývá orchestrace služeb a tento druh služeb v ní figuruje jako řídící komponenta. Vzhledem k tomu, že jsou tyto služby výrazně specializované je u nich možnost znovu využití znatelně omezena.

Kapitola 2


14

Utility services Do tohoto balíku patří služby, které jsou nutné a potřebné pro realizace procesů v rámci systému, ale neimplementují vlastní obchodně zaměřenou logiku. Typickým příkladem jsou různé transformační a mapovací procedury, logování či rozhraní pro práci s rozličnými zdroji dat. Tento typ služeb je pak možné využít napříč celou podnikovou strukturou, protože není omezen na specifické obchodní entity.

2.1.4.4.

SOA a webové služby

SOA je jako architektonický vzor plně nezávislý na technologické platformě, nad kterou je staven. Webové služby se však v praxi ukázaly jako ideální technologické prostředí, ve kterém lze naplňovat očekávané vlastnosti služeb tak, jak byly popsány výše v této kapitole a proto je často sama SOA přímo spojována s jejím použitím. Baterie technologií, která se skrývá za pojmem webových služeb, pak adresuje jednotlivé koncepty, které tvoří samotnou SOA. UDDI – Universal Description, Discovery and Integration – jako framework pro popis služeb umožňující jejich katalogizaci se dá využít pro implementaci registru služeb. WSDL – Web Services Description Language – je ideálním formátem pro popis technické části kontraktů. SOAP/XML – Simple Object Access Protocol – obstarává platformě nezávislý formát pro vlastní implementaci zpráv. Ačkoliv je SOA ve velké většině přisuzován koncept webových služeb orientovaný na zprávy, kde se využívají technologie uvedené výše, lze SOA postavit i na využití webových zdrojů REST webové služby. Vzhledem k tomu, že podle serveru Programmable Web 6 je REST služeb přibližně čtyřikrát více (údaje vztaženy k únoru 2012), než těch fungujících přes SOAP, lze očekávat, že popularita SOA postavená nad RESTovým základem poroste. Tento trend lze doložit i knihou – SOA with REST: Principles, Patterns & Constraints – významného a respektovaného autora píšícího o tématu SOA, Thomase Erla, které má vyjít v dubnu 2012. Pro SOA postavenou nad REST se pak pro popis kontraktů dá opět využít s menším ohnutím formát WSDL 2.0 nebo méně rozšířený WADL. Zprávy pak mohou být reprezentovány například široce rozšířeným a podporovaným formátem JSON nebo XML

6

www.programmableweb.com

Kapitola 2


15

Vzhledem k motivaci této práce, Integraci aplikací v prostředí cloud, je pak využití webových služeb víceméně implicitně obsaženo v samotném zadání (vzhledem k tomu, že předmětem jsou cloudové, tj. SaaS a PaaS viz 2.2.2, 2.2.3), proto se vlastní úvaha o použité technologii omezí na webové služby zaměřené na zprávy nebo na zdroje. Více v kapitole Integrace služeb.

2.1.4.5.

Business alignment 7

Business alignment je termín označující schopnost informačního systému či oddělení pružně reagovat na měnící se potřeby podniku a jeho strategických cílů. V souvislosti se SOA pak můžeme mluvit o zvětšení jeho uplatnění skrze možnost rychleji a s menšími náklady měnit obchodní procesy odlišnou orchestrací existujících služeb. Dodatečné nové služby se pak do procesu integrují, jakožto standardizované komponenty, jednodušším způsobem než celé monolitické aplikace, u kterých se předpokládá nutnost specializovaného přístupu. V neposlední řadě jsou služby definovány pouze svými kontrakty, což zajišťuje jejich snadnou modifikaci nebo výměnu či využití externího poskytovatele, což může znatelně urychlit schopnost odpovědi na nové obchodní požadavky.

2.1.4.6.

Orchestrace služeb

Orchestrace služeb již byla v textu zmíněna (2.1.4.3), jedná se o schopnost řídit tok informací skrze množinu služeb pro zajištění konkrétního řešení problému či realizaci obchodného procesu. Realizací orchestrace služeb pak vzniká opět služba – Task service. Orchestrace je tedy pro orchestrované služby transparentní a tím nesnižuje jejich znovuvyužitelnost v rámci SOA řešení. Podobným konceptem, který je určen ke skládání služeb ve větší celky, je choreografie, která je popsána v odstavci níže.

BPMN 2.0 a BPEL Business process model and notation a business process execution language jsou dva nejvyužívanější jazyky pro popis a modelování procesů. Oba se dají využít k popisu orchestrace služeb, který je pak následně zpracován enginy – orchestrátory vykonávající vlastní řízení procesů.

7

[1] (uváděn jako Business and Technology Domain Alignment)

Kapitola 2


16

Obrázek 2.5 – Ukázka BPMN procesu

Podstatným rozdílem mezi oběma jazyky je fakt, že BPMN 2.0 oproti BPEL přesně definuje i grafickou notaci pro popis procesů. Přesto, že je BPMN 2.0 jako jazyk expresivnější, umožňující zápis konstrukcí, které nejsou realizovatelné v BPEL, jsou oba jazyky pro popis orchestrací zaměnitelné. Funkční podmnožina BPMN 2.0 obsahuje veškerou expresivní sílu BPEL a tak bývá často možné přes počáteční vzájemnou transformaci (pokud využijeme jen zmíněnou podmnožinu konstrukcí BPMN 2.0) vykonávat tyto jazyky nezávisle na použitém orchestrátoru.

2.1.4.7.

Choreografie služeb

Oproti orchestraci je choreografie služeb spjata přímo s jejich vlastní strukturou. Choreografie pak znamená, že jednotlivé služby mohou volat další v implementaci nějaké funkcionality a výsledky těchto volání pak například dále používat. Použitím choreografie se do značné míry snižuje znovuvyužitelnost služeb zavlečením explicitních závislostí na konkrétní službě, nicméně tato závislost je umenšena faktem, že služba je závislá pouze na kontraktu odkazované služby nikoliv na její implementaci, jak ostatně plyne s filozofie SOA. Služby, na kterých je daná služba závislá by pak měly být explicitně uvedeny v kontraktu dané služby, aby byly závislosti jednoduše dohádatelné a zaručitelné.

2.1.4.8.

Shrnutí hlavních rysů SOA

•

Jedná se o softwarový architektonický vzor postavený kolem služeb, jejich skládání a opakovaném vyžívání napříč celým podnikovým systémem.

•

Služba je definovaná kontraktem a programy, které ji využívají, jsou závislé na informacích popsaných v kontraktu, ne na vlastní implementaci.

•

Orchestrací služeb vzniká implementace obchodního procesu a tímto způsobem nahrazuje funkcionalitu původních monolitických aplikací.

•

Implementace služeb probíhá „shora dolů“, nejdřív je definován kontrakt a podle něho se programuje vlastní logika služby.

Kapitola 2


17

•

Praktická realizace SOA je významně spojená s technologiemi webových služeb, které zastávají roli společného jazyku při integraci systémů s různým technologickým pozadím.

•

SOA je evolucí nikoliv revolucí EAI, zároveň je možné tyto přístupy provozovat vedle sebe.

•

Koncept služeb a jejich kompozice zvyšuje business alignment IT v rámci podniku implementující SOA oproti EAI

•

Služby také mohou vzniknout ze stávajících aplikací v systému, kde jsou jednotlivé kontrakty implementovány částmi původní aplikace, která může fungovat paralelně s novou architekturou a umožnit tak zavádět SOA postupně.

2.1.5. ESB ESB – Enterprise service bus – integrační platforma postavená nad obecně zavedenými otevřenými standardizovanými technologiemi, jako jsou například webové služby a XML, XSLT nebo BPMN, sloužící jako kostra pro implementaci servisně orientované architektury v podnikovém systému. Motivací ESB je poskytnutí takových technických prostředků, které umožní integrovat aplikace – služby v rámci systému postaveného podle principů SOA s minimální nutností programovat stále se opakující podpůrné (utility) služby a procedury, jako transformace, směrování správ či orchestrátorů procesů. Pojmem ESB tedy označujeme nástroj, s jehož pomocí lze vystavět systém odpovídající principům SOA, ale jeho samotná existence v systému využití SOA neimplikuje a může být nasazován i v systémech integrujících monolitické aplikace podle principů EAI, kde je také jeho historický základ. Ačkoliv ESB není konkrétní produkt, ale spíše obecný název nástroje, jejichž implementace a šíře schopností se liší podle jejich výrobce, uveďme funkce, které jsou pro tento nástroj typické •

Webové služby – SOAP, WSDL

•

Konverze struktury dat – XSLT

•

Transformace protokolů dat – JMS, HTTP, RMI

•

Transformace formátů dat – XML, JSON, POJO

•

Směrování statické nebo na základě hlavičky či těla zprávy

•

Zabezpečení – HTTPS, Web Services Security

Kapitola 2


•

Transakční zpracování – WS-Coordination

•

Mapování kontraktů na vlastní implementaci služeb

•

Orchestrace procesů

•

Monitorování, logování, audit

•

Validace, úprava dat

•

Řazení a buferování zpráv a jejich spolehlivé doručení

•

Kombinování nebo slučování zpráv

•

Clustrování a distributivnost

18

Použití otevřených standardizovaných technologií a služeb pak implicitně říká, že je možné pomocí ESB integrovat služby bez ohledu na platformu nebo jazyk ve kterém jsou implementovány. Poslední bod z výčtu vlastností – clustrování a distributivnost – je přirozeným požadavkem na takový systém, protože k zajištění vysoké dostupnosti, spolehlivosti a výkonnosti služeb je nezbytné zajistit minimálně stejné nebo vyšší takové kvalitativní charakteristiky i pro samotnou zastřešující platformu jakou je ESB.

2.1.6. Přehled a výběr ESB Práce byla od začátku směřována pro nasazení na platformě JBoss ESB 8, především díky expertním znalostem vedoucího práce o praktickém nasazení tohoto produktu. Nicméně během průběhu počáteční fáze práce byl do rozvahy zahrnut i velmi mladý a dynamicky se rozvíjející open source produkt SwitchYard 9 taktéž z velké části vyvíjen JBoss divizí společnosti Red Hat. S takto předem zvolenými mantinely byla otázka výběru zjednodušena na 2 produkty, které se ukázaly jako velmi diferencované a jejich základní rysy se i přes prakticky stejný účel výrazně lišily. Více o jejich srovnání v podkapitole JBoss (2.1.6.2.a). Přestože byl výběr zúžen na dva zmíněné produkty, je přínosné uvést i základní přehled ESB systémů, které byly v době psaní této práce široce rozšířeny a využívány, jak z oblasti komerčního/placeného softwaru, tak i open source softwaru.

8 9

http://www.jboss.org/jbossesb http://www.jboss.org/switchyard

Kapitola 2

2.1.6.1.


19

Komerční/proprietární

Krátký přehled komerčních produktů označovaných jako ESB nebo splňující vlastnosti ESB v rámci širšího řešení. Pro ilustraci přibližná cena těchto řešení se pohybuje v řádech ve stovkách tisíc korun za licenci omezenou na jeden procesor. Samozřejmě s výjimkami v obou extrémech. Přestože je ESB jakožto produkt implementující SOA určen k integraci různých platforem a tudíž na něj nejsou kladeny nároky ohledně platformy/jazyka, ve kterém je sám implementován, nelze si nevšimnout totální dominance produktů postavených na Javě/JVM, kde je jedinou výjimkou je Microsoft BizTalk Server na .NET. Název produktu BizTalk Server Oracle Service Bus

Platforma Licence .NET Proprietární Java Proprietární

WebSphere ESB

Vlastník Microsoft Oracle TIBCO Software IBM

JBoss ESB

Red Hat

Java

Fuse ESB

FuseSource

Java

Mule ESB Enterprise webMethods ESB Platform

MuleSoft

WSO2 ESB

ActiveMatrix Service Bus

Java

Proprietární

Java

Java

Proprietární OSS / LGPL / Komerční podpora OSS / Apache / Komerční podpora Proprietární

Software AG

Java

Proprietární

WSO2

Java

OSS / Apache / Komerční podpora

Tabulka 2.1 – Přehled nejvyužívanějších komerčních ESB

2.1.6.2.

Opensource

Pro opensource ESB systémy je příznačné, že za jejich vývojem kromě, globální komunity stojí ve většině případů jedna konkrétní organizace/společnost, která samotný bezplatný software vyvíjí ve dvou podobách. Zdarma dostupnou opensource verzi, s omezenou technickou podporou a verzi s plnou technickou podporou a případně nadstandardní funkcionalitou. Také je velmi obvyklé sdílení jednotlivých komponent ESB systému mezi vícero různými produkty, a to nejen v rámci jedné organizace vyvíjející více systémů s podobným využitím.

Kapitola 2


20

Následující přehled několika OSS produktů, které jsou v době psaní práce nejpopulárnější, s výčtem některých zajímavých/unikátních vlastností.

Mule Community Edition •

Open source verze Mule ESB Enterprise

•

Nejpoužívanější ESB na trhu

•

Značné rozdíly mezi Enterprise a Community verzí

•

Cloud connectors – Set předpřipravených služeb, které automatizují využívání cloudových služeb. V podstatě velmi podobná vlastnost, kterou si klade za cíl implementovat praktická část této práce pro zvolený ESB.

Service Mix •

Apache Foundation

•

Postaven kolem standardu JBI – zjednodušeně řečeno, standard pro integraci a komunikaci komponentů tvořící ESB a mající za cíl v ideálním případě využívat komponenty, jako například BPEL orchestrátor služeb, ESB různých výrobců zaměnitelně.

•

Open source verze Fuse

•

Totožná s placenou verzí

•

Integruje Camel

Camel Přesto, že se nejedná o ESB, ale „pouze“ o engine implementující nejvyužívanější EIP – Enterprise integration pattern – tedy řešení běžných problémů při komunikaci zaměřené na zprávy, jako směrování, skládání a rozdělování zpráv, transformace spousty dalších, je často využíván jako komponenta v různých ESB. •

Musí být nasazen v ESB nebo jiném běhovém kontejneru, či jako komponenta aplikace.

•

Umožňuje využít skriptování (např. Groovy, Ruby, JavaScript) pro popis a implementaci běžných integračních problémů mezi jednotlivými službami.

•

Je vhodný pro použití, když je třeba vyřešit integrační problém a ESB je pro tuto činnost příliš/zbytečně mocný.

•

Je komponentou JBoss Switchyard.

Kapitola 2


21

from("direct:start") .choice() .when() .ruby("$request.headers['user'] == 'admin'") .to("seda:adminQueue") .otherwise() .to("seda:regularQueue"); Zdrojový kód 2.1 – ukázka použití skriptování v enginu Camel

2.1.6.2.a

JBoss ESB a Switchyard

V této sekci bude vybrán konkrétní ESB server jako základ pro implementaci integrace webových služeb v prostředí cloud. Jak již bylo na začátku této kapitoly uvedeno, výběr byl pro uvedené důvody omezen na JBoss ESB a Switchyard, obojí jako produkty divize JBoss společnosti Red Hat, která se zabývá vývojem opensource middleware softwaru na platformě Java. Pod vývojovou divizi JBoss vzniká několik desítek open source projektů, jež některé nejúspěšnější jsou pak s technickou podporou poskytovány zpoplatněně pod značkou mateřské firmy Red Hat. Jako několik nejznámějších jmen projektů uveďme JBoss aplikační server, Seam framework, RESTEasy a Hibernate. Před vlastním porovnání obou produktů a výběrem vhodnějšího, uveďme hlavní kritéria, která ovlivní vlastní volbu. •

Umožnit nasazení v cloudu

•

Rychlá učící křivka

•

Aktivní vývoj a komunita

•

Využití nových moderních principů a technologií

•

Rozvoj či očekávaný budoucí vývoj

•

Množství dokumentace a příkladů

JBoss ESB vs. Switchyard JBoss ESB je jediným z obou porovnávaných produktů, který je poskytován i jako komerční řešení, což implikuje jeho vyladěnost a velké množství dostupných příkladů a dokumentace. Jeho historie sahá k roku 2006 a projektu Rosetta, ze kterého vychází. Je založen na explicitním užití MOM (message oriented middleware) pro realizaci posílání zpráv mezi jednotlivými službami. Jeho nasazení je omezeno na JBoss aplikační servery ve verzích 5 a 6 a podpora verze 7 není plánována. Naproti tomu Switchyard je projekt stále v před-produkční verzi, jehož vývoj probíhá přibližně od ledna 2011, s prvním milníkem (milestone 0.1) v březnu a první oficiální

Kapitola 2


22

vývojovou verzí (0.1) v červnu 2011. Je postaven nad standardem SCA (Service Component Architecture), který byl uveden vytvořen v roce 2007 a poskytuje kostru pro implementaci SOA aplikací, jejíž struktura by byla obdobná napříč všemi ESB produkty implementující SCA. Switchyard lze provozovat jako modul v JBoss AS 7 10, jako komponentu v rámci jiné aplikace nebo jako komponentu, která je spuštěna při běhu unit testu. Z toho je patrné, že se jedná o velmi kompaktní a běhově nenáročný systém, který však poskytuje všechny základní funkcionality očekávané od ESB. V následujících dvou úryvcích zdrojových kódů, které realizují stejnou funkcionalitu, lze demonstrovat, co se myslí explicitním využitím MOM a jak se stejná funkcionalita implementuje ve Switchyardu. ServiceInvoker invoker = new ServiceInvoker("DemoServices","ServiceB"); Message message = MessageFactory.getInstance().getMessage(); message.getBody().add("Hi there!"); invoker.deliverAsync(message); Zdrojový kód 2.2 – Ukázka poslání zprávy v JBoss ESB @Reference public ServiceB svc; ... svc.sayGreeting("Hi there!"); Zdrojový kód 2.3 – Ukázka „poslání zprávy“ ve Switchyardu

Po relativně krátkém rozhodování, byl vybrán Switchyard jako platforma pro základ k integraci cloudových služeb. V následujícím výčtu bodů je shrnuto jaké důvody vedly k tomuto rozhodnutí.

Proč byl zvolen Switchyard

10

•

Lze provozovat na JBoss AS 7, je to oproti 6 výrazně přepracovaná verze, která mimo jiné výrazně snižuje jeho systémové nároky a rychlost spuštění, což jsou vlastnosti, které se jeví jako podstatné pro cloudové nasazení.

•

Nejasná budoucnost JBoss ESB. O Switchyardu se hovoří jako o jeho nástupci a logicky je zajímavější pro práci spíše výzkumného charakteru využívat, co možná nejaktuálnější technologie a přístupy, něž technologicky letité, avšak velmi stabilní produkty.

http://www.jboss.org/as7

Kapitola 2


23

•

Je výzvou pracovat s produktem, který se vyvíjí tak říkajíc „pod rukama“.

•

Je pravděpodobné, že se v budoucnu dočká integrace nebo podpory s Openshift cloudovou platformou, která poskytuje možnost nasazení aplikací na dynamicky škálovaných JBoss 7 serverech, vzhledem k tomu, že se jedná o zásuvný modul. Tímto by bylo jeho nasazení v cloudové infrastruktuře maximálně automatizováno.

•

Oproti JBoss ESB je zde hojně využito anotací na úkor rozsáhlých XML konfigurací, což je ryze subjektivně sympatičtější přístup.

•

Vzhledem k velmi živému vývoji je zde možnost obohatit vlastní vývoj i výsledky této práce.

2.1.7. SCA – Software Component Architecture 11 Ačkoliv již bylo v této práci mnoho věnováno popisu a motivaci SOA, poskytuje nám tento koncept pouze velmi hrubé obrysy, jakým způsobem by měla výsledná aplikace vypadat, ale prakticky nic nám neříká o tom jak konkrétně a za použití jakých technologií takovéto aplikace komponovat. SCA stojí někde mezi pojmy SOA a ESB, kde můžeme brát jako architektonický pohled na aplikaci prost implementačních detailů a ESB jako konkrétní produkt vhodný pro nasazení aplikací, které jsou stavěny právě podle SOA. Problémem je, že každý ESB může mít pro vývojáře zcela odlišný aparát pro dosažení velmi podobného cíle a tím do velké míry znemožňovat migraci nejen samotných aplikací, ale také znalostí vývojářů budující integrované aplikace.

Obrázek 2.6 – Ilustrace SCA

11

Zdroj především [2]

Kapitola 2


24

Oba tyto problémy se snaží adresovat SCA, která vznikla spoluprácí předních výrobců integračních platforem jako BEA, Oracle, IBM a SAP. SCA definuje přístup, jakým způsobem je možné vytvářet služby/komponenty a jak zaručit aby tyto komponenty pracovaly v součinnosti. Pro popis SCA aplikací se využívá SCDL – Service Component Definition Language, který je typicky realizován jako XML soubor, ve kterém je definována struktura samotné SCA aplikace, která se skládá z elementů uvedených na obrázku výše. Při troše zjednodušení můžeme SCA prvky popsat následovně. Každé z komponent je umožněna implementační nezávislost, ať už se jedná o Javu nebo BPEL či Spring komponentu, každá z těchto komponent pak definuje, jaké služby poskytuje (Service) a jaké vyžaduje pro svůj běh (Reference). Vlastní komponenta pak může být tvořena rekurzivně podkomponentami, jak je znázorněno prvkem A. Kompozitním elementem je pak ohraničena aplikace, která je nasazena do běhového prostředí SCA. Propojení referencovaných služeb s vlastní implementací komponenty (označovaného jako wiring), jak je znázorněno plnou čárou mezi komponentami, je realizováno plně v režii SCA běhového prostředí. Přerušované čáry symbolizují povýšení (promotion) lokálních referencí a služeb na služby globální, tedy ty přesahující rámec SCA běhového prostředí. Pro tyto povýšené služby/reference je pak nutné explicitně uvést, jakým způsobem budou tyto spoje realizovány, ať už se jedná o webové služby a SOAP protokol nebo JMS a protokol MOM. V případě SOAP by se pak jako definice interface služby využilo WSDL, které by mohlo i být automaticky generováno například z Java interfaců níže postavených komponent. SCA samo o sobě nespecifikuje jaké jazyky či vazby jsou podporovány, není ani specifikováno jakým způsobem komunikují komponenty v rámci kompozitního elementu, tuto volnost nechává na rozhodnutí jednotlivých tvůrců SCA běhového prostředí. [2] <service name="A" promote="Component1/A"> Zdrojový kód 2.4 – Ukázka SCDL pro pospis kompozitní aplikace (neopdpovídá obrázku výše)

Kapitola 2


25

2. 2. Cloud computing O cloud computingu nebo o cloudu bylo v textu několikrát zmíněno a ač je tento termín prakticky všudypřítomným zaříkávadlem posledních několika let, vyčleníme pro vyjasnění tohoto pojmu následující podkapitolu.

Obrázek 2.7 – Ilustrace vzniku pojmu Cloud

Původ vlastního názvu cloud – anglicky mrak – se s největší pravděpodobností váže na použití symbolu mraku při popisu síťové topologie, kde symbolizoval nejčastěji Internet nebo síť, jejíž detailní popis neměl pro vlastní síťovou topologii význam a byl takto abstrahován. Z původu názvu by se možná dalo vyvozovat, že cloud je totéž co Internet, ale naneštěstí to není tak jednoduché, i když v poslední době je výraz cloud marketingovými odborníky aplikován prakticky na vše, co jen o Internet zavadilo. To co pojem cloud nebo cloud computing zastřešuje je poskytování různých informačních služeb pomocí sítě Internet [3]. Mezi takové služby patří softwarové aplikace, vývojové platformy nebo výpočetní infrastruktura. Vyvstává možná otázka, jak se liší cloudová aplikace a klasická interaktivní webová stránka, odpověď zní, že hranice mezi interaktivní webovou stránkou a jednoduchou cloudovou aplikací je neostrá a záleží na úhlu pohledu každého z nás. Jako jedno z kritérií můžeme zvolit například řešení nějakého obchodního problému a mezi první webové/cloudové aplikace pak můžeme označit webová rozhraní pro zdarma dostupné emailové schránky, která jistě splňují takovou definici cloudové aplikace, řeší jistý obchodní problém – vyřizování komunikace a jsou k dispozici prostřednictvím Internetu respektive webového prohlížeče.

Kapitola 2


26

V následujících třech kapitolách budou rozebrány tři hlavní přístupy pro využití informačních služeb v cloudu, a to infrastruktura jako služba (2.2.1), platforma jako služba (2.2.2) a software jako služba (2.2.3). Nicméně nejdříve objasněme, co znamená spojení, „jako služba – as a service“, které je společné pro všechny jmenované.

Jako služba Pokud se podíváme na termíny, které jsou v cloudu jako služba dostupné, tedy software, platforma a infrastruktura, je evidentní, že jedná o produkty, které byly historicky užívány podobně jako například psací pero. Člověk, který chtěl psát perem, si ho musel nejdřív koupit a pak ho používat. A když se opotřebovalo či zničilo, musel si koupit nové. Tento model byl typický pro všechny tří zmíněné produkty, klasickým příkladem je například obměňování licencí kancelářských balíků či kupování nových serverů. A právě tento přístup se s cloud computingem mění a prodejní model, který je nově aplikován, je podobný například odebírání elektřiny z elektrárenské sítě. Tam se také platí pouze za vlastní spotřebu a běžný člověk si také nekupuje jednou za pár let nový dieselagregát, aby uspokojil svoji potřebu po elektrické energii.

2.2.1. IaaS IaaS – Infrastructure as a service – infrastruktura jako služba, je, jak již název napovídá, poskytování hardwarové infrastruktury, jako výpočetních stanic, diskové kapacity, aniž by konzument věděl, kde přesně se fyzická zařízení nacházejí a přistupoval k nim pouze srze Internet. Například místo aby si nakoupil server s diskovým polem o určité kapacitě a ten pak někde zapojil, nastavil a spravoval, pronajme si takovou kapacitu u některého poskytovatel IaaS a data na toto úložiště ukládá prostřednictvím Internetu. Podobné je to u počítačů, namísto jejich fyzického pořízení a spravování, vytvoříme virtuální stroj, který budou reprezentovat jeho kvalitativní charakteristiky jako instrukční sada, počet výpočetních jader, jejich výkonnost či paměť, a na ten pak nahrajeme systém a aplikace, jako na fyzický disk, ovšem k interakci využijeme pouze Internet. Výhody a nevýhody oproti konvenčnímu používání počítačové infrastruktury shrňme do následujícího výčtu bodů.

Výhody •

Přenesení správy a konfigurace fyzických zařízení na poskytovatele.

•

Možnost rychle reagovat a efektivně na aktuální potřeby, například pořídit si několik desítek tisíc virtuálních výpočetních jednotek pouze na několik týdnů. Toto by se dalo použít například pro renderování animace reklamních spotů či filmů.

Kapitola 2


27

•

Nižší ekologická zátěž na jednotku výkonu. Ve velkém globálním měřítku a díky využívání virtuálních strojů je možné pro poskytovatele infrastruktury udržovat optimální vytížení celého systému.

•

Možnost využití technologií, které vyžadují expertní znalosti nebo jsou neekonomické pro nasazení v malém. Například diskové kapacity s velmi vysokou spolehlivostí.

•

Přesun nákladů z fixních na variabilní.

Nevýhody •

Omezení kontroly nad hardwarem. Poskytovatel většinou nabízí unifikovaná řešení a využití konkrétního typu hardwaru není možné.

•

Přenesení důvěry na poskytovatele v otázce zabezpečení dat.

•

Významná závislost spolehlivosti poskytovatele služeb.

•

Závislost přímého využívání hardware na internetovém připojení.

•

Různá technická omezení. Například nemožnost provozovat několik virtuálních serverů v jedné lokální podsíti a nefungující multicast.

2.2.1.1.

Využití

V této práci je IaaS přímo využita pro nasazení vlastního integračního prostředí Switchyard. Ačkoliv by bylo vhodnější využít pro tento druh problému PaaS, v době psaní této práce nebyl žádný poskytovatel, který by tuto konkrétní platformu nabízel nebo umožňoval rozšíření v tomto směru. Byla tedy využita „pouze“ IaaS a vlastní prostředí bylo spolu i s podpůrnými systémy na tuto infrastrukturu nasazeno, což umožnilo seznámit se i s problémy týkajících se nasazení takovéto platformy, které by v případě použití PaaS byly odstíněny. Bylo již zmíněno, že pro nasazení integrační platformy bude využit IaaS, otázkou však zůstává, jaký konkrétní poskytovatel byl pro tuto potřebu zvolen. Toto bude předmětem následující podkapitoly.

2.2.1.2.

Výběr poskytovatele IaaS

Ačkoliv poskytovatelů IaaS v dnešní době existuje velké množství a vznikají prakticky každým dnem (rekrutují například se z webhostingových a serverhousových společností), pro potřeby této práce byla většina parametrů, ve kterých se liší a jsou pro reálné nasazení podstatné, irelevantní. Pro potřeby této práce, tedy k prozkoumání problémů při nasazení a vlastním provozu integrační platformy je mezi poskytovateli IaaS prakticky nulový rozdíl, pokud bude možné zprovoznit několik virtuálních strojů s operačním systémem s podporou

Kapitola 2


28

Java Virtual Machine, což jsou podstatě všechny. Z důvodu, že technické charakteristiky nehrály významnou roli, mohlo dojít k vybrání poskytovatele IaaS hlavně podle netechnických parametrů. A právě díky tomuto je situace s výběrem velmi jednoduchá. Jako poskytovatel byla vybrána firma Amazon 12 a její Amazon Elastic Compute Cloud – EC2 13. Důvod zde byl jednoduchý, tato firma je průkopníkem tohoto odvětví a největším poskytovatelem IaaS vůbec a je považována za etalon pro služby tohoto typu. Díky tomuto existuje pro tento produkt největší množství návodů, dokumentace a nástrojů, které ulehčují a výrazně zrychlují seznámení se fungováním takovéto služby. Navíc byla v době psaní této práce poskytována možnost využít takzvanou Free Tier nabídku, tedy omezené množství hardwarových kapacit zdarma pro nově přihlášené zákazníky, která velmi výrazně snížila náklady spojené s využíváním této služby pro implementaci testovací platformy bez jakýchkoli negativních důsledků či omezení relevantních pro tuto práci.

2.2.2. PaaS Pokud je našim cílem v cloudu provozovat aplikace nebo informační systémy, máme buďto možnost vystavět si nad IaaS prostředí, které bude šité na míru našim potřebám nebo zvolit poskytovatele platformy, který vyřeší typické problémy a požadavky, které se vážou s nasazením takových aplikací. Typickým příkladem, který se řeší při nasazování aplikací je jejich škálovatelnost či vysoká dostupnost, oba tyto kvalitativní požadavky na aplikace jsou tak běžné, že jsou typicky řešeny poskytovatelem. Tímto může dojít k výraznému snížení nákladů na nasazení aplikace s takovými technickými kvalitami, ovšem ani zde nejsou za použitím takového druhu služby jenom pozitiva.

Výhody •

Vysoká dostupnost a škálování aplikace s minimálními počátečními náklady.

•

Odpadá správa a záplatování vlastních byť v IaaS hostovaných serverů.

•

Minimální vstupní náklady pro počáteční nasazení aplikace.

•

Využití podpůrných funkcí providera realizovatelných pouze ve velkém rozsahu. Například cachování webového obsahu na serverech poskytovatele, které jsou rozmístěny v mnoha různých geografických oblastech.

Nevýhody •

12 13

Ne každá platforma je podporována.

http://www.amazon.com/ http://aws.amazon.com/ec2/

Kapitola 2


29

•

V případě, že poskytovatel využívá nestandardní platformu, může dojít k vendor lock-in problému.

•

Minimální možnosti konfigurace či upravení platformy.

•

Závislost na podpůrných nástrojích providera. Například pro účely logování nebo filtrování přístupu.

2.2.2.1.

Využití

Jak již bylo zmíněno v podkapitole IaaS, pokud by se našel poskytovatel, který by provozoval zvolenou integrační platformu – ESB Switchyard nebo umožňoval rozšíření své platformy například konfigurací uživatelsky definovaných modulů, výrazně by to zjednodušilo vlastní nasazení. Bohužel žádný takový poskytovatel v době psaní práce neexistoval. Respektive neexistoval poskytovatel, který by nabídnul platformu pro Switchyard a zároveň možnost škálování. Společnost Red Hat totiž poskytuje PaaS pod názvem Openshift 14 určenou pro nasazení Java EE aplikací. Tato platforma je také, jako Switchyard, v raném stádiu vývoje a byla nedávno uvedena ve dvou svých verzích. Flex a Express, Switchyard lze nasadit na verzi Express, která ale bohužel v době psaní této práce neumožňuje oproti Flex clusterování aplikačního serveru (oboje JBoss AS 7) a s tím spojené clusterování Switchyardu. Verze Flex, která je zdánlivě ideální pro své rozšířené možnosti clusterování aplikací zase naopak neumožňuje modulárně zapojit Switchyard, alespoň tomu tak bylo v době psaní této práce. Nicméně se dá očekávat, že se tato možnost přidá a vznikne tak ideální platforma pro nasazení integrovaných řešení postavených na ESB Switchyard v prostředí cloudu.

2.2.2.2.

iPaaS

Při analýze možností různých opensource ESB se jako zajímavá platforma pro integraci služeb ukázala cloudově nasazená verze Mule ESB pod názvem iON 15. Jak už název podkapitoly možná napovídá, jedná se o integrační platformu poskytovanou jako služba – Integration Platform as a Service. Tato iPaaS je placená, ale vzhledem k popularitě Mule ESB se může jednat do budoucna o velice zajímavou volbu pro komerční nasazení integrovaných systémů.

2.2.3. SaaS Aplikační software poskytovaný ve formě služby přes internet je pravděpodobně to, díky čemu vděčí cloud computing své popularitě. Je to totiž produkt, který má řádově více

14 15

http://www.jboss.org/openshift/ http://www.mulesoft.com/mule-ion-ipaas-cloud-based-integration-demand

Kapitola 2


30

uživatelů, než oba předchozí a často je to právě SaaS to jediné co bývá u lidí asociováno s pojmem cloud. Na rozdíl od IaaS a PaaS, kde oproti konvečnímu řešení docházelo v ideálním a dosti zjednodušeném případě pouze k záměně kus za kus, tedy například místo fyzického serveru si pořídíme server virtuální, v SaaS tak jak fungují nyní, tedy jako webové aplikace, jen velmi těžko můžeme využít stávající funkcionality konvečních aplikací a přenést s minimálními náklady „do cloudu“ jako je to například u IaaS. Z tohoto důvodu jsou rozdíly mezi klasickým softwarem a SaaS velmi veliké a přechod na tento typ služeb s sebou obvykle značně omezení funkcionalitu známou ze stávajících desktopových ekvivalentů. Existují výjimky pracující namísto využití webové aplikace jako tenkého klienta s přenosem uživatelského rozhraní aplikace jako audiovizuálního proudu směrem ke klientovi a uživatelskými vstupy směrem zpět k serveru.

2.2.3.1.

API a WS

Software poskytovaný jako služba na Internetu je sice prozatím na rozdíl od jeho desktopových ekvivalentů značně funkčně limitován, ale zase poskytuje vzhledem ke své platformě úplně nové funkcionality, které by v klasických aplikacích nebyly jednoduše možné. Mezi takové se řadí poskytování aplikačních rozhraní jako webových služeb, které slouží například ke sdílení uživatelských dat nebo přístupu k funkcím samotné aplikace. Existuje také početná část aplikací, pro které je nabízení těchto webových služeb klíčovým faktorem v celé koncepci aplikace a integrace s jinými aplikacemi pomocí těchto služeb je pro ně podstatnou konkurenční výhodou.

Výhody •

Odpadá nutnost správy instalace a aktualizace software.

•

Odpadá potřeba synchronizace dat mezi zařízeními s přístupem na internet.

•

Data jsou uložena a spravována na serverech poskytovatele, a jsou tak ve většině případů spolehlivěji uskladněna, zálohována a chráněna proti zneužití.

•

Webové SaaS jsou dostupné na širším množství koncových zařízení, kde se jejich uživatelské rozhraní může optimalizovat podle druhu vstupních a zobrazovacích možností daného zařízení.

•

Nové možnosti takovýchto aplikací, například sdílení dat mezi více uživateli. Práce více uživatelů zároveň na jednom dokumentu nezávisle na jejich geografické lokaci.

•

Využívání softwaru jako služby, tedy náklady jsou závisle na vlastním využívaní nástroje.

Nevýhody •

Omezená funkcionalita oproti klasickým aplikacím

Kapitola 2


31

•

Nutnost neustálého připojení na internet při používání takových aplikací

•

Přenesení důvěry za informační bezpečnost dat na poskytovatele může být v případě citlivých dat problematické.

•

Uživatelský komfort, jako rychlost odezvy a plynulost uživatelského rozhraní je ve webových aplikacích stále omezený, především při práci s většími objemy dat.

2.2.3.2.

Využití

V implementační části jde o využití webových služeb poskytovaných několika SaaS a integrování je pomocí znovu využitelných komponent v rámci ESB Switchyard. Výběrem vhodných SaaS a popisem implementačních detailů vlastní integrace se bude zaobírat čtvrtá kapitola této práce.

2. 3. Clustering 2.3.1. Cluster Serverový cluster je skupina nezávislých serverů, které pracují jako jeden systém pro zajištění jeho vyšší dostupnosti nebo výkonu. Této vlastnosti pak dosahu s nižšími náklady než jaké by byly u jediného serveru se stejnými vlastnostmi. Pojem clusteru či clusterování je velmi široký a v této kapitole se zaměříme pouze na principy používané pro clusterování aplikačních nebo webových serverů.

Obrázek 2.8 – Ilustrace clusteru s vyvažováním zátěže

2.3.2. Vyvažování zátěže Vyvažování zátěže je proces, kterým se snažíme docílit rovnoměrného zatížení serverů v rámci clusteru. Tento proces může být realizován několika způsoby. Například

Kapitola 2


32

prostřednictvím DNS serveru, kde pro konkrétní doménové jméno uvedeme několik IP adres, které jsou pak například metodou Round-robin přidělovány příchozím dotazům na přeložení doménového jména clustrovaného systému. Další možností je využití http proxy, která přesměrovává jednotlivé dotazy na konkrétní servery v clusteru. Při použití http proxy pak můžeme využívat kromě Round-robin i chytřejších pravidel, například určovat cílový server podle vytíženosti jeho zdrojů (jako je zatížení procesoru nebo zaplnění hlavní paměti).

2.3.2.1.

Zachování sezení

Pokud klient komunikuje se serverem v clusteru v rámci sezení a tato komunikace je stavová – stateful, je potřeba zajistit, aby veškerá komunikace mezi konkrétním klientem byla směřována vždy na jeden server v clusteru – sticky sessions nebo zajistit, aby byla data jednotlivých sezení distribuována mezi všechny server v clusteru, případně uložena do sdílené databáze. Sdílení takovýchto dat buďto přímo mezi servery nebo pomocí sdílené databáze přináší svá úskalí. V případě sdílení dat sezení mezi přímo mezi jednotlivými servery je problém s distribucí dat a poklesem výkonnosti u větších skupin serverů, a proto je nutné držet velikost těchto skupin navzájem sdílející data co nejmenší. V případě sdílení takovýchto dat pomocí databáze je zase potřeba zajistit její replikaci, aby se zamezilo v případě selhání jednoho databázového serveru k výpadku celého clusteru, čímž by se ztratila část motivace pro jejich využití.

Obrázek 2.9 – Ilustrace clusteru kombinujícího výše uvedené přístupy

Kapitola 2


33

V případě bezstavová komunikace klienta se serverem není potřeba vzájemnou komunikaci a sdílení dat sezení řešit, a tím se zjednodušuje možnost škálování celého systému.

2.3.3. Failover Failover je postup pro překonání detekované chyby clusteru, která nastává v případě selhání jednoho či více serverů tvořící cluster. Taková chyba se zjišťuje pomocí pravidelné kontroly kondice serveru – health check, například jednoduchým avšak běžným způsobem, http GET požadavkem s kontrolou status kódu. Pokud nastane takováto chyba, musí se veškerý provoz, který obsluhoval vypadnuvší server přesměrovat na zbylé funkční jednotky.

2.3.4. Clusterování v cloudu Nasazení clusteru v cloudu funguje prakticky stejně jako v konvečním případě. Místo fyzický serverů použijeme virtuální, load balancer můžeme opět postavit na bázi nějakého virtuálního serveru s potřebnou softwarovou výbavou nebo, protože se jedná o častý požadavek, můžeme využít nějaký unifikovaný virtuální load balancer, který bůže být nabízen podobně jako unifikované virtuální servery v IaaS. Nicméně v prostředí cloudu a virtuálních serverů existuje další významná změna. Protože jsou servery virtuální a jejich vytvoření či zrušení je otázkou několika minut, lze měnit jejich počet dynamicky se zátěží a tím optimálně využívat jejich kapacity.

Kapitola 3 Nasazení systému 3. 1. Infrastruktura 3.1.1. Amazon EC2 Amazon Elastic Compute Cloud – EC2, je služba typu IaaS, která poskytuje flexibilní přístup k využívání výpočetních jednotek s instrukční sadou Intel x86 (případně s jejím 64 bitovým rozšířením), které se označují pojmem instance. Flexibilním přístupem se myslí možnost zarezervovat a spustit či zrušit libovolnou instanci v rámci EC2 v řádu jednotek až desítek minut. Faktické použití takovýchto instancí spočívá spuštění obrazu virtuálního stroje, což je datový soubor obsahující nakonfigurovaný operační systém spolu s požadovanými aplikacemi, na virtuálním hardwaru, který určují pouze základní výkonnostní parametry, které jsou poskytovatelem garantovaným minimem prostředků, které budou k dispozici pro zvolený operační systém a aplikace. Vlastní realizace takovéhoto systémů využívá vizualizace hardware, kde na faktickém fyzickém stoji – serveru je umožněno provozování jednoho anebo více virtuálních strojů, které sdílí faktické fyzické prostředky. O přístup k fyzickým zdrojům, jako je výpočetní čas, operační paměť či síťová konektivita, a řízení těchto virtuálních počítačů se stará softwarová vrstva nad fyzickým hardware označovaná jako hypervisor, kde označení hypervisor plyne z faktu, že tato softwarová vrstva dohlíží a řídí (supervise) software operačních systému, který je už sám supervizorem vlastních programů a aplikací. Je dobré zmínit fakt, že ačkoliv jsou instance nezávislé z hlediska užívání služby na níže položeném hardware a veškerá charakteristiky instance jsou ryze virtuální, není zatím možné o těchto virtuálních strojích uvažovat jako o virtuálním mediu, které je kdesi v éteru a netrpí vadami fyzických zařízení. V případě EC2 totiž, pakliže dojde k selhání fyzického zařízení, kde je instance spuštěna, nebo k většímu výpadku v rámci infrastruktury datového centra poskytovatele, dojde také k selhání všech zasažených instancí a takové situace nejenže mohou nastat, ale také dříve nebo později nastanou a je nutné s nimi dopředu počítat a přizpůsobit tomu celkové nasazení systému.

35

Kapitola 3

3.1.1.1.

Nasazení systému

36

Typy instancí

V rámci EC2 je k dispozici několik druhu instancí, které je možné dělit podle následujících kritérií. •

Kategorie instancí o Standardní o Mikro o S vysokým množstvím RAM o S vysokým výpočetním výkonem o Instance vhodné pro clustery CPU o Instance pro clustery GPGPU

•

Škálování v dané kategorii o Záleží na kategorii, obvykle násobky 2 nebo 4 (EC2 Compute units a/nebo paměti, diskové kapacity instance)

•

Způsob rezervace instance o Na požádání o Rezervované o Aukce s cenovým stropem

Normální instance (ty všechny kategorie kromě instancí pro clustery) jsou charakterizovány následujícími parametry. V případě instancí určených pro výkonné clustery pak platí, že je možné je rezervovat po skupinách, ve kterých je zaručena nízká latence a vysoká propustnost sítí. V případě GPGPU clusterů pak mají instance k dispozici grafické karty NVIDIA Tesla pro vysoce paralelizovatelné výpočty pomocí CUDA nebo OpenCl. •

Normovaný výpočetní výkon udávaný v EC2 Compute units

•

Množství dostupné operační paměti

•

Lokální disková kapacita instance

•

Platforma (x86-32/x64)

•

Rezervovaná kapacita I/O

EC2 Compute unit je jednotka výpočetní kapacity, která odpovídá přibližně výkonu jednoho jádra procesoru Intel Xeon z roku 2007 na taktu 1.2 GHz.

Kapitola 3

Nasazení systému

37

Rezervovaná kapacita instance pak určuje, jakou část sdílených prostředků síťové konektivity vázané na fyzické servery a další infrastrukturu budou mít jednotlivé instance k dispozici. Jedná se o pouze o parametr uveden relativně vůči ostatním typům. Následující tabulka shrnuje rozdíly mezi jednotlivými typy instancí. Type

CPU

Memory

Small

1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)

1.7 GB

Medium

2 EC2 Compute Units (1 virtual core with 2 EC2 Compute Units)

3.75 GB

Large

4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)

7.5 GB

Extra Large

8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)

15 GB

Micro

Up to 2 EC2 Compute Units (for short periodic bursts)

613 MB

High-CPU Medium

5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)

1.7 GB

High-CPU Extra Large


7 GB

High-Memory Extra Large

6.5 EC2 Compute Units (2 virtual cores with 3.25 EC2 Compute Units each)

17.1 GB

High-Memory Double Extra Large


34.2 GB

High-Memory Quadruple Extra Large


68.4 GB

Cluster Compute Quadruple Extra Large

33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core "Nehalem" architecture)

23 GB

Cluster Compute Eight Extra Large

88 EC2 compute units ( 2 x Intel Xeon CPU with 8 cores)

60.5 GB

Cluster GPU Quadruple Extra Large

33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core "Nehalem" architecture), plus 2 NVIDIA Tesla M2050 "Fermi" GPUs

22 GB (see note after this table)

Local Storage 160 GB instance storage (150 GB plus 10 GB root partition)

Platform

I/O

32-bit

Moderate

400 GB instance storage (1 x 400 GB)

32-bit and 64-bit

Moderate

64-bit

High

64-bit

High

32-bit or 64-bit

Low

32-bit

Moderate

64-bit

High

64-bit

Moderate

64-bit

High

64-bit

High

64-bit

Very high (10 Gbps Ethernet)

64-bit


64-bit


850 GB instance storage (2 x 420 GB plus 10 GB root partition) 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) None (use Amazon EBS volumes for storage) 350 GB instance storage (340 GB plus 10 GB root partition) 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) 420 GB instance storage (1 x 420 GB) 850 GB instance storage (1 x 840 GB plus 10 GB root partition) 1690 GB instance storage (2 x 840 GB plus 10 GB root partition) 1690 GB instance 64bit storage (2 x 840 GB plus 10 GB root partition) 3370 GB instance (4 x 840 GB plus 10 GB root partition) 1690 GB instance (2 x 840 GB plus 10 GB root partition)

Tabulka 3.1 – Typy instancí na EC2 (Převzato z [4] a platné k 22. 4. 2012)

Kapitola 3

Nasazení systému

38

Kromě vlastního výkonu jsou pak instance odlišovány i způsobem jejich pořízení, případně platby. Kromě pro IaaS typického přístup, zde označovaného Na požádání – On demand, kde se náklady na provoz počítají pouze za vlastní čas běhu instance, který se akumuluje s granularitou každé započaté hodiny, jsou k dispozici ještě dvě další možnosti rezervace a platby za instance. Rezervovaná instance je kombinace „klasického“ předplacení instance na určitou dobu (1 nebo 3 roky) se zachováním platby za aktivní spuštění instance, která je pak podstatně nižší než u výše zmiňovaného přístupu Na požádání. Tato možnost je ekonomicky výhodnější pro instance, které jsou spouštěny pravidelně, případně běží stále, v rámci delší doby (rok a více). Poslední možností je Spot instance – tedy rezervace instance podle ceny ve virtuální dražbě. Pro využití této instance je potřeba zvolit cenový strop, který jsme ochotni zaplatit za instanci za hodinu a v případě, že se v „aukčním systému“ objeví nabídka s požadovanou nebo nižší cenou za zvolenou instanci, proběhne její spuštění. Taková instance bude spuštěna do té doby, dokud bude nastavený strop vyšší nebo roven naší nabídce. V opačném případě se instance ukončí. Výhoda této možnosti je výrazně ušetření nákladů na provoz instance, průměrná úspora při využití spot instance oproti On demand byla 50%-66% v roce 2011 (v závislosti na typu instance) [5].

3.1.1.2.

Umístění kořenového disku instance

Každá instance v rámci Amazon EC2 má svůj kořenový diskový oddíl ze kterého startuje umístěn buďto přímo na fyzickém serveru, kde běží, anebo v odděleném datovém úložišti Amazon Elastic Block Store – EBS. EBS je virtuální blokově orientovaná disková jednotka, která umožňuje připojit část své kapacity jako virtuální oddíl právě jedné instanci EC2. EBS je k jednotce připojeno pomocí síťové infrastruktury a proto může vykazovat využití takto připojených oddílu výkonnostní propady, zvláště pokud je na případném fyzickém serveru mnoho menších instancí nebo je k instanci připojeno více EBS oddílů. Podstatný rozdíl mezi diskovým oddílem přímo v hostitelském serveru instance a EBS je ten, že pokud dojde k selhání fyzického serveru, na kterém běží instance, dojde taky ke ztrátě veškerých dat dané instance. Podobně s „interním“ kořenovým oddílem nelze instanci zastavit a znovu spustit, jediná možnost pro zachování aktuálních dat je vytvoření obrazu (snapshot) aktuálního disku, ukončení instance a načtení nové instance z prve vytvořeného obrazu. Tímto druhem obtíží instance využívající jako kořenový oddíl EBS netrpí a je možné je zastavit a opět spustit aniž by došlo ke ztrátě dat. Amazon EBS má přibližně 10x menší poruchovost, než klasické pevné disky (AFR 0,1 – 0,5%) [6]. Tato vyšší spolehlivost však často nemusí dostačovat a je možné oddíly z EBS zapojit do RAID, což zároveň může částečně kompenzovat výkonnostní propady. Přes výše uvedené postupy však může být stále nezbytné důležité data zálohovat, ať už se jedná o

Kapitola 3

Nasazení systému

39

databázové úložiště nebo aktuální funkční obraz instance. Tyto data lze následně buďto uložit jako další oddíly EBS nebo jako datové bloky do Amazon Simple Storage Service 16 – S3. V Amazon S3 jsou pak data uložena až s 9-9 [7] (devět devítek za desetinnou čárkou) spolehlivostí.

3.1.2. Amazon Elastic Load Balancer Amazon ELB je virtuální prvek pro vyvažování zátěže mezi jednotlivé prvky clusteru. Výhoda použití Amazon ELB, například oproti jedné vyhrazené instanci se softwarovým řešením (například Apache 17 server s modulem mod_proxy_balancer), je kromě jednodušší konfigurace v tom, že samotný ELB není tvořen jednou fyzickou jednotkou, ale dynamicky škálovanou množinou jednotek, mezi které jsou požadavky rozdělovány na úrovni DNS v infrastruktuře Amazonu. Ačkoliv ELB podporuje techniku „sticky sessions“, v rámci využití pro systém ESB a přístupu k jeho webovým službám, které jsou bezstavové, však není konfigurace „sticky sessions“ potřebná.

3.1.3. Amazon Elastic IP V Amazon EC2 je při každém spuštění jednotlivé instance přiřazeny nové privátní síťové IP adresy v rámci poskytovatelovi infrastruktury a tyto adresy jsou po dobu běhu instance neměnné. Totéž ale neplatí pro veřejné IP adresy a návazná doménová jména (která jsou pro každou instanci vytvořena), které mohou být i během provozu instance změněna. Z důvodu nutnosti mít spolehlivé a stálé připojení, ať už zvenčí (internetu) nebo v rámci providera, je k dispozici služba – Amazon Elastic IP, která jednotlivým instancím přiřadí fixní IP adresu která je vázaná na unikátní identifikátor dané instance a nemění se tedy, i když je daná instance zastavena. V případě použití Amazon ELB, však není nezbytně nutné tento postup využívat, protože skupina instancí, které jsou vyvažovány, se identifikuje nikoli privátní či veřejnou IP adresou, ale vnitřním identifikátorem instance v Amazon EC2 infrastruktuře a pro propojení instancí v rámci clusteru lze s omezením (změny při každém spuštění) využívat pouze privátní adresy instancí.

3.1.4. Omezení Při vlastní realizaci nasazení integrační platformy na instance EC2 a jejich následném clusterování, bylo potřeba počítat s omezeními, které se při realizaci obdobné konfigurace v rámci serverů v lokální síti vyhneme. Protože v základní konfiguraci EC2 to ani při začlenění instancí do Amazon Virtual Private Cloud – VPC, není možné využívat broadcast nebo multicast, který je často výchozím a preferovaným prostředkem v komunikaci 16 17

http://aws.amazon.com/s3/ http://httpd.apache.org/

Kapitola 3

Nasazení systému

40

v clustrovaném nebo distribuovaném prostředí, které je historicky spjato s nasazováním v rámci jedné lokální sítě. Pro doplnění, VPC nabízí možnost v rámci EC2 infrastruktury vytvořit privátní síť s vlastní virtuální infrastrukturou a EC2 instancemi, což může být mimo jiné užitečné pro posílení síťové bezpečnosti instancí, protože v rámci VPC,na rozdíl od běžného EC2 nejsou instance implicitně veřejně nebo v rámci celé EC2 infrastruktury dostupné a lze tak docílit toho, že je k nim přístup pouze prostřednictvím veřejné brány (zvolené EC2 instance) anebo v rámci virtuální sítě či připojením do zařízení mimo EC2 pomocí Amazon VPN Gateway.

3. 2. Operační systém Výběr a použití operačního systému pro nasazení aplikačního serveru s integrační platformou je do velké míry ulehčen tím, že je vlastní aplikační server postavěn na platformě JVM/Java. Možnosti výběru OS jsou pak v zásadě limitovány pouze podporovanými OS v Amazon EC2, protože JVM je pak implementována na drtivé většině takovýchto systémů. Instance jako taková se na EC2 může vystavět několika způsoby. Buďto vybereme obraz instance – Amazon Machine Image (AMI), z nabídky kterou poskytuje přímo Amazon nebo můžeme importovat obraz virtuálního stroje z nějakého virtualizačního nástroje. Mezi podporovanými, s omezeními, jsou v době psaní práce formáty VMware ESX, Citrix Xen VHD a Microsoft Hyper-V VHD. Pro potřeby této práce však byla zvolna první možnost, tedy výběr určitého AMI přímo z nabídky Amazonu. Nabídka takovýchto AMI obrazů se pak neomezuje pouze na operační systémy, ale také na předem instalované a nakonfigurované aplikační platformy, databázové systémy, pokročilé firewally a mnoho dalších. Podstatná většina poskytovaných systémů je na bázi nějaké distribuce Linuxu, ať už jsou to bezplatné Ubuntu, Fedora nebo Gentoo či placené Red Hat Enterprise Linux, Oracle Enterprise Linux nebo SUSE Enterprise Linux. Nabízená je také platforma Windows Server. V neposlední řadě je Amazon nabízí vlastní speciálně upravený linuxový systém, který je optimalizován právě pro běh v EC2. Tento systém je charakteristický tím, že v základu adresuje většinu specifik nasazení IaaS, jako integrace s ostatními Amazon službami, zabezpečení pomocí generovaných privátních klíčů a minimální velikost samotné instalace pro optimální rychlost startu instance. Jako systém byl v této práci využit výše zmiňovaný Amazon Linux, právě kvůli minimu konfigurace potřebné k bezchybnému provozu, maximální optimalizaci startu instance a integrované podpoře JVM. Bylo sice zmíněno, že jsou jako AMI nabízeny celé platformy, tedy operační systém včetně aplikací, ale žádná vhodná kombinace, která by obsahovala naši

Kapitola 3

Nasazení systému

41

cílenou konfiguraci, dostupná v době psaní článku nebyla, ale není se čemu divit, když vlastní platforma byla v době psaní této práce ve stádiu raného předprodukčního vývoje. Přesná konfigurace AMI, ze které se vycházelo a která byla následně upravována pro finální nasazení, nese následující označení. amzn-ami-2011.09.2.x86_64-ebs

Nicméně tento AMI byl použit pouze pro iniciální testovací instanci, následné téměř identické instance (až na konfiguraci integrační platformy) pak byly vytvořeny využitím již této hotové upravené verze jejím duplikováním.

3. 3. Aplikační platforma Aplikačně integrační platforma, kterou máme za cíl nasadit je tvořena, jak již bylo v minulé kapitole řečeno z ESB Switchyard, který je nasazen jako modul do JBoss aplikačního serveru v jeho 7. verzi. Pro vytvoření clusteru ESB Switchyard je tedy primárně nezbytné vytvořit cluster z aplikačních serverů.

3.3.1. Nasazení JBoss AS 7 Nasazení a instalace JBoss AS 7 na instanci s AMI Amazon Linux operačním systémem je vzhledem k tomu, že JVM je v AMI obsažená otázkou nahrání a extrakce zip archivu s JBoss AS 7 do zvoleného adresáře na běžící instanci, například pomocí sftp. Takto nahraný AS pak běží naprosto standardně jako na jakémkoli fyzickém serveru, jediné co je nutné pro přístup k aplikacím a administraci serveru udělat, je nastavit patřičně pravidla pro blokování příchozích požadavků podle zdrojových IP adres a portů v Amazon Security Groups, což funguje jako firewall kolem každé instance která je s danou bezpečnostní skupinou svázána. Tímto lze například měnit omezení pro vzdálenou správu instance skrze SSH pouze na určitou IP aniž by bylo nutné spouštět instanci a nastavovat nějaké vnitřní bezpečnostní politiky jako iptables nebo jiný druh aplikačního firewallu. Clusterování aplikačního serveru je otázkou sdílení jeho operačních registrů mezi jednotlivými instancemi, což například v případě nasazení webové aplikace vede k tomu, že sezení je replikováno a lze tak přistupovat na libovolné instance bez ukončení probíhající seance. V případě nasazení ESB je pak nutné, například replikovat jednotlivé neatomické probíhající procesy tak aby v případě pádu jedné instance mohl proces pokračovat na další, aniž by došlo ke ztrátě dat. Dále se tímto umožní distribuovat zátěž vzniklou v rámci jednoho serveru (tedy ne požadavky zvenčí) mezi jednotlivé účastníky například sdíleným MOM.

Kapitola 3

Nasazení systému

42

Pro zprovoznění clusterování více JBoss 7 aplikačních serverů potažmo instancí, na kterých jsou nasazeny, je třeba obejít omezení dané nefunkčním multicastingem, který je implicitním prostředkem pro vzájemnou komunikaci mezi servery. Toto se dá obejít v případě JBoss AS 7 několika postupy. Nepřímočařejším postupem je pro každý server nakonfigurovat statický výčet okolních uzlů v clusteru. Další možností je vytvoření tzv. Gossip směrovače (může jich být i vice, aby se předešlo zavlečení jediného bodu selhání), tedy jakéhosi prostředníka ke kterému se budou jednotlivé instance registrovat a získávat seznam adres ostatních uzlů, ten pak může být realizován na samostatné instanci nebo na jedné z instancí kde jsou vlastní aplikační servery. V neposlední řadě je tu možnost využít sdíleného souborového systému, ke kterému musí mít všechny instance přístup a do určité složky pak vkládají soubory s informacemi pro následné přímé propojení, tento přístup má také obdobu přímo pro Amazon S3, kde se místo sdíleného souborového systému využije sdílený datový prostor v rámci této služby. Než prozradíme, který postup byl použit v této prací, uveďme, že v rámci konfigurace serveru je nutné zvlášť nastavit jak samotné clusterování registrů serveru, což bylo popsáno výše, tak i sdílení/distribuci MOM, která je opět v základním stavu konfigurována multicastovou komunikací mezi servery. Bohužel možnosti změny této konfigurace nebyly v tomto ohledu tak široké jako v předešlém případě a jediná možnost, která byla po důkladném zkoumání dokumentace nalezena, byl statický výčet uzlů v rámci clusteru. Proto z důvodu těchto omezení byl zvolen pro obě konfigurace clusterování výčet jednotlivých uzlů v rámci clusteru. Úryvky jednotlivých konfigurací jsou uvedeny v příloze A a celá konfigurace je pak k nalezení na doprovodném médiu.

3.3.2. Nasazení Switchyard ESB Nasazení Switchyard (SY) probíhalo „nainstalováním“ modulů do aplikačního serveru. Instalace v praxi znamenala úpravu hlavního konfiguračního a nahrání příslušných knihoven do souborových struktur serveru. Je třeba zmínit, že samotný Switchyard ve verzi 0.4, tedy nejnovější při psaní této práce, nepodporoval clusterování, ve smyslu sdílení jeho vnitřních registrů a dat mezi jednotlivými instancemi. Jediným společným komunikačním prostředkem pro sdílení informací mezi jednotlivými instancemi v rámci aplikací nasazených ve Switchyard kontejneru je využití sdíleného MOM, který může sloužit k vyvažování interních zpráv mezi službami mezi jednotlivé instance a také částečně také jako sdílená persistentní platforma pokud jedna z instancí selže. Úplně bez problému ale selhání instance zatím neproběhne z důvodu například zrušení aktuálně prováděných procesů (v rámci orchestrace), které mohou trvat i v řádu dnů či týdnů. S tímto omezením, které je dané především velmi ranou fází vývoje vlastního ESB (pokud budeme důvěřovat vývojové roadmapě, tak je tato vlastnost plánována na některý z příštích předprodukčních (<1.0) milníků) je nutné se smířit a během vývoje vlastní aplikace ho akceptovat. Je očividné, že pro naprosto spolehlivé produkční

Kapitola 3

Nasazení systému

43

nasazení aktuální verze SY není určena, ale vzhledem k povaze této práce toto omezení nehraje významnou roli.

3. 4. Topologie systému Instance jejíž části byly popsané v předešlých podkapitolách byl pro testovací provoz zprovozněn na micro instanci s diskem v EBS o kapacitě 8 GB, avšak typ a parametry instance lze jednoduše měnit v případě, že je instance zastavena.

Obrázek 3.1 – Schéma jedné instance

Vlastní topologie systému je pak znázorněna na schématu níže, kde byl pro testovací účely vytvořen cluster s minimem 2 EC instancí. Parametry typu počet instancí či jejich druh lze relativně flexibilně měnit, i když jsou nastaveny staticky (ip adresy v konfiguraci aplikačního serveru). Změna jednotlivých parametrů a její promítnutí na měřitelné hodnoty bude předmětem části kapitoly o testování, která je předposlední oddílem této práce.

Kapitola 3

Nasazení systému

44

Obrázek 3.2 – Topologie nasazeného systému

3.4.1. Bezpečnostní politika V rámci zabezpečení vzniklého systému je nutné nastavit vhodná omezení pro jednotlivé instance EC2. Následující tabulka popisuje jaké porty a jaké stroje (adresy) mohou přistupovat na jednotlivé instance (bezpečnostní skupina je totožná pro všechny instance). •

sg-61405e15 je název vlastní bezpečnostní skupiny. Při odkazování sama na sebe to pak znamená, že všechny instance ve stejné skupině mohou mezi sebou komunikovat na určitém rozsahu portů a protokolu (protokolů nižších síťových vrstev jako TCP nebo ICMP)

•

@admin_ip zastupuje faktickou IP adresu počítače určeného pro vzdálenou správu instancí, pravidla s tímto jsou zavedena především kvůli omezení testovacích útoků na otevřené ssh porty jednotlivých instancí, které jsou relativně běžné v rámci EC2.

•

amazon-elb/sg-35b1b441 je název bezpečnostní skupiny ve které jsou instance vytvořeného ELB (jak bylo zmíněno muže jich být i více, ačkoliv se ELB tváří jako jedna virtuální jednotka)

Kapitola 3

Nasazení systému

45

sg-61405e15 (my_sec_group) ICMP Port (Service) ALL TCP Port (Service) 80 (HTTP) 8080 (HTTP*) 19001 0 – 65535 0 – 65535 UDP Port (Service) 0 – 65535

Source sg-61405e15 (my_sec_group) Source amazon-elb/sg-35b1b441 (amazon-elb-sg) amazon-elb/sg-35b1b441 (amazon-elb-sg) amazon-elb/sg-35b1b441 (amazon-elb-sg) sg-61405e15 (my_sec_group) @moje_admin_ip Source sg-61405e15 (my_sec_group) Tabulka 3.2 – Nastavení Bezpečnostní skupiny instancí

3.4.2. Komunikace klienta se systémem s ELB18 Následující výčet kroků předchází komunikaci mezi klientem a vlastní instancí clusteru za ELB. Tento případ předpokládá využití vlastního doménového jména pro daný systém tak, že v DNS záznamech je další hostname ELB v rámci sítě Amazonu. 1. Klient vyhledá DNS záznam pro jméno serveru například www.mydomain.com. DNS server odpoví s hostname ELB například MyDomainELB-918273645.us-east1.elb.amazonaws.com. 2. Klient vyhledá DNS záznam pro MyDomainELB…amazonaws.com, což vede k dotazu na DNS servery Amazonu, kde je dané přeloženo na adresu jednoho z možných faktických ELB instancí, například 1.2.3.4. 3. Klient otevře spojení s faktickou instance ELB na adrese 1.2.3.4, kterou obdržel v minulém kroku. 4. ELB na adrese 1.2.3.4 pak přeposílá komunikaci mezi klientem a vybranou EC2 instancí z množiny určené pro clusterování. Následná komunikace v rámci spojení již probíhá mezi klientem a konkrétní instancí.

18

Popis komunikace je přezván z [27]

Kapitola 4 Integrace služeb Pro demonstraci využití principu SOA spolu s integrační platformou ESB switchyard pro integraci aplikací v prostředí cloud, bylo žádoucí implementovat vzorovou aplikaci, která bude ilustrovat, jakým způsobem lze daný úkol zrealizovat. Připomeňme, že službami, kterými se hodláme v této práci zabývat, myslíme primárně veřejně dostupné webové služby, které poskytují aplikace typu SaaS, případně služby na pomezí PaaS/SaaS, tj. takové aplikace, které mají omezené použití pro koncového uživatele, ale poskytují velmi žádané služby pro tvůrce ostatních aplikačních systémů. Mezi náměty na integraci byly, po konzultaci s vedoucím práce, uvažovány takové scénáře, kde je vybrána z dostupných možností množina služeb, které jsou si svým způsobem blízké a slouží k podobnému účelu avšak jinými prostředky. Jako první příklad, který byl uvažován, můžeme uvést služby pro zasílání zpráv. Pro představu uveďme, jaké služby by splňovaly takováto kritéria – Twitter, Facebook, SMS brány, Služby pro zasílání emailu a další. Takovéto služby by pak byly integrovány způsobem, který by je zapouzdřil pod jednu složenou službu a podle externích nebo interních kritérií by pak bylo vyhodnoceno, do kterých služeb bude zpráva zaslaná jejím prostřednictvím doručena. Tento námět však nebyl zrealizován a místo něj byl na podobném principu vystavěn scénář pro integraci aplikací sloužících pro ukládání různých forem dat. Následující podkapitola vymezí jaké služby a jakým způsobem budou předmětem integrující aplikace.

4. 1. Integrační scénář Myšlena stojící za tímto návrhem je v ulehčení správy souborů, které jsou uloženy napříč různými SaaS aplikacemi, ať se jedná o úložiště při SaaS kancelářském balíku, či webové foto album, cílem toho integračního scénáře je unifikovat přístup k těmto zdrojům jednoduše pouze na základě jména souboru a jeho koncovky. Přístup k této nově vzniklé službě by pak měl být realizován pomocí RESTful webové služby, k čemuž tento scénář přímo vybízí.

47

Kapitola 4

Integrace služeb

48

Nicméně tato základní myšlenka byla později rozšířena o automatizovanou službu, která není závislá na uživatelském vstupu skrze výše zmíněné REST rozhraní, ale reaguje na události vzniklé přímo v integrovaných službách, kde uložení souboru do služby jedné vyvolá operaci, která soubor zpracuje za využití ostatních služeb.

4.1.1. Přehled vhodných služeb •

Dropbox 19 o Webové úložiště pro libovolné soubory, které zdarma poskytuje 2 GB volného prostoru, výhodou jsou oficiální aplikace pro všechny hlavní platformy, které umožňují synchronizaci vybraných složek na zařízení. o Veškerá potřebná funkcionalita je dostupná skrze RESTful API s autorizačním protokolem OAuth 1.0, jsou dostupné oficiální knihovny pro Javu, které zaobalují REST API a OAuth do klientského adaptéru. o Limitováno na 5000 požadavků za den pro vyvíjené aplikace. Pro zrušení tohoto omezení je nutné podat žádost, která je ovšem možná pouze v případě veřejných aplikací tak, aby bylo umožněno testování, což v našem případě nebylo realizovatelné.

•

Picasa Web Album 20 o Jak již název napovídá, jedná se o aplikaci pro prohlížení uživatelsky nahraných fotografií ve webové aplikaci, zdarma je dostupný 1 GB prostoru pro uživatelské fotografie. Fotky jsou uloženy v komprimované podobě a omezené velikosti. o Veškerá potřebná funkcionalita je dostupná skrze RESTful API s autorizačními protokoly OAuth 1.0, ClientLogin (uvedení login/hesla v každém požadavku) a AuthSub (Google proprietarní), jsou dostupné oficiální knihovny pro Javu, které zaobalují REST API a autorizační komunikaci do klientského adaptéru

19 20

http://www.dropbox.com http://picasaweb.google.com

Kapitola 4 •

Integrace služeb

49

Google Docs 21 o Kancelářský balík, který patří mezi nejpoužívanější a nejcharakterističtější zástupce SaaS pro širokou veřejnost, kromě vlastních funkcí typických pro kancelářské balíky obsahuje také vlastní úložiště souborů především typu textového či tabulkového dokumentu nebo prezentace. Velikost zdarma dostupného úložiště je 1 GB. o Prakticky totožná s Picasa Web Album – obě služby využívají rozšířené GData API

•

Amazon S3 22 o Univerzální datové úložiště, které je na pomezi SaaS/PaaS, protože ačkoli má i uživatelsky použitelné webové rozhraní je primárně určena pro vývojáře ostatních aplikací. Tato služba je výjimkou mezi ostatními zmíněnými, protože není ani v základní verzi bezplatná, ale funguje na principu platby za aktuálně využívané prostředky (v tomto případě objem dat aktuálně uložených, přenesených a počet dotazů na API). Škálovatelnost této služby je prakticky neomezená (až řády stovky PB dat). o Přístup ke službě je zprostředkován buďto skrze RESTful nebo SOAPful API. Autorizace je zajištěna pomocí hashovaného podpisu v hlavičce HTTP REST požadavku nebo v těle SOAP požadavku.

•

Následující služby byly zvažovány, ale nebyly použity. o Flickr 23 – Velmi podobná funkcionalita jako má Picasa. Zavrhnuto z důvodu osobních preferencí autora a zamezení duplikace prakticky služeb s totožným záběrem. o Microsoft Skydrive 24 – Podobná funkcionalita jakou má Dropbox. Zavrhnuto z důvodu menšího počtu klientských aplikací mimo Microsoft platformu a menšímu množství informační podpory pro vývoj v Javě.

https://docs.google.com http://aws.amazon.com/s3/ 23 http://www.flickr.com/ 24 https://skydrive.live.com/ 21 22

Kapitola 4

Integrace služeb

50

o Wappwolf 25 – služba která úzce navazuje na Dropbox a umožňuje vytvářet akce v případě, že detekuje nový soubor v synchronizované složce, pro představu například nahrání fotky na Facebook. V rámci beta-verze vývojářského programu by mělo být umožněno také volat libovolné externí služby například pomocí SOAP, což by se pro účel této práce více než hodilo. Nicméně na prosbu (přístup k těmto možnostem je v době psaní práce neveřejný) o zařazení do beta-programu nebylo reagováno a tudíž využití této služby nebylo možné. Nicméně možnost podobné funkcionality byla natolik zajímavá, že byla nakonec implementována jako služba interní v rámci aplikace.

4. 2. Návrh a implementace Návrh a implementace aplikace realizující scénář popsaný v předchozí podkapitole je úzce spjata, či dokonce určena platformou, ve které bude daná aplikace nasazena, ačkoliv z pohledu architektury aplikace se stále bude jednat o SOA. Prostředím ve kterém bude aplikace provozována, a na které je při návrhu potřeba myslet je ESB Switchyard, který implementuje více obecnější specifikace SCA architektury. Z toho důvodu je návrh aplikace tvořen tak aby odpovídal principům a možnostem SCA. Nicméně je stále důležité vnímat specifika a omezení daná konkrétním ESB, které SCA realizuje, ať už se jedná o technologická omezení, které se nemusí v návrhu promítnout nebo nadstandardní možnosti, které ESB poskytuje mimo SCA architekturu. Takovým příkladem jsou vazby (bindings) dostupné v konkrétním ESB nebo také dostupné implementační možnosti prostředí, které taky mohou hrát významnou roli při celkovém návrhu. V konkrétním případě ESB Switchyard je pak dobré pamatovat kupříkladu na jeho deklarativní zápis transformačních služeb (transformerů), které umožňují transparentní konverzi mezi různými druhy datových formátů a datových reprezentací, což může vést, při jejich využití, k zjednodušení celkového návrhu.

4.2.1. Formalizace požadavků V předchozích kapitolách byl nastíněn scénář, jaký by aplikace měla realizovat, je nicméně důležité formalizovat požadavky, které na výslednou aplikaci budou kladeny.

25

http://wappwolf.com/

Kapitola 4

4.2.1.1.a

Integrace služeb

51

Webová služba pro správu souborů

Aplikace umožní uživateli přistupovat ke čtyřem zvoleným službám schopných skladování souborů tak, že využívané služby budou pro uživatele transparentní. Budou umožněny operace – ulož – načti – smaž – pro jednotlivé soubory, které budou vnitřní logikou aplikace, propagovány na zvolené služby třetích stran. Rozhodovací logika určující, který typ souboru bude obsloužen jakou službou, by měla být implementována pomocí jazyka pro popis business pravidel, nikoliv pevně zadrátována v aplikaci. Vlastní aplikace by měla být bezstavová a neměla by využívat jakákoliv vnitřní datová úložiště. Rozhraní služby bude realizováno jako RESTful webová služba. Pro realizaci budou využity následující čtyři služby •

Dropbox

•

Picasa Web Album

•

Google Docs

•

Amazon S3

4.2.1.1.b

Služba synchronizace Dropbox

Druhou podstatnou funkcionalitou aplikaci bude automatické zpracování souborů uložených pomocí služby Dropbox tak, že pro každý nově rozpoznaný soubor nahraný do Dropboxu bude provedeno zpracování službou popsanou v předchozím odstavci pomocí operace – ulož –. Veškerá tato činnost bude plně automatizována a nebude vyžadovat účast uživatele (krom vlastního nahrání souboru/ů do Dropboxu). Veškerá data potřebná pro realizaci této služby musí být umístěna přímo ve službě Dropbox a být tak jednoduše dostupná uživateli, například pro anulování záznamů o zpracovaných souborech. Interval aktualizace/synchronizace nově uložených souborů by neměl být větší než 5 minut.

4.2.2. Návrh služeb a komponent Analýzou aplikačních požadavků vznesených v předešlé kapitole a díky jasnému rámci určeného cílovou platformou a SOA architekturou, jejíž náležitosti budou respektovány při návrhu této aplikace, bylo dosaženo návrhu množiny služeb, které spolu se službami, které hodláme integrovat, povedou k realizaci vytyčených cílů. Následující globální přehled valné většiny služeb, které jsou využity v aplikaci, ilustruje následující diagram, který navazuje na schémata uvedená v kapitole 2.1.7. Jednotlivé služby, komponenty a vazby tak, jak jsou chápány v SCA, budou následně blíže rozebrány.

Kapitola 4

Integrace služeb

52

Obrázek 4.1 – Globální pohled na služby v aplikaci

Komponenty popsané na diagramu, jsou kvůli velkému počtu a přehlednosti zobrazeny nepropojeně (bez vizualizace spojení mezi vnitřními službami a referencemi) a motivace k jejich využití může být nejasná, proto se v následující části budeme věnovat jednotlivým komponentám a službám, které poskytují, stejně jako vazbám, kterými daná aplikace komunikuje s okolím. Ačkoliv mohou komponenty realizovat více služeb, ve výše uvedeném případě je vždy jedna služba realizována právě jednou komponentou, a proto v následujícím textu mohou oba výrazy zaměňovány.

4.2.2.1. •

Komponenty

Komponenta Store File

Kapitola 4

Integrace služeb

53

o Realizuje požadavek pro uložení souboru do externích služeb podle daných kritérií. Pravidla podle, kterých je daný soubor zpracován jsou vyhodnocena službou SF rules. Služba využívá všechny externí služby pro uložení souborů. Výsledky jednotlivých volání jsou slouženy do kolekce interní službou pro agregaci zpráv. o Vstupy – Datový objekt reprezentující soubor a jeho charakteristiky. o Výstupy – Kolekce objektů popisující výsledek operace na jednotlivých externích službách. o Závislosti  •

SF Rules, Dropbox adapter, Picasa adapter, Google Docs adapter, Amazon S3 Store, Agregátor zpráv.

Komponenta Retrieve File o Realizuje požadavek pro načtení souboru z externích služeb, obdobným způsobem jako Store File. o Vstupy – Datový objekt reprezentující charakteristiky souboru, který chceme načíst. o Výstupy – Datový objekt kolekce souborů, které odpovídají kritériím. o Závislosti 

•

RF Rules, Dropbox adapter, Picasa adapter, Google Docs adapter, Amazon S3 Store, Agregátor zpráv.

Komponenta Delete File o Analogicky k předchozím komponentám, realizuje požadavek na smazání souboru. o Vstupy – Datový objekt reprezentující charakteristiky souboru, který chceme smazat. o Výstupy – Kolekce objektů popisující výsledek operace na jednotlivých externích službách. o Závislosti 

•

DF Rules, Dropbox adapter, Picasa adapter, Google Docs adapter, Amazon S3 Store, Agregátor zpráv. (Msg. Aggregator)

Komponenta Dropbox Sync o Zjišťuje jaké soubory – jejich jména – jsou nově umístěny v Dropboxu a následně volá službu Dropbox Retrieve-Store pro další zpracování.

Kapitola 4

Integrace služeb

54

o Vstupy – Žádné o Výstupy – Kolekce datových objektů reprezentující charakteristiky souboru, v tomto případě jednotlivě, ne jako jeden objekt kolekce, ale několik samostatných (kde jsou následně zpracovávány jednotlivě). o Závislosti – Dropbox adapter, Dělička zpráv (Msg. Splitter), Dropbox Retrieve-Store •

Komponenta Dropbox Retrieve-Store o Vyžádá si soubor charakterizovaný vstupním objektem a odešle jej do služby Store File o Vstupy – Datový objekt reprezentující charakteristiky souboru, který chceme načíst. o Výstupy – Žádné o Závislosti – Dropbox adapter, Store File

•

Komponenty RF, SF, DF Rules o Tyto služby zabalují logiku, které se pojí s výběrem vhodné externí služby pro danou charakteristiku souboru. o Vstupy – Datový objekt reprezentující charakteristiky souboru, který chceme načíst. o Výstupy – Kolekce identifikátorů externích služeb, které mají být využity v dané operaci.

•

Komponenty adaptérů externích služeb o Vzhledem k faktu, že ESB Switchyard nepodporuje přímou integraci RESTful služeb tak, že by byly dostupné ve formě referencí, a ani to není bez formálního a interface typu WSDL možné (nejsou dostupné), je nutné realizovat vrstvu, které bude fungovat jako proxy pro jednotlivé operace dostupné skrze REST API. Tímto trpí služby Dropbox, Google Docs, Picasa Web Album, ale adaptér využijeme i pro Amazon S3 z důvodů, které uvedeme níže. o Vstupy – V závislosti na operaci dané služby, všechny zmíněné služby podporují nějakou formu uložení, načtení či smazání souboru. o Výstupy – V závislosti na operaci dané služby. o Závislosti – Realizována mimo SCA, na vlastních externích službách skrze rozhraní webové služby.

•

Komponenty Amazon S3 Store, Retrieve

Kapitola 4

Integrace služeb

55

o Služba pro uložení, či načtení souboru do externí služby Amazon S3. V průběhu práce bylo zjištěno, že se vzhledem k omezení ze strany ESB, který zatím neimplementuje přílohy SOAP zpráv ve formátu dime, bude muset využít kromě SOAP vazby také nepřímé rozhraní realizované pomocí adaptéru. Problémem je, že Amazon S3 limituje přijímání a odesílání SOAP zpráv, které obsahují data souboru v inline formě (tedy ne ve formě přílohy) nad 1 MB a tím vynucuje využití jiného způsobu přenosu dat pro větší soubory. Logiku, která vyhodnocuje, jestli je možné poslat, či přijmou zprávu prostřednictvím přímé SOAP reference nebo využít adaptéru, realizují právě tyto dvě komponenty. o Vstupy, výstupy – dle operace, analogicky k Store File a Retrieve File o Závislosti – Amazon S3 (vlastní externí služba), Amazon S3 Adapter, Amazon S3 Security Signer. •

Komponenta Amazon S3 Security Signer o Podpisuje datové objekty, které jsou posílány do Amazon S3 protokolem SOAP, zajišťuje tak autorizaci požadavků pro danou službu, které se v ostatních případech řeší na úrovni adaptérů služeb. o Vstupy – Datový objekt v závislosti na operaci o Výstup – Podepsaný datový objekt

•

Komponenty Message Aggregator, Splitter o Spojují či rozdělují datový objekt kolekce zpráv do sekvence několika datových objektů. Agregátor je využit několika službami a neodkazuje na další komponentu, Splitter je využít pouze v choreografii odkazující na Dropbox Retrieve–Store komponentu, kde je konkrétní operace dané služby volána pro každý jednotlivý datový objekt zvlášť. o Vstupy, výstupy viz první odrážka.

•

Komponenta Zip Compressor o Poskytuje službu pro komprimování kolekce datových objektů Zip kompresí, vytváří tak z kolekce souborů, soubor zip archivu, který obsahuje soubory dané kolekce. o Vstupy – Datový objekt kolekce souborů a jejich charakteristik o Výstup – Datový objekt souboru obsahující zip archiv souborů z vstupu

4.2.2.2.

Vazby

Písmena jsou vztažena k diagramu Obrázek 4.1 – Globální pohled na služby v aplikaci.

Kapitola 4

Integrace služeb

56

•

A – Dropbox Sync – Vstupní vazba která přijímá požadavky na vykonání synchronizace službou Dropbox Sync. Požadavky do této vazby budou automaticky v určeném intervalu posílané externím klientem.

•

B – Dropbox Retrieve-Store – Vstupní vazba přijímající požadavky obsahující charakteristiku souboru určeného ke zpracování službou Dropbox Retrieve-Store.

•

C – Poskytnutí Store, Retrieve, Delete File služeb jako RESTful webovou službu. Pouze logická reference, která je nečitelná ze strany běhového prostředí jako SCA vazba

•

D – SOAP vazba externí službu Amazon S3 definovanou WSDL interfacem.

•

E – Dropbox Retrieve-Store – Výstupní vazba odesílající požadavky obsahující charakteristiku souboru určeného ke zpracování službou Dropbox Retrieve-Store.

•

F, G, H, I – Přímé využití webových služeb v adaptérech. Pouze logická reference, která je nečitelná ze strany běhového prostředí jako SCA vazba.

Důvod proč je B a E realizována jako externí vazba a ne jako interní implicitně řešená v SCA běhovým prostředím je veden nutností vyvažovat požadavky při nasazení v clustrovaném prostředí, ESB Switchyard v aktuální verzi neumožňuje clusterování vlastních služeb a proto muselo být k rozložení zátěže mezi jednotlivé uzly využito clustrovaného MOM (realizující JMS), který rozloží jednotlivé zprávy/objekty zaslané prostřednictvím jeho vazeb na jednotlivé aktivní uzly clusteru a tím přispěje k rozložení zátěže.

4.2.2.3.

Detaily webové služby

Webová služba, která umožní klientskou komunikaci s aplikací, bude, jak již bylo nastíněno, odpovídat zásadám RESTful webové služby. Jediným zdrojem (ve smyslu REST resource) této služby pak bude soubor, který bude podporovat následující operace. Načti – GET base_url/file/{název souboru} Možné odpovědi (HTTP Status) •

200 – Vrátí bytestream souboru, hlavička bude obsahovat název souboru.

•

400 – Název souboru není přijat jako platný. o Testováno proti regulárnímu výrazu (Java syntax) [a-zA-Z_0-9]{1,30}\.[a-zA-Z0-9]{1,5}

•

404 – Soubor nebyl nalezen na žádné službě (za daných pravidel).

•

500 – Blíže nespecifikovaná chyba aplikace.

Kapitola 4

Integrace služeb

57

Ulož – POST base_url/file/ Očekává data v těle požadavku ve formátu RFC 1867, tedy toho, který se využívá ve webových formulářích. Je podporován pouze jeden soubor v požadavku, ostatní data, jako jsou jiná data formuláře, budou ignorována, stejně jako následující soubory obsažené v těle požadavku. Možné odpovědi (HTTP Status) •

200 – Operace proběhla v pořádku. (soubor uložen podle pravidel aplikace)

•

400 – v případě že název souboru v těle požadavku není platný nebo je požadavek neplatný ve smyslu popsaném výše.

•

500 – Viz GET

Smaž – DELETE base_url/file/{název souboru} Možné odpovědi (HTTP Status) •

200 – Operace proběhla v pořádku. (soubor smazán podle pravidel aplikace)

•

400, 500 – Viz GET

4.2.3. Implementace komponent Silnou stránkou SCA potažmo ESB Switchyard je, že naplňuje zásady SOA a umožňuje více či méně integraci aplikací implementovaných širokým spektrem různých jazyků a technologií. Této skutečnosti bylo využito i při implementaci aplikace, které se věnuje tato kapitola a podobně jako byl na začátku přehled služeb a komponent, které načrtly obrysy, jakým způsobem bude aplikace pracovat, na následujícím diagramu je konkrétně uvedeno jakými prostředky se jednotlivé komponenty ve výsledku zrealizovaly.

Kapitola 4

Integrace služeb

58

Obrázek 4.2 – Schéma komponent a jazyků jejich implementace

Ačkoliv se zběžným pohledem může zdát, že využití takového množství různých jazyků pro vcelku malou aplikaci je samoúčelné, opak je pravdou. Při implementaci komponent bylo postupováno ryze programaticky cestou, kdy použijeme takovou technologii která danou službu, buďto implementuje s nejmenším množstvím vynaloženého úsilí, nebo přináší významné výhody oproti jiným typům implementace.

Kapitola 4

4.2.3.1. 4.2.3.1.a

Integrace služeb

59

Použité implementační jazyky Java

Java je v rámci ESB Switchyard nezbytným a univerzálním nástrojem, který nastupuje v případě, že se řeší aplikačně specifické funkce. Mezi komponenty, které byly implementovány v Javě, jsou především adaptéry externích služeb, kde se s výhodou využilo knihoven dodávaných poskytovateli služeb, které ve značné míře urychlily a zjednodušily vývoj. Java byla také použita pro implementaci všech explicitně vytvořených transformátorů a dalších pomocných služeb jako třeba Amazon S3 Security Signer (služba pro podpis požadavků na Amazon S3). Při implementaci v Javě byla s úspěchem použita řada knihoven, které implementují standardní znovu využitelnou funkcionalitu, která se nenachází přímo v Java SE nebo EE API. Především knihovny Apache Commons 26 a Google Collections 27. Samozřejmě byly v maximální míře využity i knihovny Java EE, SE a vlastní API ESB Switchyard, například implementace RESTful webových služeb (JSR-311) JBoss RESTEasy 28.

4.2.3.1.b

BPMN 2.0

Business process model and notation je, jak bylo již naznačeno v předchozích kapitolách (0), prostředek pro zápis a vykonávání business procesů a lze jej použít jako deklarativní jazyk pro popis orchestrace služeb v rámci SOA potažmo ESB Switchyard. K orchestraci služeb byl tedy použit i v případě této aplikace. Jak je patrné z předešlého diagramu, jsou služby implementované tímto způsobem výhradně ty, které nějakým způsobem řídí tok informací mezi jednotlivými službami a jsou zpravidla na nejvyšších příčkách logického členění aplikace co nejblíže ke vstupním vazbám. Následující diagram (Obrázek 4.3) ukazuje grafickou reprezentaci deklarativně zapsané a vykonavatelné komponenty Store File. Vlastní BPMN implementace obsahuje kromě viditelných informací i specifikace například ve formě skriptů (např. pro vyhodnocení platnosti podmínky na bráně – místo, kde konverguje či diverguje tok) a mapování proměnných mezi mateřským procesem a službami, které nejsou visuálně reprezentovány.

http://commons.apache.org/ http://code.google.com/p/guava-libraries/ 28 http://www.jboss.org/resteasy 26 27

Kapitola 4

Integrace služeb

60

Obrázek 4.3 – Ukázka vizuální reprezentace Store File komponenty implementované v BPMN 2.0

4.2.3.1.c

Apache Camel Routes

O Apache Camel již byla zmínka v kapitole s přehledem ESB řešení a bylo také zmíněno (2.1.6.2), že Switchyard v sobě integruje Camel jako modul běhového kontejneru a tím nabízí možnost implementovat služby jako Camel Routes. V praxi to znamená, že jednoduchým způsobem, ať už ve formě XML konfigurace nebo obdobou vzoru builder přímo v Javě, lze vytvořit služby, které se typicky a neustále opakují především při integraci aplikací za pomoci MOM. Camel implementuje Enterprise application patterns (EIP) tak jak jsou uvedeny v [8] a umožňuje tak velmi rychle implementovat komponenty realizující velmi složité problémy, jako je shlukování zpráv podle určitého klíče, filtrování a podobně. Ačkoliv Switchyard není primárně prezentován jako ESB, které pracuje nad MOM, je přesto možné aplikovat EIP i v případě komunikace jednotlivých služeb, protože vzájemná komunikace je interně realizována jako zasílání zpráv mezi službami, což je však běžně pro vývojáře transparentní. Pro ilustraci tohoto chování můžeme uvažovat službu, která bude opakovaně volat komponentu implementující EIP vzor agregátor, v tomto případě a troše zjednodušení budou datové objekty, které byly zasílány jako parametr do agregační služby shlukovány a následně odeslány jako jeden datový objekt typu kolekce do služby další. Takovým způsobem je kupříkladu implementována komponenta Agregátor použitá i v této aplikaci.

4.2.3.1.d

Drools

JBoss Drools je platforma pro implementování a správu business pravidel v aplikaci. Business pravidlem se myslí takové rozhodovací struktury, jejichž vlastnosti se mohou měnit v závislosti na změnu aktuální konfigurace aplikace, obchodní politiky nebo například

Kapitola 4

Integrace služeb

61

zákonem daných předpisů. Pravidla, která jsou takto extrahovaná z vlastního kódu aplikace, pak přinášejí do vlastního návrhu několik významných výhod. Prvním plusem je zajištění, že případná změna pravidel nepovede k nutnosti k změně zdrojových kódu, nutnosti rekompilace a následného testovaní, což může výrazně zkrátit zavedení změn do živého provozu. Dalším pozitivum je spjato s možností centrálně spravovat pravidla, která jsou použita na více místech v aplikaci či dokonce v několika aplikacích, pomocí nástrojů vhodných i pro méně informaticky zdatné, například reprezentací pravidel grafiky nebo ve formě formulářů. To vede nejen k zajištění konzistence pravidel napříč systémy, ale i zmenšuje požadavky na systémové vývojáře, protože se některé činnosti dají nyní vyřešit bez jejich součinnosti. V neposlední řadě jsou Drools pravidla zapisována nikoliv procedurálně, ale deklarativně a vykonávající engine proto může využít různých optimalizací pro urychlení rozhodování. rule "Add Google Docs route - DELETE" when #conditions $msg : FileDescriptorDTO( extension in ("txt", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "pdf") ) then #actions $msg.header.get("destinationRoutes").add(GOOGLE_DOCS_ROUTE); end ... Zdrojový kód 4.1 – Ukázka Drools pravidla (zjednodušené pravidlo použité v aplikaci)

V aplikaci se nachází několik služeb implementovaných pomocí Drools pravidel, většinou pro určení cílové služby pro směrování na gateway ve BPMN procesu (gateway – „brána“ – je element v diagramu – čtverec postavený na roh – který zajišťuje konvergenci nebo divergenci informačního toku uvnitř procesu). Pravidla v aplikaci jsou uložena staticky (v rámci aplikačního balíčku), tedy nikoliv vzdáleném repositáři, což by umožňovalo centrální správu a jejich změnu za běhu aplikace. Podpora pro vzdálená pravidla je nicméně v ESB Switchyard zahrnuta, ale vyžaduje nasazení externího systému pro správu pravidel.

4.2.3.2. 4.2.3.2.a

Detail vybraných služeb Synchronizace Dropboxu

Služba synchronizace Dropboxu (Dropbox Sync) je službou, která využívá jako přímé či tranzitivně podstatnou část služeb tvořících tuto aplikaci. Pro představu jak probíhá životní cyklus požadavku, který je touto službou obsloužen, budou popsány dílčí části, u kterých není z návrhu zřejmé, jak probíhají. Pro globální pohled na celou kompozici této služby

Kapitola 4

Integrace služeb

62

nejlépe poslouží následující diagram, který je tentokrát znázorněn s propojeními mezi komponentami.

Obrázek 4.4 – Diagram propojení komponent v detailu na službu Dropbox Sync

Detail jedné transakce V případě služby Dropbox Sync je logický počátek transakce realizován mimo aplikaci samotnou prostřednictvím uživatelské akce zapříčiňující nahrání souboru do Dropboxu. Vzhledem k tomu, že služba Dropbox aktivně neinformuje klienty/konzumenty o změnách, bylo nutné implementovat mechanizmus, který bude realizovat tuto funkčnost jinou cestou. Služba Dropbox Sync, jak bylo v návrhu nastíněno, zjišťuje změny v souborech uložených ve službě Dropbox a ty pak propaguje dále do aplikace, což vede k uložení nově detekovaných

Kapitola 4

Integrace služeb

63

souborů pomocí Store File aplikační komponenty na cílové externí služby. Nicméně služba sama o sobě potřebuje být zavolána, aby mohlo dojít ke sledu událostí popsaných výše. K tomu je využito její navázání na JMS vstupní vazbu (A), kde přijmutím požadavku do konkrétní JMS fronty dojde ke spuštění služby. Pro generování takovýchto požadavku, které pro smysluplné využití musí být v pravidelném a relativně krátkém intervalu je využit externí klient, který v intervalech jedné minuty posílá do JMS fronty zprávu a tím celou transakci zahajuje. Klient je implementován jako EJB Singleton komponenta a je nasazen ve stejném prostředí jako ESB Switchyard, tedy v JBoss AS 7 aplikačním serveru. Opakovaného volaní je docíleno pomocí @Schedule anotace, která pro EJB Bean služby umožňuje načasovat pravidelné volání anotované metody. Tímto způsobem dojde k zavolání Dropbox Sync služby a transakce poté probíhá v rámci aplikace a běhovém prostředí ESB Switchyard. Následující sled událostí odpovídá specifikaci navržených služeb a diagramu výše. Připomeňme, že vazby E a B jsou logicky propojeny a tím dochází k pokračování transakce. Jak bylo v návrhu (4.2.2) řečeno, důvodem této extrakce vazby mezi službami, které by jinak logicky vedla z komponenty Msg. Splitter přímo do Dropbox Retrieve-Store pomocí implicitní vazby SCA běhového prostředí, je motivace pro distribuci požadavků mezi uzly clusteru vzniklých v případě, že se mezi periodickými voláními změnilo více souborů ve službě Dropbox, protože jejich zpracování pak probíhá jednotlivě a právě tyto jednotlivá zpracování lze urychlit distribucí na více uzlů clusteru.

4.2.3.3.

Řešení autorizace externích služeb

Veškeré údaje potřebné pro autorizace v externích službách jsou, uloženy a čerpány staticky z java interfacu vyhrazenému konstantám. Není tedy možné zasílat soubory do stejné externí služby pod různými přístupovými právy. Ke zvolení tohoto postupu vedl fakt, že využití například konfiguračních souborů by vzhledem k charakteru aplikace nevedlo k zjednodušení přístupu ze strany uživatele (stejně by bylo nutné minimálně znovu sestavit celý aplikační archiv, ačkoliv bez nutnosti rekompilace). Uložení externích údajů v databázi by bylo možné, ale neúměrně užitku by zesložiťovalo celou aplikaci. Přístupové údaje ke službám, které jsou v základním stavu nakonfigurovány pro funkčnost s aplikací, jsou uvedeny v příloze.

4. 3. Specifika vývoje Během návrhu a implementace aplikace bylo zjištěno konkrétností, které se sice vztahují k aplikaci, ale mají také širší návaznosti, ať už se jedná o specifika ESB Switchyard nebo obecného vývoje podobných aplikací. Tato kapitola by se také dala chápat s nadsázkou jako postřehy z boje. Je také pravděpodobné, že některé z nich již byly někde v textu zmíněny či naznačeny.

Kapitola 4

Integrace služeb

64

4.3.1. REST a SOAP WS Webové služby tak, jak je tato aplikace integrovala, byly rozděleny do dvou typů, jejichž faktické rozdíly zde nebudeme zmiňovat, co však je dobré zmínit je fakt, který již mohl vyplynout z implementace služeb, SOAP je pro integraci v systémech ESB Switchyard mnohem více podporován, což umožňuje velmi elegantně externí služby dostupné přes tento protokol integrovat. Na druhé straně pro REST webové služby je nutné v podstatě vytvořit vlastního „klienta“ (adaptér), což může být v případě složitějších služeb využívající například uploadování souborů po částech relativně pracná úloha. Ostatně i implementace jednoduchého klienta pro REST službu s několika zdroji, je řádově pracnější, nežli využití automatického zpracování WSDL interface a poskytnutí vzdálené služby přes SOAP.

4.3.2. OAuth Problémem využívání OAuth jako autorizačního protokolu ve webových službách je jeho bezprostřední navázanost na použití webového prohlížeče, kde klasický případ spočívá v neinvazivním přesměrování na webové stránky vlastníka služby, kde dojde k identifikaci klienta a jeho případném souhlasu s využitím služby externí aplikací pod jeho jménem. Oříšek nastává v momentě, kdy aplikace nemá webové rozhraní. Poté se elegantní řešení OAuth změní v problematické, protože je nutné překotně simulovat uživatelovu autorizaci překopírováním URI a generovaných bezpečnostních kódů. V případě podobných aplikací se jeví, jako smysluplnější varianta „podepisovat“ požadavky přímo uživatelským jménem a heslem, případně ještě lepé, jak to je vyřešeno v Amazon S3, hashem 29, který je generován s tajným klíčem, což zajistí jak autorizaci požadavku, tak i jeho konzistenci, navíc v tomto případě není nutné používat šifrované spojení pro zamezení odposlechu přístupových údajů.

4.3.3. Maven a Jar hell Pro kompilaci a sestavování aplikace a pro správu závislostí byl při vývoji s úspěchem využit nástroj Apache Maven 30, který významným způsobem ulehčil vývoj s velmi rychle se měnícími závislostmi daných například překotným vývojem ESB Switchyard. Kromě celkového zjednodušení správy potřebných knihoven a množnosti kompilovat, testovat a sestavit aplikaci i mimo IDE, byl nenahraditelně nápomocen při odhalování konfliktů v závislostech mezi různými knihovnami. V případě, že jsou v systému knihovny sdílející společnou závislost na jedné knihovně, ale v jiné verzi, může dojit v krajních případech k velmi těžko vypátratelným chybám, kde je nutný explicitní zásah a určení s jakou ze závislostí se bude nakonec aplikace sestavovat. Bohužel to není vždy tak jednoduché jako

29 30

Autentizace zpráv na základě hashování – http://en.wikipedia.org/wiki/HMAC http://maven.apache.org/

Kapitola 4

Integrace služeb

65

zvolit nejnovější možnou verzi dané knihovny. Jen těžko si lze představit, jak by se podobný problém řešil bez obdobného nástroje.

4.3.4. Transformery Transformery 31 jsou velmi užitečnou vlastností, kterou nabízí Switchyard, o čemž se bylo možné v průběhu implementace nesčetněkrát ubezpečit. Vzhledem k tomu, že jejich použití je velmi jednoduché, bylo možné uvažovat nad službami nezávisle, nehledě na to jaké vstupy či výstupy mají komponenty se kterými je daná služba nucena komunikovat. Důležité je, že v i v případě takto nezávisle stavěných služeb se není nutné obávat zvýšeného množství služeb pomocných, které by suplovaly deklarativně definované transformátory, ale jejich použití by muselo být explicitní a tím by činily celý návrh méně čitelným.

4.3.5. Vývoj na rozvíjející se opensource platformě Z trošku jiného úhlu než předchozí ryze technická specifika je vývoj na platformě, která zatím nedosáhla své oficiální produkční verze a její vývoj je veden ryze veřejně podle zásad opensource software, nicméně ho vyvíjí profesionálové, za nimiž stojí komerčně aktivní firma. Vzhledem k tomu, že je Switchyard ve stále raných stadiích vývoje, zdarma a s prozatím relativně malou základnou uživatelů bylo, především v raných fázích poněkud obtížné vniknout do problematiky a zorientovat se, ačkoliv se vývojáři snaží udržovat technickou dokumentaci a uživatelskou příručku v rozumné kvalitě, je patrné, že vlastní vývoj systému je momentálně přednější, než aktualizace a rozšiřování materiálů pro vývojáře. Tím, že se jedná o stále ranou verzi, bylo na místě očekávat omezené funkce a chyby, na což se v průběhu vývoje této aplikace také narazilo. Ačkoliv se může zdát, že vývoj na takto mladém systému s sebou přinesl pouze obtíže (v porovnání se stabilními a rozšířenými systémy), přinesl i zajímavé příležitosti. Například řešení problémů, kterých nebylo málo, přímo s hlavními vývojáři na veřejném IRC 32 kanále bylo neocenitelné, stejně jako možnost alespoň malým způsobem přispět k dalšímu vývoji reportováním možných chyb a vznášením požadavků pro další vývoj. Bylo také velmi zajímavé (ač někdy k naštvání), jaký pokrok byl dosažen za dobu psaní této práce, kdy proběhly verze 0.2 až 0.4. K rozmrzelosti mohlo přispět, že problémy, které byly v rámci této práce komplikovaně řešeny v raných verzích, byly v následujících verzích odstraněny autory samotnými (toto se týkalo hlavně integrace SY s aplikačním serverem). Nakonec této podkapitoly bych jen připomenul množství práce, které bylo věnováno na implementaci clusterování na úrovni MOM, protože samotný SY zatím clustrovatelný není,

31 32

https://docs.jboss.org/author/display/SWITCHYARD/Transformation irc://irc.freenode.org/#switchyard

Kapitola 4

Integrace služeb

66

a právě to bude s příchodem (dle informací vývojářů) následující verze implicitně vyřešené clusterováním na úrovni samotného SY.

4. 4. Rozšíření nástroje pro podporu a správu Jedním z cílů této práce bylo také rozšířit nástroj pro podporu a správu služeb vytvořených pro tuto aplikace. Toto v praxi mohlo a mělo vypadat tak, že se rozšíří editor BPMN 2 procesů (který je oficiálně určen pro SY, jedná se o zásuvný modul do IDE Eclipse) o nové elementy, podobně jak je rozšiřuje samotný SY o univerzální SY komponentu, která umožňuje jednoduše graficky pracovat se službami SY v rámci procesu. Proces přidání vlastních elementů do výše zmiňovaného pluginu je proces neinvazivní a nevyžaduje změnu pluginu samotného, což by mimo jiné velmi zkomplikovalo jeho znovuvyužití v případě nové verze, plugin je relativně snadno rozšířitelný o nové úlohy (jak se v něm služby označují) a to tím, že skenuje aktuální knihovny a zdrojové kódy v projektu aby našel eventuelní rozšíření, stejným způsobem jako toho dociluje pro přidání vlastní generické úlohy SY. Problém nastává v momentě, kdy chceme přidat vlastní úlohy, které by navíc měly být spustitelné/zpracovatelné běhovým prostředím SY, v tomto případě je nutné z jedné strany implementovat rozhraní (a tím se nemyslí jednoduchý Java interface), které umožní jejich volání přímo z BPMN a zároveň zachovat funkčnost SY, což vzhledem k tomu jak netriviálně je implementována komunikace mezi BPMN komponentou a SY nebylo z časových důvodů možné a dost možná ani realizovatelná aniž by nedošlo k silné závislosti na konkrétní verzi SY tím, že se například rozšíří jeho celková komponenta pro podporu těchto vlastních uživatelských úloh. Z výše uvedených důvodů a časového omezení pro analýzu realizaci alternativních řešení nebyl tento cíl práce naplněn.

Kapitola 5 Nasazení aplikace a testování Tato kapitola je logickým propojením předchozích dvou kapitol (Kapitola 3 a Kapitola 4), kde na námi vytvořenou platformu umístěnou v cloudové infrastruktuře nasadíme aplikaci, které byla věnována Kapitola 4. Zmíníme se však také o specifickém způsobu testování služeb v ESB Switchyard, které v sobě kloubí sílu unit testování a zároveň běh ve specifickém běhovém prostředí. Nasazení aplikace a její výkonnostní měření pak bude završením této kapitoly.

5. 1. Specifické unit testování Zajímavou vlastností, která významně ulehčuje vývoj služeb a ESB aplikací je testovací aparát, kterým Switchyard disponuje. Kromě jednoduchých jednotkových testů, které lze samozřejmě využít pro komponenty aplikace psané v Javě, přináší nebo spíš rozšiřuje možnost jednotlivě testovat samostatné služby a vazby, které jsou v rámci SCA aplikace definovány. Této funkcionality je dosaženo rozšířením standardního jUnit testovacího mechanismu v Javě tím, že se pomocí anotací u vlastních testů a testovacích tříd definují parametry, které slouží k zavedení a parametrizování vlastního Switchyard běhového prostředí. Jak takový test služby vypadá je vidět na následujícím ústřižku kódu. @RunWith(SwitchYardRunner.class) @SwitchYardTestCaseConfig(...) public class ServiceTest { @ServiceOperation(serviceName + "." + operationName) private Invoker doOperation;

}

@Test public void testOperationNotNull() { Object recieved = this.doOperation.sendInOut(new MyDTO()).getContent(); Assert.assertNotNull(recieved); }

Zdrojový kód 5.1 – Ukázka testování v SY

67

Kapitola 5

Nasazení aplikace a testování

68

Způsobem uvedeným výše byla v aplikaci testována většina služeb. Zároveň se tento přístup hodil k experimentování a zkoušení nových komponent (například Drools nebo BPMN), kde je možné zjišťovat a nastavovat hodnoty které jsou pak v běžném provozu spravovány transparentně runtime. Toto se ukázalo jako klíčové při vývoji BPMN komponent, kde jsou některé proměnné přenášené mezi procesem v BPMN a službami jež jsou volány, předávány poměrně netriviálně a hlavně jsou tyto vnitřní operace velmi špatně dokumentovány, což vyžaduje zvýšenou nutnost pozornosti.

5. 2. Nasazení a škálování systému Aplikace je nasaditelná do běhového prostředí obdobně, jako aplikace do webových či aplikačních serverů, ve formě war, či jar archivu. Aplikaci takto připravenou lze nahrát standardní cestou na JBoss AS 7 s modulem SY a nahraní a spuštění aplikace je pak čistě v režii aplikačního serveru. Aplikace jde kromě platformy, nasazené v cloudové infrastruktuře (viz Kapitola 3) spustit i v lokálním prostředí, je však nutné mít správně nainstalován a nakonfigurován aplikační server a modul SY (kromě konfigurace prostředí samotného jsou nutné deklarace JMS front, které aplikace využívá). V případě nasazení do clustrovaného prostředí v cloudové infrastruktuře je situace obdobná, pouze se aplikační balík umístí na do aplikačního serveru každé instance v clusteru. Umístění EJB komponenty pro periodické spouštění služby je ovšem omezenou na pouze jeden libovolný uzel s clusteru, protože implementace clustrované EJB Singleton služby nebylo realizováno. Nicméně zprávy, které jsou touto EJB službou periodicky zasílány jsou MOM distribuovány rovnoměrně na oba uzly a tudíž dochází k distribuci zátěže.

5. 3. Metodika testování Pro zátěžové testování na clusteru běžící aplikace byl zvolen následující scénář. Pro minimalizaci ovlivnění výsledků nízkou datovou propustností linky testující stanice byla pro zátěžové testy vytvořena nová instance v EC 2 (typ Micro 33), na kterou byl nainstalován nástroj pro měření zátěže Apache Benchmark 34, který je součástí Apache HTTP serveru. Následně byl tento nástroj využit pro zátěžové testování celého clusteru a pro porovnání také jednotlivého uzlu. V případě testování clusteru byla jako adresa hostu použita adresa loadbalanceru přiřazeného našemu clusteru a v případě testování jednotlivého uzlu byla

33 34

viz Tabulka 3.1 – Typy instancí na EC2 (Převzato z [4] a platné k 22. 4. 2012) http://httpd.apache.org/docs/2.0/programs/ab.html

Kapitola 5


69

použita veřejná adresa zvoleného uzlu (libovolného). Vzhledem k tomu, že se ukázalo, že instance EC2 typu micro není schopna kvůli nízkému množství RAM (613 MB) pracovat korektně s nasazenými aplikacemi (docházelo k náhodnému ukončování procesu serveru s odůvodněním na vyčerpání paměťové kapacity), byly pro test využity instance typu small a medium pro porovnání škálování s množstvím výpočetních prostředků jedné instance.

Obrázek 5.1 – Diagram testovacího prostředí

Pomocí zátěžového testování byla zkoušena REST webová služba, která je vstupním místem pro aplikaci popsanou v kapitole 4 Integrace služeb. Funkcionalita realizující automatickou synchronizaci služby Dropbox s aplikací byla testována pouze formálně tak, že bylo do synchronizované složky Dropbox nahráno přibližně 100 souborů a bylo sledováno, jestli jsou v rámci požadavky na uložení jednotlivých souborů distribuovány, což bylo potvrzeno okometricky z připojených serverových konzolí. REST služba aplikace pak byla testována pouze pomocí operace GET, protože ostatní operace jsou velmi porovnatelné ve složitosti uvnitř aplikace a pro přehled vlivu různých konfigurací platformy na výkon aplikace je dle mého názoru dostačující. Vzhledem k faktu, že aplikace využívá externích služeb, bylo na místě očekávat to, že výkonnost aplikace bude naprosto závislá právě výkonnosti služeb externích. V tomto hrají velkou roli kontrakty (SLA 35) jednotlivých služeb, které formálně upřesňují jaké kvantitativní a kvalitativní charakteristiky bude daná služba poskytovat (například minimum požadavků za sec).

35

Service-level agreement – http://en.wikipedia.org/wiki/Service-level_agreement

Kapitola 5


70

5. 4. Výsledky testování Výsledky testování při nastavení Apache Benchmark, 500 souběžných spojení, 1000 požadavků, požadavek na GET file. Výsledky jsou průměrem několika měření. Typ instance

Typ testu

Typ souboru*

Velikost požadavků/s souboru

medián latence [s]

maximální latence [s]

Small

Instance

bin

7B

98,6

4,54

10

Small

Cluster

bin

7B

183

3,5

7.87

Medium

Instance

bin

7B

142

1,93

7,03

Medium

Cluster

bin

7B

281

2,95

6,4

Small

Instance

jpg

~1 KB

28

12,09

31,89

Small

Cluster

jpg

~1 KB

58,9

6,19

16,9

Medium

Cluster

jpg

~1 KB

85,5

3,83

11,18

Small

Instance

txt

7B

4,04

4,51

20,03

Small

Cluster

txt

7B

4.91

4,1

14,3

Tabulka 5.1 – Data ze zátěžového testu

* Typ souborů určuje, jaké externí služby budou využity pro získání souboru, v případě bin je to pouze Amazon S3, pro jpg je to Amazon S3 a Picasa Web Albums a pro txt je to Amazon S3 a Google Docs. Jak je možné vidět z dat, počet požadavků, které je schopna aplikace obsloužit nezávisí pouze na množství hardwarových prostředků, což je očekávatelné, ale i na typu souboru, protože od něj se odvíjí, jaké externí služby budou využity. V případě využití pouze služby Amazon S3 (pro typ souboru bin), je logické, že počet požadavků bude maximální a odezva minimální, protože lze předpokládat velmi silné spojení mezi Amazon EC2 a S3. S každou další službou pak výkonnost klesá, jak je vidět u jpg, kde může hrát také roli větší velikost souboru. V případě txt souboru, který jako jediný z testovaných využívá Google Docs, může udivit velmi nízký a neškálující frekvence požadavků, to je dáno tím, že Google Docs, ačkoliv se to oficiálně neuvádí, omezuje počet požadavků na jeden účet skrze své API na

Kapitola 5


71

přibližně 10/s (dle neoficiálních zdrojů 36), což odpovídá, protože pro načtení souboru v rámci aplikace jsou potřeba 2 požadavky (vyhledat interní id dle jména a stáhnout podle id). Všechny tyto požadavky byly záměrně nad velmi malými soubory, aby se anulovalo limitování nízkou kapacitou linky klienta. Bylo testováno stáhnutí 766 KB souboru typu jpg na 20 souběžných připojení, 200 požadavcích, small instanci a clusterováním s průměrnou rychlostí 2,27 MB/s. Je evidentní, že v případě integrování služeb je integrační aplikace plně závislá na technických parametrech všech služeb, které využívá. Výsledky těchto testů nemají vést k hlubším závěrům o výkonnosti dané aplikace nebo platformy, která je stále v rané fázi vývoje a lze očekávat, že rychlostí optimalizace prozatím nejsou aktuálním cílem jejích autorů, ale spíše demonstrovat jakým způsobem lze v cloudovém prostředí rozšiřovat možnosti aplikace za použití jak horizontálního (počet uzlů clusteru) tak vertikálního (výpočetní síla jednotlivých uzlů) škálování clusteru.

36

http://stackoverflow.com/questions/7643296/hitting-rate-limit-for-google-maps-api-but-dont-know-why

Kapitola 6 Závěr Integrace aplikací bude dle mého názoru s přibývajícím významem softwaru postaveného ve formě webové aplikací v budoucnu stále více rozvíjející se disciplína softwarového inženýra. Touto prací byly nastíněny základní principy a postupy, které je dobré brát v potaz, pakliže je naším cílem integrovat aplikace čistě v rámci Internetu. Pro tento účel posloužily, jak teoretické přehledy technologických možností a aplikačních architektur tak i praktická realizace platformy čistě využívající cloudové infrastruktury a na ni následně nasazený demonstrační systém integrující webové aplikace třetích stran. Pro praktickou realizaci byla zvolena softwarová architektura orientovaná na služby – SOA, která se zdá být pro řešení podobných situací výhodná a je, podobně jako cloudové aplikace obecně, do budoucna značně perspektivní. V případě takovéto architektury je pak značně žádoucí, využít pro výstavbu integrované aplikace některé z řady možných aplikačních platforem, které podporují jako tmel výstavbu aplikací, které se odkazují na SOA. Jedna z těchto platforem, které se často obecně označují jako Enterprise Service Bus byla také zvolena, jako základ pro výstavbu vlastní integrující aplikace, tím se stal JBoss Switchyard. Kromě zmíněného odkazu na SOA, byl tento produkt zajímavý i způsobem opensource vývoje, který byl v době psaní této práce navíc v rané fázi, což přineslo řadu poznatků a zkušeností, které by se produkčním softwarem daly těžko či vůbec uskutečnit. Završením této práce bylo vystavění clustrovaného systému postavené nad zvolenou integrační platformou čistě v cloudové infrastruktuře Amazon EC2, což v sobě zahrnovalo jak konfiguraci vlastních virtuálních uzlů clusteru a následné konfigurace aplikačních serverů pro podporu clusterování, tak i nasazení vlastní ukázkové aplikace a její zátěžové testování. Jak je z výše uvedeného patrné, tato práce zahrnovala značné množství relativně různorodé softwarově inženýrské činnosti, který měla jednoho společného jmenovatele, cloud. Věřím, že ačkoliv může mít toto slovo nálepku marketingového sloganu, vedly i výstupy této práce k identifikování skutečných možností a přínosů, které tento fenomén poskytuje.

73

Kapitola 7 Použitá literatura 1. Erl, Thomas. SOA : principles of service design. místo neznámé : Prentice Hall, 2008. 978-0-13-234482-1. 2. Chappell, David. Introducing SCA. http://www.davidchappell.com/. [Online] 8 2007. http://www.davidchappell.com/articles/introducing_sca.pdf. 3. Velte, Toby J., Elsenpeter, Rober a Velte, Anthony T. Cloud Computing, praktický průvodce. místo neznámé : Computer Press, 2011. 9788025133330. 4. Amazon. Amazon Elastic Compute Cloud Documentation. AWS Documentation. [Online] [Citace: 20. 1 2012.] http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Welcome.html?r=6341. 5. —. Amazon EC2 Spot Instances. Amazon AWS. [Online] Amazon. [Citace: 20. 1 2012.] http://aws.amazon.com/ec2/spot-instances/. 6. —. Amazon Elastic Block Store (EBS) – Amazon EBS Volume Durability. Amazon AWS. [Online] Amazon. [Citace: 20. 1 2012.] http://aws.amazon.com/ebs/. 7. —. Amazon Simple Storage Service (Amazon S3) – Data Durability and Reliability. Amazon AWS. [Online] Amazon. [Citace: 20. 1 2012.] http://aws.amazon.com/s3/. 8. Woolf, Bobby. ESB-oriented architecture: The wrong approach to adopting SOA. IBM developer Works. [Online] IBM, 1. 2 2012. http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/. 9. Hohpe, Gregor a Woolf, Bobby. Enterprise Integration Patterns. místo neznámé : Addison-Wesley Professional, 2003. 978-0321200686. 10. Barnatt, Christopher. A Brief Guide to Cloud Computing. místo neznámé : Constable & Robinson, 2011. 978-80-245-1660-8.

75

11. IBM Redbooks. Patterns: Implementing an SOA using an Enterprise Service Bus. IBM Redbooks. [Online] [Citace: 1. 2 2012.] http://www.redbooks.ibm.com/abstracts/sg246346.html. 12. CloudStorageStrategy.com. Cloud Computing Unleashes the Potential of Service Oriented Architecture. Cloud Storage Strategy. [Online] Cloud Storage Strategy. http://cloudstoragestrategy.com/2009/06/cloud-computing-unleashes-the-potential-ofservice-oriented-architecture.html. 13. McKendrick, Joe. Why SOA really, really matters in a cloud computing world. ZDNet. [Online] ZDNet. [Citace: 20. 1 2012.] http://www.zdnet.com/blog/service-oriented/whysoa-really-really-matters-in-a-cloud-computing-world/2179. 14. Chatterjee, Arunava. Service-Component Architectures. Dr. Dobb's. [Online] Dr. Dobb's. http://drdobbs.com/architecture-and-design/201202701. 15. Robinson, Rick. Understand Enterprise Service Bus scenarios and solutions in ServiceOriented Architecture. IBM developer Works. [Online] IBM. [Citace: 20. 1 2012.] https://www.ibm.com/developerworks/library/ws-esbscen/. 16. Optimation. Open Source Enterprise Service Bus (ESB) Evaluation. http://www.optimation.co.nz. [Online] [Citace: 20. 2 2012.] http://www.optimation.co.nz/assets/Resources/Optimation-ResourceESB-Comparison.pdf. 17. Berg, Jose Luiz. The Integration Between EAI and SOA. SOA Magazine. [Online] [Citace: 20. 1 2012.] http://www.soamag.com/I49/0411-2.php. 18. Bloomberg, Jason. Where is the SOA in REST-based SOA? ZapThink. [Online] ZapThink. [Citace: 20. 1 2012.] http://www.zapthink.com/2011/09/14/where-is-the-soain-rest-based-soa/. 19. Malladi, Sastry. RESTful SOA in the Real World. InfoQ. [Online] http://www.infoq.com/presentations/RESTful-SOA-in-the-Real-World. 20. Leymann, Frank. BPEL vs BPMN 2.0: Should you care? Universität Potsdam. [Online] 2010. [Citace: 20. 1 2012.] http://bpt.hpi.unipotsdam.de/pub/BPMN2010/Program/bpmn2010_leymann.pdf. 21. Juřek, Michael. Moderní integrace aplikací. www.microsoft.com. [Online] 2004. [Citace: 1. 2 2012.] http://download.microsoft.com/download/8/6/c/86c09926-affc-4e14bec0-3c45cd989436/Moderni_integrace.pdf.

76

22. Vollmer, Ken. The Forrester Wave™: Enterprise Service Bus. The Forrester Wave. [Online] 25. 5 2011. [Citace: 20. 1 2012.] http://www.slideshare.net/jricardoferreira/theforrester-wave-enterprise-service-bus-q2-2011. 23. Cope, Rod. Comparation of Open Source ESB Solutions. Slide Share. [Online] 4. 8 2010. [Citace: 20. 1 2012.] http://www.slideshare.net/OpenLogic/comparison-of-opensource-esb-solutions. 24. Barr, Jeff, Narin, Attila a Varia, Jinesh. Building Fault-Tolerant Applications on AWS. Amazon AWS Whitebooks. [Online] 10 2011. [Citace: 20. 1 2012.] 25. Tavis, Matt. Web Application Hosting in the AWS Cloud: Best Practices. Amazon AWS Whitebooks. [Online] 5 2010. [Citace: 20. 1 2012.] http://d36cz9buwru1tt.cloudfront.net/AWS_Web_Hosting_Best_Practices.pdf. 26. JBoss. Community Forum - No AS 7 for JBoss ESB. JBoss. [Online] https://community.jboss.org/message/627892. 27. Swidler, Shlomo. The “Elastic” in “Elastic Load Balancing”: ELB Elasticity and How to Test it. Shlomo Swidler – Cloud Developer Tips. [Online] [Citace: 20. 1 2012.] http://shlomoswidler.com/2009/07/elastic-in-elastic-load-balancing-elb.html. 28. Wikipedia Community. Enterprise application integration. Wikipedia: The Free Encyclopedia. [Online] [Citace: 20. 1 2012.] http://en.wikipedia.org/wiki/Enterprise_application_integration. 29. —. David Wheeler (computer scientist). Wikipedia: The Free Encyclopedia. [Online] [Citace: 20. 1 2012.] http://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist). 30. Tidwell, Doug. Cloud - SOA = Zero. IBM developer Works. [Online] IBM. https://www.ibm.com/developerworks/mydeveloperworks/blogs/doug_tidwell/entry/cloud_ soa_zero2?lang=en.

77

Příloha A Konfigurace MOM Úryvek z konfigurace MOM clusterování <server name="Mako" xmlns="urn:jboss:domain:1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchemainstance"> ... <profile> <subsystem xmlns="urn:jboss:domain:messaging:1.1"> ... ... ... ...
jms
netty 500 true <static-connectors> server2-connector ... ... ... <socket-binding-group name="standard-sockets" default-interface="public"> ... ... ...

78

Příloha B Služby a přístupové údaje Veškeré konstanty pro autorizaci do externích služeb jsou uloženy ve zdrojových kódech aplikace, v Java interfejsu: cz.cvut.fit.culkajac.dp.Constants;

Uživatelská přihlašovací jména a hesla jsou také uložena na CD v souboru credentials.txt ve složce src.

79

Příloha C Uživatelský návod Pro spuštění aplikace pro testování v lokálním prostředí postupujte podle následujících kroků. 1. Ujistěte se, že je v systému obsažen Java Runtime verze 1.6 nebo vyšší 2. Rozbalte obsah archivu switchyard-as7-0.4.zip ve složce {CD}/platform/ do zvolené složky na cílovém počítači (označíme jako {server_folder}). 3. Spusťte server v módu standalone s defaultní (ve smyslu konfigurace v defaultním konfiguračním souboru) konfiguraci pomocí příkazu v konzoli podle vaší platformy (*nix – .sh, windows – .bat). > {server_folder}/switchyard-as7-0.4/bin/standalone.(sh|bat)

4. Nasaďte aplikaci zkopírováním všech aplikačních balíčků z {CD}/bin/ do

{server_folder}/switchyard-as7-0.4/standalone/deployments

5. Aplikace by nyní měla běžet a webová služba být přístupná na adrese http://localhost:8080/cvut-dp/app/file{/resource}

6. Pro testování nahrávání souboru lze využít připravený formulář na adrese http://localhost:8080/cvut-dp/postFile.xhtml

80

Příloha D Obsah CD CD │ ├─ ├─ ├─ └─

src bin platform text

– – – –

zdrojové kódy aplikace z implementační části balík sestavené a zkompilované aplikace zkonfigurovaný aplikační server zdrojový soubor a pdf textu této práce

81

Příloha F Seznam použitých zkratek AMI

Amazon Machine Image

API

Application Programming Interface

BPEL

Business Process Execution Language

BPMN

Business Process Model and Notation

EAI

Enterprise Application Integration

EBS

Elastic Block Storage (Amazon)

EC2

Elastic Compute Cloud (Amazon)

EIP

Enterprise Integration Patterns

EJB

Enterprise Java Bean

rozhraní pro programování aplikací

integrace podnikových aplikací

návrhové vzory pro podnikovou integraci

ELB

Elastic Load Balancer

ESB

Enterprise Service Bus

podniková sběrnice služeb

GPGPU

General-Purpose Graphics Processing Unit

grafická karty pro univerzální výpočty

IaaS

Infrastructure as a Service

IDE

Integrated Development Environment

JBI

Java Business Integration

JMS

Java Messaging Service

JSON

JavaScript Object Notation

Javascriptový zápis objektů

JVM

Java Virtual Machine

MOM

Message oriented middleware

Java virtuální stroj softwarová vrstva pro předávání dat pomocí definovaných kanálů

OSS

OpenSource Software

PaaS

Platform as a Service

POJO

Plain Old Java Object

REST

REpresentational State Transfer

RMI

Remote Method Invocation

SaaS

Software as a Service

SCA

Service Component Architecture

SCDL

Service Component Definition Language

SLA

Service-Level Agreement

ujednání o rozsahu služeb

SOA

Software Oriented Architecture

architektura orientovaná na služby

SOAP

Simple Object Access Protocol

SY

SwitchYard

vývojové prostředí

základní objekt v Javě vzdálené volání metod

82

UDDI

Universal Description Discovery and Integration

URI

Universal Resource Identifier

VHD

Virtual Hard Disk

VPC

Virtual Private Cloud

VPN

Virtual Private Network

WADL

Web Application Description Language

jazyk pro popis webových služeb (typicky REST)

WS

Web Service

webová služba

WSDL

Web Services Description Language

jazyk pro popis webových služeb (typicky SOAP)

XML

eXtensible Markup Language

značkovací jazyk

identifikátor zdroje

83

Integrace aplikací v prostředí cloud

Recommend Documents