Servisne orientované architektúry (SOA)

Transcription

1 Bankovní institut vysoká škola Praha zahraničná vysoká škola Banská Bystrica Katedra kvantitatívnych metód a informatiky Servisne orientované architektúry (SOA) Service oriented architectures (SOA) Bakalárska práca Autor: Andrej Bronda Informační technologie Vedúci práce: Doc. RNDr. Juraj Pančík, CSc. Banská Bystrica apríl, 2012

2 VYHLÁSENIE Vyhlasujem, že som bakalársku prácu Servisne orientované architektúry (SOA) spracoval samostatne s použitím uvedenej literatúry. Svojím podpisom potvrdzujem, že odovzdaná elektronická verzia práce je identická s jej tlačenou verziou a som oboznámený so skutočnosťou, že sa práca bude archivovať v knižnici BIVŠ a ďalej bude sprístupnená tretím osobám prostredníctvom internej databázy elektronických vysokoškolských prác. V Banskej Bystrici, dňa Andrej Bronda

3 POĎAKOVANIE Rád by som sa poďakoval vedúcemu práce Doc. RNDr. Jurajovi Pančíkovi, CSc. za konzultácie pri vedení práce.

4 ANOTÁCIA BRONDA, Andrej: Servisne orientované architektúry (SOA). [Bakalárska práca]. Bankovní institut vysoká škola Praha, zahraničná vysoká škola Banská Bystrica. Katedra kvantitatívnych metód a informatiky. Vedúci práce: Doc. RNDr. Juraj Pančík, CSc. Rok obhajoby: Počet strán: 43 Bakalárska práca sa zaoberá Servisne orientovanými architektúrami (SOA). Vysvetľuje ich prínos pri podnikových informačných systémoch Prvá kapitola je zameraná na teoretické vymedzenie pojmov z danej oblasti. Druhá a tretia kapitola obsahuje podrobnejší popis servisne orientovaných architektúr a webových služieb. A posledná kapitola prezentuje možnosti integrácie a praktický príklad. Kľúčové slová: Servisne orientované architektúry, SOA, Integrácia, Webové služby, SOA Governance, IBM Webspehere

5 ANNOTATION BRONDA, Andrej: Service oriented architectures (SOA). [Bachelor s Thesis]. Banking Institute College of Banking Prague, Foreign University Banská Bystrica. Department of Computer Science & Quantitative Methods. Supervisor: Doc. RNDr. Juraj Pančík, CSc. Year of defense: Page count: 43 Bachelor s Thesis deals with Service oriented architectures (SOA). It explains their benefits in connection with enteprise information systems. First chapter is focused on theoretical definitions from the area. Second chapter contains detailed description of the Service-oriented architectures and Web services. Third chapter presents integration capabilities and a practical example. Key words: Service oriented architectures, SOA, Integration, Web services, SOA Governance, IBM Websphere

6 OBSAH ÚVOD TEORETICKÉ VYMEDZENIE POJMOV Softvérové inžinierstvo Architektúra softvéru Životný cyklus IS Podnikové procesy INTEGRÁCIA PODNIKOVÝCH APLIKÁCIÍ Evolúcia integrácie podnikových aplikácií Middleware Princípy integrácie podnikových aplikácií Výber integračného riešenia Webové služby Architektúry orientované na služby Portály SERVISNE ORIENTOVANÉ ARCHITEKTÚRY (SOA) História SOA Koncept SOA Proces zavádzania SOA Výhody SOA Lepšia integrácia Základná znovupoužiteľnosť Ovplyvnenie starších investícií Nezávislosť Zavedenie štandardnej reprezentácie dát XML Negatíva SOA Náklady... 21

7 3.5.2 Nedostatok znalostí o SOA Nároky na IT infraštruktúru SOA Governance Webové služby WSDL SOAP UDDI BPEL ANALÝZA VYUŽITIA SOA PRI NÁVRHU, REALIZÁCII A RIADENÍ PODNIKOVÝCH INFORMAČNÝCH SYSTÉMOV Prístupy k integrácii Enterprise Service Bus Websphere Integration Developer Príklad použitia servisne orientovanej architektúry Služba práca so skladom Služba práca s objednávkami Služba práca so zákazníkmi Proces vytvorenia objednávky ZÁVER ZOZNAM POUŽITEJ LITERATÚRY ZOZNAM OBRÁZKOV A TABULIEK PRÍLOHA

8 ÚVOD Predmetom tejto bakalárskej práce sú Servisne orientované architektúry. Servisne orientovaná architektúra je často krát nepochopený pojem. Veľa ľudí si myslí, že vybudovalo servisne orientovanú architektúru, a pritom to tak vôbec nemusí byť. V tejto bakalárskej práci by som chcel priblížiť Servisne orientované architektúry a objasniť pojmy s nimi spojené. Cieľom práce je opísať a analyzovať využitie servisne orientovaných architektúr (SOA) v návrhu, realizácii, správe a riadení podnikových informačných systémov. V prvej a druhej časti sa práca zaoberá základnými pojmami ako sú : SOA, Webové služby, SOA Governance, podnikové procesy a iné. V tretej časti práca opisuje postup zavádzania SOA, výhody a nevýhody servisne orientovaných architektúr, a taktiež čo by mala SOA spĺňať. V poslednej časti mojej práci sa venujem prípadovým štúdiám využitia SOA v praxi, kde ako softvér využijeme IBM WEBSPEHERE INTEGRATION DEVELOPER. Ukážeme si vytvorenie služieb a ich vzájomnú komunikáciu. 8

9 1 TEORETICKÉ VYMEDZENIE POJMOV Softvérové systémy predstavujú zásadnú časť informatiky využívanú v množstve oblastiach. Oblasťou softvérových systémov sa zaoberá disciplína softvérového inžinierstva. Dôležitými vlastnosťami softvérových systémov sú architektúra a životný cyklus. 1.1 Softvérové inžinierstvo Softvérové inžinierstvo je disciplína, ktorá sa zaoberá, špecifikáciou, vývojom, riadením a údržbou informačných systémov. Inak povedané softvérové inžinierstvo sa orientuje na všetky pohľady výroby softvéru. (Rábová, 2008, s.30) Softvérové inžinierstvo (SI) je aplikácia systematických, disciplinovaných, kvantifikovateľných krokov k rozvoju, operáciám a údržbe softvéru. (IEEE Standard Glossary of Software Engineering Terminology, IEEE std , 1990). 1.2 Architektúra softvéru Architektúru tvorí základná organizácia systému, ktorý je tvorený komponentmi, vzťahmi medzi nimi, prostredím. Je popísaná určitými pravidlami, ktoré determinujú jej správanie, tvar/formu a vývoj. (podľa štandardu IEEE , IEEE Recommended Practice for Architectural Description of Software Intesive Systems). V tejto definícii je použitý pojem komponent. Veľké množstvo z definícií obsahuje tento pojem, ale nevysvetľuje ho. Táto definícia je preto úmyselne nejasná a to preto aby mohla byť použitá pre viac rôznych interpretácií v priemysle spojenom so softvérom. Architektúra softvéru je jednou z disciplín softvérového inžinierstva. (Bieliková, 2007, s. 40) 1.3 Životný cyklus IS Tvorba softvérového produktu je zložitý proces označovaný ako životný cyklus vývoja. Životný cyklus začína prvotným nápadom a končí likvidáciou produktu a výmenou za iný. Táto z prvého pohľadu celkom jednoduchá definícia v sebe skrýva oveľa viac zložitejších prvkov. Etapy životného cyklu vývoja Špecifikácia problému úvodné štúdie Analýza logický model Návrh technologický model 9

10 Implementácia implementačný model Zavedenie a testovanie produktu, dokumentácia Prevádzka, údržba a rozvoj produktu. (Rábová, 2008, s. 37) 1.4 Podnikové procesy Podnikový proces je súhrnom činností, transformujúcich súhrn vstupov (práce, pôda, kapitál, informácie) na súhrn výstupov (hodnota pre zákazníka) pre iných ľudí alebo procesy, používajúc k tomu ľudí a nástroje. (Řepa, 2007, s. 15) Viazanosť medzi podnikovými procesmi a informačnými systémami je veľmi silná. Projekty reorganizácie podnikových procesov, sú úzko spojené s projektmi implementácie a inovácie podnikových informačných systémov Toto sa často deje vo vzájomnej nadväznosti alebo súčasne. (Basl, 2008, s. 116) Procesný prístup sa dá využiť vo všetkých hlavných fázach životného cyklu IS podniku: Pred implementáciou - analýzy, vizualizácia a modelovanie podnikových procesov s ich možnosťou ich úpravy pred vlastnou implementáciou IS. V priebehu implementácie - využitie referenčných procesných modelov zahŕňajúce najlepšie skúsenosti (best practices), ktoré môžu implementáciu urýchliť a tiež ju zlacniť. V priebehu prevádzky IS - využitie procesov pre prevádzku vlastných aplikácií IS a ďalej využitie IS pre podporu sledovania a riadenie výkonnosti procesov na báze IS. (Basl,2008, s. 117) 10

