Porovnání Výkonu Switchyard a Jiných OSS ESB Implementací

MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

Porovnání výkonu SwitchYard a jiných OSS ESB implementací

BAKALÁRSKAPRÁ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 architecture, 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 deﬁní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é vlastnosti 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 vysvetl’ujeme základné poznatky zo strany integraˇcnýchsystémov, do kto- rých spadá aj architektúra ESB a špeciﬁkácie SCA, o ktorých budeme mat’ samostatné kapitoly. Dalejˇ našu pozornost’ upriamím na vysvetlenie SOA pravidel a k deﬁnovaniu 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 testovania 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 nakonﬁgurované 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 prezentovaniu š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é špeciﬁká 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ŽOBNEORIENTOVANÁ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 zakryt’ implementaˇcnédetaily služby/komponenty. Dobrý princíp abstrakcie zlepšuje zrnitost’ (granularity) systému a zjednodušuje správu a úpravy systému. 4. Znovupoužitie (Service Reusability) – Pri návrhu akejkol’vek služby ˇcikomponenty by sa malo poˇcítat’ s jej využitím i v iných projektoch. Pri zaistení tohto princípu treba dbat’ na dobrý archi- tektonický návrh systému. 5. Nezávislost’ (Service Autonomy) – Aby mohla služba zaistit’ správne fungovanie a dodržanie definovaného kontraktu, musí v sebe obsahovat’ vnútornú logiku nezávislú od správy zdrojov, z ktorých ˇcerpá. 6. Bezstavovost’ (Service Statelessness) – Takisto podporuje princíp znovupoužitel’nosti, pretože komponenty, ktoré si nepamätajú svoj stav, je možné kedykol’vek a bez akýchkol’vek inicializaˇcnýchpo- žiadavkov použit na inom mieste. 7. Možnosti identifikácie (Service Discoverability) – Tento princíp má aj svoje ekonomické opodstatnenie. Služba, je doplnená o komuni- katívne metadáta, ktorými je možné služby efektívne rozpoznat’. 8. Princíp skladania (Service Composability) – Služby sú efektívne komponenty vel’kého celku, bez ohl’adu na objem a komplexnost’ celku služieb. Týmto princípom je zaistené zloženie jednotlivých služieb a zaistenie ich vzájomnej spolupráce.

2.1.1 Point-to-point model Prvý prístup, ktorým je možné organizovat’ služby je vytvorenie priamych prepojení, tzv. point-to-point prepojení. Výhodou takéhoto prístupu spo- ˇcívav rýchlom prvotnom nasadení a to s vysokým výkonom. Jeho nevý- hoda nastáva, ak do systému pridávame d’alšie uzly. Postupom ˇcasumôže takto vzniknút’ komplikovaná „spaghetti” architektúra, ktorá je nároˇcnána údržbu a na akékol’vek uskutoˇcneniezmeny. Tento prístup sa pripodobˇnuje predošlým usporiadaniam ešte z ˇciasspred SOA[7].

4 2. SLUŽOBNEORIENTOVANÁARCHITEKTÚRA (SOA)

Obr. 2.1: Koncepˇcnézobrazenie point-to-point modelu

2.1.2 Hub-and-spoke model

Dalšímˇ prístupom je Enterprise Application Integration (EAI), ktorý na seba prevzal zbernicovú topológiu. Jedna z jeho usporiadaní je hub-and- spoke (hub – stred kolesa, spoke – prieˇckana kolese), pre ktorý má v knihe Enterprise Integration Patterns[8] oznaˇcenie message broker. Táto topológia prináša množstvo výhod. K tomu, aby sme mohli do systému integrovat’ novú aplikáciu staˇcízaistit’ len jedno spojenie s hubom. Samotná centra- lizácia nám umožˇnujejednoduchú realizáciu bezpeˇcnostnej politiky, audit alebo monitorovanie. Prispieva k sprehl’adneniu celej architektúry a tým k zníženiu ﬁnanˇcnýchnákladov. Nevýhodou však ostáva závislost’ celého integraˇcnéhoriešenia na jednom bode (single point of failure)[9].

Obr. 2.2: Vl’avo koncepˇcnézobrazenie hub-and-spoke modelu, vpravo kon- cepˇcnézobrazenie ESB;

5 2. SLUŽOBNEORIENTOVANÁARCHITEKTÚRA (SOA)

2.1.3 Bus model (ESB) Posledným modelom je podniková zbernica služieb (d’alej len ESB). Nie je možné popriet’, že viacero dnešných proprietárnych ESB implementácií obsahovali pôvodne EAI architektúru (WebSphere Message Broker 6, TIBCO BusinessWorks 5, SONIC ESB)[9]. V období tejto transformácie bolo ob- tiažne presne stanovit’ rozdiely medzi týmito architektúrami. V podstate sa jedná o podobné architektúry, avšak s rozdielom, že všetky služby sú v ESB navzájom prepojené zbernicou (bus). Táto zbernica sa stará o doru- ˇcovaniespráv medzi službami a d’alšiu funkcionalitu. Viac a do h´lbky si o ESB povieme v d’alšej kapitole.

2.1.4 SCA OASIS architektúra Za posledný model spomenieme SCA architektúru, ktorá je podporovaná a vytvorená vd’aka spolupráci spoloˇcností IBM a Oracle. V roku 2007 bola oficiálne poskytnutá štandardizaˇcnej autorite OASIS na posúdenie a štandardizovanie[10]. V máji 2011 vyšla na stránkach OASIS najnovšia verzia špecifikácie pod verziou 1.1. Na rozdiel od všetkých doterajších mo- delov riešenia integrácie, ktoré boli zamerané na rozloženie komponent do štruktúry schopnej rýchlu výmenu dát, sa SCA prístup zameral na životný cyklus (life cycle). Rozhodnutie putovania správy po komponentách neur- ˇcujeESB zbernica, ale vývojár pri definícii kontraktu so životnými cyklami všetkých možných scenárov. SCA prístup a ESB prístup sú momentálne naj- modernejšie prístupy integraˇcnéhoriešenia. Na obrázku je možné vidiet’ teleso, ktoré graficky znázorˇnujeprístupové služby s definovanou adresou (vl’avo) oˇcakávajúcepríchod správ. Na pravej strane je znázornená referencia, odkial’ je komunikácia presmerovaná von. Implementaˇcnáimple- mentaˇcnálogika sa nachádza vo vnútri telesa. Pre dôkladnejšie pochopenie tohto princípu navštívte kapitolu 5.1, kde si vysvetl’ujeme tieto princípy v architektúre SwitchYard.

Obr. 2.3: Koncepˇcnézobrazenie ciest deﬁnovaných v SCA architektúre

6 3 Podniková zbernica služieb (ESB)

3.1 Charakteristika posielania správ

Doruˇcovaniespráv prebieha odoslaním správy odosielatel’skej služby zo svojej všeobecnej fronty1 zbernici. Zbernica túto správu prijíma a spraco- váva, potom môže posielat’ jej výsledok do fronty adresáta. Každá pri- pojená služba si potom preberá správy zo svojej vlastnej fronty a spraco- váva ich. Takýto koncept umožˇnujedecentralizáciu zbernice, ˇcímsa na- skytá možnost’ rozdelit’ zbernicu na viac ˇcastía tým i na viac strojov a viac lokácií. Správy sa spracovávajú asynchrónne a v prípade, že je zbernica vy- t’ažená, nemusí odosielatel’ ˇcakat’. Zbernica si správu „vyzdvihne” sama až nadobudne vol’né prostriedky. Obvykle ESB môže transformovat’ formát správy, ﬁltrovat’ správy, menit’ obsah správ a vd’aka podporovanému tra- sportu JMS (Java Message Service)2 poskytuje prístup publish-and-subscribe. Tento prístup umožˇnujeodosielanie správ bez udania adresáta. Možné je to vd’aka tomu, že vrámci zbernice prebiehajú mechanizmy, ktoré zaist’ujú, že sa služby môžu prihlásit’ k odberu správ zo zbernice. Tie následne tieto správy odoberú. Jeho výhodou je, že je tým možné, aby jednu správu odo- beralo hned’ viacero služieb, priˇcomodosielatel’ o tom nemusí vediet’. Dal-ˇ ším využitím je možnost’ takto urˇcit’ službám prístupové práva, vyváženie zát’aže (load balancing)3 ˇci failover4[10].

3.2 Prehl’ad základných vlastností

Teraz si predstavíme zoznam základných schopností, ktoré by mal každý produkt architektúry ESB obsahovat’[10]. Zoznam by mohol byt’ samozrejme širší a doplnený o d’alšie technológie, ale nemuselo by sa jednat’ o funkciu, ktorého absencia by odobrala danému produktu oznaˇcenie „ESB”. • Priehl’adnost’ (Location transparency) – ESB robí odosielatel’a a prijímatel’a úplne nezávislými od seba. Pôsobí ako centrálna platforma, cez ktorú komunikujú všetky aplikácie. Odosielatel’ nemusí

1. O tejto fronte hovoríme všeobecne, tu sa nejedná o JMS frontu. 2. JMS je API, ktoré v Jave poskytuje platformu pre manipuláciu so správami v podniko- vom prostredí 3. Optimalizaˇcnátechnika, ktorá zabezpeˇcujerozloženie zát’aže medzi viacero zariadení. 4. Zálohovací operaˇcnýmód, ktorý nahradí pôvodný systém v prípade, že sa stane nedo- stupným skrze pád systému alebo downtime.

