MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Û¡¢£¤¥¦§¨ª«¬­Æ°±²³´µ·¸¹º»¼½¾¿Ý Porovnání výkonu SwitchYard a jiných OSS ESB implementací BAKALÁRSKA PRÁCA Pavol Bako Brno, 2013 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským die- lom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich ˇcerpal,v práci riadne citu- jem s uvedením úplného odkazu na príslušný zdroj. Pavol Bako Vedúci práce: Mgr. Marek Grác i Kl’úˇcovéslová SOA, ESB, SCA, servisne orientovaná architektúra, service oriented archi- tecture, enterprise service bus, integraˇcnýsystém, výkonnostné testovanie, podniková zbernica služieb ii Pod’akovanie Chcel by som sa pod’akovat’ pánovi JiˇrímuPechancovi, ktorý ma sprevá- dzal po celú dobu práce, a ktorý mal strpenia na moje otázky. Takisto by som sa chcel pod’akovat’, že mi umožnil po dobu niekol’ko mesiacov pra- covat’ na bakalárskej práci v priestoroch spoloˇcnostiRed Hat vo svojej do- stupnosti a umožnil mi tak efektívnejšie riešit’ problémy. iii Obsah 1 Úvod ................................... 1 2 Služobne orientovaná architektúra (SOA) ............. 3 2.1 Integraˇcnésystémy a SOA pravidlá . 3 2.1.1 Point-to-point model . 4 2.1.2 Hub-and-spoke model . 5 2.1.3 Bus model (ESB) . 6 2.1.4 SCA OASIS architektúra . 6 3 Podniková zbernica služieb (ESB) .................. 7 3.1 Charakteristika posielania správ . 7 3.2 Prehl’ad základných vlastností . 7 3.3 Hl’adanie definície ESB . 9 4 Metodika testovania .......................... 10 4.1 Scenáre testovania a prostredie testovania . 10 4.1.1 DirectProxy . 11 4.1.2 CBRProxy . 11 4.1.3 XSLTProxy . 13 4.2 ESB Performance framework . 13 4.2.1 Výkonnostné testovanie v ESB Performance . 13 4.2.2 ESB Performance framework . 14 4.3 Amazon AWS EC2 . 16 4.3.1 Parametre AMI . 16 4.3.2 Spúšt’anie testov - všeobecne . 17 5 SwitchYard - implementácia ..................... 18 5.1 Základné vlastnosti frameworku . 18 5.2 Postup pri implementácii . 20 5.2.1 Príprava nástrojov na implementáciu . 20 5.3 Implementácia scenárov . 21 5.3.1 DirectProxy . 21 5.3.1.1 DirectProxy bug a workaround . 22 5.3.2 CBRProxy . 22 5.3.2.1 CBRProxy bug a workaround . 22 5.3.3 CBRSOAPHeaderProxy . 23 5.3.4 CBRTransportHeaderProxy . 23 5.3.5 XSLTProxy . 23 5.4 Nasadenie do Amazon EC2 . 24 6 Testovanie ................................ 25 6.1 Mule ESB . 25 iv 6.1.1 Výsledky a chybové situácie . 26 6.2 SwitchYard v0.7 . 26 6.2.1 Výsledky a chybové situácie . 26 6.3 UltraESB v1.7.1-Vanilla . 27 6.4 WSO2 v4.6.0 . 28 6.4.1 Rozdiel v testovaní WSO2 v4.6.0 oproti ostatným ESB 29 7 Vyhodnotenie výsledkov ....................... 31 7.1 Vyhodnotenie na základe vel’kosti správy . 31 7.2 Vyhodnotenie na základe súbežného prístupu . 32 7.3 Vyhodnotenie z pohl’adu testových scenárov . 33 7.4 Výsledné porovnanie . 35 8 Záver ................................... 37 A Ostatné grafy výkonnostného testovania . 42 B Zát’až CPU na Amazon EC2 po dobu testu . 47 v 1 Úvod Heterogénnost’ súˇcasných informaˇcných technológií môžme považovat’ v dvoch perspektívach za pozitívne a negatívne. Za pozitívum môžeme považovat’ existenciu zdravej konkurencie medzi softvérovými spoloˇcnos- t’ami a priestor pre širšu škálu vol’by spomedzi technologických ponúk. Na druhej strane heterogénnost’ a vzájomná nekompatibilita prináša nutnost’ dodatoˇcnejintegrácie, ktorá predstavuje zbytoˇcnúzát’až navyše. Momen- tálne kl’úˇcovýmslovom na poli integrácie je ESB (Enterprise Service Bus), ktorý v slovenˇcinepoznáme ako podniková zbernica služieb. Systém pod týmto pomenovaním si môžme predstavit’ ako funkˇcnýinteg- raˇcnýsystém postavený na princípoch službovo orientovanej architektúry (SOA - Service Oriented Architecture) so svojbytnou topologiou, ktorá vy- užíva zbernicu dát. Vzhl’adom na to, že máme na trhu celú škálu proprietárnych alebo open source ESB, vyhodnotenie vhodného výberu ESB pre potreby daného pod- niku môže byt’ nel’ahkou úlohou. Hoci majú všetky ESB základné vlast- nosti spoloˇcné,ich realizácia používa úplne diverzné prístupy, štandardy a protokoly. To sa samozrejme odráža i v jednom zo základných kritérii pri porovnávaní ESB, ˇcímje výkon. Našou úlohou bolo priniest’ trochu svetla do danej oblasti touto prácou, ktorá práve poskytne objektívne vý- sledky výkonov od niektorých open source ESB. Hoci v ˇcasepísania tejto práce už niekol’ko podobných testovaní prebehlo, táto práca je jedineˇcná v tom, že prvýkrát prezentuje výkon nováˇcikana poli integraˇcnýchsys- témov a to SwitchYard. SwitchYard je vydávaná pod taktovkou najväˇcšej ˇcistoopen source spoloˇcnostiRed Hat. Na SwitchYard sa teraz upriamuje zvýšená pozornost’, lebo ho Red Hat plánuje nahradit’ za ich doterajší JBoss ESB[3]. Dalejˇ táto práca sumarizuje a sprehl’adˇnujeteoretické pozadie ESB a pravidiel SOA. Ponúka detailnú dokumentáciu, ktorá v prípade potreby testovania d’alších verzii môžu poslúžit’ vývojárom. Pri tvorbe tejto práce sme prechádzali tromi fázami, konkrétne teore- tickou ˇcast’ou, praktickou ˇcast’ou a testovaním. V teoretickej ˇcastisi vy- svetl’ujeme základné poznatky zo strany integraˇcnýchsystémov, do kto- rých spadá aj architektúra ESB a špecifikácie SCA, o ktorých budeme mat’ samostatné kapitoly. Dalejˇ našu pozornost’ upriamím na vysvetlenie SOA pravidel a k definovaniu pojmu ESB, ktorý i dnes býva nesprávne chápaný. V praktickej ˇcastisa venujeme metodike testovania, implementácii testova- cích scenárov SwitchYardu a prezentovaniu výsledkov. Metodiku testova- nia v mnohom ovplyvnil open source testovací framework od AdroitLogic 1 1. ÚVOD s názvom ESB Performance. Dané scenáre, ktoré framework podporuje pat- ria do dnešných najˇcastejšíchscenárov, s ktorými je možné sa stretnút’ v ESB systémoch. Vel’kú ˇcast’ našej energie sme vložili do implementácie SwitchYard sce- nárov kvôli nášmu nedostatku znalostí s používaním tejto technológie a im- plementaˇcnouzávislost’ou, ktorá je daná požiadavkami ESB Performance. Ostatné ESB boli nakonfigurované už v spustitel’nej podobe, preto sme sa jej vývojom nezaoberali. Náš projekt bude poskytnutý tvorcom testovacieho frameworku a tiež bude sprístupnený open source pre zaistenie d’alšieho vývoja. V ˇcastitestovania sa venujeme priebehu testovania a prezentovaniu výsledkov vo forme ˇciarových grafov. Jednu kapitolu venujeme prezen- tovaniu štyroch ESB, ktoré sme považovali za najvhodnejšie vzhl’adom na spol’ahlivost’ výsledkov. Sú to SwitchYard v0.7, Mule ESB v3.3.0., Ul- traESB v1.7.1. a WSO2ESB v4.6.0. V jednoduchosti si predstavujeme zá- kladné špecifiká daných ESB a následne prezentujeme samostatné výsledky každého z nich. V siedmej a poslednej kapitole koneˇcne sp´lˇnamepod- statu práce danou v názve. Porovnanie výkonu prebieha z niekol’kých per- spektív: zo strany scenárou použitia, zo strany vel’kosti posielaných správ a zo strany súbežných prístupov (používatel’ov). Na záver si zhrnieme vý- sledky. Dalšieˇ grafy vrátane celkového grafu je možné nájst’ v prílohovej ˇcasti. 2 2 Služobne orientovaná architektúra (SOA) Aplikaˇcnéprostredie dnešných podnikových systémov je mimoriadne he- terogénne ak vezmeme do úvahy množstvo protokolov a štandardov, ktoré používa. Vzniká tak vel’ký problém nekonzistencie rôznych apliká- cií od rôznych dodávatel’ov. Integrácia týchto aplikácií je pritom jednou z podmienok pre dosiahnutie prosperujúcej organizácie, a preto je nutné hl’adat’ riešenia na tieto požiadavky[1]. Ciastoˇcnériešenieˇ prinieslo stano- venie SOA pravidiel, podl’a ktorých sa každý podnikovo orientovaný sys- tém mohol budovat’, aby bol neustále integrovatel’ný. Na základe týchto pravidiel vznikali rôzne integraˇcnériešenia, ktoré však prechádzali neustá- lym vývinom. Viac k tejto téme si povieme v tejto kapitole. 2.1 Integraˇcnésystémy a SOA pravidlá Zaistenie prepojenosti systému znamenalo pre podniky nemalé finanˇcné prostriedky. Integrácia systémov bola zaist’ovaná ad-hoc podl’a potreby a bez pravidiel alebo postupov. Následne vzniknuté komplikácie vo sfére integrácie viedli postupne k definovaniu pravidiel SOA. Zámerne uvádzam slovo „postupne”, pretože princípy SOA nevznikli revoluˇcne,ale evoluˇcne a stále sa uˇciliz chýb svojich predchodcov. V priebehu rokov sa vyskytli nové technológie ako napr. XML a webové služby (web services)1[2], ktoré boli taktiež doplˇnovanédo spomínaných pravidiel. SOA je sada princípov a metodológií, ktoré pomáhajú k integrácii zložitých aplikácií, ktoré posky- tujú služby[6]. SOA pravidlá by mali slúžit’ k tomu, aby sa daný systém navrhol tak, aby sa v budúcnosti mohol agilne vyvíjat’ a rozširovat’. Agilný prístup je schopnost’ tvorit’ a reagovat’ na zmeny k dosiahnutiu úžitku v turbulentnom podnikatel’skom prostredí[4]. Pristúpime teraz k jej 8-mim hlavným princípom[5]: 1. Štandardizovaný kontrakt služby (Standardized Service Contract) – Kontrakt služby je presne definovaný. To znamená, že už pri ná- vrhu SOA komponenty treba zvážit’ jej technické rozhranie a formát dát. Kontrakt je považovaný za istý sl’ub danej služby svojmu oko- liu, ˇcobude poskytovat’. 2. Slabé väzby medzi komponentami (Service Loose Coupling) – Väzby medzi službami by mali byt’ ˇconajtenšie. To sa dá docielit’ 1. Web Service (WS) je systém pre komunikáciu elektronických zariadení po internetovej sieti. 3 2. SLUŽOBNE ORIENTOVANÁ ARCHITEKTÚRA (SOA) tým, že sú závislosti komponent dodatoˇcnedefinované tesne pred použitím a naviac externe, teda mimo vyvinutú službu, ˇcímsa re- dukuje závislost’ kontraktu služby, jej implementaˇcnejlogiky a kon- zumentov. 3. Princíp abstrakcie (Service Abstraction) – Jeho ciel’om je ˇconajviac