11 2 INTEGRÁCIA PODNIKOVÝCH APLIKÁCIÍ Masívne rozšírenie IT technológií má za následok veľké množstvo používaných softvérových systémov. Vzájomná spolupráca týchto systémov dokáže výrazné zvýšiť celkový prínos informačných technológií. Dôvodom, prečo sa zaoberáme integráciou, je to dôležitá téma, ktorá rieši spoluprácu rôznych systémov. Aby človek, ktorý ide na úrad vyplniť nejaký formulár, nemusel byť posielaný s ďalším formulárom na ďalší úrad a to len preto, že systémy týchto dvoch úradov nespolupracujú. 2.1 Evolúcia integrácie podnikových aplikácií Rozvoj informačných technológií prináša stále nové prostriedky, ktorými môžu nasýtiť svoje potreby. To všetko však za cenu často veľmi úzkej špecializácie takýchto prostriedkov. Pri týchto prípadoch sa nám vynárajú otázky typu: Ako takéto prostriedky vzájomne prepojiť za účelom zdieľania a ako znovu využiť programy a aplikácie, ktoré sme už vyvinuli a nasadili do prevádzky a ako prepojiť technológie a aplikácie nielen v rámci organizácie. Z pohľadu používateľa je cieľovým stavom taký integrovaný systém, ktorý napĺňa ciele a potreby všetkých stupňov riadenia organizácie. Z informatického pohľadu je cieľ samozrejme ten istý, ale s požiadavkou, aby cieľový systém bol tvorený ľahko integrovateľnými prvkami, ktoré sú podľa aktuálnych potrieb spojené do vhodného celku, pričom ho možno ale "rozpojiť" a následne spojiť do celku iného.,,integráciou v podnikovej informatike rozumieme akt alebo proces, ktorým kombinujeme, prepojujeme a spájame rôznorodé zdroje podnikovej informatiky do vyššieho celku, pričom komponenty dohromady spolupracujú a zdieľajú dáta bez znateľného zdržanie a koordinujú svoju funkcionalitu tak, že sa takáto kombinácia komponentov javí používateľovi ako jednotný systém. (Pour, a iní, 2009, s. 353) Pri integrácii nás v dôsledku špecializácie komponentov musí zaujímať, ako spolu komponenty môžu komunikovať, ako spolu môžu spolupracovať a akým spôsobom je možné spoluprácu riadiť. V súvislosti s možnosťou prvky integrovať nás potom zaujíma aj stupeň interoperability komponentov, to je schopnosť komunikácie, vykonávania programu, prenášanie dát medzi rôznymi komponentmi, bez toho, aby používateľ a tiež aplikácie disponovali znalosťami o charakteristikách týchto komponentov. Oblasť integrácie v informatike sa postupne vyvíjala so zlepšovaním informačných technológií. 11

12 Základné evolučné etapy v oblasti integrácie tvoria: integrácie programov skorá fáza obdobia integrácie, kedy prestali byť budované samostatné aplikácie a bolo potrebné vzájomne prepojovať hotové programové moduly, knižnice funkcií a procedúr spoločná databáza úzko súvisí s rozvojom databázových systémov, ktoré umožňujú rôznym aplikáciám zdieľať spoločnú množinu dát balíky etapa súvisí s nástupom typového aplikačného softvéru, kedy sú vytvárané komplexné riešenie tvorené radom prepojeným modulov, jednotlivé moduly svojou funkcionalitou potom podporujú definovaný proces middleware základný middleware súvisí s nástupom objektov a komponentov a vhodných middlewarových prostriedkov, ktoré umožňujú integrovať programy vyvinuté v rôznych prostrediach, napríklad Java, C #, VisualBasic a podobné, to umožňuje, aby napríklad "balík" mohol byť tvorený heterogénnymi komponentmi a bola tak maximálne využitá schopnosť konkrétnej technológie integrácia podnikových aplikácií súvisí s potrebou integrovať aplikácie, ktoré sú súčasťou rôznych aplikačných balíkov integrácia medzipodnikových aplikácií súvisí s integráciou aplikácií, ktoré sú prevádzkované rôznymi organizáciami, napríklad zapojenými v dodávateľskom reťazci a podobné iné (Pour, a iní, 2009, s. 354) 2.2 Middleware,,Middleware je programové vybavenie, ktoré je umiestnené medzi operačným systémom a aplikáciami a ktoré ponúka aplikáciám všestranne použiteľnú množinou služieb. Služby vytvárajú prevádzkové systémové prostredie, ktoré umožňuje procesom, programom a aplikáciám vzájomnú interakciu v distribuovanom systéme prostredníctvom siete. (Myerson, 2002, s.34) Základný middleware predstavuje množinu prostriedkov, ktorú možno rozdeliť do nasledujúcich kategórií: 1. Komunikačný middleware poskytuje protokol pre prenos správ alebo dát medzi programami a programovým rozhraním, prostredníctvom ktorého program pristupuje ku komunikačným službám. 12

13 2. Prostriedky integračného middleware rozširujú funkcionalitu základného middleware v rôznych smeroch. Využívajú sa predovšetkým v situáciách, kedy spolu majú komunikovať či majú byť vzájomne integrované v zásade nezávislé aplikačné systémy. 3. Prostriedky aplikačnej integrácie - netvoria čisto middlewarové prostriedky, ale prostriedky vnútorne integrujúce middleware s aplikačnou logikou orientovanú na podnikové procesy. (Pour, a iní, 2009, s. 355) 2.3 Princípy integrácie podnikových aplikácií Technologických prostriedkov existuje celá rada. Prístupov (alebo ich kombinácie), ako zabezpečiť integráciu. Všeobecne tento proces alebo platformu riešenia označujeme termínom integrácie podnikových aplikácií (EAI, Enterprise Application Integration). Integrácia podnikových aplikácií je množina konceptov, prístupov, metód, technológií, ktorá umožňuje organizácii vzájomne prepojiť pôvodne často vzájomne nekompatibilné nezávislé čiastkové riešenia alebo informačné systémy. EAI ako platforma je potom množina nástrojov technológií umožňujúcich efektívnu spoluprácu a správu aplikácií. (Pour, a iní, 2006, s. 318) Snahou konceptu EAI JE: Odstrániť sémantickú nekonzistenciu dát Odstrániť obsahovú nekonzistenciu dát Skryť fragmentáciu dát Skryť fragmentácii obchodných procesov Odstrániť duplicitu vo funkcionalite aplikácií Integrácia aplikácií je zložitá a komplexná oblasť, preto je potrebné sa pozerať na riešenie z rôznych pohľadov 13

14 Middleware Obrázok 2-1 Množina prístupov k integrácii Integračné štýly Úroveň integrácie Architektúra integrácie Sú použité v konkrétnom integračnom riešení Orientácie integrácie Zdroj:Pour,2006, s Výber integračného riešenia Rozhodovanie, akú kombináciu prístupov, štýlov úrovne integrácie zvoliť, akú architektúru zostaviť, závisí na rade kritérií: Tesnosť väzby medzi aplikáciami - Medzi aplikáciami môže existovať veľmi tesná väzba alebo väzba môže vykazovať rôzny stupeň voľnosti. Hĺbka zásahu do aplikácie vyvolaná požiadavkami integrácie, keď sa tvorcovia kódu často bránia zásahom do programového kódu aplikácie z rôznych dôvodov (komplikovanosť riešenia, zníženie výkonu, nutnosť udržiavať ďalší kód). Technológie - Rôzne prístupy Štýly vyžadujú doplnenie infraštruktúry o ďalší množinu špecializovaného programového vybavenia. Formát štruktúry dát - Aplikácie často pracujú s rozdielnymi formátmi štruktúrou. Objemy dát, ktoré si vymieňajú aplikácie môžu byť rôzne. Zdieľanie funkcionality. Prevádzkový výkon, teda čas kedy aplikácie Alebo jej časti musia čakať na výsledok spracovania ďalšej aplikácie. Úroveň spoľahlivosti komunikácie. (Pour,2006, s.331) 2.5 Webové služby Pri integrácii aplikácií často vyžadujeme, aby niektoré aplikácie využívali nejakú funkcionalitu aplikácie inej. Možným riešením je využitie webových služieb (web services). 14

15 Ak hovoríme o webových službách, potom by mohla byť položená otázka, prečo práve služba a práve webová. Termín služba používame preto, že funkcionalitu aplikácie, ktorá má byť zdieľaná inými aplikáciami alebo má byť aplikáciami využívaná, možno vlastne označiť za službu iným aplikáciám. Označenie "webová" sa používa preto, že komunikácia medzi poskytovateľom služby a žiadateľom o službu využíva osvedčené prenosové protokoly internetových stránok. Keďže takýmto protokolom je protokol HTTP (Hypertext Transfer Protokol), čo je natívny protokol Služby WWW (World Wide Web), sú služby označované prívlastkom webové. Samozrejme v komunikácii možno využiť i ďalšie protokoly známe z internetu ako napríklad. SMTP, FTP a iné. Podrobnejšie sa budeme webovým službám venovať v kapitole 3.8. (Pour, a iní, 2006, s. 332) 2.6 Architektúry orientované na služby V súvislosti s webovými službami si môžeme položiť otázku, či nebudovať systémy Tak, aby zodpovedali štandardom práve webových služieb. Koncept, ktorý sa zaoberá princípmi postupmi ako to dosiahnuť sa označuje ako architektúra orientovaná na služby (Service-Oriented Architecture, SOA). SOA je podrobne rozobratá v kapitole Portály Portály patria k jednému z prístupov integrácie aplikácií. Portál je množina technológií a aplikácií, tvoriacich univerzálne rozhranie. Portál umožňuje každému, koho sa dotýkajú činnosti organizácie (zákazník, používateľ, dodávateľ, zamestnanec), zúčastniť sa procesov organizácie, pristupovať ku všetkým relevantným informáciám, komunikovať s ostatnými participujúcimi ľuďmi a realizovať adekvátne aktivity spojené s podnikovými procesmi. Historicky je pojem portálu spojený s tzv.vstupnými miestami v sieti internetu. Tá vznikla z potreby pomôcť používateľom internetových stránkach v orientáciu v množstve informácií, ktoré sú v jej rámci v sprístupnené. Z pôvodne katalogizačných služieb (napr. Yahoo!, Seznam.cz, Atlas.cz) sa vyvinuli miesta (brány), ktorá rôznym spôsobom okrem usporiadaných informácií katalógov ponúkajú prístup k širokej škále služieb. Jedná sa o služby plno textového vyhľadávanie informácií, službu elektronickej pošty, on-line rozhovorov, službu sprostredkovávania spravodajstva, prístup k elektronickým obchodom, možnosť využívať pripravené aplikácie (web-blog, šablóny vlastných stránok), až po prístup ku špecificky orientovaným aplikáciám ako napríklad finančným kalkulátorom, slovníkom, 15

16 aukciám. V dnešnej dobe sú informácie takýchto portálov kontextovo previazané, aby používateľ dostál všetky relevantné informácie, ktoré podporia tú ktorú ním zvolenú činnosť. (Pour,2006, s. 344) 16