7 3. PODNIKOVÁZBERNICASLUŽIEB (ESB)

poznat’ fyzickú adresu adresáta. Prepojenie odosielatel’a s prijíma- telom môže byt’ spomenuté v XML konﬁgurácii, v databázach alebo v Service registry vrámci ESB.

• Konverzia transportných protokolov (Transport protocol conver- sion) – ESB podporuje a integruje širokú škálu aplikácií s rôznymi zaužívanými transportnými protokolmi. Komponenty poskytujúce konverziu transportných protokolov sa nazývajú adaptéry protokolov (protocol adapters).

• Transformácia správ (Message transformation) – Nebýva zvykom, aby formát prijatej správy exaktne vyhovoval formátu správy, ktorú oˇcakávaciel’ova aplikácia. ESB dokáže automaticky správu jedného formátu transformovat’ do správy iného formátu. Bežnou technoló- giou je v tomto prípade XSLT5 a XPath6.

• Smerovanie správ (Message routing) – Obvykle sa správy neposie- l’ajú jednému ciel’u, ale množstvu d’alších a ESB musí rozhodnút’, kam tie správy posielat’. Správy sa napr. môžu posielat’ prijímate- l’om na základe ich obsahu (content based routing), na základe toho, ˇci spadajú alebo nespadajú pod správový ﬁlter (message ﬁlter routing) alebo na základe zoznamu prijímatel’ov (recipient list routing).

• Obohatenie správ (Message enhancement/enrichment) – ESB do- káže správy modiﬁkovat’ a dop´lˇnat’ chýbajúce informácie, ktoré môžu byt’ požadované. Nejedná sa pritom o princíp transformá- cie správy. Doplˇnovanéinformácie ˇcerpádo externého dátového zdroja, napr. databáze pomocou klientského ID.

• Bezpeˇcnost’ (Security) - Prístup do systému zabezpeˇcujeautentizá- cia, autorizácia a kryptograﬁcké protokoly na uspokojenie bezpeˇc- nostných požiadaviek poskytovatel’a služieb.

• Správa a management (Monitoring and management) – Pretože ESB je najkritickejšie miesto v celom systéme, je nutné aby bolo možné toto miesto monitorovat’ a udržiavat’. Obvyklou otázkou u monitorovania webových služieb býva, ˇciwebová služba beží a kol’ko volaní obsluhuje za jednotku ˇcasu.

5. XSLT (Extensible Stylesheet Language Transformation) je XML technológia urˇcenána automatizovanú transformáciu XML dokumentu 6. XPath je XML technológia urˇcenána prístup k požadovanej hodnote vrámci XML dokumentu

8 3. PODNIKOVÁZBERNICASLUŽIEB (ESB)

3.3 Hl’adanie deﬁnície ESB

Pri používaní výrazu ESB je možné sa stretnút’ s celou sériou protichod- ných tvrdení. V tomto pojme sa rozchádzajú aj vyjadrenia odborníkov[12]. Prvotným nedorozumeniam a konfliktným definíciam predchádzalo, ked’ stále viac odborníkov zaˇcaliESB považovat’ za produkt. K tomuto javu mohlo viest’ aj to, že sa produktom ˇcastopridávalo toto oznaˇcenie.Správne by sme za ESB mali považovat’ nie tak produkt, ako skôr integraˇcnúarchi- tektúru a koncept riešenia. Produkt je už len samotná implementácia tohto návrhového vzoru. S jednou z najvýstižnejších definícií prichádza IT pora- denská spoloˇcnost’ Gartner, Inc. V ich kontexte je ESB nová architektúra, ktorá využíva webové služby, správový middleware, inteligentné presmerovanie a tran- formáciu. ESB sa správa ako odl’ahˇcenáa všadeprítomná integraˇcnáspojnica, cez ktorú teˇcúsoftvérové služby a komponentové toky[13].

9 4 Metodika testovania

V tejto kapitole si predstavíme jednotlivé scenáre prípadov použitia, ktoré uplatníme na každom testovanom ESB. Jedná sa o najbežnejšie prípady komunikácie webových aplikácií pomocou metódy webových služieb[15]. Takisto si predstavíme testovací framework, ktorý testovanie daných scená- rov podporuje a nakoniec si predstavíme špeciﬁká Amazon EC2, na ktorom budú testy bežat’.

4.1 Scenáre testovania a prostredie testovania

Väˇcšinadnešných správ putujúcich cez ESB do vel’kej miery využívajú in- ternetový protokol HTTP/S pre SOAP/XML správy1. Práve na tieto tech- nológie boli zamerané naše scenáre testovania, priˇcomsme sa zamerali na 3 aspekty testovania. Testy boli spúšt’ané na získanie hodnôt jednak rých- losti prenosu akotakého (scenár DirectProxy), rýchlosti prenosu pri presme- rovávaní na základe obsahu správy (scenáre z rodiny CBRProxy) a nakoniec rýchlosti prenosu správy vrátane transformácie obsahu správy (scenár XSLTProxy). V d’alších kapitolách si ich predstavíme viac do h´lbky[15]. Pre úˇcelytestovania sme použili testovací framework s názvom ESB Performance od spoloˇcnostiAdroitLogic. Rozhodli sme sa zvolit’ si ho na základe faktu, že sa najlepšie hodí na testovanie scenárov, ktoré sme si sta- novili. ESB Performance však okrem našich požadovaných scenárov poskytuje aj testovanie WS-Security[15]. Vzhl’adom k faktu, že SwitchYard v0.7. túto funkcionalitu nepodporuje, sme tento scenár vynechali a venovali sa len prvým 5-tim scenárom. Funkcionalita WS-Security je podporovaná až vo verzii 0.8[14]. Scenáre budú implementované vo forme proxy služby, ktorá prijíma správu od klienta, na základe jeho špeciﬁka so správou nieˇcourobí a pre- pošle službe na pozadí, ktorá správu prijme a vráti spät’ cez proxy službu k prvotnému klientovi. Po prebehnutí celej cesty testovací framework za- znamená výsledný ˇcas[15].Najprv si však vysvetlime scenáre a následne si povieme viac o testovacom frameworku a o spôsoboch jeho nasadenia. V poslednej ˇcastikapitoly si ukážeme rozsahy správ a poˇctysúbežných po- užívatel’ov, ktorí sa budú na náš ESB dotazovat’.

1. Simple Object Access Protocol je protokol na výmenu správ po sieti pomocou protokolu HTTP a tvorí základný spôsob komunikácie medzi webovými službami.

10 4. METODIKA TESTOVANIA

4.1.1 DirectProxy Tento scenár demonštruje funkciu ESB vystupovat’ ako virtuálna vrstva pre webové služby na pozadí. Mohli by sme to pripodobnit’ Apache Tomcat server2 alebo hardware zariadenie pre vyváženie zát’aže3, ktoré boli v pop- redí od webových služieb na pozadí na zobrazenie rovnováhy výkonu a poskytovat’ failover mód. Hoci tento scenár neobsahuje vyvažovanie zát’aže ani failover, bezpeˇcnostnúverifikáciu ani XSD validovanie4, väˇcšinaESB podporuje tieto funkcie[15]. V tomto scenári budeme používat’ definíciu WSDL. WSDL (Web Service Definition Language) je všeobecne XML súbor, ktorý vo svete webových služieb slúži na definovanie spôsobu komunikácie s we- bovou službou ˇciže SOAP komunikácie. Táto služba bola klientovi do- stupná na adresovej URL v tvare http://localhost/://DirectProxy.

Obr. 4.1: Koncepˇcnézobrazenie DirectProxy[15].

4.1.2 CBRProxy Tento prípad užitia demonštruje skutoˇcnost’, že správa môže byt’ presmero- vaná k rôznym koncovým bodom vzhl’adom na jej obsah. Preto vzhl’adom k rôznemu obsahu je možné správu podl’a toho rôzne spracovávat’. Tento scenár bude prezentovaný pod tromi variantami: 1. Presmerovanie vzhl’adom na obsah hlaviˇckyHTTP[15] – Tento prvý scenár porovnáva najoptimálnejšiu cestu na smerovanie správ, ktorá je založená na HTTP hlaviˇckáchtransportnej vrsty. Táto technika je široko využívaná pri smerovaní protolom Hessian5 alebo iných dávok (payload), ktoré nie sú na základe SOAP protokolu, ˇcoju robí extrémne efektívnu.

2. open source webový server vyvíjaný organizáciou Apache 3. HLD je fyzická jednotka, ktorá presmeruváva poˇcítaˇcejednotlivému serveru. Toto presmerovanie sa volá load balancing. 4. XML validovanie XML dokumentu, ˇcije požadovaného tvaru alebo obsahu 5. Binárny protokol pre webové služby, ktorý sa vd’aka svojej jednoduchosti používa v mobilných zariadeniach.

11 4. METODIKA TESTOVANIA

Táto služba bude pre klienta prístupná pod adresou: http://localhost/://CBRTransportHeaderProxy.

2. Presmerovanie vzhl’adom na obsah hlaviˇckySOAP[15] – Tento scenár rozhoduje o presmerovaní správy na základe SOAP hlaviˇcky. Prístup do SOAP hlaviˇckymôže byt’ lepšie optimalizovaný než do vel’kého SOAP tela. SOAP hlaviˇckamôže poskytovat’ špecifické in- formácie o SOAP správe ako napr. smerovacie dáta, autentifikaˇcné dáta atd’. Podmienky vyhodnocuje XPath filter na SOAP hlaviˇcke. Tento test berie SOAP hlaviˇckuako jednoduchý text typu String a potom vykonáva porovnanie k danému konštantnému Stringu. Táto služba bude pre klienta prístupná pod adresou http://localhost/://CBRSOAPHeaderProxy

3. Presmerovanie vzhl’adom na telo (body) SOAP správy[15] – Tento scenár bude demonštrovat’ schopnost’ presmerovávat’ XML správu na základe stanoveného porovnania XPath výrazu na SOAP tele. Tento testovací scenár oˇcakávaXML element s hodnotou „IBM” na presmerovanie požiadavku do služby na pozadí. Táto služba bude pre klienta prístupná pod adresou http://localhost/://CBRProxy

Obr. 4.2: Príklad SOAP správy s ukážkou ˇcastíobsahu, na základe ktorých sa správa presmeruje.

12 4. METODIKA TESTOVANIA

Obr. 4.3: Koncepˇcnézobrazenie CBR scenárov [15]

4.1.3 XSLTProxy Tento scenár demonštruje schopnost’ menit’ samotný obsah správ a transformovat’ ho na iné typy. V praxi sa správy konvertujú z XML do CSV6, Text a pod. alebo dop´lˇnajúo d’alšie atributy. Obvykle ESB ponúkajú viacero možností na transformáciu ako XSLT, XQuery7 a pod. Tento scenár bude oˇcakávat’ SOAP správu daného formátu a pomocou použitia vopred pripraveného XSLT súboru budú názvy jej tagov preme- nované na jej reverzný tvar. V tejto reverznej podobe sa odošle službe na pozadí, ktorá správu vráti a skôr než sa správa dostaví k pôvodnému klientovi sa pomocou iného XSLT súboru premení zas do pôvodnej podoby[15]. Táto služba bude pre klienta prístupná pod adresou http://localhost://XSLTProxy

Obr. 4.4: Koncepˇcnézobrazenie XSLTProxy[15]

4.2 ESB Performance framework

Náš testovací framework je jednoduchý na použitie a má vopred prichys- tané scenáre použitia ôsmich rôznych open source ESB implementácií. Zá- roveˇnobsahuje všetky potrebné nástroje a skripty, takže nie je potrebné niˇc doinštalovávat’.

4.2.1 Výkonnostné testovanie v ESB Performance Výkonnostné testovanie je testovanie za úˇcelomzistenia správania istého softvéru za istých extrémnych okolností. V našom prípade použijeme testo-

6. Comma-Separated Value súbor ukladá hodnoty v riadku oddelené ˇciarkou. 7. XQuery je podobne ako XPath dopytovací jazyk pre XML dokumenty.

13 4. METODIKA TESTOVANIA vanie na základe vel’kosti správ posielaných cez ESB a na základe množstva súˇcasnýchprístupov na systém. V každom scenári bude každý používatel’ posielat’ správu hned’ viackrát za sebou, aby sme tým získali viac výsled- kov pre lepšie spriemerovanie. Nižšie uvádzame zoznamy vel’kostí správ a poˇctysúˇcasnýchprístupov, ktoré ESB Performance podporuje. Výkonnostný test bude obsahovat’ správy vel’kostí: 512 bytov, 1 KB, 5 KB, 10 KB, 100 KB[15]; Teraz nasledujú poˇctysúbežných prístupov (používatel’ov)[15], v zát- vorke je ˇcíslo,kol’kokrát za sebou bola správa poslaná jedným používate- lom:

• 20 súbežných používatel’ov (1000)

• 40 súbežných používatel’ov (1000)

• 80 súbežných používatel’ov (100)

• 160 súbežných používatel’ov (100)

• 320 súbežných používatel’ov(100)

• 640 súbežných používatel’ov (10)

• 1280 súbežných používatel’ov (10)

• 2560 súbežných používatel’ov (10)

4.2.2 ESB Performance framework

Tento testovací framework bol prvýkrát koncipovaný v roku 2005 in- žiniermi spoloˇcnosti Virtusa Corporation pod vedením Asankha Perera a v jeho tíme pôsobili ešte Jacqueline Thangarajah a Sandeep Vallabhaneni. V roku 2007 bol testovací framework prvýkrát vydaný WSO2 ESB tímo- vími ˇclenmiAsankha Perera, Ruwan Linton, Indika Kumara a Chathura Ekanayake vrátane s WSO2 technickým vedením Paul Fremantle a Sanjiva Weerawarana[16]. ESB Performance Test Suite je dodávaná ako súˇcast’ balíˇckovéhovyda- nia samostatného ESB vyvíjaného spoloˇcnost’ou AdroitLogic s názvom Ul- traESB (cca 40 MB)[16]. Ako poznámku udávam, že spoloˇcnostAdroitLogic vznikla v roku 2010 práve horespomínaným Asankha Perera. Framework obsahuje v stiahnutel’nom balíˇcku[16]:

• vysoko výkonnostnú mock službu na simulovanie služby na pozadí

14 4. METODIKA TESTOVANIA

• vysoko výkonnostný a multivláknový HTTP/S klient a generátor testov

• príklady správ v škále od 512 bytov až po 100K bytov

• loadtest.sh a smoketest skripty na spúštanie testov

• graﬁcký nástroj SOA ToolBox na pomoc s nastavením scenárov s ho- ciktorým ESB

• nástroj na konverziu výsledkov do CVS formátu pre d’alšiu analýzu tabul’kových procesorov (spreadsheet) ako je napríklad MS Excel alebo OpenOfﬁce.

Vzhl’adom k tomu, že ESB Performance je open source projekt, tak sa postupom ˇcasuk výpomoci implementovania testových scenárov pridávali aj ostatné vývojárske spoloˇcnostipôsobiace na poli ESB. V šiestom kole ESB Performance máme k dispozícii testové scenáre od 8-mich rôznych ESB[17]. Sú to:

• UltraESB v1.7.1 - Vanilla/Enhanced

• WSO2 v4.0.3

• Mule ESB CE v3.3.0

• Talend ESB SE v5.1.1

• JBoss ESB v4.11

• Apache ServiceMix ESB v4.3.0

• Fuse ESB v4.4.0

• Petals ESB v4.1.0

Nie všetky implementácie sú zaruˇcenesprávne implementované, pretože niektoré poˇcastestovaní vykazovali rôzne nedostatky, ktoré sú popísané na webe ESB Performance. Autori frameworku to vysvetl’ujú i sˇcastisvojím nedostatkom ˇcasua nedostatkom poznania[17]. Našim úmyslom však nebude rozoberat’ jednotlivé chyby a pády v tes- toch, ale predovšetkým ich výkon. Naše testovanie sa teda bude orientovat’ predovšetkým na výsledky, ktoré sú validné a vhodné na porovnávanie na- prieˇcškálou vybraných ESB.

15 4. METODIKA TESTOVANIA

Spôsobom stiahnutia UltraESB balíˇcka sa môžu testy sputit’ na lo- kálnom poˇcítaˇci[18].Avšak pre úˇcelytestovania je možné testy spúšt’at’ i v cloud systéme8 Amazon EC2[19], ktorý si popíšeme a taktiež použijeme v nasledujúcich podkapitolách.

4.3 Amazon AWS EC2

V návode sa odporúˇca,aby sa pre úˇcelytestovania používala cloud com- putingová platforma od spoloˇcnostiAmazon.com, Inc. s názvom Amazon Web Services. V našom prípade využijeme jednu zo sady služieb Ama- zonu, ktorá sa sa volá Amazon Elastic Compute Cloud (d’alej len Amazon EC2). Táto služba poskytuje cenovo prístupný nájom virtuálnych poˇcíta- ˇcovvhodných i pre testovanie výkonu softvéru. Pomocou tejto služby sme schopní nakonﬁgurovat’ parametre našich virtuálnych poˇcítaˇcov, ktoré sa volajú Amazon Machine Images (AMI). My si však nepotrebujeme vytvá- rat’ vlastné AMI, ale použijeme verejne prístupné AMI od tvorcov ESB Per- formance pod ID „ami-09ef4560”. Tvorcovia frameworku dávajú podrobný návod[19].

4.3.1 Parametre AMI Dané AMI bolo spustené na Amazon EC2 High CPU Extra Large (c1.xlarge) inštancii s unixovým systémom Ubuntu 10.10. Táto inštancia beží na 64 bit architektúre s RAM pamät’ou 7GB s 8 GB Elastic Block Store (EBS) diskom. EBS je úložný systém pracujúci na základe obsadzovania blokov pamäte. EBS pamät’ je funkˇcnánezávisle od AMI inštancie[20]. Dalejˇ naša AMI inštancia bude využívat’ výkon s hodnotou 20 ECU jed- notiek, ˇcoje 8 virtuálnych jadier, priˇcomjedno jadro obsahuje 2,5 ECU. ECU je skratka pre EC2 Compute Unit, ˇcoje veliˇcinavýpoˇctovéhovýkonu zave- dená spoloˇcnost’ou Amazon. Amazon túto jednotku zaviedlo pre prehl’ad- nejšie porovnávanie AMI inštancií. Podl’a Amazonu je ECU pripodobni- tel’ná procesoru s výkonom 1.0 - 1.2 GHz 2007 Opteron alebo 2007 Xeon procesora[21][22]. Systém obsahoval Apache Tomcat server, Maven 3.09, Java Develop- ment Kit (JDK)10 a UltraESB balíˇcek,v ktorom bol obsiahnutý náš ESB Per- formance framework so všetkými ESB s nasadenými (deployed) scenármi.