17 3 SERVISNE ORIENTOVANÉ ARCHITEKTÚRY (SOA) Ako sme si spomenuli v kapitole 2.6 SOA je koncept ktorý sa zaoberá postupmi a princípmi, tak aby zodpovedali princípom webových služieb. Teraz si uvedieme dve definície SOA: Týchto definícií je mnoho ale každá má spoločný základ a to ten, že je založená na princípe služieb.,,soa je forma technologickej architektúry, ktorá je založená na princípe služieb, pretože je SOA realizovaná na technologickej platforme webových služieb, vytvára tak potenciál, ako podporovať a rozširovať tieto princípy v obchodných procesoch a najrôznejších podnikových oblastiach. (Hurwitz, 2009 s. 25),,Súčasná SOA predstavuje otvorenú, rozšíriteľnú, federačnú a komponovateľnú architektúru, ktorá podporuje servisnú orientáciu a skladá sa zo služieb, ktoré sú autonómne, schopné QOS(Quality of Service), podporujú rozmanitosť, spoluprácu, zistiteľnosť a sú implementované ako webové služby. (Erl, 2009 s. 55) SOA sa vyvinula zo starších platforiem, zachováva užitočné vlastnosti tradičných architektúr a prichádza s rôznymi princípmi, ktoré sa starajú o servisnú orientáciu na podporu servisne orientovaného podniku. SOA odbočuje od architektúry klient server vo veľkej miere. Aj keď SOA stále používa niektoré technológie, ktoré pôvodne používala architektúra klient server. Servisne orientované architektúry sú viac prepracované a prinášajú zložitosť, ktorá kontrastuje s jednoduchosťou architektúry klient server. (Erl, 2009 s. 97) 3.1 História SOA Alexander PASIK, bývalý analytik v Gartner použil prvý krát termín SOA v roku 1994, hoci učil middleware architektúry. Keďže tradičná architektúra klient/server nebola dostatočne presná na opis distribuovaného počítania - opisovalo sa ako vykonávanie frontendu (ovládania) na desktopových PC, a vykonávanie backendu (výpočtu) na iných počítačoch. Rozdiel medzi pojmami klient/server architektúry a SOA zdôraznil v zameraní sa na serverovskú časť výpočtu pri návrhu aplikácií využívajúcich princípy SOA. (Josuttis, 2007 s. 56) 17

18 3.2 Koncept SOA Koncept SOA dodržiava nasledovné charakteristiky: Minimálny zásah do existujúcej aplikácie. A ak je aj nejaký zásah potrebný mal by byť pri implementácii čo najmenší. Ak je zmena aplikácie nevyhnutná, mali by sa to lokalizovať na jednom mieste. Nezávislosť a autonómia aplikácií. Každá aplikácia by mala rešpektovať autonómiu ostatných aplikácií. Komunikácia medzi aplikáciami by mala prebiehať spôsobom, ktorý nezasahuje do druhej aplikácie. Nedostupnosť jednej aplikácie by nemala mať dopad na funkciu celého systému, alebo by tento dopad mal byť len minimálny. Komunikácia medzi aplikáciami by mala byť natoľko všeobecná, aby mohla zostať zachovaná aj pri zmene alebo náhrade niektorej z aplikácií, v ideálnom prípade by sa táto zmena alebo náhrada nemala mimo danej aplikácie vôbec prejaviť. Škálovateľnosť. S počtom aplikácií: pridanie ďalšej aplikácie do integračného prostredia by malo pripomínať pripojenie typu Plug&Play. Zložitosť a nákladnosť tohto pripojenia by mali závisieť len na zložitosti a komplexnosti pripájanej aplikácie. Jednotlivé aplikácie je potom možné rozvíjať oddelene, bez ohľadu na zvyšok prostredia. Dodržiavanie štandardov. Aplikácia by mala dodržiavať existujúce štandardy. Čím rôznorodejšie a heterogénnejšie prostredie, tým viac sa (dodržiavaním štandardov) integrácia zjednodušuje. ( ) 3.3 Proces zavádzania SOA Zavádzanie SOA architektúry je zložitý a rozsiahly proces, ktorý trvá dlhší čas, tento proces opisuje článok od Jiřího Šlefra v odbornom časopise Computerworld. 1. V prvom kroku je dôležité stanoviť si dôvod prečo ideme SOA architektúru zavádzať a rozhodnúť sa či je podnik ochotný podstúpiť všetky riziká spojené so SOA. Medzi tie najhlavnejšie riziká patria najmä vysoké náklady na vývoj, riziká spojené s nestabilitou prostredia a nedostatočná rýchlosť implementácie zmenových požiadaviek. 2..Druhý krok hovorí o potrebe zabezpečiť podporu všetkých ľudí, ktorí by mohli ovplyvniť, spomaliť alebo úplne ukončiť proces zavádzania SOA. 18

19 3. Ďalším krokom je vytvorenie vízie a stratégie ku ktorým chceme zavedením SOA dospieť. Táto stratégia by mala korešpondovať so stratégiou celého podniku. Vízia nasadenia SOA môže vyzerať napríklad takto:,,po zavedení SOA bude architektúra podniku postavená na existencii znovupoužiteľných služieb, ktoré umožňujú rýchlo, spoľahlivo a s minimálnymi nákladmi realizovať obchodné ciele a procesy 4. Keď už máme vytvorenú stratégiu tak je nevyhnutné sa uistiť, že všetci, ktorým je určená jej rozumejú rovnako a nedošlo k jej nepochopeniu. 5. Tento krok sa považuje za organizačný posun, ktorý je kritický pre úspech. Je to opatrenie, pri ktorom dostávajú členovia tímu a ostatní zamestnanci právomoci, ktoré súvisia so zmenou. Pre SOA architektúru sú typické právomoci spojené s definíciou obchodných cieľov, návrhom znovupoužiteľných služieb atď. Pokiaľ, by tento krok nebol dodržaný, nedá sa očakávať, že postupy budú dodržiavané. 6. Vytváranie krátkodobých cieľov, o tom hovorí šiesty krok. Zavádzanie SOA je dlhodobý proces zmien, preto je nutné sa sústrediť na krátkodobé ciele ako sú napr. nasadenie prvej služby alebo znovupoužitie služby. 7. Tento krok je úzko prepojený s predchádzajúcim. Využitie krátkodobých výsledkov na podporu vedenia môže mať synergický efekt, zvýši si podpora a ešte viac sa otvorí cesta k procesu zavádzania SOA. 8. Ako bolo povedané v piatok kroku vznikajú právomoci, postupy, štandardy. Cieľom ôsmeho kroku je posunúť tieto právomoci na úroveň povinný. Pri dodržaní tohto osembodového postupu sa nezaručuje úspech, ale sú minimalizované riziká spojené s procesom zavádzania SOA. (Computerworld, 2/2011) 3.4 Výhody SOA Tu si uvedieme dôvody prečo zavádzať SOA a následne z toho plynúce výhody podľa THOMASA ERLA. 19

20 3.4.1 Lepšia integrácia Servisne orientované architektúry so svojimi službami zavádzajú systém komunikácie nezávislý na predajcovi, môžu podniky zavádzať vysoko štandardizované štruktúry popisu služieb a správ. Výsledkom je vnútorná spolupráca, vďaka ktorej môžeme pri projekte integrácie aplikácií venovať viac času návrhu a menej vývoju Základná znovupoužiteľnosť Tvorba opätovne použiteľných služieb mierne zvyšuje úsilie na ich vývoj a požiadavky na použitie štandardov, ale takto znovupoužitelné služby znižujú náklady a čas spojené s budúcim vývojom servisne orientovaných riešení Ovplyvnenie starších investícií Prijatie technológie webových služieb prinieslo aj trh s adaptérmi, to následne umožnili aj starším prostrediam spolupracovať so servisne orientovanými architektúrami integrácie. Pred tým oddelené informačné systémy sa môžu pokúšať o združenie, bez potreby vývoja nestálych integračných riešení z bodu do bodu Nezávislosť SOA zavádza nezávislý systém komunikácie a tým dáva voľnosť oddeleniam informačných technológií aby neboli zviazané jednou vývojovou platformou alebo middlewarem. SOA abstrahuje riadiacu logiku a technológiu do špecializovaných vrstiev služieb, tak sa môžu zakladať voľne spojené vzťahy medzi týmito dvoma doménami podniku Zavedenie štandardnej reprezentácie dát XML Na najzákladnejšej úrovni je SOA postavená na jazyku XML. Samovysvetlujúca povala XML vylepšuje čitateľnosť dát pre vývojára, analytika a návrhára. Ak je plne zavedený štandardný formát reprezentácie dát, znižuje sa zložitosť všetkých aplikačných prostredí. (Erl, 2009 s. 63) 3.5 Negatíva SOA Samozrejmosťou je, že každá zmena so sebou prináša aj negatíva, tými sa bude práca zaoberať v tejto kapitole. 20

21 3.5.1 Náklady Medzi negatíva určite patria počiatočné náklady. Aj keď by sa mala architektúra zavádzať postupne od malých projektov, žiadna spoločnosť sa nevyhne týmto nákladom. Tie môžeme rozdeliť do troch skupín. Organizačné náklady podnik bude musieť predbežne zabezpečiť nové procesy. Je potrebné identifikovať a opísať procesy, ktoré má služba alebo služby podporovať a je potrebné venovať úsilie pri tvorbe nových metodík vývoja IT služieb tak aby podporovali princípy SOA. Architektúra SOA je o kooperácii služieb a to sa nedá dodržiavať bez dôsledného dodržiavania štandardov. V súvislosti s týmto je potrebne vybrať podporné technológie ktoré sú značne nákladné, lebo sa jedná o veľmi odborné činnosti. Softvér Nakoniec musí podnik investovať do softvérových produktov podporujúcich Nedostatok znalostí o SOA SOA je stále ešte len rozvíjajúca sa, nedospelá oblasť a stále ešte platí, že vo svete neexistuje dostatočný počet materiálov popisujúcich "best practices" v oblasti nasadzovania SOA. Neexistujú jasne definované návody a príručky a preto si každá spoločnosť musí vyvinúť vlastné metodiky, zamerané na popísanie toho, ako pri realizácii SOA postupovať Nároky na IT infraštruktúru Vzhľadom k tomu, že informačný systém postavený na architektúre orientovanej na služby je zostavený z veľkého množstva nezávislých služieb, ktoré spolu musia komunikovať prostredníctvom siete, sa stáva takýto systém veľmi komplexným a kladie vyššie nároky na zaťaženie siete. nároky spočívajú v nutnosti riadenie tokov, čo si vyžaduje investície do vzdelávania zamestnancov príkladom je nutnosť školenia administrátorov v ovládaní softvérových produktov ako je ESB. (Erl, 2009 s. 67) 3.6 SOA Governance,,SOA governance je o tom, či podnik vytvára správne veci, či sa tieto veci budujú správne, a zabezpečuje to že, čo vybudovala sa chová normálne. (Stephen, 2011, s. 45),,SOA governance je oblasť, ktorá sa zaoberá procesmi, pravidlami, princípmi, riadením a kontrolou spôsobu, ktorým je SOA v spoločnosti nasadzovaná a používaná. Cieľom SOA governance je maximalizácia prínosu SOA všetkým stranám. (Computerworld, 2011) 21

22 ,,Cieľom SOA dozoru (governance) je zaručiť, že zvolená SOA stratégia prinesie spoločnosti alebo organizácii maximálnu hodnotu. Je to stanovenie kontroly, riadenia a administrácie IT prostredia za účelom ovplyvňovania a presadzovanie definovaných akcií a chovania. ( ) SOA Governance adresuje - Aké rozhodnutie musia byť urobené pre efektívnu správu? Kto musí tieto rozhodnutia urobiť a kto ma aké práva? Ako bude rozhodnutie formulované?,,efektívna SOA Governance je kombinácia ľudí, procesov a technológií. Adresuje celkový SOA životný cyklus (od vytvárania cez použitie a zosúladenie so zámermi organizácie). ( ) KCI Kompetenčné centrum integrácie v originále ICC Integration Competency Center, je útvar, ktorý býva hlavným riadiacim orgánom v procese SOA governance. Jeho kompetencie a zodpovednosti bývajú zahrnuté v celej organizácii. Kompetenčné centrum Integrácie je tým ľudí ktorý zaisťuje činnosti spojené s integráciou aplikácií v rámci spoločnosti a zároveň aj s aplikáciami ich partnerov. Tento tým je zodpovedný za celý životný cyklus služieb na integračnej platforme od identifikácie až po samostatný beh. Je jednoznačnou autoritou v oblasti definície štandardov integrácie v rámci spoločnosti. Typicky má toto centrum 5-6 členov ale počet rolí je vyšší, to znamená, že niektorý členovia vykonávajú viac úloh. Manažér KCI je vedúci týmu a rieši jeho fungovanie. Je garantom vydaných štandardov a plánuje rozpočet. Táto rola je unikátna a preto ju obhospodaruje práve jeden človek. Integračný architekt definuje metodiky a štandardy na úrovni softvéru a hardvéru. Táto pozícia je zdieľaná asi 3 ľuďmi. Analytik KCI identifikuje potreby vzniku nových služieb a dopady na tie existujúce. Definuje podobu rozhrania a preberá požiadavky na vznik nových služieb. Rola je zdieľaná asi 3 ľuďmi. Vývojár KCI uskutočňuje vývoj služieb na integračnej platforme, testuje aplikačné jednotky a kontroluje kvalitu kódu služby ak bola vyvíjaná mimo KCI. Pozícia je zdieľaná asi 3 ľuďmi. 22

23 Manažér kvality zodpovedá za existenciu všetkých testov u všetkých služieb. Spolupracuje na testoch v rámci projektu a zodpovedá za automatizované testovanie. Aplikačná podpora ako je z názvu zrejmé pracovníci vykonávajúci túto rolu zodpovedajú za riešenie chýb a problémov so službami. Release manažér je zodpovedný za dodanie releasu k migrácii a za plánovanie releasu. Táto rola je taktiež unikátna. Správca depozitára služieb zodpovedá za procesy v rámci depozitára za vstupy do neho zadaných a definuje požadované externé vstupy pre celú fázu životného cyklu služby. Manažér SLA a kapacít integračnej platformy má na starosť prevzatie požiadaviek na kapacity volania služieb od konzumentov, prevádza vyhodnocovanie SLA a požadovaných kapacít, dáva podnety na navýšenie výkonu integračnej platformy, rola je tiež unikátna. patria: Zodpovednosť KCI a jeho právomoci sú rôzne a je ich veľa. Medzi tie najdôležitejšie Stanovenie a údržba štandardov pre integráciu systému v rámci spoločnosti a so systémami obchodných partnerov Riadenie kvality a konzistencie integračnej architektúry a jej súlad so stratégiou IT architektúry Riadenie návrhu a realizácie služieb Riadenie kvality, konzistencie, transparentnosti a neduplicity služieb Evidencia a zaistenie viditeľnosti služieb pre konzumentov Zaistenie robustnosti a stability integračnej platformy Podpora riešenia problémov so službami Plánovanie a riadenie investícií do integračnej platformy (Computerworld, 9/2011) Pre riadenie SOA je existencia kompetenčného centra dôležitá, ale väčšinou sa snahy o jeho zavedenie stretávajú s nepochopením a odmietavým prístupom a to z dôvodu, že KCI nemá obchodný prípad, je jasné že vytvorenie nového oddelenia je finančne náročné, ale v porovnaní s výnosmi, ktoré by SOA mohla priniesť sú zanedbateľné a centrum by mohlo mať veľký vplyv na chod celej spoločnosti, táto obava ma čisto politický charakter. 23

24 Priebeh riadenia životného cyklu služieb je základným a hlavným procesom SOA. Životný cyklus začína identifikáciou vzniku jej potreby a končí dožitím, ktoré môže prebehnúť vypnutím alebo vyradením z prevádzky. Typicky sa životný cyklus delí na tri základné časti: definícia požiadaviek a analýza, návrh a vývoj, a prevádzkovanie. V rámci definície požiadaviek a analýzy je identifikovaná potreba zavedenia služby a prebieha analýza funkčnosti. Sú vypracované biznis procesy, ktoré službu využívajú. Vytvára sa príslušná dokumentácia a schvaľujú sa požiadavky na službu. Je potrebné zadať okrem funkčných požiadaviek aj tie nefunkčné ako sú doba odozvy a predpokladané zaťaženie. V druhej fáze návrhu a vývoja spolupracuje integračný architekt a analytici a spoločne identifikujú dopady na existujúce služby a systém. V tejto fáze dochádza k detailnému vypracovaniu služby a uzatváraní potrebných SLA. Nasleduje vývoj potrebných úprav a test implementovaných častí. V rámci prevádzky sa odovzdajú implementované zmeny do prevádzky. Preberie sa implementácia aj dokumentácia a prebehnú akceptačné testy. Vykonajú sa výkonnostné testy a služba ostáva monitorovaná až do jej vypnutia. Obrázok 3-1 Životný cyklus riadenia služieb Identifikácia Analýza Zmeny v biznis Schválenie Vytvorenie potreby novej funkčnosti procesoch biznis a podanie služby vlastníkmi zadania Definovanie požiadaviek a analýza Testovanie Implementácia Dokumentovan Návrh Identifikácia ie implementačný dopadu do a uzatvorenie ch zmien systému Návrh a vývoj Preberanie do prevádzky Akceptačné Preberanie testy implementácie Konfigurácia infraštruktúry Konfigurácia a nasadenie služby Prevádzkové a monitorovaci e služby Prevádzkovanie Zdroj:Computerworld 9/11 24

25 Popis životných služieb je dlhodobý proces, jeho riadenie je zložité a vyžaduje si vysokú mieru spolupráce a komunikácie. V každej fáze sa využívajú rôzne nástroje, a preto je viac ako vhodné zaviesť nástroj na evidenciu. Tento evidenčný nástroj sa typicky nazýva Service alebo SOA Repository. Umožňuje evidovať služby a ich artefakty rôzneho druhu, následne umožňuje pridať službám parametre a triediť ich. Tento nástroj využívajú rôzny aktéri procesu životného cyklu riadenia služieb: Biznis architekti a analytici Integrační architekti Návrhári a vývojári Prevádzkari SOA Repository je neodmysliteľnou častou SOA Governance. Potreba sa ukazuje už pri 50 a viac službách v organizácii. (Computerworld,10/ 2011) 3.7 Webové služby Pre webové služby existuje takisto veľmi veľa definícií vybrali sme si tieto tri.,,webová služba je jednou z možností realizácie služby v architektúre SOA. Webová služba je softvérový systém identifikovaný jednotným identifikátorom URI (Uniform Resource Identifier). Ktorého verejné interfejsy a väzby sú definované a opísané pomocou XML a jeho definícia môže byť objavená (nájdená) inými softvérovými systémami, ktoré potom môžu spolupracovať s WS spôsobom predpísaným v jej definícii pomocou XML správ prenášaných internetovými protokolmi. (Automa, 2008 s ) Webová služba je softwarový systém navrhnutý na podporu interakcie strojov cez počítačovú sieť. Poskytuje rozhranie, ktoré je strojovo spracovateľné (špecificky WSDL). Ostatné systémy interagujú s webovou službou spôsobom, ktorý je predpísaný ich opisom pomocou SOAP správ, typicky prenášaných prostredníctvom HTTP s XML serializáciou v spojení s inými webovými štandardmi. ( ),,Webová služba je softvérový modul dostupný zvyčajne prostredníctvom siete (napr. Internet), ktorý vykonáva úlohy, rieši problémy, riadi transakcie v mene používateľa alebo aplikácie. Dôležitou vlastnosťou webovej služby je samoopisnosť (samotná webová služba obsahuje informácie, ktoré ju opisujú). Webové služby tvoria infraštruktúru distribuovaného 25