8. Systém, ktorý umožˇnujevyužívanie výpoˇctovýchzdrojov vzdialeného poˇcítaˇca,ku ktorému obvykle pristupujeme cez internet. 9. http://maven.apache.org/docs/3.0/release-notes.html 10. http://www.oracle.com/technetwork/java/javase/downloads/index.html

16 4. METODIKA TESTOVANIA

4.3.2 Spúšt’anie testov - všeobecne Všetky testy prebiehali iba vrámci tejto AMI inštancie, preto nebolo po- trebné zaist’ovat’ izolovanost’, pretože všetka komunikácia prebiehala iba medzi lokálne hostovaným generátorom testov (load generator), ESB a služ- bou bežiacou na pozadí (backend service), v našom prípade Apache Tom- cat server. Každému ESB bolo v nastavení alokovaných 2 GB Java Heap pamäte. Všetky potrebné spúšt’ania sme iniciovali cez Secure Shell (SSH) pomocou PUTTY. Celkovo sme tak zakaždým vytvorili 5 SSH sedení (session)[19].

• 1. sedenie: Bolo urˇcenéna spustenie Apache Tomcatu, ktorý bežal ako služba na pozadí.

• 2. sedenie: Bolo urˇcenéna spustenie daného ESB, ktoré sme chceli podrobit’ testovaníu.

• 3. sedenie: Bolo urˇcenéna spustenie generátora testov. Pri urˇcitých ESB bolo zapotreba ešte predtým spustit’ skript recreate-secure- requests.sh zabezpeˇcujúci to, aby ESB dostali nanovo vytvorené WS-Security požiadavky (requests). Tomu ale bolo možné sa vyhnút’ jednoduchým zakomentovaním WS-Security príkazov v generátore testov, pretože WS-Security scenárom sa v našej práci nezaoberáme.

• 4. a 5. sedenie: Bolo urˇcenéna zobrazovanie výsledkov testu. Na jednom bol podrobný výpis hodnôt, ktoré test zaznamenal a na druhom iba prípady pochybenia ESB. 5. sedenie pre beh testov nebolo povinné.

• 6. sedenie: Toto sedenie taktiež nebolo povinné, ale bolo užitoˇcné ako nástroj na transformovanie výsledkov z .txt na .cvs formát. Spúšt’aˇce a logové súbory zaznamenávajúce výsledky z bežania každého ESB sú dostupné v prieˇcinku ~/client-scripts.

17 5 SwitchYard - implementácia

SwitchYard je nový framework pre doruˇcovanieslužieb vyvíjaný spoloˇc- nost’ou Red Hat a je sˇcastipostavený na OASIS špeciﬁkácii SCA štandardu1 a sˇcastina ESB. Jedná sa o celkom iný princíp prístupu ako tomu bolo u jeho predchodcu JBoss ESB[3]. Podl’a stránok JBoss Community sa jedná o zjednodušený service delivery framework poskytujúci kompletnú podporu pre vývoj, rozširovanie a riadenie servisne orientovaných aplikácií[24]. Hlavný rozdiel medzi SwitchYard a tradiˇc- ným ESB spoˇcívav kladení dôrazu na sprehl’adnenie životného cyklu (run- time) služby, priˇcomu „klasického” ESB toto bolo ponechané len na zbernicu. Do jadra SwitchYard-u je možné pridávat’ moduly, ktoré okrem iného môžu zabezpeˇcovat’ prepojenie, transformáciu, routing a mnoho d’alších funkcií, ktoré sú typicky asociované s „klasickými” ESB[24].

5.1 Základné vlastnosti frameworku

Každý projekt vo SwitchYard je zložený z jednej alebo viac komponent, ktoré každá osahuje vlastnú implementaˇcnúlogiku. Komponentu je možné implementovat’ rôzne: vrátane Javy, Camel smerovacích definícii2, BPMN2 procesov3alebo Drools pravidiel4. Každá komponenta obsahuje vlastné prístupové body a výstupové body. Podl’a toho ich voláme služby komponent a referencie komponent (component services a component references). Tieto sú vzájomne namapované medzi sebou a tak vytvárajú cestu skladajúcu sa z rôznych komponent. Všetky toky sú definované v tzv. composite5 (na obrázku hlavná fialová plocha). Zvonka prístupné cez jej composite službu (composite service). Na pravej strane composite máme definovaný výstupný bod, ktorému sa ho- vorí composite referencia (composite reference) a slúži na definovanie adresy externej služby mimo SwitchYard kam komunikácia smeruje[23]. Nasledovný obrázok je diagram znázorˇnujúcipríklad SwitchYard projektu a je vytvorený pomocou SwitchYard editoru GEF (Graphical Editor Framework). Koncepˇcnesa diagram prezentuje ako tok správ zl’ava – do- prava: Správy pristupujú do systému cez composite služby vl’avo. Spra-

1. Service Component Architecture http://oasis-opencsa.org/sca 2. http://camel.apache.org/ 3. http://www.omg.org/spec/BPMN/2.0/ 4. http://www.jboss.org/drools/ 5. Composite je špeciﬁcký termín pochádzajúci zo špeciﬁkácii OASIS jeho slovenský ek- vivalent nieje známy, preto v tejto práci budeme uvádzat’ jeho anglickú podobu.

18 5. SWITCHYARD - IMPLEMENTÁCIA

Obr. 5.1: Príklad SwitchYard composite s popiskami jej obsahu[23].

cované sú komponentami v strede a opúšt’ajú systém cez composite refe- renciu vpravo. Rozhranie sa používa na definovanie prístupných operácií vrátane vstupu, výstupu alebo typu poruchy pre jednotlivé operácie. Swit- chYard podporuje 3 možnosti definovania rozhrania (interface): Java rozhranie, WSDL portové typy a generické ESB. Java rozhrania a WSDL port typy dovol’ujú definovat’ jeden alebo viac operácii, priˇcomgenerické ESB rozhranie deklaruje vstup, výstup a prípadne chybový typ len pre jednu operáciu[23]. Pomocou GEF nám je umožnené jednoduchú tvorbu composite na plátne (canvas) jednoduchým pridávaním obrazcov z palety vpravo (pa- lette). Výsledné grafické zobrazenie však nie je niˇciné ako XML konfigurá- cia, ktorá medzi tagmi generuje informácie všetkých komponent, služieb a referencii, vrátane ro- zhraní, na ktoré sa odkazujú. Tento Eclipse plugin umožˇnujejednoduché prepínanie medzi grafickým a zdrojovým XML režimom. Tento XML súbor je jedineˇcnýv celom SwitchYard projekte s názvom switchyard.xml[23].

19 5. SWITCHYARD - IMPLEMENTÁCIA

5.2 Postup pri implementácii

V tejto kapitole sa budeme venovat’ implementácii, ktoré sme už popí- sali vyššie, avšak teraz pôjdeme viac do detailov. V prvom rade kvôli lep- šiemu ovládaniu sme sa rozhodli vývoj testovacích scenárov programovat’ lokálne na poˇcítaˇci.Týmto rozhodnutím sme si museli pripravit’ prostredie so sériou nástrojov pre vývoj. Popíšeme ho a následne prejdeme k jednotli- vým scenárom. V poslednej ˇcastisi popíšeme nasadenie nášho projektu do virtuálneho poˇcítaˇcaAMI na serveroch Amazon EC2.

5.2.1 Príprava nástrojov na implementáciu

Rol’u virtuálneho klienta zohrávala testovacia aplikácia pre posielanie SOAP správ SoapUI. SoapUI je populárny open source framework, ktorý poskytuje rozhranie, v ktorom sa dá jednoducho napísat’ text správy a po- slat’ na URL, ktoré potrebujem. Odpoved’ sa zobrazí po prebehnutí komu- nikácie klienta so serverom. V našom prípade server vracal správu v ne- zmenenej podobe. Zo súborov ESB Performance boli prístupné všetky testovacie správy všetkých vel’kostí, ale lokálne sme pri implementácii a ove- rovaní výsledkov používali zakaždým len jednu a to 1K_buyStocks.xml, pre- tože správy boli svojou štruktúrou rovnaké a líšili sa iba množstvom dup- licitného obsahu pre dosiahnutie požadovanej vel’kosti. Rolu servera nám zabezpeˇcovalJBoss Application Server verzie 7.1. a spúšt’ali sme ho cez Eclipse plugin v standalone podobe s názvom JBDS (JBoss Developer Studio). Inou možnost’ou by bolo spúšt’anie cez príka- zový riadok spustením ./standalone.sh alebo standalone.bat, ale pre pohod- lie sme na našom lokálnom poˇcítaˇcipoužívali funkciu spúšt’ania servera na JBDS IDE. Na serveri sme mali rozmiestnené dva súbory switchyard- esbperformance.jar a service.war. Prvý zo spomínaných súborov je náš projekt urˇcený na testovanie, ktorý sme vyvíjali vo našom IDE. Dal sa s jednoduchost’ou nasadit’ (deploy) pomocou funkcií v Eclipse. Druhou možnost’ou by bolo skopírovat’ .jar súbor manuálne do zložky /standalone- /deployments servera. Druhý zo spomínaných súborov je samotná služba na pozadí. SwitchYard projekt slúži ako frontendová služba v popredí (proxy), ktorá preberala požiadavky od klienta (SoapUI). V rámci composite sa mala odohrat’ funkcionalita ESB a predala sa službe na pozadí. Táto služba nebola niˇcíminým ako jednoduchým servletom, ktorý z proxy preberal správy a hned’ ich aj poslal spät’ ku proxy naspät’ a odtial d’alej klientovi.