26 počítača, pozostávajúcu z viacerých rôznych navzájom komunikujúcich aplikačných modulov, virtuálne predstavujúc jeden logicky systém. (Papazoglou, 2008, s. 54) Webová služba môže byť 1. Nezávislá obchodná úloh, ako napríklad výber peňazí alebo vklad 2. Úplný obchodný proces ako automatizovaná platba 3. Aplikácia ako životné poistenie 4. služba, ktorá sprístupňuje zdroj, sprístupnenie databázy Dlhodobým cieľom technológií webových služieb je umožniť existenciu distrubovaných aplikácií, ktoré sa môžu dynamicky skladať podľa meniacich sa potrieb. (Papazoglou, 2008) Obrázok 3: Ukážka komunikácie Obrázok SOAP, 3-2 Ukážka UDDI,WSDL komunikácie SOAP, UDDI,WSDL klient využívajúci hľadanie služby webovú službu priamy prístup k popisu služby SOAP komunikácia pomocou XML správ Webová služba zverejnený popis rozhrania služby UDDI register odkaz na popis služby WSDL Zdroj: Webové služby umožňujú jednoduchú komunikáciu medzi aplikáciami v heterogénnom prostredí, pretože komunikácia je založená na platforme nezávislých štandardoch. Aplikácie si medzi sebou posielajú XML správy. 26

27 Celá technológia webových služieb je založená na troch častiach: SOAP Simple Object Access Protocol je protokol používaný na komunikáciu WSDL Web Services Description Language štandardizovaný formát pre popis rozhrania webovej služby UDDI Universal Description, Discovery and Integration štandardný mechanizmus na registráciu a vyhľadávanie webových služieb ( ) WSDL WSDL špecifikuje formát každej SOAP správy. WSDL interfejsy sú vytvorené každou webovou službou a môžu byť zdieľané s cieľom umožniť dynamickú väzbu. Prostredníctvom dynamickej väzby môžu nové webové služby komunikovať s novými pridanými službami bez akéhokoľvek dodatočného programovania alebo zmeny konfigurácie. (www2.fiit.stuba.sk, ) Obrázok 3-3 Definícia WSDL umožňuje voľné spojenie medzi službami Vyhovuje formát správ definovanom v Vyhovuje formát správ definovanom v služba A služba B Definícia WSDL pre službu B Definícia WSDL pre službu A Zdroj: Erl, 2009 s. 116 Jazyk WSDL slúži k opísaniu sieťových služieb ako množiny koncových bodov spracovávajúcich správy. Operácie a správy sú opisované na abstraktnej úrovni a až potom sú zviazané s konkrétnym sieťovým protokolom a dátovým formátom. To umožňuje ľahké vytvorenie popisu rozhrania, ktoré ponúka jednu službu viacerými spôsobmi. V praxi WSDL 27

28 popisy najčastejšie opisujú služby, ktoré si posielajú správy pomocou formátu SOAP a protokolu HTTP. WSDL vzniklo ako spoločná iniciatíva firiem Microsoft a IBM, ktoré si uvedomili potrebu zjednotenia jazyka používaného pre popis rozhraní webových služieb. Nadväzuje tak na predchádzajúce aktivity, ako na jazyky NASSL (Network Accessable Service Specification Language), SCL (SOAP Contact Language) a SDL (Service Description Language). WSDL súbor s definíciou rozhrania služby je XML dokument. Skladá sa hlavne z nasledovných elementov, ktoré tvoria základné časti každého WSDL popisu Types - Na uľahčenie vyhľadávania webových služieb bol vytvorený štandard UDDI. Tento štandard umožňuje webovým službám dynamicky vyhľadávať ďalšie webové služby. Webové služby môžu jednoducho vyhľadať a použiť nové služby v run-time bez ľudského zásahu. Message - Definuje formát predávaných správ pomocou skôr definovaných dátových typov. Správy fungujú ako vstupné alebo výstupné štruktúry pre operácie. Každá správa sa môže skladať z niekoľkých logických častí s vlastným dátovým typom. Pri použití SOAP-u pre RPC zodpovedá jedna časť správy jednému parametru vzdialenej metódy. Operation Abstraktná definícia operácií, ktoré sú službou podporované. U operácie sa definujú, aké má vstupy a výstupy. Vstup a výstup je opísaný už existujúcou správou (message). V SOAP RPC modelu zodpovedá operácii metóda. PortType Združuje dokopy niekoľko operácií. Service Združuje niekoľko koncových bodov (portov) do jednej služby ( ) Abstraktný popis WSDL porttype(alebo interface) -operation Mesagge 28

29 Konkrétny popis Binding Port(alebo koncový bod) Service SOAP Komunikácia medzi webovými službami je založená na správach, to znamená, že vybraný systém výmeny správ musí byť štandardizovaný, aby všetky služby bez ohľadu na pôvod, používali rovnaký formát a protokol prenosu. Prijatie správy službou je základnou akciou v architektúre SOA a jedinou akciou ktorá zavádza servisne orientovanú automatizáciu. SOAP je protokol pre posielanie správ XML a je základom webových služieb. UDDI a WSDL štandardy vznikli až neskôr a ďalej rozširujú jeho možnosti použitia. SOAP umožňuje zasielanie XML správ medzi aplikáciami, správa je jednosmerný prenos informácie od odosielateľa k prijímateľovi, ale vďaka kombinácii niekoľkých správ môžeme pomocou SOAP-u ľahko implementovať bežné komunikačné scenáre. Najčastejšie sa SOAP používa ako náhrada vzdialeného volania procedúr. Jedna aplikácia pošle v XML správe požiadavku druhej aplikácii, tá požiadavku obslúži a výsledok zašle ako druhú správu späť pôvodnému iniciátorovi komunikácie. V tomto prípade druhá aplikácia splnila istú službu prvej. Pri tomto použití SOAP - je spomínaná služba vyvolaná webovým serverom, ktorý čaká na požiadavky klientova v okamihu, kedy cez HTTP príde soap-ová správa, spustí službu (webovú službu) a predá jej požiadavku. Výsledok služby je potom predaný späť klientovi ako odpoveď. ( ) Každá správa je zabalená do obalu, ktorý je známy ako obálka. Každá správa môže obsahovať hlavičku, oblasť určenú pre uchovanie metadát. Obsah správy je uložený v tele správy, ktorá je bežne formátovaná ako XML. Základnou vlastnosťou komunikácie SOAP použitú v servisne orientovaných architektúrach je dôraz na tvorbu správ, ktoré budú inteligentné a samostatné. Nezávislosť správ sa implementuje pomocou blokov hlavičiek, pomocných metadát uložených, v hlavičke obálky. 29

30 Základná kostra SOAP-u vyzerá takto <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header>... </soap:header> <soap:body>... <soap:fault>... </soap:fault> </soap:body> </soap:envelope> Správy SOAP môžu obsahovať veľké množstvo pomocných informácií, ktoré súvisia s doručením a spracovaním obsahu. Bloky hlavičiek je možné vybaviť napríklad týmito vlastnosťami: Inštrukcie pre spracovanie, ktoré môžu spúšťať sprostredkovatelia alebo koneční príjemcovia Informácie o smerovaní alebo priebehu práce spojené s danou správou Bezpečnostné opatrenia implementované v správe Pravidlá spoľahlivosti týkajúce sa doručenia správy Informácie o kontexte a správe transakcií Informácie o vzájomných vzťahoch UDDI UDDI ponúka mechanizmy pre registrovanie, kategorizovanie a vyhľadávanie webových služieb. UDDI funguje ako veľký adresát, ktorý obsahuje informácie o subjektoch (firmách) a nimi poskytovaných služieb. Samotný register pracuje rovnako ako webová služba a komunikácia s ním opäť prebieha pomocou SOAP-u. UDDI register obsahuje nasledujúce štyri druhy entít: Podnikateľské entity (firmy) biznis entity 30

31 U každej firmy v registri sú zaznamenané základné údaje - ako názov, stručný popis a kontaktné údaje. Každej firme môžu byť priradené klasifikačné identifikátory, ktoré určujú oblasť ich podnikania a geografickú polohu. Služby - biznis service Ku každej firme sú v registri uložené zoznamy služieb, ktoré firma poskytuje. Každá služba je opäť opísaná a obsahuje zoznam šablón väzieb, ktoré ukazujú na technické údaje nutné pre využitie služby. Šablóny väzieb - binding template Šablóny opisujú, ako a kde je možné so službou komunikovať. Typicky je táto informácia opísaná odkazom na WSDL súbor s definíciou rozhrania služby. Každá šablóna okrem toho odkazuje na typ služby, ktorý implementuje. Typy služieb - service type Typ služby definuje abstraktnú službu. Funguje teda ako obdoba rozhrania, ktoré je známe napr. z Javy. Niekoľko firiem môže ponúkať rovnaký druh služby s rovnakým rozhraním, a teda aj typom služby. Typ služby je popísaný tzv. Technickým modelom (tmodel). Typická práca s UDDI prebieha tak, že vývojár prehľadáva register a nájde si službu, ktorú potrebuje. Získa pre ňu popis WSDL a môže ju začať rovno používať. Je nutné ešte dodať, že UDDI nemusí obsahovať iba popisy webových služieb prostredníctvom WSDL, možno do nej ukladať popisy služieb v ľubovoľnom formáte. Z dôvodu interoperability sa však spoločne s UDDI používa práve SOAP a WSDL. ( ). 3.8 BPEL Jazyk BPEL (Business Process Execution Language) disponuje jasne definovanou sadou aktivít, ktoré možno využiť pri modelovaní obchodných procesov určených k automatizovanému strojovému vykonávanie. Je veľmi podobný tradičným programovacím jazykom, obsahuje aktivity vetvenie, slučky, priradenie premenné, volanie služby, vyvolanie výnimky a pod Tieto aktivity tak umožňujú konštrukciu ľubovoľného procesu. BPEL je dnes ustálenú definíciou, ktorú vzala pod svoje krídla štandardizačnej organizácie OASIS a vedie BPEL ako štandard pre popis interakcií medzi (webovými) službami. Preto tiež jeho plný názov znie WS-BPEL (Web Services Business Process Execution Language). 31

32 Hovorí, že vzťahy medzi službami možno opísať pomocou tzv obchodného procesu (business process). Obchodný proces je mapa aktivít, ktoré reprezentujú rôzne operácie, z ktorých najdôležitejšie je práve volanie rôznych služieb. Proces v poňatí štandardu WS-BPEL opisuje postupnosť a podmienky volanie služieb v servisne orientovanej architektúre (SOA) známe aj ako tzv orchestrácie služieb. Cez túto zložitú definíciu sa jazyk BPEL výborne hodí k jednoznačnému popisu firemných procesov, podľa ktorého možno procesy následne strojovo vykonávať. Hlavné vlastnosti a ciele BPEL: Definuje obchodné procesy, ktoré volajú externé služby pomocou webových služieb a zároveň vystavujú svoje rozhrania ako (webovú) službu. Samotný obchodný proces sa tak stáva službou. Tak možno skladať procesy do väčších celkov. Definuje obchodný proces pomocou jazyka založeného na štandarde XML. BPEL nedefinuje grafické znázornenie procesov, ale štandardizuje jeho XML definíciu. Poskytuje funkcie pre manipuláciu s dátami, umožňuje definovať procesné premenné a pomocou týchto dát ovplyvňovať beh procesu. Podporuje riadenie životného cyklu obchodného procesu. Proces je možné spustiť, predčasne ukončiť, pozastaviť, znovu spustiť, a pod. Podporuje long-running transakčného modelu, ktorý umožňuje definíciu hraníc transakcie a kompenzačných akcií pri neúspešnom dokončení transakcie. Používa webové služby pre dekompozíciu a skladanie obchodných procesov. Je postavený na štandardoch webových služieb. Podporuje riadenie obchodných procesov udalosťami. ( ) Ako ukážku BPEL procesu môžeme použiť náš, ktorý sa nachádza v praktickej časti práce. 32

33 4 ANALÝZA VYUŽITIA SOA PRI NÁVRHU, REALIZÁCII A RIADENÍ PODNIKOVÝCH INFORMAČNÝCH SYSTÉMOV V tejto kapitole sa práca zaoberá prístupmi k integrácii a podnikov zbernicou ESB. V podkapitole 4.4 je rozpracovaný príklad použitia servisne orientovanej architektúry. 4.1 Prístupy k integrácii Najjednoduchším prípadom integrácie je priama väzba medzi dvoma aplikáciami, ktorá sa tiež označuje ako bod bod integrácie (point to point integrácia).pri takomto riešení musíme zaistiť, aby aplikácie riadila pracovný tok a zabezpečila transformáciu správy do podoby, ktorej rozumie cieľová aplikácie. Transformácia môže byť tiež vykonaná až cieľovú aplikáciou. V oboch prípadoch musíme do aplikácií zahrnúť znalosť o aplikácii druhej. Rozhranie cieľových aplikácií je často realizované pomocou aplikačných adaptérov. Bod - bod integrácie vedie k tzv "špagetovej integrácii", kedy vzniká veľké "klbko väzieb" medzi jednotlivými aplikáciami. Riešením je zapojenie sprostredkovateľa, ktorý zaisťuje integráciu. Takýto koncept sa označuje aj ako hub and spoke. Na sprostredkovateľov (tzv. integračný server, integračné broker) sú prenášané požiadavky na zabezpečenie transformácie správ, riadenie komunikácie a riadenia pracovného toku. Koncept umožňuje minimalizovať počet väzieb medzi aplikáciami a centrálne riadiť pracovný tok. Zdrojové aplikácie potom nemusia nič vedieť o požiadavkách cieľových aplikácií. Integračný broker často disponuje konektormi, ktorými je zaistený prístup k vybraným aplikačným balíkom, k technológii služieb a dátovým zdrojom. V prípade veľkého počtu integrovaných aplikácií môže dôjsť k zahlteniu centrálneho uzla. Možným riešením v prípade, kedy je možné vystaviť aplikačnú a biznis logiku ako služby, je podniková zbernica služieb (ESB - Enterprise Service Bus). Tá umožňuje vytvoriť vhodné prostredie, v ktorom integrované služby môžu byť prevádzkované na ľubovoľnom uzly systému. (Pour, a iní, 2009, s. 368) 4.2 Enterprise Service Bus Enterprise Service Bus je koncept a voľba ako implementovať servisne orientované architektúry. Hlavným cieľom Enterprise Service Bus je poskytovať virtualizáciu podnikových zdrojov, ktoré umožňujú obchodnej logike podniku byť rozvíjaná a spravovaná 33

34 nezávisle na infraštruktúre, sieti a poskytovaní týchto podnikateľských služieb. Zdroje v ESB sú modelované ako služby, ktoré ponúkajú jednu alebo viac obchodných operácií. (Endrei, 2004) Enteprise Service Bus (ESB) je nový druh middleware podporujúceho servisne orientované interakcie medzi podnikovými aplikáciami. Podobne ako hardvérová zbernica na PC, ESB inteligentne smeruje dáta tečúce medzi podnikovými systémami, prispôsobujúc a transformujúc ich podľa požiadaviek systémov. (efocus, 2006) Obrázok 4-1 Enterprise Service Bus Enterprise Service Bus Odberatelia služieb Transformuje správu medzi odberateľom a poskytovateľom Usmerňuje požiadavky Poskytovatelia služieb Zdroj:(Endrei,2004, s.34) ESB ako jeden zo základných stavebných prvkov servisne orientovanej integrácie umožní prejsť postupne na servisne orientovanú architektúru a využiť možnosti tejto konfigurovateľnej integračnej vrstvy. Koncept ESB prináša voľnú väzbu aj na operácie a metódy aplikácií, ktoré spolu s dátami vytvárajú služby. ESB sprostredkúva komunikáciu medzi službami (integrovanými aplikáciami) prostredníctvom správ. ESB zabezpečuje prenos správ, spoľahlivé doručenie správ, transformáciu správ a ich smerovanie. ( ) 34

35 Obrázok 4-2 Integrácia služieb bez použitia ESB služba služba služba služba služba služba Obrázok 4-3 Integrácia služieb s pomocou ESB služba služba služba Enterprise Service Bus služba služba služba Zdroj: Vlastné spracovanie Každé moderné ESB musia riešiť tieto problémy: Voľné spojenie nie je dosiahnuté s WSDL alebo webovou službou samostatne. Robustnejšie riešenie je dosiahnuté využitím sprostredkovacej vrstvy medzi klientmi a poskytovateľmi služieb. Takáto sprostredkovacia vrstva by mala byť tiež schopná premostiť protokoly, formáty správa zabezpečovacie technológie. 35

36 Transparentnosť pripojenia je stratégia ukrývania fyzického umiestnenia koncových bodov služby pre klientov služby. V ideálnom prípade klienti služieb by mali vedieť o jedinom, logickom stroji a mene portu pre každú službu. Klient by nemal poznať skutočné koncové body služby. Mediácia - sprostredkovanie. ESB je medzi vrstva, ktorá je umiestnená práve medzi klientmi a poskytovateľmi služieb. Táto vrstva poskytuje výborné miesto pre zvyšovanie pridanej hodnoty pre architektúru, bez toho, aby sa zmenili aplikácie na oboch koncoch. Transformácia schémy Webové služby, ktoré sú publikované na servisnej zbernici môžu využiť inú schému ako je pôvodná schéma poskytovateľa služby, ktorého reprezentujú Skladanie služieb. ESB môže pôsobiť ako fasáda a vykonáva rad volaní webových služieb, ktoré sa objavujú klientovi ako jediná služba. Skladanie služieb využíva tento model, ktorý volá viac volaní služieb v mene tzv. proxy služby a vracia jediný výsledok späť klientovi. Load Balancing - rozdeľovanie záťaže Vzhľadom k umiestneniu v akejkoľvek architektúre, ESB sa dobre hodí na rozloženie záťaže požiadaviek na viacej koncových bodov služby. Pri registrácii poskytovateľa služby je zvyčajne možné zadať zoznam koncových bodov služby kde je služba spustená. Je možné zmeniť tento zoznam, pridať alebo odobrať koncový bod služby, bez nutnosti reštartovať ESB server. Presadzovanie Bezpečnosti bezpečnosť by sa mala presadzovať centralizovaným spôsobom, kedykoľvek je to možné. Toto umožní vyššiu úroveň štandardizácie a kontroly v bezpečnostných otázkach. Monitorovanie ESB hrá samozrejme dôležitú úlohu pre zavedenie SOA. Preto je potrebné mať silný spôsob sledovania stavu prevádzky na ESB a to v aktívnom a aj reaktívnom režime. Schopnosť aktívneho zobrazenia výkonnostných ukazovateľov na ESB môže pomôcť vyladiť výkon ESB. Monitorovanie výkonnosti môže ďalej pomôcť plánovaniu zvýšenia kapacity. Reaktívne monitorovanie umožňuje nastaviť upozornenia na konkrétne podmienky a situácie. Napríklad, ak konkrétna služba nie je vykonaná rámci definovaného času, ESB by malo mať možnosť poslať upozornenie tak, že administrátor môže začať analyzovať dôvody problému. Konfigurácia vs. Programovanie Moderné riešenie ESB by malo byť konfiguračne - založené, nie závislé od programovania. Tu neexistuje nič na kompilovanie a nasadzovanie. 36