20 5. SWITCHYARD - IMPLEMENTÁCIA

Na tomto mieste by sme radi spomenuli vel’mi užitoˇcnúhandler triedu MessageTrace. Za jej použitia sa kód triedy Message Trace aplikoval na vstupy a výstupy jednotlivých služieb v composite, aby v log správach za- bezpeˇcovalvýpis stavu komunikácie z tých bodov. Použitie nástroja Mes- sageTrace sa dodatoˇcnedeﬁnuje do zdrojového kódu switchyard.xml ako diet’a tagu v tomto tvare:

5.3 Implementácia scenárov

5.3.1 DirectProxy

Definovanie služby DirectProxy je podmienené definovaním rozhrania. Pre tento úˇcelsme sa inšpirovali zdrojovými kódmi iných ESB, ktoré boli v testovacom frameworku už pripravené a použili WSDL súbor ProxyWSDL- embedded.wsdl. WSDL súbor bol identický v každom ESB, preto sme sa ho snažil použit’ v ˇconajmenej zmenenej podobe. Nevyhnutnou zmenou však bolo definovanie názvu služby. Predvolene bola uvedená hodnota EchoSer- vice, ktorú sme zmenili na DirectProxy. Toto bolo miesto, kde sa urˇcovalo, ako bude vyzerat’ vygenerovaná cesta, na ktorú neskôr sa bude odkazovat’ klient. Výsledná cesta sa teda generovala v tomto tvare: http://localhost:// Pretože sa však do jednej WSDL dá nadefinovat’ jedine jedna služba, pre každý d’alší scenár musel byt’ samostatný WSDL. Tvorba komponent, služieb a referencii prebiehala za použitia grafic- kej palety. Názvy týchto obrazcov sme volili podl’a vlastného uváženia, ale s tým, že názvy vzájomne prepojených služieb s referenciami vyžadovali rovnaký názov. Vlastnosti (Properties/Bindings) composite služby DirectP- roxy obsahovali:

• WSDL URI - odkaz na vlastný WSDL súbor

• Context Path originálnu cestu, ktorá sa bola odlišná od ciest ostat- ných služieb

21 5. SWITCHYARD - IMPLEMENTÁCIA

• k službe bola zadeﬁnovaná jedna z Bindings možností a tu kon- krétne SOAP

Vlastnosti composite referencie DirectProxyRef obsahovali:

• WSDL URI odkaz na originálny WSDL súbor