37 Jednoducho sa zmení konfigurácia a aktivujú sa tieto zmeny. ( ) 4.3 Websphere Integration Developer WebSphere Integration Developer predstavuje jednoducho použiteľné prostredie na tvorbu obsahu pre komplexnú integráciu architektúry SOA. WebSphere Integration Developer zjednodušuje integráciu a urýchľuje implementáciu SOA interpretáciou prostriedkov IT ako komponentov služieb za účelom opätovného použitia a zvýšenia efektivity. Predstavuje nástroj založený na platforme Eclipse, ktorý umožňuje tvorbu riešení BPM a integračných riešení na základe architektúry SOA v produktoch WebSphere Process Server, WebSphere ESB a WebSphere Adapters. Websphere Integration Developer: Zjednodušuje integráciu prostredníctvom funkcií, ktoré urýchľujú implementáciu SOA. Jednoduchšia tvorba obsahu, ktorá urýchľuje vývoj riešení, vrátane rozšírenej podpory mediačných nástrojov. Zostavujte procesy a integračné riešenia intuitívnym presúvaním pomocou myši na vizuálne definovanie postupnosti a toku podnikových procesov. Integruje testovanie, ladenie a nasadenie pri vývoji riešení. Umožňuje na podnik zameraný vývoj, pričom sa plne integruje s produktom WebSphere Business Modeler na importovanie modelov za účelom rýchlej implementácie. Podporuje generovanie užívateľských rozhraní pre ľudskú interakciu, ktoré je možné ľahko prispôsobiť. Na modelový príklad využitia architektúry SOA v praxi sme použili Websphere Integration Developer vo verzii 7.0 a Websphere Process Server taktiež vo verzii 7.0, je potrebné aby sa tieto verzie zhodovali, inak by nebolo možné spustiť ich spoločne a je potrebné nainštalovať ich v správnom poradí inak nám to nebude fungovať. ( 4.4 Príklad použitia servisne orientovanej architektúry Príklad bude predstavovať jednoduchý obchod. Vytvoríme služby umožňujúce pracovať so skladom, vytvárať objednávky na tovar a registrovať nových zákazníkov. 37

38 Prvým krokom bude vytvoriť Integračné riešenie (Integration solution) s názvom ObchodSolution. Tento projekt bude obsahovať všetky ďalšie (pod)projekty knižnice, jednotlivé služby ako aj vytvorené procesy. Každá služba pozostáva z dvoch častí: rozhrania a implementácie. Rozhranie opisuje, čo dokáže služba robiť (opisuje možné operácie), zatiaľ čo implementácia zabezpečuje vlastnú funkcionalitu. Rozhranie bude vždy oddelené v samostatnom projekte (typu knižnica library). Takéto oddelenie je dôležité z dôvodu použitia služby v ďalších projektoch Služba práca so skladom Ako prvú vytvoríme službu umožňujúcu prácu so skladom. Ako už bolo spomenuté, rozhranie služby bude vždy definované v samostatnom projekte typu knižnica. Vytvoríme knižnicu SkladServiceLibrary, ktorá bude obsahovať rozhranie SkladInterface s potrebnými operáciami. Obrázok 4-4 Rozhranie Skladu Zdroj: Vlastné spracovanie Tu sme si vytvorili tri operácie. Prvou je zistenie, či je tovar na sklade. Ako vstup operácie je potrebné špecifikovať kód Tovaru. Výstupom operácie je odpoveď áno alebo nie. Druhá operácia slúži na zistenie množstva tovaru na sklade. Výstupom je číselná hodnota. Posledná operácia je pridanie tovaru na sklad, kde na vstupoch sú kód a množstvo Tovaru. Výstup tu nemáme. Následne je potrebné vytvoriť implementáciu definovanej služby. Implementácia sa bude nachádzať v projekte typu meditation module. Projekty takéhoto typu je možné nasadiť na ESB alebo ProcessServer a tým danú službu sprístupniť. Vytvoríme meditation module SkladService používajúci knižnicu SkladServiceLibrary. SkladService bude obsahovať implementáciu rozhrania definovaného v knižnici SkladServiceLibrary. Vzor pre implementáciu získame 38

39 vygenerovaním Java komponenty SkladServiceImpl implementujúcej rozhranie SkladInterface. Trieda SkladServiceImplImpl obsahuje nasledovný kód: import java.util.hashmap public class SkladServiceImplImpl { } private static Map<String, Integer> sklad = new HashMap<String, Integer>(); static { sklad.put("ram1024mb", 5); sklad.put("hd100gb", 3); } public Boolean jetovarnasklade(string kodtovaru) { if (sklad.get(kodtovaru)!=null && sklad.get(kodtovaru).intvalue() > 0) return true; return false; } public Integer zistimnozstvotovarunasklade(string kodtovaru) { if (sklad.get(kodtovaru)!=null) return sklad.get(kodtovaru); return 0; } public void pridajtovarnasklad(string kodtovaru, Integer mnozstvotovaru) { sklad.put(kodtovaru, mnozstvotovaru); } Jednoduchá implementácia skladu je vytvorená použitím hash tabuľky. Pre každú položku skladu je možné evidovať jej názov a počet kusov na sklade. Trieda umožňuje ukladať tovar na sklad a zisťovať stav tovaru na sklade. Z dôvodu zjednodušenia testovania je sklad automaticky naplnený dvomi tovarmi - RAM1024MB (päť kusov) a HD100GB (tri kusy). Aby bolo možné vytvorenú službu použiť (a otestovať), je potrebné ju zverejniť. Službu je možné zverejniť kliknutím na triedu SkladServiceImpl a vybraním možnosti Generate Export. 39

40 Obrázok 4-5 Zverejnenie služby Zdroj: Vlastné spracovanie Teraz je možné komponent otestovať kliknutím na SkladInterfaceExport1 a voľbou Test Component. Do tabuľky na pravo zadáme do položky kód tovaru HD100GB. Obrázok 4-6 Testovanie kompomentu Zdroj: Vlastné spracovanie Spustíme službu na Webspehre Process Server a ako odpoveď dostaneme, že premenná výsledok je áno (true.) Obrázok 4-7 Testovanie komponentu-výsledok Zdroj: Vlastné spracovanie Služba práca s objednávkami Rovnakým spôsobom je možné vytvoriť službu na prácu s objednávkami. Rozhranie ObjednavkyInterface bude definovať dve operáciu vytvorobjednavku a zististavobjednavky. Vstupom prvej operácie sú kód Tovaru, kód Zákazníka a množstvo tovaru. Výstupom je číslo objednávky. Vstupom operácie zististavobjednavky je kód objednávky a výstupom je jej stav. 40

41 Obrázok 4-8 Rozhranie Objednavky Zdroj: Vlastné spracovanie Implementačná trieda ObjednavkyServiceImplImpl vyzerá nasledovne: import java.util.hashmap public class ObjednavkyServiceImplImpl { class Objednavka { String kodtovaru; String kodzakaznika; Integer mnozstvotovaru; String stav; } private static Map<String, Objednavka> objednavky = new HashMap<String, Objednavka>(); public String vytvorobjednavku(string kodtovaru, String kodzakaznika, Integer mnozstvotovaru) { Objednavka o = new Objednavka(); o.kodtovaru = kodtovaru; o.kodzakaznika = kodzakaznika; o.mnozstvotovaru = mnozstvotovaru; o.stav = "nova"; String kodobjednavky = String.valueOf(objednavky.size()); objednavky.put(kodobjednavky, o); return kodobjednavky; } } public String zististavobjednavky(string kodobjednavky) { Objednavka o = objednavky.get(kodobjednavky); return o.stav; } Implementácia podobne ako pri sklade využíva hash mapu na ukladanie existujúcich objednávok. V súlade s implementovaným rozhraním sú definované metódy umožňujúce vytvorenie objednávky a zistenie stavu objednávky. 41

42 4.4.3 Služba práca so zákazníkmi Podobne ako pri predošlých dvoch službách je definované rozhranie a implementácia. Na obrázku ZakazniciInterface máme zobrazené rozhranie s 2 operáciami: overenie, či je zákazník registrovaný a registrovanie zákazníka. Pri registrovaní zákazníka sa očakávajú vstupy meno, adresa a DIČ. Na výstupe je kód zákazníka. Obrázok 4-9 Rozhranie Zakaznici Zdroj: Vlastné spracovanie Služba umožňujúca prácu so zákazníkmi je implementovaná nasledovnou triedou. Je možné registrovať nových zákazníkov, alebo dohľadať existujúcich. import java.util.hashmap public class ZakazniciServiceImplImpl { class Zakaznik { String meno; String adresa; String dicrc; } private static Map<String, Zakaznik> zakaznici = new HashMap<String, Zakaznik>(); public Boolean jezakaznikregistrovany(string menozakaznika) { for (String k : zakaznici.keyset()) { Zakaznik z = zakaznici.get(k); if (menozakaznika.equals(z.meno)) { return true; } } return false; } public String registrujzakaznika(string meno, String adresa, String dicrc) { Zakaznik z = new Zakaznik(); z.meno = meno; z.adresa = adresa; 42

43 z.dicrc = dicrc; String kodzakaznika = String.valueOf(zakaznici.size()); zakaznici.put(kodzakaznika, z); return kodzakaznika; } public String zistikodzakaznika(string menozakaznika) { for (String k : zakaznici.keyset()) { Zakaznik z = zakaznici.get(k); if (menozakaznika.equals(z.meno)) { return k; } } return null; } } Proces vytvorenia objednávky Teraz už máme vytvorené tri služby, každá má vlastné rozhranie (Interface) a sú pripravené na použitie. V ďalšom kroku vytvoríme proces, ktorý bude znázorňovať použitie pripravených služieb. Proces bude definovaný v projekte typu modul. Vytvoríme modul ObjednavkaModul používajúci predtým vytvorené knižnice. Vďaka týmto knižniciam bude modul presne vedieť, ako sú pripravené služby definované. Vytváraný proces bude umožňovať vytváranie nových objednávok. Objednávka je určená kódom tovaru, názvom zákazníka a množstvom tovaru. Obrázok 4-10 Biznis objekt Objednávka Zdroj: Vlastné spracovanie Vytvoríme biznis objekt s názvom Objednávka, ktorý bude predstavovať vyššie opísanú objednávku. Tento objekt bude slúžiť na komunikáciu s vytváraným procesom. 43

44 Samotný proces sa bude taktiež javiť ako služba bude možné ho zavolať, poslať mu určité vstupy a očakávať výstupy. Aby bolo možné s procesom pracovať ako so službou, je potrebné definovať rozhranie opisujúce službu procesu. Obrázok 4-11 Rozhranie Objednavky Zdroj: Vlastné spracovanie Rozhranie NovaObjednavkaInterface definuje operáciu novaobjednavka. Na vstupe sa očakáva biznis objekt Objednávka, na výstupe je reťazec cisloobjednávky. V ďalšom kroku je možné pristúpiť na samotné vytvorenie procesu. Vytvoríme biznis proces NovaObjednavkaProcess implementujúci rozhranie NovaObjednavkaInterface. Skôr, ako zadefinujeme samotný proces, je potrebné definovať závislosti procesu na použitých službách v našom prípade sú to služby skladu, zákazníkov a objednávok. Tieto závislosti je možné definovať pretiahnutím rozhraní služieb do diagramu procesu. Ak sú tieto rozhrania správne pridané, budú sa zobrazovať v pravom panely v položke Reference Partners. Obrázok 4-12 Objednávka proces a využívanie rozhraní Zdroj: Vlastné spracovanie 44

45 Obrázok 4-13 ReferencePartners Zdroj: Vlastné spracovanie Nakoniec je možné definovať logiku procesu. Proces je zapísaný pomocou BPEL štandardu. WebSphere Integration Developer však umožňuje vytvoriť celý proces graficky bez potreby poznania tohto jazyka. Po spustení procesu sa na základe objednávky na vstupe najprv zistí, či je daný tovar na sklade (operácia jetovarnasklade). Táto operácia je uskutočnená práve volaním služby umožňujúcej prácu so skladom. Ak služba oznámi, že tovar nie je na sklade, proces vráti chybu oznamujúcu, že tovar nie je na sklade. Z dôvodu jednoduchosti nie je chyba predstavovaná samotným typom, ale je len oznámená v očakávanom návratovom type. Ak sa požadovaný tovar nachádza na sklade, proces pokračuje kontrolou dostatočného množstva tovaru na sklade. Zistenie množstva tovaru na sklade je opäť vykonané pomocou služby skladu (operácia zistimnozstvotovarunasklade). Pri nedostatku tovaru na sklade proces opäť vráti chybu, tentoraz oznamujúcu nedostatok tovaru na sklade. V prípade dostatočného množstva tovaru na sklade sa nakoniec zistí, či je daný zákazník registrovaný (operácia jezakaznikregistrovany). Operácie týkajúce sa práce so zákazníkmi sú definované v službe umožňujúcej prácu so zákazníkmi. Proces teda uskutoční zistenie registrácie zákazníka pomocou služby zákazníkov. Ak zákazník nie je registrovaný, tak sa zaregistruje (operácia registrujzakaznika). Ak je registrovaný, postúpi sa na konečné vytvorenie objednávky (operácia vytvorobjednavku). Objednávka je vytvorená pomocou služby objednávok. Výsledkom procesu je číslo objednávky vrátené službou vytvárania objednávok. 45

46 Obrázok 4-14 BPEL proces Zdroj: Vlastné spracovanie Na začiatku sú všetky databázy prázdne, len na sklade sú dva tovary: RAM1024MB (päť kusov) a HD100GB (tri kusy). Ak spustíme proces s korektným kódom tovaru (RAM1024MB alebo HD100GB) a korektným množstvom (menej ako päť resp. (menej ako tri kusy), tak sa automaticky vytvorí daný zákazník a nakoniec aj nová objednávka. Pri opakovanom volaní s rovnakým zákazníkom sa už ďalší zákazník nevytvorí, vznikne len nová objednávka. Keďže všetky databázy sú implementované len pomocou hash mapy v pamäti, pri najbližšom reštarte servera sa vymažú na pôvodné hodnoty (všetky až na sklad budú prázdne). Zaujímavosťou je, že aj samotný proces je možné zverejniť ako službu, a tým pádom použiť v ďalších procesoch. 46

47 Teraz môžeme testovať na úvod si zadáme ako vstupné hodnoty, tie, ktoré sú uvedené na obrázku nižšie. Obrázok 4-15 Zadávanie vstupných hodnôt do procesu Zdroj: Vlastné spracovanie Keďže sme si ako vstupné hodnoty vybrali existujúci kód tovaru (HD100GB), tak by mal proces prejsť ku kontrole množstva tovaru. Množstvo tovaru ktoré sme zadali je jeden kus, na našom sklade sa nachádzajú tri kusy tohto tovaru, tak by mal proces pokračovať ďalej a registrovať zákazníka a vytvoriť kód objednávky. V prílohe 1 sa nachádza celý proces pri týchto vstupných parametroch, je tu možné vidieť volania a odpovede služieb, aj celé prostredie IBM Websphere Integration Developer vo verzi 7.0 Ako výsledok dostaneme nami požadovaný kód objednávky Obrázok 4-16 Požadovaný výstup testovania Zdroj: Vlastné spracovanie Na tomto jednoduchom príklade sme si ukázali ako funguje SOA architektúra v praxi. V našom modelovom príklade spolu komunikovali rôzne webové služby, toto je jedna z možností integrácie. Tieto webové služby by sa určite dali po určitých rozšíreniach použiť aj 47

48 v praxi na skutočný internetový obchod a následne by sa mohli použiť znovu ako hotové riešenie. Ale na ukážku fungujúcej SOA architektúry bol dostačujúci aj náš príklad. 48

49 ZÁVER Predmetom tejto bakalárskej práce boli Servisne orientované architektúry. Hlavným cieľom bolo opísať a analyzovať využitie Servisne orientovaných architektúr (SOA) v návrhu, realizácii, správe a riadení podnikových informačných systémov. Jedným z čiastkových cieľov tejto bakalárskej práce bolo vysvetliť Servisne orientované architektúry a pojmy s nimi spojené. Tomuto čiastkovému cieľu sme sa venovali v prvej a druhej kapitole práce. Ďalším čiastkovým cieľom bolo analyzovať možnosti využitia SOA, ktoré sme si rozobrali v štvrtej kapitole. Posledný čiastkový cieľ, ktorým malo byť prípadové využitie SOA v praxi, sme po dohode s vedúcim práce nahradili, a ukázali sme si vlastný príklad, založený na SOA architektúre, ktorý je spracovaný v kapitole štvrtej. Určite je ešte veľa vecí spojených so Servisne orientovanými architektúrami, ktorých sme sa mohli dotknúť, lebo téma Servisne orientované architektúry ma veľmi široký záber, a stále pribúdajú nové a nové veci s touto témou spojené. Táto práca poukazuje na hlavné výhody a taktiež nevýhody zavedenia SOA do podniku. Každý, kto plánuje zavedenie SOA, by si mal uvedomiť, že sa jedná o časovo a takisto aj finančne veľmi náročný projekt, ktorý však pri správnom zavedení a dodržaní správnych postupov prináša vytúžené ovocie. Prínosom tejto bakalárskej práce bola práca so softvérom IBM WEBSPEHERE INTEGRATION DEVELOPER. Na záver si dovoľujem uviesť, že sa domnievam, že hlavný cieľ a čiastkové ciele tejto bakalárskej práce sa mi podarilo naplniť v požadovanom rozsahu. 49

50 ZOZNAM POUŽITEJ LITERATÚRY 1. BASL, J. BLAŽÍČEK, R Podnikové informační systémy. Praha : Grada Publishing, a.s, ISBN BIELIKOVÁ, M. NÁVRAT, P Štúdie vybraných tém softvérového inžinierstva 3. Bratislava : Slovenská technická univerzita v Bratislave, ISBN EELES, P. CRISPPS, P Architektura softwaru. Brno : Computer Press, a.s, ISBN ENDREI, M. et al Patterns: Service-Oriented Architecture and Web Services. s.l. : International Business Machines Corporation, ISBN X. 5. ERL, T SOA Servisně orientovaná architektura Kompletní průvodce. Brno : Computer Press, a.s., ISBN HOLLEY, K. DR ARSJANANI, A SOA Questions Asked and Answered. Boston : Pearson Education, Inc., ISBN-13: HURWITZ, J. et al Service Oriented Architecture For Dummies, 2nd IBM Limited Edition. Indiana : Wiley Publishing, Inc., ISBN JOSUTTIS, N Soa in Practice. s.l. : O Reilly Media, Inc., ISBN-10: PAPAZOGLOU, M Web services: principles and technology. Essex : Pearson Education Limited, ISBN RÁBOVÁ, I Podnikové informační systémy a technologie jejich vývoje. Brno : Tribun EU, ISBN: ŘEPA, V Podnikové procesy Procesní řízení a modelování, 2., aktualizované a rozšířené vydání. Praha : Grada Publishing, a.s, ISBN STPEHEN, G. et al SOA Governance Governing Shared Services On-Premise and in the Cloud. Boston : Pearson Education, Inc, ISBN-13:

51 13. POUR, J., GÁLA, L. a ŠEDIVÁ, Z. 2009,. Podniková informatika (2., přepracované a aktualizované vydání). Praha : Grada Publishing, a.s., 2009,. s ISBN POUR, J., GÁLA, L.. a TOMAN, P. 2006,. Podniková informatika. Praha : Grada Publishing, a.s., 2006,. s ISBN MYERSON, J The Complete Book of Middleware. United States : Auerbach Publications, ISBN www2.fiit.stuba.sk [Online] www2.fiit.stuba.sk/~lhudec/sin/webove_sluzby_a_bezpecnost_1.ppt. 17. Automa , Computerworld. Šlefr, J efocus , [Online] [Online] Systémová Integrace. Rydzi, Daniel , [Online] [Online] [Dátum: ] ibm.com/software/products/sk/sk/wid/ [Online] architektura.pdf. 51

52 ZOZNAM OBRÁZKOV A TABULIEK Obrázok 2-1 Množina prístupov k integrácii Obrázok 3-1 Životný cyklus riadenia služieb Obrázok 3-2 Ukážka komunikácie SOAP, UDDI,WSDL Obrázok 3-3 Definícia WSDL umožňuje voľné spojenie medzi službami Obrázok 4-1 Enterprise Service Bus Obrázok 4-2 Integrácia služieb bez použitia ESB Obrázok 4-3 Integrácia služieb s pomocou ESB Obrázok 4-4 Rozhranie Skladu Obrázok 4-5 Zverejnenie služby Obrázok 4-6 Testovanie kompomentu Obrázok 4-7 Testovanie komponentu-výsledok Obrázok 4-8 Rozhranie Objednavky Obrázok 4-9 Rozhranie Zakaznici Obrázok 4-10 Biznis objekt Objednávka Obrázok 4-11 Rozhranie Objednavky Obrázok 4-12 Objednávka proces a využívanie rozhraní Obrázok 4-13 ReferencePartners Obrázok 4-14 BPEL proces Obrázok 4-15 Zadávanie vstupných hodnôt do procesu Obrázok 4-16 Požadovaný výstup testovania

53 PRÍLOHA 1 53