• Endpoint Address cestu na službu na pozadí (v našom prípade to bolo zakaždým http://locahost:9000/service)

Komponenta bola deﬁnovaná ako samostatný XML súbor DirectRoute.xml s Apache Camel smerovacími pravidlami.

5.3.1.1 DirectProxy bug a workaround

Ak je vo WSDL-ku definovaná viac ako jedna operácia, tak je potrebné definovat’ operationSelector (vypíše sa táto hláška: „No operationSelector was configured for the Camel Component and the Service Interface contains more than one operation”), ale pre SOAP spojenie (binding) neexistoval podporovaný operationSelector. Riešenie spoˇcívav pridaní tohto XML kódu do switchyard.xml[25]: ${header . org . SwitchYard .operationName} Táto zmena musela byt’ zahrnutá vo všetkých zvyšných scenároch.

5.3.2 CBRProxy

Tento scenár je implementaˇcnena 90 percent rovnaký ako DirectProxy. Táto služba presmeruje správu k ciel’ovému odkazu na základe obsahu. K tomu sme využili ﬁlter, ktorý prepúšt’al správu na základe XPath podl’a vzoru ostatných ESB.

5.3.2.1 CBRProxy bug a workaround

V tomto prípade sme znova narazili na chybu. Riešením malo byt’ pridanie tohto kusa kódu do Camel komponenty[26]:

22 5. SWITCHYARD - IMPLEMENTÁCIA

Táto chyba nastala tým, že obsah správy sa konvertoval do InputStream, ktorý neumožˇnovalopakovaný prístup k obsahu správy. Vyriešenie spoˇcí- valo v explicitnej konverzii na typ String, ktorý umožˇnujeopakovaný prí- stup. Táto zmena musela byt’ zahrnutá vo všetkých zvyšných scenároch.

5.3.3 CBRSOAPHeaderProxy

Tento scenár je obdobný ako CBRProxy, ibaže ﬁlter v komponente sme de- ﬁnovali na základe properties hlaviˇcky, ktorá sa posielala v SOAP správe. Scenáre DirectProxy, CBRProxy a CBRSOAPHeaderProxy boli namapo- vané do spoloˇcnejcomposite referencie z dôvodu minimalizovania dup- licitného kódu (pozri Obr. 5.2).

5.3.4 CBRTransportHeaderProxy

Tento scenár neobsahoval WSDL rozhranie, ale bol vytvorený podl’a rozhrania generického ESB. K jeho definovaniu staˇcíuviest’ vstupný a vý- stupný typ správy, ˇcobolo v našom prípade String. Tento scenár je obdobný ako CBRProxy, ibaže filter v komponente sme definovali na základe properties hlaviˇcky, ktorá sa posielala v SOAP správe. V SoapUI ale bolo nutné túto hlaviˇckumanuálne doplnit’ do zoznamu properties hlaviˇciek(Headers) danej správy. Pri testovaní na Amazon EC2 toto nastavenie nebude po- trebné.

5.3.5 XSLTProxy

Tento scenár sa nevyhol d’alším zásahom do WSDL súboru a to z dôvodu charakteru tohto scenára. Pretože tento scenár pracuje s dvomi formátmi správ (normálny a reverzný formát). Z toho dôvodu sa následne definovalo aj reverzné XSD Schema. Tento zásah zároveˇnpodmieˇnujeaj celú radu d’al- ších zásahov do konfigurácie WSDL, ktoré nebudem rozoberat’. Do switchyard.xml dodefinujeme deklaratívne mimo tagov composite transformátory, ktoré obsahujú atribúty from a to pre hodnoty formátu QNames6 a atribu- tom xsltFile s cestou k XSLT súboru. Jeden transformátor definuje cestu od normálneho formátu k zmenenému a druhý transformátor cestu zo zmene- ného stavu do pôvodného. Tento scenár sa mohol implementovat’ aj pomocou Apache Camel.

6. Qualified Names je validný identifikátor pre XML elementy a ich atributy. Pri svojom definovaní používa aj XML menné priestory.

23 5. SWITCHYARD - IMPLEMENTÁCIA

Obr. 5.2: Graﬁcké zobrauzenie switchyard.xml

5.4 Nasadenie do Amazon EC2

Importovanie nášho projektu na cloud je pomerne jednoduché. Aplikaˇcný server podl’a konvencie sa importoval do zložky ~/esbs. Sám však obsahoval nasadený projekt s našimi scenármi. Službu na pozadí samozrejme nesmie obsahovat’, lebo táto sa spúšt’a cez Apache Tomcat server. Pri im- plementácii sme pracovali aj so spúšt’aˇcom smoketest.sh, ktorý slúžil na jed- noduché overenie, ˇcináš projekt je spustitel’ný pre všetky scenáre i v loadtest.sh. Samotný spúšt’aˇc loadtest.sh však nieje vhodný na spúšt’anie Swit- chYardu. Dôvodom bolo deﬁnovanie unikátnej cesty (path) pre každý sce- nár, ktorý nieje v loadtest.sh v požadovanom tvare. Preto sme ho upravili tak, aby oˇcakávalov URL cestu presne ako sme si ich nakonﬁgurovali v projekte. Okrem iného sme v ˇnomvynechali všetky SecureProxy scenáre, ktoré sa v loadteste.sh vyskytovali. Tento nový shell skript sme si nazvali loadtest-switchyard.sh. Výsledky testovania SwitchYardu je možné nájst’ v kapitole 6.2. SwitchYard.

24 6 Testovanie

V tejto kapitole si ukážeme prvé grafy, ktoré budú zobrazovat’ výkony všet- kých ESB po jednom. Všetky hodnoty v grafoch sú spriemerované z troch nezávisle od seba spustených testov. Vo všetkých grafoch je na ose Y hodnota v jednotkách transakcií za sekundu (transactions per second – TPS).

6.1 Mule ESB

Jeden z dnes najpopulárnejších open source ESB integraˇcnýchplatforiem je Mule ESB s viac ako 1.5 milióna stiahnutiami[27]. Za jeho pôvodcu sa považuje Ross Mason, ktorý založil Mule projekt v roku 2003 a odvtedy pracoval na tom, aby sa Mule stal najvýznamnejšou integraˇcnouplatfor- mou. Mason založil svoju prácu na základe práce Georga Hohpe a Bobby Woolfovej knihy Enterprise Integration Patterns1. Výhodou Mule ESB je, že väˇcšinaimplementácie môže byt’ prevedená pomocou Java tried. Mule tak- tiež podporuje viac ako 20 transportných protokolov a integruje množstvo integraˇcnýchprojektov ako sú Spring2, ActiveMQ3, Joram4, CXF5, Axis6 a Drools[11]. Po tom, ˇcov roku vyšla Mule verzia 1.0 sa celému projektu na trhu naskytla väˇcšiapozornost’ ˇcoviedlo k založení spoloˇcnostiMuleSource. V roku 2009 sa spoloˇcnost’ premenovala na MuleSoft[28]. Od verzie 3 Mule prechádza postupne ku konceptu “flows”, ktorý dáva dôraz na životný cyklus a prepojenie jednotlivých komponent. Nie je tomu až tak dlho, ked’ Mule 2.0 používal prístup služieb s jednou komponentou. Verzia 3 však nad’alej plne podporuje koncept služby, ale blízkej budúcnosti je možné sa doˇckat’ migraˇcnéhoprogramu na transformáciu starých konfigurácií do konfigurácií tretej verzie[29]. Mule ESB sme si pre úˇcelytestovania vy- brali pre jej populárnost’. Pri spustení sme sa držali návodu na webe ESB Performance[19].

1. Addison-Wesley Professional, 2003 2. http://www.springsource.org/ 3. http://activemq.apache.org/ 4. http://joram.ow2.org/ 5. http://cxf.apache.org/ 6. http://axis.apache.org/axis/

25 6. TESTOVANIE

6.1.1 Výsledky a chybové situácie Beh testov sa zaobišiel bez vážnejších errorov a pádov, ktoré by spôsobili prerušenie testovacieho procesu. Všetky testy dobehli do konca. Následný graf zobrazuje výsledky testov. Najpomalšie scenáre sa ukázali tie, ktoré spúšt’ajú 20 súbežných prístupov a najrýchlejšie s prístupom 2650. Tomu však nedoporuˇcujemverit’, lebo pri vyšších súbežných prístupoch (ako napr. 2560) Mule zaˇcalvykazovat’ chyby o neuskutoˇcnenýchkomuniká- ciách, ktoré takto mohli celkový ˇcasopticky skrátit’, lebo neúspešná komu- nikácia „trvá” kratšie ako úspešná. Narastanie vel’kosti správ má tendenciu komunikáciu mierne spomal’ovat’. Scenár CBRTransportHeaderProxy do- padol zo všetkých ostatných scenárov najhoršie. Spriemerované hodnoty scenárov sú: DirectProxy: 3165,18; CBRProxy: 2976,51; CBRSOAPHeaderProxy: 1448,10; CBRTransportHeader: 2170,81; XSLTProxy: 2048,73;

Obr. 6.1: Výsledky MuleESB

6.2 SwitchYard v0.7

6.2.1 Výsledky a chybové situácie Podl’a vzoru ostatných ESB, sme zmenili konﬁguráciu java pamäte v zložke esbs/SwitchYard-as7-0.7/bin/standalone.conf. Pôvodné hodnoty „JAVA_OPTS="-Xms64m-Xmx512m -XX:MaxPermSize=256m . . . ” sme zmenili na „JAVA_OPTS="-Xms512m -Xmx2048m -XX:MaxPermSize=256m . . . ”, ˇcím sme dosiahli pripodobnenie SwitchYard nastavenia ostatným ESB nasta- veniam, ktoré mali Java pamät’ nastavenú na 2 GB. Ak sme túto zmenu ne- spravili, log servera by vypísal chybovú správu o nedostatku Java pamäte:

26 6. TESTOVANIE

„java.lang.OutOfMemoryError: GC overhead limit exceeded”. Avšak po tejto zmene problém pretrval už len pri scenári „100 KB – 2560 users” testy padli na základe Putty fatal erroru: „Network error: Software caused connection abort”. Tento problém sa týkal internetového TCP spojenia a dal sa jednoducho odstránit’ nastavením minimálneho ˇcasu,za aký má byt’ TCP spojenie považované za živé (nastavenie TCP keepalive)[30]. Po tomto nastavení problém pri scenári „100 KB – 2560 users” pretrval, priˇcomsi st’ažoval na dodatoˇcný nedostatok java heap pamäte. Skúsili sme navýšit’ vel’kost permanentej generácie na „-XX:MaxPermSize=512m”, problém však nezmizol. Pokraˇcovalisme teda navýšením Java Heap pa- mäte na „-Xms2048m -Xmx4096m -XX:MaxPermSize=256m” a testy prešli bez d’alších problémov.

Obr. 6.2: Výsledky SwitchYard

V scenároch DirectProxy, CBRProxy, CBRSOAPHeaderProxy a XSLTP- roxy sa posielanie správ vel’kosti do 1 KB javilo, že nemá vplyv na vý- kon. Avšak pri d’alšom zvyšovaní vel’kosti správ prudko klesá výkon. Vel’- kost’ správ mala najmenší vplyv na výkon pri scenári XBRTransportHea- derProxy, ktorého hodnoty takmer neklesali. Neprebehnutých komunikácii bolo len symbolicky málo a neboli zapríˇcinenévysokými výkonnostnými nárokmi. DirectProxy: 1025,24; CBRProxy: 879,55; CBRSOAPHeaderProxy: 1182,30; CBRTransportProxy: 1301,28; XSLTProxy: 842,04;

6.3 UltraESB v1.7.1-Vanilla

Prvá verzia bola vydaná v januári 2010 a zdrojový kód bol otvorený pod AGPL licenciou7 v auguste 2010. Je známa hlavne kvôli svojmu vysokému

7. http://www.gnu.org/licenses/agpl.html 27 6. TESTOVANIE výkonu. Podl’a slov Asankha Perera[31], CEO spoloˇcnosti,UltraESB bol od zaˇciatkusvojho vývoja doprevádzaný jednotkovými testami (unit testing)8 a vydanie 1.7 má najviac testami kryté zdrojové kódy (okolo 50%) spomedzi všetkých ostatných ESB. Zakladatelia spoloˇcnostiboli pred rokom 2010 zamestnancami WSO2. Beh testov pre UltraESB prebehol bez akýchkol’vek problémov a neboli za- znamenané žiadne neúspešné interakcie. Najmenej úspešný bol scenár na transformácu pomocou XSLT a najlepší bol scenár routovania na základe hlaviˇckyHTTP. Pri správach o vel’kosti 10 KB bolo poznat’ pokles výkonu pri scenári DirectProxy, CBRProxy a XSLTProxy. V grafe je možné pozo- rovat’ pravidelnost’ poklesu výkonu u väˇcšinyscenárov za súbežného prí- stupu 640 používatel’ov, priˇcompri následovnej hodnote 1280 súbežných používatel’ov táto hodnota prudko vyskoˇcilaponad lokálny priemer. Spriemerované hodnoty scenárov sú: DirectProxy: 4455,59; CBRProxy: 3408,85; CBRSOAPHeaderProxy: 3622,16; CBRTransportHeader: 4923,47; XSLTProxy: 1877,35;

Obr. 6.3: Výsledky UltraESB

6.4 WSO2 v4.6.0

Toto ESB je open source implementácia rovnomennej spoloˇcnostiWSO2 sídliacej v USA, vo Vel’kej Británii a na Srí Lanke. Je založená na Apache Synapse ESB. Jej vlajkonosiˇcomsa považuje americká internetová aukˇcná sieˇneBay s neustálym spracovaním transakcií v hodnote 2000 dolárov za sekundu[32].

8. Unit testing zahrˇnuje nástroje, metodiku a testovanie ˇciastkovýchjednotiek zdrojového kódu.

28 6. TESTOVANIE

Poskytuje jedinú kompletnú open source SOA middleware podporu na dnešné heterogénne podnikové prostredia - interne a v cloud systéme. WSO2 ESB t’aží z výhod transportu zavedeného v Apache Synapse9. To umožˇnujespracovanie vel’kého množstva súbežných požiadaviek pomocou málo zdrojov a málo vláken[33]. WSO2 ESB v4.0.3 bol súˇcast’ou testovacieho benchmarku v 6. kole (Round 6). V januári 2013 však bol vydaný ˇclánokspoloˇcnost’ou WSO2 zverejˇnujúcinajnovšie výsledky testovania pri implementovaní najnovšej verzii WSO2 ESB v4.6.0 a WSO2 ESB v4.5.1. Naj- novšie verzie tohto ESB zaznamenali výrazný pokrok vo výkone. Svoje testovanie sa rozhodli pomenovat’ ako 6.5 kolo (Round 6.5), pretože súˇcas- t’ou testovania boli aj výsledky z d’alších ESB[34]. WSO2 používa Passth- rough Transport (PTT) ako svoj primárny transport. PTT je vylepšený me- diaˇcnýstroj, stojaci na základe XPath pre CBR a výrazne vylepšuje XSLT schopnosti nazývané „Fast XSLT”. Navyše vykazuje lepšie hodnoty využi- tia pamäte[35]. Spriemerované hodnoty scenárov sú: DirectProxy: 4678,22; CBRProxy: 3554,73; CBRSOAPHeaderProxy: 3965,12; CBRTransportHeader: 4897,31; XSLTProxy: 2962,15;

Obr. 6.4: Výsledky WSO2 ESB

6.4.1 Rozdiel v testovaní WSO2 v4.6.0 oproti ostatným ESB Testovacie rozhranie urˇcenépre testovanie WSO2 v4.6.0 bolo mierne upra- vené a bolo obsiahnuté v samostatnom balíˇcku benchmark-client-wso2.zip. Obsahovalo vlastné loadtest skripty, ktoré obsluhovali všetky potrebné sú- bory priamo z vlastného balíˇcka benchmark-client-wso2.zip, vrátane XSLT sú- borov, SOAP správ.

9. http://synapse.apache.org/

29 6. TESTOVANIE

Takisto aj výpis správ bol pozmenený a boli vynútené zmeny v nasta- vení operaˇcnéhosystému. Testovanie WSO2 v4.6.0 takisto prichádza s no- vými scenármi pre extrémne prípady užitia 100 KB správ pri scenári CBR- Proxy. Dalejˇ zavádza nový scenár XSLTEnhancedProxy, na demoštrovanie výsledkov za použitia „Fast XSLT”. Navyše sa pri niektorých vysoko ná- roˇcnýchscenároch rozhodli zvýšit’ poˇcetposielania správy v jedného pou- žívatel’a z 10-krát na 200-krát, ˇcosa im zdalo byt’ objektívnejšie. Pre ostatné detaily odporúˇcamnavštívit’ stránku ESB Performance Round 6.5. Daný ˇclánokporovnáva výsledky týchto testov s výsledkami ostatných ESB, pri- ˇcomtie boli testované za konﬁgurácii stanovených ESB Performance. My sme testy spustili nanovo a naše výsledky sú preto unikátne[34]. V našom teste výkon pri narastajúcej vel’kosti správ mierne klesal. Naj- horšie hodnoty nastali pri scenári XSLTProxy, ale za použitia „Fast XSLT” boli hodnoty omnoho pôsobivejšie. Najúspešnejšie spomedzi ostatných scenárov boli DirectProxy a CBRTransportHeaderProxy. Chybné neprebe- hnuté komunikácie pri testovaní nastali len symbolicky málo, ale tie, ˇcosa vyskytli nastali pri vyššom zát’ažovom stupni a v slabšom scenári XSLTP- roxy.

30 7 Vyhodnotenie výsledkov

7.1 Vyhodnotenie na základe vel’kosti správy

V prvom grafe na ose X máme výsledky na základe scenára a pri každom scenári vzhl’adom na vzrastajúcu hodnotu súbežných prístupov. Pri prvom grafe je možné vidiet’, že pri konštatnej vel’kosti správ súbežnost’ prístu- pov nemá vel’ký vplyv. Najstálejšie hodnoty ukázal SwitchYard, ktorý ale dosahuje najslabšieho výkonu. Vo všetkých prípadoch najlepšie skonˇcili WSO2 a UltraESB. Pri druhom grafe so správami približne dvadsat’krát väˇcšímisme zaznamenali rozdiely. SwitchYard má nad’alej najstálejšie hodnoty, hoci najnižšie. Mule v DirectProxy a CBRProxy dosahoval najlepšieho výkonu, priˇcompri druhom prípade dokonca prevyšoval všetky ESB. Glo- bálne najlepšie výkony ukázali WSO2 a UltraESB, priˇcomUltraESB bola mierne nad hodnotami WSO2.

Obr. 7.1: Výkon ESB za posielania správy o vel’kosti 512 B

31 7. VYHODNOTENIEVÝSLEDKOV

Obr. 7.2: Výkon ESB za posielania správy o vel’kosti 10 KB

7.2 Vyhodnotenie na základe súbežného prístupu

V grafe so súbežným prístupom 20-tich používatel’ov boli výsledky Mule ESB a SwitchYard porovnatel’ne podobné, priˇcomboli celkovo nižšie ako WSO2 s UltraESB, ktoré boli 3 – 4-krát výkonnejšie. Obe dosahovali porovnatel’ne podobné hodnoty, priˇcomUltraESB mala mierne lepšie hodnoty. Pri narastajúcej vel’kosti správ výkon výrazne klesal. Dalšíˇ graf znázorˇnujevýsledky s najnároˇcnejšímstupˇnomsúbežného prístupu, ktorý nebol spustený za použitia správ väˇcšíchako 5 KB. V sce- nároch DirectProxy a CBRProxy boli Mule ESB, UltraESB a WSO2 porovnatel’ne podobné. V ostatných scenároch Mule zaˇcalvýrazne zaostávat’, pri- ˇcomv XSLTProxy výrazne poskoˇcila prekonal aj pokroˇcilejšiuXSLT tech- nológiu od WSO2. Tento úspech však treba spochybnit’ kvôli riziku nepres- nosti dát, ktoré sme si uviedli v kapitole 6.1.1.

32 7. VYHODNOTENIEVÝSLEDKOV

Obr. 7.3: Výkon ESB za posielania správy za prípadu 20 súbežných prístu- pov

Obr. 7.4: Výkon ESB za posielania správy za prípadu 2560 súbežných prí- stupov

7.3 Vyhodnotenie z pohl’adu testových scenárov

Globálne je v tomto grafe poznat’ klesajúcu tendenciu v priamej úmere s na- rastaním vel’kosti správ. Najlepšie hodnoty ukázali WSO2 striedavo s Ul- traESB.

33 7. VYHODNOTENIEVÝSLEDKOV

Obr. 7.5: Výkon ESB pri DirectProxy

Najlepšie hodnoty zaznamenala dvojica WSO2 a UltraESB a za vyššieho súbežného prístupu ich dobiehal Mule ESB.

Obr. 7.6: Výkon ESB pri CBRProxy

V CBRSOAPHeaderProxy SwitchYard dosahoval nižšie hodnoty ako Mule ESB a ten nižšie ako WSO2 s UltraESB.

Obr. 7.7: Výkon ESB pri CBRSOAPHeaderProxy

V CBRTransportHeaderProxy Mule ESB a SwitchYard dosahoval hod-

34 7. VYHODNOTENIEVÝSLEDKOV noty nižšie ako WSO2 s UltraESB.

Obr. 7.8: Výkon ESB pri CBRTransportHeaderProxy

XSLT transformáciu nalepšie poskytovala nová pokroˇcilatechnológia od WSO2, ale pri najvyššom súbežnom prístupe ju Mule prekonával.

Obr. 7.9: Výkon ESB pri XSLTProxy

7.4 Výsledné porovnanie

Najhoršie skonˇcilivýsledky výkonu SwitchYard, pri ktorom vzhl’adom na jeho uvedenie na trh to nemusí znamenat’ prehru. Projekt je ešte vo vývoji, hoci sa už hovorí o skorom príchode verzie 1.0[14]. V niektorých prípa- doch však už dobieha a prekonáva populárny Mule ESB a to vo všetkých prípadoch použitia pri 20 súbežných prístupov a v prípade presmerovania komunikácie na základe SOAP hlaviˇckyu správ do 1 KB. Výrazný pokrok by nastal pri zameraní sa na vylepšení priamej komunikácie ako pri sce- nári DirectProxy, pretože rýchlost’ priamej komunikácie ovplyvˇnujevšetky scenáre. Na tret’om mieste skonˇcilspomínaný Mule, ktorý bol v priemere vyše

35 7. VYHODNOTENIEVÝSLEDKOV dvakrát výkonnejší ako SwitchYard. Mule dosahoval výkon porovnatel’ný s najlepšími ESB pri scenári presmerovania komunikácie na základe obsahu SOAP správy. Na zlepšenie výkonu ESB by sme odporúˇcilizamerat’ vývoj na scenár CBRSOAPHeaderProxy a vylepšit’ výkon za súbežného prístupu 20 používatel’ov. Najväˇcšímprekvapením však bol príchod poslednej verzie WSO2 v4.6 v januári 2013, ktorá od verzie 4.0 zvýšila svoj výkon o 100% a prekonala Ul- traESB. Náskok však je len mierny a miestami zaostáva za UltraESB. V prí- padoch transakcie s nižším stupˇnomsúbežného prístupu skonˇcilamierne lepšie ako jej konkurent. Rovnako je možné poukázat’ na výhodu UltraESB pri komunikácii so správami vel’kosti presne 10 KB. V ostatných prípadoch WSO2 skonˇcillepšie alebo nerozhodne. Tieto dve implementácie sú favoritom na trhu a nedá sa im niˇcvyˇcítat’, av- šak pre UltraESB je tu stále priestor pre pokrok pri scenári s použitím XSLT.

36 8 Záver

Táto práca zoznamuje ˇcitatel’a s problematikou integraˇcnýchsystémov a predstavuje súˇcasne princípy a implementácie. Prínos autora spoˇcíva v tom, že prináša prvé výsledky o výkone nováˇcikaSwitchYard, ktoré sú po- rovnávané so zabehnutými a výkonnými ESB na trhu. Táto práca môže poslúžit’ ˇcitatel’om k ujasneniu výkonnostných rozdie- lov súˇcasnýchESB. Postup, pod ktorým sa testy odohrávali sú podrobne popísané a v prípade potreby môžu poslúžit’ ako doplˇnujúcaliteratúra pre zopakovanie testovania. Autor prichádza s projektom s naimplementova- nými scenármi vo SwitchYard v0.7. V budúcnosti bude zdrojový kód projektu poskytnutý open source a vývojárom testovanieho ESB Performance. Pretože vývoj SwitchYard postupuje úctyhodnou rýchlost’ou, krátko pred dokonˇcenímmojej práce vyšla d’alšia verzia 0.8. Spomínaný projekt však nie je bez dodatoˇcnýchzmien použitel’ný v novšej verzii.

37 Literatúra

[1] ŠULC, Radek. SOA ve službách obchodních proces ˚u (1.). Computerworld: Deník pro IT profesionály [online]. Praha: IDG Czech, a.s, 6.8.2009 [cit. 2013-05-05]. Dostupné z: http://computerworld.cz/technologie/soa-ve-sluzbach-obchodnich- procesu-1-4464

[2] JOSUTTIS, Nicolai. SOA in practice. 1st ed. Sebastopol: O´Reilly, 2007, xv, 324 s. ISBN 05-965-2955-4.

[3] DENMAN, James A. Red Hat makes a switch: SwitchYard project to replace JBoss ESB. SearchSOA [online]. 2012 [cit. 2013-05-15]. Do- stupné z: http://searchsoa.techtarget.com/feature/Red-Hat-makes- a-switch-SwitchYard-project-to-replace-JBoss-ESB

[4] MARIN, Lucian E. The Agile Executive. The Agile Exe- cutive [online]. 5.1.2010 [cit. 2013-05-15]. Dostupné z: http://theagileexecutive.com/2010/01/05/deﬁne-agile- development/

[6] DE SOUSA, Susan What is SOA or Service Oriented Architecture?. Su- san de Sousa’s My PM Expert [online]. © 2009 [cit. 2013-05-15]. Do- stupné z: http://www.my-project-management-expert.com/what-is- soa.html

[7] SVOBODA, Radek. Srovnání dostupných implementací speciﬁkace JBI. Brno, 2009. Diplomová práce. Masarykova Univerzita Fakulta In- formatiky. Vedoucí práce Mgr. Pavel Drášil.

[8] HOHPE, Gregor. Enterprise integration patterns: designing, building, and deploying messaging solutions. Boston: Addison-Wesley, 2004, li, 683 s. ISBN 03-212-0068-3.

[9] ŠKODA, Petr. Integrace aplikací. Brno, 2010. Diplomová práce. Masa- rykova Univerzita Fakulta Informatiky.

[10] FRYE, Colleen. A Look at Service Component Architecture (SCA). SearchSOA [online]. 1.3.2010 [cit. 2013-05-15]. Dostupné z:

38 8. ZÁVER

http://searchsoa.techtarget.com/news/1396825/A-Look-at-Service- Component-Architecture-SCA [11] TIJS RADEMAKERS, Jos Dirksen. Open source ESBs in action: exam- ple implementations in Mule and ServiceMix. Greenwich, CT: Man- ning, 2009. ISBN 19-339-8821-5. [12] ROSEN, Michael. Applied SOA: service-oriented architecture and de- sign strategies. Indianapolis, IN: Wiley Pub., c2008, xxxiii, 662 p. ISBN 04-702-2365-0. [13] RICHARDS, Mark. The Role of the Enterprise Service Bus. InfoQ [online]. 23.10.2006 [cit. 2013-05-15]. Dostupné z: http://www.infoq.com/presentations/Enterprise-Service-Bus [14] BABO, Keith. SwitchYard Release Overview – 0.8. JBoss Community [online]. 26.3.2013 [cit. 2013-05-15]. Dostupné z: https://community.jboss.org/wiki/SwitchYardReleaseOverview- 08 [15] PERERA, Asankha Framework - Performance Test Cases. ESB Performance [online]. 4.7.2012 [cit. 2013-05-15]. Dostupné z: http://esbperformance.org/display/comparison/Framework+- +Performance+Test+Cases [16] PERERA, Asankha Framework - Objectives and History. ESB Performance [online]. 4.7.2012 [cit. 2013-05-15]. Dostupné z: http://esbperformance.org/display/comparison/Framework+- +Objectives+and+History [17] PERERA, Asankha ESB Performance Testing - Round 6. ESB Performance [online]. 31.8.2012 [cit. 2013-05-15]. Dostupné z: http://esbperformance.org/display/comparison/ESB+Performance+Testing+- +Round+6 [18] PERERA, Asankha Execution - Executing Locally. ESB Per- formance [online]. 6.1.2013 [cit. 2013-05-16]. Dostupné z: http://esbperformance.org/display/comparison/Execution+- +Executing+Locally [19] PERERA, Asankha Execution - EC2 Execution of Round 6. ESB Performance [online]. 4.1.2013 [cit. 2013-05-16]. Dostupné z: http://esbperformance.org/display/comparison/Execution+- +EC2+Execution+of+Round+6

39 8. ZÁVER

[21] BERNINGER, Daniel. What the heck is an ECU?. Cloud Price Calculator [online]. 18.10.2010 [cit. 2013-05-16]. Dostupné z: http://cloudpricecalculator.com/blog/hello-world/

[23] BABO, Keith. User Guide. User Guide - Over- view [online]. 25.3.2013 [cit. 2013-05-16]. Dostupné z: https://docs.jboss.org/author/display/SWITCHYARD/User+Guide

[24] SwitchYard. JBoss Community [online]. 2013 [cit. 2013-05-16]. Do- stupné z: http://www.jboss.org/switchyard

[25] IGARASHI, Tomohisa. Re: need a web service proxy quickstart in SwitchYard. In: JBoss Community [online]. 10.10.2012 [cit. 2013-05-16]. Dostupné z: https://community.jboss.org/message/764167#764167

[26] IGARASHI, Tomohisa. Camel-implemented component converts message to InputStream. In: JBoss Community [online]. 8.4.2013 [cit. 2013- 05-16]. Dostupné z: https://issues.jboss.org/browse/SWITCHYARD- 1329

[27] Understanding Integration From A "Needs-Based" Perspec- tive - Mule vs. ServiceMix / Fuse ESB. MuleSoft: connecting the new enterprise [online]. [2013] [cit. 2013-05-16]. Dostupné z: http://www.mulesoft.com/resources/esb/understanding- integration-needs-based-perspective-mule-vs-servicemix-fuse-esb

[28] Mulesource becomes MuleSoft. H Online [online]. 2.9. 2009 [cit. 2013- 05-16]. Dostupné z: http://h-online.com/-743219

[29] YAGEN, Ken. Mule 3: Services or Flows? You can have both!. MuleSoft Blog [online]. 23.2.2011 [cit. 2013-05-16]. Dostupné z: http://blogs.mulesoft.org/let-your-services-ﬂow-free/

[30] THAT, Daniel. PuTTy Fatal Error - Network error: Software caused connection abort [SOLVED]. Daniel That [online]. 21.10. 2012 [cit. 2013-05-16]. Dostupné z: http://danielthat.blogspot.cz/2012/10/ssh- putty-session-network-time-out.html

40 8. ZÁVER

[31] UltraESB - The Future of Enterprise Systems Integration - Webinar - June 2012. Youtube [online]. 2012 [cit. 2013-05-15]. Dostupné z: http://www.youtube.com/watch?v=sNwvM6IF-cE

[32] BABCOCK, Charles. Open Source Helps eBay Process $2000 Per Second. InformationWeek [online]. 1.8.2011 [cit. 2013-05-16]. Do- stupné z: http://www.informationweek.com/infrastructure/trafﬁc- management/open-source-helps-ebay-process-2000-per/231002969

[33] How the WSO2 ESB outperforms other major open source esb vendors (slideshare). Yenlo [online]. 21.3.2013 [cit. 2013-05-17]. Do- stupné z: http://www.yenlo.nl/nl/how-the-wso2-esb-outperforms- other-major-open-source-esb-vendors/

[34] ABEYRUWAN, Dushan. ESB Performance Round 6.5. WSO2 [online]. 30.1.2013 [cit. 2013-05-16]. Dostupné z: http://wso2.org/library/articles/2013/01/esb-performance-65

[35] WSO2 to Present Technical Webinar on Capabilities of WSO2 ESB 4.6. WSO2 [online]. 14.3.2013 [cit. 2013-05-16]. Dostupné z: http://wso2.com/about/news/wso2-to-present-technical-webinar- on-capabilities-of-wso2-esb-4-6/

41 A Ostatné grafy výkonnostného testovania

42 A.OSTATNÉ GRAFY VÝKONNOSTNÉHO TESTOVANIA

43 A.OSTATNÉ GRAFY VÝKONNOSTNÉHO TESTOVANIA

44 A.OSTATNÉ GRAFY VÝKONNOSTNÉHO TESTOVANIA

Obr. A.1: St´lpcový graf so spriemerovanými výkonnostnými hodnotami vzhl’adom na TPS (transaction per second)

45 A.OSTATNÉ GRAFY VÝKONNOSTNÉHO TESTOVANIA

Obr. A.2: Všetky výsledky B Zát’až CPU na Amazon EC2 po dobu testu

Obr. B.1: MuleESB

Obr. B.2: SwitchYard

47 B.ZÁTAŽˇ CPU NA AMAZON EC2 PODOBUTESTU

Obr. B.3: UltraESB

Obr. B.4: WSO2 ESB