Univerzita Karlova Prahe Matem a ticko-fyzikálna fa kul ta DIPLOMOVÁ PRÁCA. Ludovít Dékány

Transcription

1 Univerzita Karlova Prahe Matem a ticko-fyzikálna fa kul ta DIPLOMOVÁ PRÁCA Ludovít Dékány Systémy založené na spolupráci služieb (SOA) používané mimo e-komerciu Katedra softwarového inžinierstva Vedúci diplomovej práce: Prof. RNDr. Jaroslav Král, DrSc. v Studijný program: Architektúra a princípy softwarových systémov

2 Pod'akovanie Chcel by som sa poďakovať Prof. RNDr. Jaroslavovi Královi, DrSc. za vedenie mojej diplomovej práce, za pomoc pri jej písaní a za poskytnutie hodnotných podkladov. Taktiež ďakujem spoločnosti Trask solutions s.r.o. za poskytnutie know-how ohl'adom praktického využitia servisne orientovanej architektúry. Prehlasujem, že som svoju diplomovú prácu napísal samostatne a výhradne s použitím citovaných prameňov. Súhlasím so zapožičaním práce. I ', I,,, <) I V Prahe dňa ~udovít Dékány

3 Obsah Pod'akovanie 2 Obsah 3 Zoznam obrázkov 5 Abstrakt 6 1. Úvod 7 2. Teória Služba (Service) Komponentová orientácia (Component orientation) 1 O 2.3. Kompozitná aplikácia (Composite application) 1 O 2.4. Objektová orientácia (Object orientation) Servisná orientácia (Service orientation) Previazanosť ( coupling) VS SO Objektovo orientované rozhranie Servisne orientované rozhranie Charakter vzájomného posielania správ Servisne orientovaná architektúra (Service oriented architecture) SOA O. SOA antipattems Webové služby (Web services) WSDL - Web Services Description Language SOAP - Simple Object Access Protocol UDDI - Universal Distribution, Discovery and Interoperability v Dalšie technológie webových služieb Manažment Bezpečnost' Portál Podpora procesov Transakčnosť Obsluha správ Metadáta ESB (Enterprise Service Bus) TIF Popis Pojmy História Na začiatku bol len jeden projekt Webové služby vs. messaging Prístup, k budovaniu integračnej infraštruktúry Uspech projektu To ostatnéje už história Architektúra Transportná vrstva Obsluha správ QoS Agenti Konektory Aktívne komponenty Nástroje

4 3.5. Definície služieb 3.6. Použitie 3.7. Predpoklady pre možné použitie Predpoklady kladené na backendy Predpoklady kladené nafrontendy Predpoklady kladené na dátové zdroje 3.8. Vlastnosti TIF Základné vlastnosti Ďalšie vlastnosti Charakteristiky ktoré TIF pine nespíňa 3.9. Porovnanie 4. Záver Litera túra

5 Zoznam obrázkov Obrázek I : Role viažuce sa k službe Obrázek 2: Služba ajej rozhranie Obrázek 3 : Komponent Obrázok 4 : Kompozitná aplikácia Obrázok 5 : Objektová orientácia Obrázok 6 : Servisná orientácia Obrázok 7 : Procedurálne orientované posielanie správ Obrázok 8 : Dokumentovo orientované posielanie správ Obrázok 9 : Technológie webových služieb Obrázok 1 O : Časti WSDL Obrázok 11 : WSDL Obrázok 12 : Použitie SOAP-u Obrázok 13 : Formát SOAP dokumentu Obrázok 14 : Použitie UDDI Obrázok 15 : Rozširujúce technológie webových služieb Obrázok 16 : Špecifikácie bezpečnosti webových služieb Obrázok 1 7 : ESB Obrázok 18: Príklad riešenia pomocou TIF-u Obrázok 19 : Zjednodušená architektúra TIP-u Obrázok 20 : Pripojenie komponentu k transportnej vrstve Obrázok 21 : Vytvorenie jednosmernej komunikácie Obrázok 22 : Vytvorenie obojsmemej komunikácie Obrázok 23 : Komunikácia vzdialených bodov Obrázok 24 : Prepojenie viacerých konzumentov Obrázok 25 : Príklad riešenia založenom na TIF-e Obrázok 26 : Správa vo formáte XML Obrázok 27 : TIF Load Balancing & Backup Obrázok 28: Zapojenie backendu pomocou agenta Obrázok 29: Zapojenie TIF Connector-u Obrázok 30: Zapojenie TIF BESIM-u Obrázok 31 : Zapojenie TIF Routera Obrázok 32 : Zapojenie TIF Inspectoru Obrázok 33 : Zapojenie TIF Publisheru Obrázok 34 : Použitie TIF B2B Gateway a TIF B2B Connectoru Obrázok 35 : Použitie TIF pre riešenie SOA Obrázok 36 : Použitie TIP pre riešenie EDA Obrázok 3 7 : Použitie TIF pre riešenie ETL Obrázok 38 : Použitie TIF pre riešenie B2B I I

6 Abstrakt Názov práce: Systémy založené na polupráci lužieb (SOA) pouzívané min10 e-komerciu Autor: J;udovít Dékány Katedra (ústav): Katedra softwarového inžinierstva Vedúci diplomovej práce: Prof RNDr. Jaroslav Král, DrSc. vedúceho: Abstrakt: Architektúra orientovaná na služby (SOA) je momentálne jedným z hlavných pojmov v oblasti informačných technológií. Princípy SOA sa postupne dostávajú do povedomia širokej IT verejnosti. Táto práca skúma fenomén SOA v prostredí mimo e komerciu a skladá sa z dvoch komplementárnych častí. Prvá časťje orientovaná teoreticky a zameriava sa na objasnenie základných princípov SOA, ukazuje možné prínosy nasadenia a taktiež rizika nesprávneho prístupu. Detailne sú rozobrané i aspekty základného vzoru SOA, ktorým je Enterprise Service Bus. Druhá časťje zameraná sk6r prakticky a skúma softwarový produkt Trask Integration Framework, ktorý vznikal v českých podmienkach, a aj napriek tomu je schopný konkurovat' produktom kategórie Enterprise Service Bus nadnárodných spoločností. Práca objasňuje históriu a pozadie tohto produktu a detailne skúma produkt z pohl'adu zvolených technológií, zvoleného prístupu a zvažuje tiež potenciálne prínosy a rizika pre zákazníka. Súčasťou práce je aj porovnanie produktu Tras k Integration Framework s dalšími produktmi dostupnými na trhu. Kl'účové slová: SOA, ESB, TIF Title: Service oriented architecture (SOA) used outside e-commerce Author: Eudovít Dékány Department: Department oj Software Engineering Supervisor: Prof RNDr. Jaroslav Král, DrSc. Supervisor's address: Jaroslav.Kral@mff cuni.cz Abstract: Service oriented architecture (SOA) is one oj the main buzzword used in information technology area these days. The princip/es of SOA are slowly getting well known to the wide IT community. This work explores the phenomenon ca/led SOA outside e commerce and is composed oj two complementary parts. The first part is theoretical/y oriented and is focused on clarifying the basic princip/es oj SOA; it shows the possible advantages oj using SOA and also the risks when it is used incorrectly. The aspects of the basic SOA pattern, Enterprise Service Bus, are investigated in detail. The second part is oriented practically and explores the software product Trask Integration Framework (TIF). Although it was developed in Czech environment it is able to compete with other Enterprise Service Bus productsfrom global companies. This workfocuses on history and background oj TIF; it also studies this product from the perspective oj chosen technologies and approach and describes the potential assets and risks for customer. Part oj the work is also a comparison oj the Trask Integration Framework product with other products common on market. Keywords: SOA, ESB, TIF - 6 -

7 1. Úvod Service Oriented Architecture (SOA) architektúra orientovaná na služby je podl'a viacerých IT společností kl'účovým paradigma súčasnosti ale aj budúcnosti. Spoločnosti ako IBM, Microsoft, BEA, Sanic a mnoho dalších sa preto predbiehajú v poskytnutí produktu, ktorý by umožnil efektívne, rýchle a jednoduché vytvorenie servi sne orientovanej architektúry. V čom je však čaro SOA, ktorému každý podlieha? Teoretická časť sa zameriava na popis servisne orientovanej architektúry použitej mimo e komerciu a jej porovnanie i prepojenie s objektovou orientáciou. Zároveň sa detailne popisujú webové služby, ktoré sú v dnešnej dobe často mylne považované práve za servisne orientovanú architektúru. Práca popisuje taktiež modelové vzorové situácie, ktorých je treba sa pri používaní servisne orientovanej architektúry vyvarovat'. V závere sa popisuje architektonický štýl Enterprise Service Bus. Tento pojem rozširuje servisne orientovanú architektúru, nad ktorou definuje sadu Quality of Services. Tento architektonický štýl v dnešnej <lobe implementujú vedúce spoločnosti IT charakteru. Praktická časť je zameraná na predstavenie produktu, ktorý dokáže konkurovat' drahým produktom vedúcich IT spoločností dnešného sveta a zároveň poskytovat' dostatočnú funkčnost' pre vytvorenie servisne orientovanej architektúry. Popisuje nielen samotnú architektúru produktu, ale aj príčiny vzniku a ideologické pochody pri návrhu a výbere konkrétnych technológií. Produkt je rozobraný nie len z perspektívy pozorovatel'a a užívatel'a, ale aj z perspektívy návrhára a vývojára, čím umožňuje čitatel'ovi nahliadnuť do výhod a nevýhod samotného produktu aj zo zákulisia

8 2. Teória 2.1. Služba (Service) Služba by sa dala definovat' ako určitá časť autonómneho softwaru implementujúca znovu použitel'nú funkčnost'. Služba má jasnú definíciu a je vol'ne dostupná určitej skupine spotrebitel'ov. Služba i jej spotrebitelia tvoria koncové body virtuálnej P2P (Pier to Pier) siete. V rámci tejto P2P siete majú služba i jej spotrebitelia ekvivalentné postavenie. [ 1] K pojmu služba sa viažu dva druhy rolí. Poskytovatel' služieb (service provider) a užívatel' (spotrebitel') alebo konzument služieb (service consumer). Poskytovatel' služby (softwarový komponent) je jedným koncovým bodom P2P siete. Služba je volaná za účelom uspokojit' potreby konzumenta služby. Konzument služby je druhým koncovým bodom P2P siete... : ; :,.. : ;. '...,.... :,.. s,.:. e M.. ;:'.:i!.!::'. '. ce.... :.:...:.: :.:.;. y:... :. '..:+Qqrj :S.ťOi'lijf :;:; ::. Hll f ;.;::~; :i : ::: :~::.. ::... :.:-~~ :.. : :. '.~:.; :?'..:~-::.~:. Se vice provider O brázok 1 : Role viažuce sa k službe Funkčnost' služby a tým aj službu samotnú definuje poskytovatel' služieb. Toto je dané častou anonymitou konzumentov a ďalej faktom, že služba je často verejná a jej konzumentem preto maže byť ktokol'vek. Služba, ako jej názov už napovedá, je určitá netriviálna funkčnost', ktorá je sprístupnená určitej skupine potenciálnych užívatel'ov. Konzumentov služby nie je možné konkrétne špecifikovať (kategorizovat'). Konzumentom maže byť ktokol'vek, kto dokáže danú službu lokalizovať a využiť. Službu preto nemusí používať nutne len,,obyčajná" aplikácia. Konzumentom mažu byť napríklad aj iné služby alebo aj človek (napríklad prostredníctvom užívatel'ského rozhrania). Služba ako časť autonómneho softwaru by sa dala rozčlenit' na dve časti : rozhranie služby a implementácia služby. Service Obrázok 2 : Služba a jej rozhranie - 8 -

9 Dóležitejšou časťou služby z hl adiska celkového pohl adu na službu je jej rozhranie (interface). Rozhranie totiž definuje sp6 ob prí tupu k lužbe a u čitým spósobom vymedzuje aj jej funkčnost. Preto je v dobe návrhu služby vel mi d6ležitá jasná predstava o budúcej funkčnosti vytváranej služby a formáte jej rozhrania. V zhl adom na zdiel ané používanie služby by bola neskoršia zmena rozhrania vel'mi zložitá, a preto je nutnost kvalitného návrhu rozhrania o to vačšia. Formát rozhrania služby je možno ešte d6ležitejší ako samotný obsah rozhrania. Určitým spósobom totiž vymedzuje ciel ovú kupiny konzumentov služieb, ktorí sú schopný danému formátu rozhrania porozumieť. Výher konkrétneho formátu rozhrania závisí od prostredia, v ktorom sa služby budú využívat'. Rozhrania v prostredí e-komercie (aliancie) sú vačšinou popísané a implementované pomocou štandardne definovaného jazyka. Výber formátu rozhrania móže zásadným spósobom ovplyvniť použitel'nosť služby. Použitím neštandardného alebo propietárneho jazyka by sa okruh potenciálnych konzumentov služby radikálne znížil. Takúto službu by mohli využívat' len konzumenti schopní popis služby pochopit' a porozumieť mu. V prostredí e-komercie ale nieje vačšinou dopredu známy okruh konzumentov služby. Tento okruh sa totiž počas životnosti služby može l'ubovol'ne meniť. Keďže rozhranie je jediná verejne prístupná časť služby, popisuje vlastne službu ako celok. Rozhranie musí preto obsahovat' dostatočné množstvo informácií, ktoré službu identifikujú, aby ju prípadní konzumenti služby mohli nájsť, identifikovat', pochopit' a aj použit'. Tieto informácie sú o to doležitejšie, že implementácia služby nie je verejne dostupná. Rozhranie musí popísať všetky vstupné dáta a všetky výstupy služby, ako sú dátové toky alebo výnimky vyvolané počas vykonávania implementácie služby. Ďalej by malo dobré rozhranie obsahovat' dostatok metadát pre popis služby, keďže názov služby nemusí dostatočne dobre popisovat' službu samotnú, a taktiež maže existovat' viac služieb rovnakého názvu. Názov služby síce o službe niečo vypovedá, ale v niektorých pripadoch móže byť názov len slabá identifikácia služby. U verejných služieb je kvalitný popis služby doležitejší omnoho viac, než u služieb poskytovaných úzkemu okruhu konzumentov. Formát rozhrania v prostredí mimo e-komerciu (konfederácia) však nie je nutne popísaný pomocou štandardne definovaného jazyka. v tomto prostredí existujú totiž vačšinou pevnejšie vzťahy medzi komunikujúcimi stranami. Preto sa v rámci konfederácií niekedy upúšťa od štandardne definovaného popisovacieho jazyka pre popis rozhraní a používajú sa proprietáme formáty správ. Implementácia služby je zvyčajne považovaná za "čiemu skrinku", ktorá bližšie nešpecifikovaným sposobom zaisťuje funkčnost' služby. Pre samotného konzumenta nie je důležité ako je konkrétna služba naimplementovaná. Návrh implementácie služby je druhoradý, prvoradý je návrh rozhrania. Implementácia sa počas života služby maže podl'a potrieb meniť, rozhranie by sa však meniť vel'mi nemalo. Aj vďaka tomu, že implementácia služby je skrytá pred konzumentom, je prípadná zmena implementácie taktiež skrytá pred konzumentom a je čiastočne nezávislá na rozhraní služby. Implementácia služby maže byť jednoduchá v zmysle práce s jednoduchým objektom až po zložitú vnútomú logiku obsahujúcu volania iných služieb. y Dalšia vlastnost', ktorú však nie je možné nájsť v každej definícii služieb je bezstavovost'. Služby by nemali zdiel'ať stav medzi jednotlivými volaniami. To znamená, že implementácia - 9 -

10 služby by nemala byt závislá na konte ~ te alebo stave predchádzajúceho volania služby. Táto vlastnost nie je pre služby nutná ale len doporučená Komponentová orientácia (Component orientation) Komponentová orientácia je myšlienka vytvárania určitých funkčných jednotiek, znovu použitel'ných stavebných blokov nazývaných komponenty. Neexistuje jednoznačná exaktná definícia komponentu. Častá odkazovaná formulácia pojmu komponent od Clemensa Szyperski hovorí o softwarovom komponente ako o binámej jednotke kompozície so zmluvne definovanými rozhraniami a explicitnými závislosťami. Komponent je nezávisle používaný tretími stranami. Conrol Offered ' Required interface JÍ ~ Configure Obrázok 3 : Komponent Táto fonnulácia hovorí o komponente ako o binámej jednotke kompozície. Binámej preto, lebo komponent je používaný tretími stranami a zdrojové kódy komponentov si ich tvorcovia chránia. Pre možnost' použitia však komponent musí poskytovat' určitú sadu rozhraní, ktoré sprístupňujú funkčnost' tohto komponentu. Explicitnými závislosťami komponentu sa rozumejú extemé konfigurácie vytvorené užívatel'om komponentu za účelom určitého ovplyvňovania (dolaďovania) funkčnosti komponentu. Ďalšou možnou externou závislosťou móžu byť extemé komponenty využívané daným komponentom pre svoju funkčnost'. Výhody komponentov zužitkováva kompozitná orientácia. [2][3] 2.3. Kompozitná aplikácia (Composite application) Kompozitná aplikácia je aplikácia vytvorená za pomoci znovu použitia logiky z dvoch alebo viacerých už existujúcich komponentov bez nutnosti vytvorenia novej aplikácie od úplného začiatku. Kompozitná aplikácia využíva už implementovanú funkčnost' komponentov, ktoré je možné viacnásobne využívat'. [4]

11 Obrázok 4 : Kompozitná aplikácia Prečo sa ujala táto myšlienka využívania znovu použitel'ných stavebných kameňov? Vačšina spoločností sa musí dynamicky prisposobovať často sa meniacej situácii v oblasti ich pósobenia. V e-kommercii to maže byt' napríklad ponúkanie nových produktov, služieb, častá zmena obchodných parterov, tlaky konkurencie, v oblasti mimo e-kommercie to zase maže byť meniaca sa legislatíva alebo vývoj spoločnosti. Na tieto, ale aj ďalšie rýchle zmeny musí reagovat' takisto aj software, ktoré tieto spoločnosti využívajú k svojmu chodu. Vytvorenie takéhoto softwaru trvá určitý nezanedbatel'ný čas a prostriedky. Neustále vytváranie nového softwaru pri každej zmene by bolo prinajmenšom neefektívne. Preto je nanajvýš výhodné vytváranie softwaru z určitých l'ahko znovu použitel'ných stavebných kameňov. Pre spoločnosti zaoberajúce sa výrobou softwaru je výhodné pri vytváraní tohto softwaru využit' už vytvorený kus kódu pre danú funkčnost' a nepísať implementáciu určitého problému opakovane. [5] 2.4. Objektová orientácia (Object orientation) Objektová orientácia je myšlienka, pri ktorej sa objekty reálneho sveta zovšeobecňujú objektov programovacích jazykov. do Všetky počítačové jazyky sú určitým spósobom zovšeobecnením niečoho. Asembler zovšeobecňuje samotný počítač, na ktorom je daný kód asembleru spustený. Jazyky ako BASIC alebo FORTRAN zase zovšeobecňujú asembler. Úlohou tohto zobecnenia je poskytnúť programátorovi určitý,sveť, pomocou ktorého sa maže vyjadriť a pomocou ktorého nástrojov móže danú úlohu vyriešiť. Programátor vlastne vytvára určitú transformáciu sveta (priestoru) úlohy a sveta (priestoru) nástroja, v ktorom sa danú úlohu pokúšal riešiť. Vytváranie týchto transformácií vzhl'adom na fakt, že odlišnost' dvoch koncových priestorov je relatívne vel'ká, bolo vo vačšine prípadov náročné. Vyžadovalo to určitú úroveň skúseností a výsledný kód bol často obsiahly a tým pádom aj ťažšie spravovatel'ný

12 Objektová orientácia však prinie la priblíženie týchto dvoch k ncových priestorov: priestoru úlohy a priestoru nástroja (jazyka). Objektová orientácia poskytuje ná troje na vyjadrenie ktoréhokol vek prvku priestoru riešenia ako objektu priestoru nástroja bez nutnosti zložitej transformácie. Prvky úlohy sú abstrahované ako objekty, ktoré majú určité vlastnosti vyjadritel né dalšími objektmi a s týmito prvkami sa dajú prevádzať určité činnosti ktoré sú v priestore riešenia vyjadrené metódami daných objektov. Toto zobecnenie vďaka tomuto prístupu značne približuje oba koncové priestory čo umožňuje nezanedbatel'ne urýchliť čas potrebný na riešenie vačšiny daných úloh. Výsledný kód je čitatel'nejší a lepšie odráža riešený problém. Aby sa s konkrétnymi objektmi pracovalo dobre, zavádza objektová orientácia určité stupne abstrakcie. Konkrétnu stoličku (tú na ktorej práve sedím) je možné vyjadriť ako konkrétnu inštanciu objektu v priestore riešenia. Všetky konkrétne objekty (inštancie) sa dajú zaradiť do určitých tried. Príkladom móže byť napríklad trieda stoličiek, ktorá pokrýva všetky stoličky roznych vlastností (vel'ké stoličky, malé, modré alebo biele, dokonca aj tú moju, na ktorej práve sedím). Tak ako aj v reálnom svete, kde sú všetky objekty (i triedy) reálneho sveta kategorizovatel'né (stolička, polička i stolík sú všetky určitou podmnožinou skupiny objektov označovaných ako nábytok), hola zavedená určitá možnost' zoskupovania tried. Je teda možné triedu stolička vlastne považovat' za konkrétnu podtriedu triedy nábytek, triedu nábytok ako podtriedu triedy zariadenie domácnosti atd'. V ďaka tomuto prístupu je možné vytvoriť rozne stromovité štruktúry pre popis reálneho sveta. Equipm.ent Fum.iture Appliances Chair Tabl e Sofa Obrázok 5: Objektová orientácia Ďalšou vlastnosťou objektov reálneho sveta je určité zdiel'anie spoločných vlastností daných skupín tried, ktoré majú spoločnú nadtriedu. Táto vlastnost' je daná sposobom akým sa jednotlivé nadtriedy v reálnom svete vytvárajú. Vačšinou sa totiž objekty (a tým aj triedy,

13 ktoré reprezentujú) dajú spojit do J dnej vlastností. kupiny (nadtrie y) na základe spoločných Preto je pri definovaní tried možné triedam prirad o vat vlastnosti ( atribúty) a dokonca i metódy, ktoré odvodené triedy (podtriedy v strome tried) dedia. Príkladom móže byť vlastnost' farba u triedy zariadenie domácno ti ktorú trieda nábytok dedí. Ako bolo ukázané, objektová orientácia kopíruje obraz reálneho sveta a dokáže s kópiou tohto sveta pracovat'. Komunikácia medzi dvoma objektmi prebieha pomocou volania metód, ktoré vracajú alebo menia dáta. Hlavným rysom objektovej orientácie je relatívne vysoká jemnost' rozhrania. Objekty poskytujú vel'ké množstvo metód pre jemnú prácu s nimi. [6] 2.5. Servisná orientácia (Service orientation) Servisná orientácia je myšlienka vytvárania softwaru za pomoci autonómnych komponentov tvoriacich virtuálnu P2P sieť. Tieto komponenty, ako naznačuje názov, sú tvorené službami (servismi). Verejne známou časťou služieb je ich rozhranie. Implementácia služieb je skrytá, tvorí akúsi, či emu skrinku'. Komunikácia v rámci tejto P2P siete prebieha pomocou asynchrónnej výmeny správ. Pri servisnej orientácii sa kladie vysoký doraz na dynamickosť služby. Aplikácia pri vytváraní pozná len rozhranie volanej služby, ale implementácia služby sa móže počas životného cyklu aplikácie meniť. Ďalej je možná podpora dynamického vyhl'adávania služieb, alebo výmeny služby za inú. [7] o 2.6. Previazanosť (coupling) Obrázok 6 : Servisná orientácia Previazanosť (vazba medzi jednotlivými časťami, komponentmi softwaru) (coupling) je určité vyjadrenie závislosti medzi róznymi komponentmi jedného systému. Inými slovami definovanie určitého stupňa závislosti jedného komponentu na druhom komponente. Existujú dva extrémy, čo sa previazanosti častí systému týka :

14 Silná vazba (Tight coupling) - sy t 'my touto vazbou m '-'dzi jednotlivými časťami sú pevne zviazané a zmena jedného komponentu vyvoláva zmeny aj druhého komponentu. Slabá vazba (Loose coupling) - systémy s takouto vazbou majú nízky stupeň vzájomnej závislosti a je možné jeden komponent zmeniť bez následkov na druhý komponent. u systémov so silnou vazbou sú komponenty previazané už v čase kompilovania alebo v čase behu za pomoci synchrónneho volania. Zmeny prevedené do jedného komponentu sa prenášajú aj do ostatných komponentov práve kvóli silnej previazanosti. Táto silná previazanosť sposobuje ťažšie testovanie i vývoj softwaru a pripadná zmena jedného komponentu je ťažko realizovatel'ná. Výhody systémov so slabou vazbou: Možnost' dynamickej zmeny (alebo výmeny) komponentov počas životného cyklu systému. Táto zmena komponentu nemá vplyv na ostatné komponenty, a preto je táto zmena jednoduchá. Táto vlastnost' systémov so slabou vazbou je výhodná pre spoločnosti ( organizácie ), kde sa často menia určité časti systémov. Pri vytváraní komponentov systémov so slabými vazbami si vývojári móžu vybrat' l'ubovol'nú technológiu postavenú na l'ubovol'nej platforme. Táto vlastnost' dovol'uje prepojenie roznych subsystémov, ako sú proprietáme systémy napísané napriklad v jazyku Cobol slúžiace desiatky rokov s novšími jazykmi ako JAV A alebo C++. Takáto slabá previazanosť komponentov dáva určitú ochranu komponentom od seba navzájom. Z chyby jedného komponentu sa móže systém rýchlejšie zotavit' napríklad pomocou vymenenia inštancie jedného komponentu za inú inštanciu komponentu. Na druhú stranu aj silná vazba má svoje využitie. Príkladom m6žu byť komponenty, ktorých tesná previazanosť je kritická pre dizajn aplikácie. Pri navrhovaní systémov preto nie je vhodné vyberať stupeň previazanosti jednotlivých komponentov na základe momentálnej popularity jedného či druhého prístupu. Malo by záležať skor na požiadavkách vytváraného systému. Preto je dóležité, aby architekti (návrhári) správne pochopili výhody a dopady slabej i silnej vazby. Dosiahnutie slabej vazby medzi jednotlivými komponentmi systému je v podstate vecou dodržania určitých zásad uvol'ňujúcich vazbu medzi jednotlivými komponentmi. Medzi tieto zásady (pattems) patria : Nezávislost' umiestnenia komponentu - nie je podstatné kde sa jednotlivé komponenty systému nachádzajú. Možnost' jednoduchej zmeny komponentu dovol'uje využívat' jeden deň napríklad jeden komponent umiestnený v rámci spoločnosti, ale druhý deň už využívat' služby iného komponentu umiestneného na druhom konci sveta u partnerskej organízácie. Táto zásada je podporovaná vďaka možnosti dynamického vyhl'adávania komponento v. Nezávislost' komunikácie - nie je podstatné aké komunikačné protokoly alebo formáty vytvárané/používané komponentom sa používajú k výmene správ. Pre prepojenie rozdielnych komunikačných protokolov však treba použit' štandardné protokoly pre prepojenie róznych formátov

15 ezávislost bezpečnosti - nie j podstatné aké bez čno tné modely jednotlivé komponenty používajú pokial sa pouzijú tandardy ktoré dokážu medzi jednotlivými bezpečnostnými modelmi takzvan pr kladat. Nezávislost inštancií - táto zásada hovorí o komponentoch ktoré by mali podporovat' synchrónnu i asynchrónnu komunikáciu a bez tavovost komponentov. [8] VS 50 Objektovo orientované technológie sú v dnešných ča och široko využívan' a obl'úbené. Toto paradigma je úž dávno overené a zažité. Existuje široká paleta nástrojov, ktoré túto technológiu podporujú. Asi aj pre tieto skutočnosti objektovo orientované myslenie ovplyvňuje vel'a l'udí používajúcich servisne orientované technológie. Pre presnejšie vyjadrenie ide o časté vytváranie služieb, ktorých rozhrania sú viac objektovo orientované než servisne orientované. V podstate by to nebol žiaden vel'ký problém. Je možné vytvárať služby, ktorých rozhrania sú objektovo orientované. Túto orientáciu je možné spoznať podl'a jemného rozhrania, ktoré poskytuje množstvo metód. Takto orientované rozhranie má však svoje obmedzenia. Pre názorné porovnanie je vhodné načrtnúť jednotlivé možnosti vytvorenia kompozitnej aplikácie použitím rózne orientovaných rozhraní medzi komponentmi. [9][10] Objektovo orientované rozhranie Pri objektovo orientovanom rozhraní je základným princípom vyuz1vanie zdiel'aných objektov (zdiel'ané komponenty kompozitnej aplikácie ). Pre úspešné použitie týchto zdiel'aných objektov je ale nutné k týmto objektom získat' odkaz (získat' určitú referenciu, dokázat' inštanciovať) v ostatných komponentoch, ktoré tento objekt využívajú. Preto je základným predpokladom v objektovo orientovanom systéme koncept spoločného zdiel'ania určitého typového systému. Tento systém je tvorený hierarchiou rozhraní, na ktorých sa komunikujúce strany musia dopredu dohodnúť. Až po dohodnutí sa na spoločných rozhraniach je možná integrácia objektovo orientovaného systému. Integrácia je následne dosiahnutá pomocou vzdialeného volania procedúr (Remote Procedure Call, RPC). Tieto objekty majú príliš vel'kú granularitu a vzdialené volanie cez internet pridáva príliš vel'ké navtšenie réžie. Navyše sú týmto riešením prepojené komponenty príliš zviazané. Organizácia spravujúca používaný komponent zmenením komponentu alebo jeho zmazaním naruší chod ostatných komponentov závislých na tomto komponente. Určitým vylepšením systému založeného na objektovo orientovaných rozhraniach by bolo použitie technológií servisne orientovanej architektúry. Toto riešenie by eliminovalo nutnost' zdiel'ania určitého typového systému, keďže metadáta by bolí uchovávané v určitom popisujúcom metajazyku (napr. WSDL). Toto vylepšenie umožňuje jednoduchšiu integráciu roznych platforiem či roznych programovacíchjazykov. Takýmto vylepšením objektovo orientovaného rozhrania však ostávajú niektoré deklarované nevýhody. Granularita rozhrania sa nezmenila a réžia transformovania volaní do XML správ a následné spatné transformovanie správy do volania funkcie ciel'ového komponentu ostáva. [9][10]

16 Servi ne orientované rozhranie U serv1sn ori ntovaného rozhrania j základn u my lienkou vytv r ni lužieb ktoré po kytujú určité bu ine s funk no ti (u l ná funk no t pokrývajúc určitú business operáciu). Tieto operácie majú charakt r j dn j kompl n j op ráci využívajúcej k svojej činno ti viacej elementámych operácií alebo aj v lanie iných lužieb. akto definované rozhrania majú vačšiu granularitu. Poč t vy tavených op rácií i poč t volaní zdiel aného komponentu sa zníži, čo má za dó ledok zníž ni réži pri volaní služieb. Závislost' komponentov používajúcich servisne orientovan, rozhrania a zníži a zmena komponentu nemá taký dopad na ostatn' kompon nty ako je to pri obj ktovo orientovaných rozhraniach. Vnútomá implementácia komponentu sa maže I ubovol n menit pričom však rozhranie zostáva rovnaké. Platformová alebo jazyková n závi lost je tiež zaručená. [9] [ l O] 2.8. Charakter vzájomného posielania správ Charakter vzájomného posielarria správ medzi dvoma komunikujúcimi komponentmi sa dá obecne rozdeliť do dvoch skupín. Procedurálne orientované Orientované na dokumenty Procedurálne orientované správy sa používajú u služby, ktorá má charakter funkcie s definovanými vstupnými a výstupnými parametrami. Dóležitým predpokladom pre tieto funkcie je ich odozva v reálnom čase. V implementácii funkcie sa na požiadavku v reálnom čase vygeneruje odpoveď a tá sa posiela spat' konzumentovi služby. Toto posielanie správ má charakter synchrónnych správ. Typickým príkladom može byť prístup do vzdialenej databáze alebo "real-time" služba pre objednávku určitého tovaru. Objektovo orientované rozhrania sú vačšinou procedurálne orientované. Obrázok 7 : Procedurálne orientované posielanie správ U dokumentovo orientovaných správ má požiadavka na službu formu komplexnej správy obsahujúcej dostatočné množstvo informácií potrebných na vykonanie zložitej operácie, ktorá sa bude spracovávať ako celok. Príkladom by mohla byť zložitá objednávka daného tovaru, ktorá vyžaduje viac netriviálnych krokov. Medzi tieto kroky móže patriť zistenie určitých údajov z databáze, poprípade spracovávanie zložitých výpočtov, alebo aj služieb iných dodávatel'ov (partnerov). Keďže spracovanie takejto správy nemusí skončit' v reálnom čase, zvykne poskytovatel' služby poslať nejakou formou konzumentovi služby oznámenie o prijatí správy, poprípade sa posielajú aj pravidelné infonnácie o stave spracovávania správy

17 amozrejme luži b mu í mat k n~ urn nt lužb predstavu o funkčno ti lužby. Zvyčajn právy v kytujú rn dzi b h dnými partn rmi ktorí sú dohodnutí na konkrétn j ej int rakcii m dzi bou po a pra vávania právy počínajúc oznamovacími ami o stave pracovania právy c z rózn úhla n ' právy o vývoji objednávky/príkazu až po po ielani ú tov al bo p ňazí rn dzi partn rmi. Posielanie dokumentovo orientovaných práv n1á charakter a ynchrónn h do fronty požiadaviek často bez požadovania odpovede. pos1 lania správ Dokumentovo orientované správy sú vačš in ou doménou ervisne orientovaných rozhraní. Service consumer - - -~---o-p_1 OP2 I Service Pf Vider OP3. :.... : \ $er\fic~ consum~r ;...,_.... OP 4 Obrázok 8 : Dokumentovo orientované posielanie správ 2.9. Servisne orientovaná architecture) SOA architektúra (Service oriented Servisne orientovaná architektúra je architektonický štýl, ktorého ciel'om je vytvorenie slabej vazby medzi službami poskytujúcimi servisne orientované rozhrania. SOA definuje len architektúru, nedefinuje konkrétne technológie pomocou ktorých je možné servisnú orientáciu dosiahnuť. [ 11] Definícia servisne orientovanej architektúry od IBM sa zakladá na webových službách ale nevylučuje i použitie iných technológií. [12] Vytvorenie servisne orientovanej architektúry je možné dodržaním niekol'kých zásad [13]: Autonómnosť - služby sú autonómne

18 Zdi I anie fi rmáln h p pi u - pr záj mnú kom nikáciu j potreba zdiel at formálny popi lužb umožňujú i olani lužb Slabá vazba - vazba m dzi po kyt vat l m a k nzurn nt rn lužb j labá kladatel no t' - lužby móžu v lať dal i Južby Íin vznikajú rózne úrovne abstrakcie lužieb Znovu použit I no t - lužby ú vytváran ' za účel 1n vytvor nia zn vupoužitel'ných funkčností Bezstavovost - lužby by malí byt ma imáln b z tavové Zistitel nosť - služby by mal i umožňovat vyhl adávanie VOJI h popiskov pre umožnenie používania služby Medzi výhody SOA patria [14]: Flexibilná architektúra Nižšie náklady na integráciu Zvýšená znovupoužitel'nosť zdrojov Vysoká návratnost' investícií SOA antipatterns Servisne orientovaná architektúra je síce vynikajúca myšlienka vytvárania systémov orientovaných na služby, ktoré sú l'ahko rozšíritel'né, lacné a vynikajú ešte mnohými výhodami, ale pre vytvorenie SOA je potrebné vyvarovat' sa určitých situácií. Vzor (pattem) je zachytenie problému a jeho úspešného riešenia. Slúži na predanie znalostí a skúseností nadobudnutých riešením daného problému. Tento príklad by mal poučit' l'udí znalých vzoru o možnosti identifikácie a riešenia problému. Anti vzor (antipattem) je vzor poukazujúci na nesprávne riešenie, ktorého sa treba vyvarovat'. Poukazuje na situáciu, vlastnosti riešenia ktoré sa uberá nesprávnym smerom. Podáva spósob ako dané riešenie dostat' znova spat' na správnu cestu. Nasledujúce SOA antipatterns popisujú modelové situácie, ktorých je treba sa vyvarovat' pri implementovaní servisne orientovanej architektúry. SOA antipatterns : Technology bandwidth So, Whaťs New? The Big Bang Web service == SOA The Silo Approach Misbehaving Registries Chatty Services Point-to-point Services Component-less Services

19 T chnology band\ idth - adapt vani SO úrovni. á ledkom ú zvýv né náklady na I tohto problému je vytvor nie ben fit v SO l n na t hn 1 gi k j úrovni al ni na business b z v, razn j ná ratn ti inv tí ií. Ako ri šenie zí kat l ných rie ním. So Whaťs New? - ituácia kedy k ptici v pol čno ti argu1n ntujú proti O SOA je len nový názov pre ni čo č j už v p I n ti irnpl m nt vané. neimplementovanie OA a trata možno ti č rpať jeho výh d. Ri ním j existujúceho riešenia so OA a zvýraznenie príno ov. tvrdením že á l dkom je porovnanre The Big Bang - situácia opačná problé1nu o Whať New?. Prevláda pre vedč nie presadiť SOA okamžite a čo najrýchlejšie. Neuváženým aplikovaním OA a žiadaný e~ kt nedostaví ale naopak, m6že to viesť k návratu k starému rie eniu a zanevreniu na OA. Riešením je vytvorenie určitého postupu postupného nasadzovania OA prihliadnutím na business výhody. Web service == SOA - prevláda mylná predstava, že webové služby sú synonymo1n pre SOA. Nahradenie existujúcich API volanfm webových služieb bez odpovedajúcej architektúry móže viesť k zahlteniu webovými službami bez výrazného efektu. Riešením je vytvorenie plánu prechodu na SOA a vzdelávanie v oblasti SOA a webových služieb. The Silo Approach - problém identifikovania jednotlivých služieb založený na identifikovaní služieb podl'a izolovaných aplikácií a nie na základe business funkčnosti. Následne to vedie k duplikovaniu tých istých služieb pod iným názvom a tento fakt navyšuje investície a znižuje ziskovosť. Riešením je vytvorenie spoločného frameworku pre identifikovanie služieb. Misbehaving Registries - problém vznikajúci duplikovaným nesprávnym používaním centrálnych registrov služieb. Následkom móžu byť problémy identifikovania služieb napríklad pri vyhl'adávaní chýb. Ďalším dosledkom može byť znížená bezpečnost' a výkonnost'. Riešením je adaptácia best practices" používania centrálnych registrov. Chatty Services - problém vznikajúci implementovaním služieb s rozhraním vysokej granularity. Výsledkom je vel'ká výmena dát a príliš časté volanie služieb, čo má za následok stratu výkonnosti a zvýšené náklady na vývoj. Riešením je vytváranie služieb s business orientovaným rozhraním. Point-to-point Services - problém nahradenia integračného riešenia P2P volaním webových služieb bez ohl'adu na skutočné použitie riešenia. Následkom je strata benefitov SOA riešenia. Riešením tohto problému je použitie podnikovej zbemice (Service Bus) pre vytvorenie SOA implementácie. Component-less Services - problém vytvárania služieb bez jasného priradenia služby k danému komponentu. Vytvárajú sa služby bez vrstvenia. Následkom je porušenie princípov modulámeho designu a princípov logickej štruktúry, čo má za následok stratu flexibility. Riešením je uvedomenie si princípov SOA. [ 15]

20 2.11. Webové služby (Web services) V podstate neexistuje jedna exaktná d finí ia w b definícií sa dá zaradiť do jednej z dvoch kupín. )' h luži a ruhú tr nu a 1na Jedna skupina definícií hovorí o webových lužbá h ak p ru n, h t hn I' gií pomocou ktorých je možné vybudovat' rvi n ri nt anú r hit k túru. Z ' kladn ' mi stavebnými kameňmi (komponentmi) tejt archit ktúr ú lu y. Ti t lu b ú pr poj né navzájom práve pomocou webových lužieb. ad u techn I ií 1n lia P\ W DL a UDDI. [16] Druhá skupina definícií by sa dala zhrnúť ako definícia h aplikáciách založených na technológiách O P W D Webovými službami nemyslia sadu technológií al už k nkr tn volané pomocou protokolu SOAP. [ l 7] b v ' ch tužbách ak o d finíci t da impl ment van lužby Definícia Webových služieb od IBM je obdobná ako prvá d finí ia p pi ujú a Webové služby ako sadu technológií. IBM sa však od tejto definíci d hýl ila tým ž vy lov n nehovorí o UDDI, ale len o SOAP a WSDL. Nejde o to, ž by IBM DDI nepovažovalo za jednu z technológií Webových služieb, len prevláda názor že UDDI nie j tak dol žité ako ostatné dve normy. [18] Trojica technológií webových služieb slúži na : SOAP - definícia formátu správy pomocou ktorých služby navzájom komunikujú WSDL - definícia formátu popisujúceho rozhranie služby UDDI - popisuje centrálny register definícií služieb. :;": ':.::.- '..'.: :'.': :;':.: :. - ~ : ;-. :':.' ;.. :n$ervi@, : ~~šu,mar Service provider Obrázok 9 : Technológie webových služieb Pri použití webových služieb dokážu objekty, programy, databáze od jednoduchých až po rozsiahle pomocou vytvoreného SOAP dokumentu poslat' správu (požiadavka) nejakej službe :i poprípade takisto vo forme SOAP dokumentu dostat' požadovanú odpoveď. Webové služby Jráve definujú formát týchto správ, definujú popis rozhrania služby, ktorá bola volaná, iefinujú mapovanie obsahu správ z a do programovacieho jazyka, v ktorom je program iapísaný a takisto definujú sposob zverejňovania popisku služby ajej následné vyhl'adávanie. 1ožné použitie webových služieb je rozsiahle. Možu byt' použité v aplikačných klientoch na rístup do rezervačných alebo infonnačných služieb. Webové služby móžu byť napríklad

21 použité aj v systémoch B2B (business to business) pre systém integrujúci obchodný proces róznych spoločností v jednom systéme alebo napriklad aj v systémoch EAI ( enterprise application integration) pre systém spojujúci rózne podnikové systémy viacerých podnikov za účelom vzájomnej spolupráce WSDL - Web Services Description Language Názov WSDL by sa dal preložiť ako jazyk pre popis webových služieb. Tento názov dobre popisuje, na čo by WSDL vlastne malo slúžiť. WSDL je formát pre popísanie rozhrania webových služieb. WSDL poskytuje spósob ako popísať rozhranie webovej služby i jej viazanosť na určitú sieťovú adresu. Vzniknutý WSDL dokument má formát XML dokumentu. WSDL vzniklo za spolupráce spoločnosti pripojilo ďalších 23 spoločností. Microsoft a IBM. K predloženiu na W3C sa WSDL spolu s ďalšími formátmi tvorí jadro Webových služieb. Je učené pre oba typy orientácie správ, tak ako procedurálne, tak i dokumentovo orientovaných. WSDL sa skladá z troch základných častí : Definície typov Definície operácií Definície viazanosti služieb Data types Messages Operations Port types Bindin s Obrázok 10 : Časti WSDL Jednotlivé časti mažu byť popísané v samostatných súboroch a neskor rozne zoskupované do výsledných WSDL súborov. Táto možnosť zaručuje možnost' opakovaného používania napríklad definícií alebo používanie globálnych definícií v rámci organizácie. Pre jednoduchost' WSDL súboru ale možu byt' všetky časti aj v jednom súhrnnom súbore

22 Štruktúra WSDL súboru je rozdelená na tri úrovne v tejto podobe zámeme. Každá z častí je vlastne iná úroveň abstrakcie. Tieto úrovne abstrakcie sú definované nezávisle na transportnej vrstve tak, aby bolo možné definovat' zároveň i niekol'ko transportných vrstiev pre jednu službu. Napríklad je možné definovat' službu prístupnú pomocou SOAP cez HTIP alebo ako SOAP cez JMS. Časť definície typov sa skladá z dvoch častí definície dátových typov (types) a definície správ (messages). V časti types sa definujú dátové typy potrebné pre posielanie správ. Pre maximálnu prenosnosť sa u WSDL používa XSD kanonický systém typov a je považovaný za východzí systém dátových typov. Pri definícii je mozne definovat' nový pomenovaný dátový typ použitel'ný v celom vytváranom WSDL dokumente, popripade vo všetkých dokumentoch, do ktorých sa táto definícia zahmie. Definícia správ definuje správy a ichjednotlivé typy pomocou dátových typov. Každá správa má jednoznačné meno, može sa skladať z niekol'kých pomenovaných častí, ktoré možu mať svoje dátové typy. Názov správy je unikátny medzi správami dokumentu, podobne je názov časti správy unikátny v rámci jednej správy. Definícia správy je zámeme takto obecná, keďže správa móže byť neskór naviazaná viac druhov konkrétnych formátov. Definície operácií je možné rozložit' na tri menšie časti : definícia operácií, definícia typov portov a definícia vazieb. r / t /P s;. <p.:i~t/> </ne.ss ;;J.ge> <nes.sa qe> <po-::tr rpe..- <.:.::p~ t /> -<o...:tp-...:.t/> ':ra u.lti> <I ope::: a t i.1.:.j:~> <./ pvrttyµe.,. <bindinq-;. <body/> <. /: nput> <m.;. t r:n.: t> <body/> <.:/outv::.~ t> Obrázok 11: WSDL I WSDL podporuje možnost' odpovede na správu a preto sú v ňom definované 4 typy operácií: One way - jednosmemá správa od konzumenta k poskytovatel'ovi, obsahuje len input. Request-response - poskytovatel' služby dostáva správu, na ktorú následne odpovedá správou, obsahuje input, následne output a popripade l'ubovol'ný počet fault. Solicit-response - poskytovatel' odosiela správu a následne dostáva správu od konzumenta, obsahuje output, následne input a poprípade l'ubovol'ný počet fault. Notification -poskytovatel' pošle správu konzumentovi, obsahuje len output

23 Input, output i fault sa odkazujú na už definované správy. Názov inputu a outputu nemusí byť definovaný, naopak fault musí mať meno zadané. Zadané m ná musia byť jednoznačné v rámci jedného porttype. Operácie sú uzavreté do tagu porttype, ktorý definuje logicky spaté operácie, operácií móže byť viac, musia ale byť jedinečného mena. Definícia vazieb (binding) definuje pre porttype formát správy a detaily protokolu. Pre jeden porttype može byt' l'ubovol'né množstvo vazieb. Každá vazba má jednoznačne definované meno v rámci WSDL dokumentu. Element binding umožňuje pre každý porttype, pre každú operáciu porttypu, a pre každý input, output a fault správu definovat' rozširujúce informácie obsiahnuté ako elementy v týchto tagoch. Posledná časť WSDL, definícia viazaností služieb, sa skladá z dvoch častí : definície portov a definície servisov. Definície portov (ports) priraďujú jednotlivým vazbám (binding) koncové body priradením adresy. Definícia služieb (service) zoskupuje logicky spojené porty do skupín. Samozrejme názov servisu i portu sú unikátne v rámci celého WSDL dokumentu. [ 19] SOAP - Simple Object Access Protocol Technológia SOAP je definovaná ako protokol pre vytvorenie Messaging frameworku", tzn. frameworku založenom na správach. SOAP verzia 1.2 je protokol určený pre výmenu štruktúrovaných dát v decentralizovanom, distribuovanom prostredí. Vďaka tomu, že je založený na technológii XML je možné pomocou neho vytvoriť jednoducho rozšíritel'ný framework pre výmenu správ nad širokým spektrom transportných vrstiev (protokolov). Tento framework je následne nezávislý na programovacích modeloch, programovacíchjazykoch alebo platformách. Hlavnými ciel'mi SOAP sú jednoduchost' a rozšíritel'nosť. Tieto ciele sú dosiahnuté vynechaním" určitých vlastností, ktoré poskytujú distribuované systémy. Medzi tieto vlastnosti patria napríklad : Bezpečnost' Zaručené doručovanie správ Transakčnosť Pri prepojení takých systémov pomocou SOAP, ktoré sa bez týchto vlastností nemažu zaobísť, je nutné použitie roznych rozšírení, ktoré tieto vlastnosti zaručujú. SOAP je v podstate jednosmemý komunikačný model, ktorý slúži na prenos správy od odosielatel'a k príjemcovi. SOAP podporuje aj prenášanie správ za pomoci prostredníkov (intermediares), ktorí m6žu správu čiastočne spracovať a predať ďalej. SOAP definuje aj mechanizmus ako je možné jednosmemú komunikáciu podporovanú SOAP-om adaptovat' na dvojsmemú komunikáciu Request I Reply používanú pre

24 procedurálne orientovanej výmene správ alebo ako pomocou SOAP prenášať dokumenty používané pri dokumentovo orientovanej výmene správ. kompletné.' >.. '. ~.. :::. : ::<. : ~.:..;-': : <... ;.. : :.... ::: pn)g~rfr.f.:. :: : Program 1 :. ::: :...:.: :;- ; ; ;',.....;. Program 2 Program 3 Program ~ Obrázok 12 : Použitie SOAP-u SOAP bol navrhnutý ako abstraktný, nezávislý komunikačný protokol vhodný pre premostenie alebo spojenie dvoch alebo viacerých komunikujúcich strán. Prepojené systémy mažu byť postavené na roznej kombinácii hardwaru alebo softwaru, ktorý podporuje komunikáciu cez Internet, ako napríklad.net alebo J2EE. Samotná SOAP správa sa skladá z niekol'kých hlavných častí: Envelope - ohraničuje samotnú správu Header - Obsahuje metadáta používané pri spracovávaní správami komunikujúcimi stranami alebo prostredníkmi Body - samotné telo správy obsahujúce dáta Attachment - obsahuje jeden alebo viacej dokumentov priložených ku správe RPC interaction - definuje ako modelovať RPC volanie pomocou SOAP Encoding - definuje sposob reprezentácie jednoduchých i komplexných dát prenášaných v tele správy. [20] I ;! "' : ''......:. : Obrázok 13 : Formát SOAP dokumentu

25 2.14. UDDI Universal Distribution, Discovery and I nteroperabi I ity Podl'a zastrešujúcej organizácie OASIS [21] je UDDI významný protokol pre vytváranie webových služieb. UDDI slúži na vytvorenie štandardnej platformy, ktorá umožňuje spoločnostiam a aplikáciám jednoducho, rýchlo a dynamicky vyhl'adávať a používať webové služby a takisto jednoducho svoje webové služby publikovat' a dosiahnuť tak situáciu, že ich služby móžu byť rovnako jednoducho, rýchlo a dynamicky používané inými spoločnosťami. UDDI bol vytvorený nezávislým konzorciom softwarových spoločností, založeným spoločnosťami Microsoft, IBM a Ariba. Účelom konzorcia bolo vytvorenie štandardu pre popis, registráciu a vyhl'adávanie webových služieb. UDDI je konceptuálne podobný službe Yellow pages". V Yellow pages" spoločnosti registrujú svoje údaje ako telefónne číslo, fax, a ďalšie kontaktné údaje. Pri registrácii sú tieto spoločnosti zaraďované do kategórií podl'a zemepisnej polohy, oblasti podnikania, charakteru poskytovaných služieb. Iné spoločnosti následne móžu taktiež za pomoci služby Yellow pages" v tomto registru vyhl'adávať a zisťovať kontaktné údaje spoločnosti, ktoré ponúkajú služby, o ktoré majú záujem. UDDI funguje obdobne ako Yellow pages". Je možné do nebo registrovat' webové služby, ktoré je možné následne vyhl'adávať a následne vďaka vráteným údajom o službe aj volať a komunikovat' s nájdenými službami. Pre komunikáciu s UDDI registrom sa používa SOAP a vďaka poskytnutému rozhraniu je možné za pomoci SOAP volaní volať funkcie pre pridávanie alebo vyhl'adávanie služieb v rámci UDDI registra. WSOt...,,... ~ : ' l 5 \. _.,,.,. I. /-- \ I 6 ) \.. ) SOAP. WSDl Service provider I I I ~ ~ i j i ~ ~ I l I I Obrázok 14 : Použitie UDDI

26 Typicky sa proces registrovania webovej služby do UDDI r gi ra kladá z krokov: 1. Poskytovatel' služby musí najprv vygenerovat W DL súbor popisujúci webovú službu, ktorú poskytuje. 2. Tento WSDL súbor sa registruje pomocou funkcie UDDI v registre. Po tomto vložení obsahuje UDDI register kontaktné informácie o ponúkanej službe vrátane WSDL súboru popisujúceho službu. 3. Potenciálny konzument služby vyhl adáva pomocou funkcie UDDI službu, ktorá vyhovuje jeho požiadavkám. 4. UDDI register vracia požadovaný WSDL súbor popisujúci službu. 5. Klient generuje odpovedajúce volanie za pomoci WSDL súboru. 6. Klient volá určitú funkciu služby za pomoci protokolu SOAP a poskytovatel' služby odpovedá taktiež pomocou správy vo formáte SOAP. UDDI ako centrálny register nie je obmedzený na popisy služieb vo formáte WSDL. Popisy registrovaných služieb možu byt' v l'ubovol'nom XML formáte ktorý popisuje službu. [22] Ďalšie technológie webových služieb Základné technológie webových služieb ako sú SOAP, WSDL a UDDI sú vhodné na premostenie dvoch technologických domén roznych dodávatel'ov systémov. Pre rozumné použitie v rámci podniku, alebo napriklad pre výmenu citlivých dát medzi dvoma obchodnými partnennije ale potrebná ďalšia množina noriem, ktoré vhodne rozšíria základné normy webových služieb o ďalšie doležité vlastnosti a kvalitu služieb. Proces obohatenia webových služieb o doplňujúce rozširujúce normy sa podobá úsiliu skupiny Object Management Group (OMG) pri vývoji Common Object Request Broker Architecture (CORBA). OMG definovalo komplexnú softwarovú architektúru podporujúcu transakčnosť, asynchrónne posielanie správ, bezpečnost', zotavenie z chýb, atd'. Podobné úsilie vyvíja konzorcium W3C ohl'adom webových služieb

27 I 1 H oo Názov oblasti Norma....,....,......,.-. ~....,. -. ~. ' " l Typ oblasti Distribuovaný manažment WSDM, WS#Management Manažment Súčinnosť WS-Provisionlng Bezpečnosf WS -Security Bezpečnost' Bezpečnostná politika Bezpečná výmena dát Dóveryhodné posielanie správ WS-SecurityPolicy WS~SecureConversation WS-Trust Federalizovaná správa identit WS-Federation l" '~~rt;'í " " " '"-" " "' " " " ""' " '-" "-'" " " " " '"-" " " " -'" " "' "-""" "" " ' "" " "'" " " " '"-"" " "'" "mw.""-'w "."'" " "' "'"."""" "" "'""' " """ " ď'"".""v "" '" ws~~,w." -. v'" '" "" "'" ""VYVV'"Y' '"V"'"''-"'" 'Y _,,""-"''WY j v """'' ' ' Portál Transakčnosť" WS-Transactions, WS-Coordínation. WS-CAF T ransakčnosť a podpora procesov Podpora procesov BPEL4WS, WS-COL Oprácie.so správami WS-Eventing, WS-Notification Messaging Zookupovanie správ. ~ ~. ~ - ~... :...:.:. _._ :~ ;...:.. ~. Srnerovanie správ :..: ~:. ~ : ~ ~ : ~... :'., ~. ~.. : : Spof atthvosť správ...:... WS-Enumeration, WS-Transfer : WS-.Addressing, WS-MessageOalivery ~-...,...,. : WS-Reliab.teMessag ingt WS-Reliability _ Zaobarovanie správ '. SOAP, MTOM PubUkácia a vyhraqávanie UDDI, WSIL Metadata,...;... ~. ;~.:.;.:.;.: :...:~.~....Y ~;:.~.:.~:..... ~... :~.:... ~ "'"'-" ;;._., , :....,.., ~.. n-.n. '. '... v...., n ;-..vjia' , '.YllN"""''' '" ,...,....,,.,,,, ,, Pravidfá Popis. služi.eb WSDL Zisl<avanie metadát WS-MetadataExchemg:e I ' Obrázok 15 : Rozširujúce technológie webových služieb 1 i Proces obohatenia webových služieb o doplňujúce normy sťažuje fakt, že vedúce spoločnosti ktoré sa podiel'ali na vytvorení noriem SOAP, WSDL a UDDI sa už nevedia zhodnúť na jednotlivých rozširujúcich normách a každá presadzuje svoje vízie budúcnosti. Rozšijúce normy by sa dali rozdeliť do nasledujúcich základných oblastí: Manažment Bezpečnost' Portál Transakčnosť Obsluha správ Správa procesov Metadáta

28 Manažment Správu podnikových zdrojov a ich následnú integráciu podporujú nasledujúce doporučenia: WSDM - Web Services Distributed Management, ktorý podporuje správu zdrojov pomocou webových služieb, ako aj správu webových služieb ako určitého typu zdroja. [23] WS-Management - konkurenčná špecifikácia k WSDM, pokrývajúca len časť problému, ktorý pokrýva WSDM. [24] WS-Provisioning - norma popisujúca API schéma nutné pre zaistenie súčinnosti medzi systémami spravujúcimi zdroje pomocou webových služieb. [25] Bezpečnost' Jednou z najdůležitejších rozširujúcich noriem sú normy ohl'adom bezpečnosti webových služieb. Bezpečnost' je důležitá pre zaistenie dovemosti a integrity webových služieb. Nie je dovolené, aby niekto iný ako určený príjemca správ videi obsah doverných správ a mohol s nimi svojvol'ne manipulovat'. Bezpečnostné normy sú důležité aj pre zaistenie prístupu k webovým službám, aby webové služby mohol využívat' len ten, pre koho sú určené. Špecifikácie k bezpečnosti webových služieb: WS-Security - popisuje rozšírenie normy SOAP o ďalšie úrovne ochrany pomocou integrity, diskrétnosti a overovania správ. Tieto mechanizmy umožňujú použitie roznych bezpečnostných modelov a šifrovacích technológií ako sú napriklad podpisy alebo bezpečnostné žetóny (tokeny) ako X.509 certifikáty alebo Kerberos tikety. [26] WS-SecurityPolicy - definuje množinu bezpečnostných vyhlásení týkajúcich sa noriem WS-Security, WS-Trust, a WS-SecureConversation. Popisujú ako majú byť prenášané správy zabezpečené, aby hola zároveň zaručená kompatibilita a súčinnosť medzijednotlivými účastníkmi komunikácie. [27] WS-Trust - definuje rozšírenie normy WS-Security pre popis ďalších rozšírení výmeny bezpečnostných žetónov, ktoré slúži na overenie identity komunikujúcich strán navzájom pre zaistenie dóvery medzi stranami. [28] WS-SecureConversation - rozšírenie WS-Security a WS-Trust, ktoré popisuje ako spravovat' a autentifikovať výmenu správ medzi komunikujúcimi stranami vrátane výmeny bezpečnostného kontextu a vytvorenia kl'účov pre spojenie, v rámci ktorého prebieha konverzácia (výmena viacerých správ). [29] WS-Federation - popisuje ako spravovat' dovemé vazby (identity, bezpečnostné požiadavky) v heterogénnom prostredí roznych bezpečnostných domén medzi webovými službami. [30] WS-Authorization - popisuje správu autorizačných dát a autorizačných postupov webovými službami. [31] WS-Privacy - popisuje ako webové služby definujú ochranu súkromia. Následne konzumenti týchto služieb musia tieto definície rešpektovať. [32] Vzťah medzi hlavnými špecifikáciami ohl'adom bezpečnosti webových služieb popisuje nasledujúci obrázok

29 I SOAP Portál Obrázok 16 : Špecifikácie bezpečnosti webových služieb Pre potreby priameho integrovania webových služieb do užívatel'ského rozhrania - preto vznikla norma WSRP. WSRP (Web Services for Remote Portlets) je špecifikácia, ktorá definuje volanie webových služieb priamo z portálov. WSRP taktiež umožňuje u distribuovaných portálov zdiel'ať portlety ako virtuálne webové služby využitel'né v iných portáloch. [33] Podpora procesov Process flow (správa procesov) je kritická pre automatizovanie business procesov v rámci podniku. Správa procesov sa často nazýva orchestrácia, lebo popisuje vzťah medzi sériou interakcií nutných pre vykonanie daného ciel'u, ako sú napríklad prevedenie objednávky, spracovanie rezervácie alebo splnenie určitého plánu. Procesy sú modelované ako postupnosť krokov definovaných pre daný business proces. Postupnost' krokov tvorí združenie funkcií, pre ktoré je možné definovat' webovú službu. Základné normy pre podporu správy procesov sú: XLANG - rozšírenie WSDL vytvorené spoločnosťou Microsoft pre podporu správy procesov v rámci webových služieb. Umožňuje spájať jednotlivé služby do reťazca dlhodobých transakcií. [34] WSFL - XML jazyk definujúci popis možného zostavovania jednotlivých webových služieb do zložitých sekvencií. Definuje poradie volania služieb i dátového toku medzi jednotlivými volanými službami. Bol vytvorený spoločnosťou IBM. WSFL je vlastne konkurenčnou normou k norme XLANG. [35] BPEL4WS - jazyk pre definovanie workflow modelu obsahujúceho transakcie skladajúce sa z definovaných sekvencií webových služieb. Túto normu podporujú mimo iných aj spoločnosti IBM, BEA a Microsoft. BPEL4WS vznikal z XLANG a WSFL a nahrádza ich. [36]

30 \\ - DL ( h )ít lr 1phy I ri ti n L, n u '() j 1.' pr )pt ni p luprá m 'dzi k )n' )\'\"I11Í k llll nt~lljll 'lflll l ) hni n r 'I. k Il'l r I t. n11 pr..., ram \' c m m ddu. [_ } Tran ak 110. ť v v t aut matizo 1nýd1 bu inc:~ )r r: ií hnjú tr u1, k i r )k/itú úl 'hll. l i~t\1jú korektno ť pr v d nia, ' rit: súvisiaci h )I (.;I. cii na l Vtt 1m1 t \. ť k t nul. /I >it; \i krokov ' operá i nav n k j 1via ak) at rni kt ~ J tr í 'tt na i ht 1 n11. Tradičné tran akčn, pr tokoly nic sú \' rám i \\ d n ~, h sl u> i( h r i r nt:. Riešením pr t nt probl 'm je n 1rTTI'l 1 pn ' fl j skur iny )1. 1. rnjv 1n~ I u::in.. Tran action Protocol (BTP), kt r: 1. isťuj ~ }c v~ skdky \ )hni 1 vi t cr\ h \ d v\ h ~lu> it:b sú korelctne propag van ' a zd icťané. l- ] Medzi dal i normy pr podp ) fu tran: k n )Sti web)\'\ h :luiid1 patri W -Tran acti n - d ťinuj mechanizmus pn.: p jp )fu cr n. 1k n j sú inno:ti m dzi r6znymi doménami web vých. lužich a pr'í u s tr 111s 1kci mi Jl'HJ \ t:h 1ni. lu)' ~mi. [39] W -Coordination - po kytuje protokol prc ko H. iin \ " lni 1k "ií Ji tribu v 1n ' h aplikácií. [ 40] WS-CAF ( ompo "' ite AppliC' ti ) íl f ran1e\ )rk) j' J._ 'k prc. tandar nú p )dp ru prenášania kontextu, koordináciu a sprá u tr ns'1kcií..'khdá _., z tr h. ecif 1k "' ií: o WS-CTX ( onte, t) - j dnoduchý f rc 111 work pr sprá u ke ntc. tu o WS-CF (Coordinati n Fr mcwork) - definuj c ntráln h ke ordin tora kt spravuje kont xt v' inforrnáci "ko aj správu prop' 1 ani-i úspc n ~ ti jednotlivých služieb o WS-TXM (Tran acti n Management) definuje tri tran. 'lk n ' pr t k )I kt r m6žu byť použité v koordina č nom fr mcw< rku prc zaist ~nic tran ak n ti volaných sekvencií lužicb. [ 41] Obsluha správ Messaging protocols (protokoly prc správu pr v) zai 'fujú sprá ne fung an1c r zn ch komunikačných scenárov používaných pri výmcnc práv~ ak u: Asynchrónnajednosme1ná komunikácia Request I Response Broadcast Publish I Subscribe Ďalšie webové služby m6žu závisieť na určitej kvalit ]uži b ak, u: Spol'ahlivé (zaručené) doručovanie správ Propagovanie transakčného alebo bezpečno tn 'h k nt tu Správne smerovanie doručovania právy c z definovaných pro tr dníkov

31 \\".-I utin: pr t ) )I pr i tin n ani ( '-.{\ r id~ n j v "' p ) p ru ú 1 i r ) k~. k t ru 111 t '11n~ h \\ -R ť rral - pr ({k )l pr m 1 nu ~ rn m i k u k n t 1: u f'i i t r lll t: r \ )f11 )U hla\'i 'k) :\. prť \'Y l - ) B I k E.- t n i hl E. h 1 n 1 (f l l I pr\: \ t )r ni aplika néh prntl)k )lu prl: a~~ ndu, nrn k )munika iu I Hll u JTl z I /c n ) h n 1. 1 L [ 4} 1-rrrPR - HTTI f cli 1hl. pr t )k )I rtru ujúci. r )L hli\t J ru \ anic.: 11 rtf p k t n1 dzi k )n1unikujú 'imi.:tr'1nar11i. I i. i mn )/:t\ pr hl m ' n. p )I' hliv 'h) 1 ITTI pr t )k lu. [~5] W -Eventing - definuje 1ákla inú mn )/inu p r~i ií kt r. 111 ~ 1u \\d )\'t.: slu>h p uží ať z ú I m hláscnia n )tifik: it:) ur itt.:j u I l )sti. ( lj W - tiťi ati n n rrna pn.: <kfm n ani Puhlish,' ul s ihc sct:n/1 l J ):idarli-1 ~ J v pr \ b vé luzby. [47) W -Enum r ti n - n nna dctinujúv1, ' L k nstruk iu pn.: 1i. k 1nit: <.Vt kt )f m jú tvar k 1 kcic )d web ) ch, lul.ich. [ 4 ] W - ran ~ r - d ťi n uj w d \ c hc )' m i s I u/. a m i m n )).in u j t: cj n ) u h : h p (, i i ( t~ P t Put a D l te) definuje jcdn tnú mozn sť ak i h hť. ( J W -Addr ing definuje n1cchanizmus i I ntifik 1Vania knnc )V ch ) o k munikácie nczávi l na transp )rtncj rst c d 1k 1 kt )r mu je mo1n~ je irh du h adr ovani práv. [50] W -M age elivcry - tát) n )rtna ric. i ten i:t, prohl m ak ) n )íjll'l - ddr. sing, ale je int grovaný de WSDL a pouzí aj h) t y. 1 1:11 i lf č),' - dr s:in' \ ext rné."r fcr nčn, vla tn ti. [ 5 1] W -R liabl Me. aging - definuje d )ruc ) ací protokol ncz-' isl)' rl 'l tr, n: rtn j vr tve pr p l'ahliv ' d ru ni. práv rncdzi komunikujú irni st ranami. D finuj taki to OAP binding prc využitic v rá1nci cb )V, ch sl u.ich. [ 5-I W -R liability - r z írenic n nny 'OAP, kt ) fé de cj' a p dp( ru pr sp )I ahli doručovanie práv climin ciu duplicitných. pr v rad nic doru < ani spr. I~ ] MTOM (M age Tran nli. i n pti1nizati n M chanism) - p )pi uj m optimalizácie práv m dzi dvo1na j dn )tli v mi b( dm i k munik nc.;j Optimalizácia a d finuj vždy mcdzi d ma. AP uzlami ( )d i J t I pro tredníci) a je zal žcná na, I ktívn m k' d vaní jcdnc tli ých a, tí L [54] Metadáta Poslednou skupinou noriem ú n nny za1 t ujúc pridanú h dn tu v bla ti prá s metadátami - dáta o dátach. WSIL (Web ervice In pection anguag ) - n rma známa j p d názv m WS- Inspection, XML formát pr p dp ru dynamick ' h vyhladávania do tupných webových služieb v rámci vzdialenéh pric t ru. Tát n rma umožňuj aplikáciám vyhl adávanie služieb, o ktoré majú záujem. [55] WS-Policy - popisuje flexibilnú gramatiku pre vyjadreni požiadaviek možno tí a základných charakteristík jednotlivých webových lužieb. Tieto vla tno ti sú

32 \'!.i~ dr n r Ill. Hl n ri t: ni. r\l rn. :i' u Ul l.. t li- i I ).. ) atdi ' <.: \' h :lulic..:h in \ " lť.'\ ).i n r : n ~ rnmun: lnť p,)i 1 Ja ~. (.- j \. -. kt~ 'Hal. trnu.. n rm 1. t ',\ r \ ~ lr 1 m tnn1zr n : 111<.:t 1 F t 1 - ri nt \ \-ineny 1 ri\ l'l m ' 1 \\'.'I l \ ~ -I li '. rrn t d Id ~ uj p dp r ) \'ať 1j hudú ESB (Enterprise erv1c Bu ) Z viact:r) ch m )ln)\:h tkfiní ií t )hto i. t ), 1 \: ~k.~dujú <.:h) i )jmu \~pi~ 1 i f. ' I h d a I a d t in v ať a k u r ' i t } ar hit c k t Hl i L 1' ~ \ 'I r pr rn i d J k\ art. Id r~ I tli i n ~ pr j (;nic.: ri ad né z iel'anie p <lnik( \'~ d1 1dr jnv (:luiich. 11 li~ \ il J: t t c..:/ hl~ u rn t hn I i kú 1 r "zn r )d ť t\ chto 1.dr )jov. Pr ytv r nic r i.:n ricnt )\"lntj ir hitcktúrv j nutn sa Jri tť rin ÍJ \'. Pn; vytv rcni luži b je nutné ytvoriť r )fhr 1ni 1 pn: c.:.-istujú c..: 1kh n ~lui. h) huď pri 111 ). alebo za p užiti adaptér). ytv )rcnic infra~truktúry na rnjni1s j lir vni /.n un n un1.1niť pr no a m ro ani práv reprc.1entujúcich v )hni 1 jt:<ln )tli \ ~ d1 slu/ich. T 1ktit:1 jl: <.h k>.ité um žnif zmcnu i1npkm ntá -- ic slu >:by he1. dósl ik v n 1 kl i nt)\' 111 j shuhy. I t j podmi n n ' ni l n vyt r nírn ser i:ne ( rient( 111) --h slu>icb 1le aj ur it HJ p ldp trany infra truktúry v la( slu/by ncz.á islc na skut( cncj r I ht: slul.hy 1 komunikačn 'h pr t k lu. B po kytuje infra truktúru pr k 1rn unik 'iu, p sidanic :pr i 1 sprá u ud ll( stí. Hn u ktorej je m žné vytv riť servi. ne ricntovanú architcktúru. I 1 lcj L. B p )Sk vtujt: n str )je pr hlavné integračné vzory. Rózna Iiteratúra p pi ujc r ~ zn vla tn i ktoré z t) 1 chto vhstností tv 1ri 1 z ' khd ale niektoré na druhú tranu t v ria r >Z. 1rcnu ťunkcnosť E ~ f. Z 1Zn-1m la.~ tn ~ tí poskytovaných róznymi implem ntáciami B: Komunikácia o Srn rovanic práv (routing) o Adre ovani práv (addrc ing) o P dpora komunikačných t chnol 'gií, tandard )V o Publi h I ub cribc o Reque t I re ponse Prepojenie lužieb o Definícia rozhrania lužby o Podpora pre zámenu implem ntáci lužby o Modely výmeny práv o Vyhl'adávanie a zver jňovanie Južieb Integrácia o Databáza o Adaptéry o Skladanie služieb o Mapovanie lužieb o Transformácia protokolov o Podpora aplikačných serverov o Podpora r6znych jazykových rozhraní prc vol ani luži b QoS

33 r-. '-' B 'P o o o l r )\' o o o o I r ~.HL ' l i 1 )Jr r~ 1 ~ru n h)p). tt:hnia. p i\ n. 1 : Ut(IltÍfik 'ťt :\ U t ) rt I ~ ~ 1 I "\' rn ). ť P )dp ra. tand ird )\ h / r1. luiit.;h \k mn : ť Pricpustn )S ť D )Stupn )Sť., prac )\'antt.= pr v o Validácia o ran. fi m1 ' c ia práv o b hac( van i sprí v anažmcnt o Registr ' cia slu/ich o L )ging. m )nit )fing o Vyhradá ani slulich M d I van1c lnteligcncia infra. truktúry Z týchto ponúkaných vla tno:tí je ale kn urcitá mrn)/in'1 )hsi 1hnutú mcdzi 1.'khdn ' mi v]a tno ťami nutnými k d siahnutiu E. B. Ticto vlastrn sti sú : Komunikácia o Siner vani "práv (r)uting) o Adr vanie práv ( addrcssing) o Admini tratívna podpora n1 rovania 1 adr s )Van1a o A p ň jeden p" b vým ny pr ív (Publi h I suhs 'ribc, Rcqu t I r p ns.. ) o A p ň j den tran p rtný protok 1 Prepoj nie služi b o Otvorený rnod I pr vým nu. práv. kt ffý odd I ujc srncrc van i pr d a1notnej aplikáci " p dp r )U z' mcny impl mcnt cic luzby Integrácia o Podpora integrácic )užicb (na pr. wcbo é služby, ad' pť ry, Java 2 Tieto základné v]astno ti plňujú najča tej iu definíciu E. ' B: ESB je logický architekt nický k mp n nt po kytujú infra truktúru r p ktujúcu princípy SOA Požaduje použitie r zhraní nezávi lých na implcmentá ii, kotnunika n, pr t kol nezávislé na umie tnení lužby pr no n t a zn vupoužit J n Iužby r zhraním slabou vazbou. ESB je implementovaná ako dí tribuovaná h t rogénna infra truktúra E B poskytuje nástroj pre právu infra truktúry (58]

34 Cli nt Cli EJEJEJ c Provider Provider ro id r ( hr 1ok 17 : :: B

35 3. TIF 3.1. Popis Tr. k Intcgrati )J1 Framt:\\ 'rk ( r11:). ~k) u1 rn/ )\ rnp ' ~ h J int 1 r 1 n. ťr~ m ' rk ~ p I n st i T r 1 s k : t I u t i n s ~. r. ). Tra ~ k lntcgrati )fl Fr Il1t:W )fk. h} '' 1 i I rnmarnl 11n'iť, k) impkrtlt:llt: i architekt )ni "' kéh ) v1 )fll )/ll'l ( \ arh:h ak 1:nt rprisl:.' r\' i e Bu. 1.'l vh n~ pr~ int gráciu int~mých aut )n rnnych n1útr )I o imk )\'}' h k Hnp nu1t \',un i k n t: i r{ ic H pr p 1juje j dn )tli v' servisnc ( ricnt n 1 n k 1111 HH.:nt a1 li k: i k Hlf it.: I H1úk júcc a k nzumujúct: lužby. TIF takticž um )lt'lujc flcxihilné rit:scnit: intcgral n)lh s cn ír n 'tk sú I vu1t nv n rchit cturc (ED ). Exctr ct Trnnsťorm 1nd I. nd LTL) a I _I inkgr'\ i i. R zh ran i a j cd not I i ) c h k ) m p ) n nt ()v p ) s kyt uj ú i h s I u i h) t v r i 1 hu s in -- s~ H 1 nt v n funkci in1plen1 ntujúcc procesy pt núkané kon11 ncntrni. Rozhranic kon1pon nt v je cr jnc znám v rámci k nťedcr 'cic, z 1thr c) i1nplc1ncnt kia komp )fl<.:ntu n1 1/-c n1 1ť ch r- kt r čiernej krinky. K )lllp 1ncnty tv ria k )JlC )Vé hody irttl'llrn:j.- i tc ( r r )~ ktorá vznikn prepoj ním za pom I -u. Prepojením j dn tlivých k mponcnto\ konfc lcrcícic <l( irtuálncj P... P sictc k )nzu1ncntov a po kytovat rov bu ine orient( van)'ch služicb pon1 Kou TI F-u znik'í 'lí 'hit k túra orientovaná na 'lužby. TIF ponúka m žn f jcdnoduch ' ho a rý 'hlcho nasndcnia h z nutnt stí ust miz ani produktu u zákazníka. Na ad nic pr duktu sp) íva v in. ta V cii k nfigur,ciij dn tli ' h komponentov TI F-u. 1 át v la tn) ' ť je z ru ná p 1rn >c 1U ir )kcj podp )ry r zlicn, h komunikačných protok I v pr intcgr 'ciu k rnpon ntov

36 Co _... < on o c Compo e t IF Corn Componen Co pon nt )br I.ok l : Pdkl d ri. ni t porno ou TI F-u 3.2. Pojmy V texte a používajú p )jm ako fr )J1tcnd 'l ba kcnd. Fr nt n d j c i n ý n áz p rc k ) n Lu m c n ta s I tuhy ar h i t c k túr ) rit: nt van cj na s I už b. Backcnd rn je n druhú stranu ( zna o an " p )Sk t 'lt I História Na začiatku bol len jeden projela Prvá verzia produktu Tra k lnt gration Framc\ rk, ktorý sa dne: už d p az), ť za.: vznikla v prieb hu impl m ntácic n véh y:t 'mu pr obsluhu klient v p I n) ti Capital Bank a.. (dne, " M ney Bank, a.s.) už v pri bchu r k) 2002 až V pri hu analýzy bolo identifikovaných dvaná ť v I mi róznor dý h aplikácií s kt rým i ~ a y t m pr obsluhu klientov mu el int gr vat. Integr v né. y:t 'my b li prc 'dzko n w ni k rk' h róznorodých op račných y 't 'm ch využívali r " zne dát ' zdr je a b li po tav n na odlišných programátor kých t chn I' giá h. Vzhrad m k t jt r''zn r d ti b I r zh dnuť implementáci i di tribuovanej int gračnej infra truktúry zal ž n j n princíp ch ktor by minimalizovali dopady na int grovan ap li k i a d budúcna by urnožň vali nad al j rozširovat integračnú infraštruktúru o ďal ie rie cnia a aplikácie. Hlavné požiadavky kladené na pripravované rie enic bol i: Znovupoužitel'no ť - ielen na úr vni jedn tlivých luži b al aj na úrovni c lej integračnej infraštruktúry. Granularita a modularita - iel om bolo pripravit moduly a lužby pokrývajúce definované funkčnosti. Interoperabilita - Potreba vzájomn j komunikáci medzi aplikáciami na róznych platformách, róznymi dátovými zdrojmi, priprav ných pomocou róznych technológií róznymi dodávatel mi

37 . rn: jl L ) - Ri ni fll '\l ) r1 h aplik 1~ m1 ta. ~ h: n Ir. /tn<.:n_ \ ' d P'ld r1 hraní u int 1r n h r 1hr ni. Id ) 1t. t n c r J B t l ) p > a J )\ ~lil t'.. ta n la r d i / )\ a t i nt ~' r n u í elník) ha i h m'lp )\'ani na h) ln )ty v k H1kr tnv h 11 likú i h. B z tavo\o t - ~ "tncj k rnp Hihilit~ \ í/íí 'l Ill }n ti ť 1I. Í h) r /\)_jal I lltjtn ~ti 'l ' t~ h /.mi n. (p /n.: p 1ra i. Jh: 1 u - ~, l. )c.: prt.: rn1 ln llíl t ht i ru.<.:." h rn r. \'\ h1incjsi. a \~\ ' lr \ lť ph1ií\~ni 1 priltn~. 1 \~ h,.. tanhrj)\... j(;n. s wt:b v) mi slu:.>h uni. I i t ). t 1n<.hr. 1 m ni 1 a r 1. i ujú : 1 )~ l 111 / v I nli 1btiaJ.nc /'li. tiť k 11/i. kn 'ÍU. spiitnú ~ tllp ~ tihilitu 'llc.: i k mp itil ilitu llh.: /Í -zn 'TllÍ ca ť, rn i r i c. c n i 1). ntr 'ln, da b ' z, luži b - / h\ l I 111 )/' n inl 1 r~ n~ :lujh. ť kti 'n z rad \ ýv<.. j )\'}' h n, str j \' \' r~írn i pr j ktu mu. h 1n iknút ntr ln ' z luži b. kt r ' )b:ahujc nickn inť)rm ' í it: ) jt.: in tliv~ h ~ltut di k aj inf n11 'i T't) p )] i 1davk 1 vyplynul 1 v pri t chu ri. cnia '\ b h implik ' n najn1a p )trcb )U r1istc:ni '1 vs )kc:j d )Stupn( sti a r )/~hcl ni 1 rit'- '/t.: c1 t t j takmer n yhnutn ' 111 pr dp( kladon1 I r implcmcnt" ciu t k h t ) ri. cnia. práva a dohl ad - Ricsc nic musel r )skytnúť n{ str )j<.: pn: t.: ť kt ívn\' d hl d, právu clej intcgračncj infr'l. truktúry Webové /užhj i'.~. n1 ssag111x Ako komunikačné tcchnol 1gic b )li posudz vané ari :mty vytuiti'l \\'cho )' h :luzi h n d htt (konkrétn na ad ním IBM Web. 'phcn.: ppli " lti )ll. cr cru) 1 n'1pr 1ti t )f11u Orient d Middl war (MOM) (k )nkrétne IBM W ~b phcrc ). Behom úvodn 'ho na adcnia b I r zhodnut ' orit:nt) ať sa prcd<. ctk ' 111 na b.,phcr Hlavným d" v <lom j ~ že Web 'pherc M je pr< dukt pri 1m ur :\ n, prc int gr 1u róznorodých aplikácií v het r g 'nn m prostr dl napr )ti h mu é sluzb I p m prípade pred tavujú tandard prc vlastné tcchn Jogickc rozhran ic, al na int gra n 111 t 'm stále o táva rie ni rady r z iahlych pr bl ' rn kt ré cb 1V : lužb n ric. i. Najvačšie obavy pojené na ad ním Web ph r M bolí p jen, m 1Žn u C'l o u r (t.j. s dlhšou dobou na prcno. práv) kt ráj z princípu u pn dukt v k t ' ri v 1a než u priamej ynchr ' nnej komunikácii. 11 li pret) vykonan ' zátažove k t kt r' I ti t obavy vyvrátili Prístup k budovaniu integračnej infravtruktúry Okrem volby Web pherc MQ ako integračn j technol gi kt rá významn vplyvnila podobu TIF bola takti ž rie ná t ' ~,ka aký1n p b m vybud vat vla tnú int ra nú infraštruktúru. V priebehu projektu boli zvažovan, ti t dv hlavn varianty : Definovat pravidlá pre dodávat I ov apliká if - na úr vni int gra n ho týmu definovat' pravidlá pre prácu právami MQ (formáty p ob volania atd.) a ponechat ťaži ko na rie it l'och zodpov dných za jednotlivé integrované aplikácie. Toto je cesta, ktorou a vel mi ča to integračn' pr j kty uberajú. Implementovať integračnú infra "truktúru v rámci pr ~ kt vého týmu - pripravit v rámci projektu adu modulov, ktoré pokrývajú v ob cn' požiadavky kladené na

38 mt 1 r~ nu inť t'tru tu 1 (/~thn1uj rnj r. J n tn~ :1 ~l )f 1/i. t ntn. /' h I nic: )tlllllli. i. \. lij-' iu "r f ' \ 1 J4', p): )h ~ t:trt.:nia t \ )\.k 1111 t ntn_. J s l. pr \} ink 'r u I \ t.. u it u ' ll: n tn) R )/h Jnut it: paj I \ pr )_ pt: h Jruhc.:j \ ari uh: im pkm nt \ ť intt 'f'l nú infr'l tru túru \ r n1 "'i pr jt:kt \' 'h ) t) nni. I )\ ) y i rt knt \ \ b r l hrr. kdt) n( p str ) st 'l p I i k á. i í 'l i ' h d )d á \'' t r \ \. " n n Ill n <.: hy : k ) In I li k ) \ 1 i ttr'. ltl. Zt b) h li kn :t' n n n pr 1vi 1~ a J \ 'lt li t h} > 1r n \" li i h :pint: ni.. I d/i Lrt:jmé ri1ik by patrili : nutn )~ť k Hnunik (Ít:., \)'~ '<.:tkni 1 d kénn p tu d d. v, t c r v nutno s ť k mp k. n ) h t<.: st h \l ' d I a t r,. 1 \ nt: s I taktiež 111 zn) ť ch) h \' spt: i tik" ii ka)th t 1k{ tl\ha h> r ){cil iúlm.: V ctk\ h dod, V'lk r \'. a c v\ fakt )í ct:ny 1ko j.1.n.:j m ~ / pn.:d hú i1:1j i t.: hl h du variant, dod, atcr impkm 'ntuj<.: r 1 H.Jra d tin van~ h Pí'l\'idi L /fl'hlh.:nah \' 'Zll' 111né d )I d ) h rrnon )gramu pr j<.:ktu t 1ktic.:J d) L<.:n) d bv k.. 1j\'i 1 j 1r jm~ )t; ly de d' atelia rnust:li ric. iť pod )hné itnpkmcnt 1 rh.: rh.hnic: t 1.h t ne b:. pakc van in1plcn1c11lovali r )Vnak n1<.: }nni~nny I n r ~ znyini d <t' v~ t lt11i r zn 'm pó obon1. Zn )Vupoužitel n t - ra/ priprn cn int gra nť m )duly je moint'. p 1k n uj'it prc d,al ic ric. enia a aplikáci 1 budovat k onccpčnú inkgra nú infr lstruktúru organizá ie., Uspech projektu Ukázalo sa ako výhodné~ že cel' intcgracn-í infra. truktúra boh bud n 'lná \ rám i pr )j tu nového k li nt k' h y ť mu -- ri cnic bol) pripra en<.: ( ch lo dt p d na pr )j t, dodávat I ov b li minimalizované aj mo/.n po cdať že u.1. pricbchu je lnch) pr )j ktu náklady na vybudovanic intcgračncj infra. truktúry z kazník< i zúro~ili. Organizácia zákazníka naviac zí kala prv tri dnu intcgračnú inf rastruktúru 11' b: z ktorá umožnila IT oddel niam rganizáci prac) ať s ovcťa ač. ou flc. ibilit u a r g ať rýchlejšie na požiadavky bu in u d padm i do viac rých syst To o tatné je už hi tória Moduly dodané v rámci projektu b li d z iatku k n ipc an' akc celk m bccn int gra n nástroje použitel'n' pr I ub v 1 né int gr n aktivity. Jeh najva u výh d u j jednoduchost a znovupoužitcl nosť maximálnym doraz m na cfi ktivitu na ad nia príno pre zákazníka. Vzniknuté moduly bol poločn ťou Tra k luti n vzat ako základ pr duktu Tra k Integration Framework ktorý j d alej rozvíjaný a r zšir vaný, používaný v rade dal ích riešení a u ďalších zákazníkov a pred tavuje vynikajúci základ pr konc pčné bud vanie integračnej infraštruktúry v skutočnom zrny le pojmu nt rpri rvic Bu. rí

39 3.4. Arch e, ura.\n.:hit ~ktúra I -u J 1.n 1.1 mt:n i n-1 na: k iuju )rn l uku. Obr zo k 19 : Z j d n od u n 1 r hit k hí r TI - u Tran portn rst vrstva 1aru UJU" prcn-i. mit: správ m J1i je n tlivúni b dmi P2P iet. Ob luh a práv - vr:t a 1.a )hal'uj ú 'a jcun tli ' ~ r )1.i 1<l vky a i h o l( )\''" I ) :prá\ deftn van j fi )rmy Qo - vr tva p kytujúcn dcfinovanú k 11itu slu.1ich Agenti - typové adaptéry (br' ny) prc uni c z lne vn lan i r )Zh r 1n i 1 r ~ 1.11 c h t J l ' h backendov Konektory - j dnodu ho p užitcl né kni7.ni pn.: intcgr: 'iu Tll:-u it fr nt nd \ ' h aplikácií konzumujúcich lužby ktívne kompon nty - množina aktívnvch komr )f1 nt< v kt ) f á roz. iruj int gr cn ~ m žn ti framew( rku Nástroje - množina užit čných ná, troj ) V ktoré 1jcdn )du. ujú spra ) ani a prá u vzniknut u infra truktúr u Transportná vrstva Transportná vrstva lúži na preno práv vytvár n_' ch z ú cl m vzáj n11nej k muniká i medzi jednotlivými k ne vými bodmi virtuálncj P2P si t. K n v b dy t jt P2P i t ú tvorené konzurncntrn i al b p kyt v a tel mi. luz i b. I ha týcht ) k ne vý h b d v j v rámci infra truktúry al r vn c nná. Transportná vr tva je primám tv rcná produktom firmy IBM IBM W b ph r MQ. T nt produkt bol vybraný prihliadnutín1 na predchádzajúc kú no ti jeho p uzívaním a po skúsenostiach jeho na adením u zákazník v v iných pr 0 kt ch. Tlf však nie je úzko patý touto implementáciou tran p rtnej vr tvy. J m žná j dn duchá zmena architektúry a použiti in 'ho MOM al bo in j tcchn I' gi na pr n práv. Pre TIF sú d6ležité nasledujúce kl účové vla tno ti po kytované MQ : Zaručené doručenie práv práve raz Asynchrónny prístup k správam

40 J nodu hý rn H11 )nn... ' a tn 1 t.' ir )h.. r Jr )ra pht ť )riun R ) h Ll "'UH ~ t 3 r r ah I i\ ť.' t 1 h i I i t 1 j i n i u h ) r l) / h r Tn i't Z hradl,ka sp )r 1hliv. ti tran. 1 )rtn j \ rst\ ~ j<..: r iru nt'. i ru nit: "f r i, n.1 \ s a d I p ) v l: d ať. l t: k r i t i. ~ ~. I n n. r ) rt n / \ r t \ a tll lj k n ) v) m i h dm i in fra. t ruk.tú~ i n k j t.: I~ i nt<.:...' r ~ n ~ 'r m " t r J... \ pr a. i n tu i [ d n \. I /'l r ll l t r r n i. Hl i ll r ' i t) 'h. r r i m v i Zaru en~ p)siclanic.: : pr~ \ t krl-m ~trat~ spr i\) run J1uj t tk.ti > duplik )\ miu. pr: pn zn )VU p )Sichní sprúv pt \ai ) Van~ h ta strakn(. O )fuccnic,právy je 1.aru ~ <..:né d )k. n "l 1j \ ' príp tc..k, ic: i t: I n \ t J akt nidd )r) pr )k n 1 ce t je d ča._ ne ncdt. tupn). Prí tup k j dn )ti i ) ch sprá varn s 1k vsc h ne nit: je.: r )Vn ak). / 1ru <..: né d ru vyžadujú najma práv repr z ntujú --e 1ktívn )J r1 1 m ni 1 (napr. plat bný príkaz). 'a in1hú stranu pasívnc opcrú ic (napr. 1ostat k na ú tc ncvyr dujú v takej 1niere nutn )..'ť zaru' ného d )flj 'ov'uii 1 sprav I n.:t )/ n m )/U : l.: hif nek nzi t nciu dát. A ynchr ' nn ť práv je dólcžitá prt: zaruče nic funk n )Sti systému ll'lpr. ' príp Hh.: Je i I<. ~ y témy b žia v iných casov)"ch int rval) h ncl: zdroj é sy tcmy. 1 t) as) n hrónn. t j zaručená porno u. ynchr nnych ťn nt kt ré posic lan~ spr í y p )dr/.i 1 ž d) a:u p<. k i I i h cielový prv k z fronty n vybcric. Rýc hl )Sť asynchr )nn h d ru ania spr1 je príp d bežiaceho y t ' mu prakticky r vnaká ako r "chk sť synchr nnc.:h ) d ru ) 111 ia :pr. apr. odosielanie práv prc datawarchou,c rcaltin1c. MQ po kytuje jednoduchú mc žno ť m m itorin gu aktivit transp )rtncj r:t. T nt monitoring slúži na vyhodnoc vanie vyťažcnia jcdn )tli ýc h hodo infra. truktúry. V rípad preťaž nia je m žn' ná ledne p dniknúť nápravné kn k pr r ru cni pi nul )."ti tun ' arna inte gračného riešen ia. Monitoring taktiež umožňuje I d vani. tavu jednotlivých k ne) ý 'h bc de infra ~ truktúry. Na základe ledovania zaplncnia fr nty ci rovéh y tému j napr. m žné id i.ntifik ť v ktorých y tém výkonn tn n tačí odp v dat na p žiadavk. MQ je podporovan' na ir k j palet plat~ riem d 7) (mainfr m ) c z iseries (A /400) až po M Wind w. 1 áto vla tn f po kytuje vač m n ti na ad nia inte gračného rie enia u ir i ho kruhu p t nciálnych zákazník v. Robustno t a pol ahl ivo t tran portn j vr tvy patrí k základným pr dp klad 111 nasadenia. k m r ného Stabilita a jednoducho t rozhrania pre prácu tran portnou vr tv u zaru UJ do tatočne efektívne a zároveň jednoduch, použiti t jto vr tvy v rámci int gračn 'h fram worku. Taktiež garantuje že nebude nutné ystém prepracovat pri zrn n tandardov čo je napr. problém webových služieb. Ďalšími podstatnými vlastnost ami MQ sú :

41 na ln n1 ) ) t in ) I h TL.lJll i. ~ ran:1 )rtll~ J \ inťr 1"tru J\nami ~\. ~. turu lllj r t \ r.1 ' ' ť na I l 11 l l ~ lil: /ú1'hdn~.rni \l'l\t:hn:mi ~ 1m~r mi 1 > u. Ut:Uc transp rtn j \ r t\.. {)ut:uc I 1anagt:r. : \lulll tl "lt 1t., ~ ) k_ tu i u,1 I( i \. n afn r J a I ) fp \'t:d~í /'l \: mí~f mi~ pr \v Jtl ' ( Ul'llť 1.Ul,t 1 crrní a <' rlllllll klicntmi. 'han nt: I.\ \t(mo\ i '-ILJ/t a i r r 1 t nu.: ~ lllhulik. ~ 1 i nh: i1 1 < ucuc rnvzáj )Ill a_j ~ i h ~lit:ntmi. 4 Jll "l Ka2d\ a~tívn\' k )11\P rh.:nt pri.i ímajú i \rr~\\ ~ mu i mať pnr.1 h. nú fr )n l...: c.. 1 kt )r J 1_1ann správy )d in~ ch komponerltt)\'. /. tc.it) ťnmt: m '>ic h hc.:rať pra : kn lllj rh. nt. kt r mu sú ticto správy urcené. Pokial' h) / _Jcdn J front. ) i lb<.: aln I r;n _ t' k m1 nt nt. malt h_ tieto k )mponcnty vyk HltÍvať ro\rrtkú Linn )\ť. ahy ncd "I) k ne.: kt<:1mm1~t1 k:n1 h >\ tlť 111 '"y t ' mu. 'Ít fr nt't n:pr / ntuj k m \ ~ b > i t )p I ) 'll Fronta k )Illp< ncn tu.1c ko1nponcnt )111. as! ne hrúnna. thjr; ia \ 1 prijatc \pr n y a/ d ) i h \ \ / hi hnut ia h nel ager Co o nt Ohr '.1.ok 20: Pripoj na ompon ntu tr n portn j r t i 1, j ú h komp ncntu na mcr ať d) fr nty prij ímajú cho k )mponcntu. 1, kt< \ 1nikn pr p j ni rn dzi od._ i Jater )(TI a prij Ímatc ť )Jll spr-' \'\. d 1Si laj Ú j ~om p )J1CJ1l m{ Žť gcncr) ať Spí, V_' prc prijím júci k< n1p nene kt I',' ich jednu p dn1h j postuj n. pr uj. Pr e j cd n duch ' z, r.j íll j d 1l é h () ( do" i dat d' a ~ t ') í d c h 'Í JI aj ú. c ~ r rá \ ~ od )

42 c u ni tn e ft J f u Prt: um in ni lh)j m<.:rrh:j ~ '11Hmi~4 it m i1i ' 'Ill; j 'Una ťr HHa \ "a1j )m ~m íl" J r ll l~ll I r~ \ I. l r. 1 I uch o v ú \'a : I r~i \' y p u tu J u t.: <.: k n \ J c ln 'm m c r ť n l c i 11 ) n c i t 1 n 1 frn nt y s ú n )\ n ) e n ne a i c h r l) / I i n \ ltl i c na ( 11 ad a u t j J t h jt:dnt:j ťront: h )I( nun l/ll~., a llnrr tln n t kn Compon nt g r Ohr10~2: ~horn oh m njk>mun Pr zapojeni d\') h \'Z'lj Hnn knmuníkujú 1d k 'nlp )fl(jlt \. t) í ~u\ ~ 111 je rnoiné r HJ.i:iť UV'l ( w:ue. 1 '111'1 'l' -. 'ť/ ~tnr. \l'l.jpfllll't "lfllllni~ ; í t r n.:tc":i. <.: \"., k nutné vvtv )riť srccific"~ ťn nty < dk 11u.Jú 't a rn,., ltakm: front: in: \Jdial n prq ~ mc Tict fronty sa nak )IlfígunlJÚ 'l r Hl1 ~Hl tran flú\ i Hl qu Uc.::-. 1 k tnúln\. 1 I t_. ht) ~~v i rtu á In y c h fr rn t sr r á vy a u tomat i, " : p n. n <.: "ú J ) / J i ti n h i d' ) ~ h ťr HH. " k ú. prac vané cit:rc v) m k mp< ncnt Hn. r )t) ri \cnie "lúji aj ak ) ur it~i rll< ha J ri v." r ku zdialcn ' ho ucuc 'tnagcra, kecly sa p )SJ lané "Pr<'1\ y nc~t at1a a. ú u hc)\ ~rn( lc k:'tln m ueuc Manager) i v j ho tran~m ission qu u ~. Tot zapojcnic je taktic.í r )U7.Í ané rri k<hlhhli" :tcii \ \}~nko 1ahc1p l n\rni ~ ncnn1. ul žený mi napríkjad V <lcmílit ffí/.o\"ll1<:j l.úl1t:. t 1k Hl1 rrípa<.k,í<.: moi'n. \ '\Ulit fakt /C.:. pr p j nic Qucuc M rnagcrov rnú1c inici 1li11\'tť ktor~k )l\ck / ni h Component Queue anager Ou u anag r C m n nt Obr 1.ok 2 : K omunik i Vldi I n.' h h do Pri nap ~ ní v1a r< h k nzurn nt v lujhy j p tr bn dcfin v t a dp v dajú e c dkazy íl' ti t fr nty pr ú. p. nú k munik ' iu. n ti i fr nt - 4.._ -

43 Corrpon r t -- ) /C)k - :,, J>lj ni( \i O /U l fr\ p č c t I ar )j c n \ ' h " l m i r H.: nt I) \ d ). d \) " I t ()I I\ l ' I. I \ I t I l la ) I i. ' t. ' l. h r i<.: n ť. Ph t Í'l j ~ In lu h ~ I ra \ 1 d I a : K a.i I~ " )mp )fh.:nt prij1maju i ~J r ~ n~ mu't mať f n: knt lu I r ntt. t l (( t1 ' spravy rn_pma 1 je nu fr Hltu J llllljll ~pr~í\ y kn Jtdn. m. rn r ljll F r rn ta u r uj t: k n "\ oj ho r r í j c m u. ' t ) ~i <.:I a t d' t n i c. f>p i ul r H: i s v oj ~ p ) I i a J n l.: \ i ~h.: c r í.. k n n / u m <.: nt i. \, ta " n m J 1 pa i J <. i J c nt i f i k ~ í i a ťr n t ~ J ) " t H c i m i h > ť ' J ) I l: n ~, J r )' d. tn nt ' kl r l lili. > k i " Postupnýrn budovaním _jt: rn inl~ v:t }riť d '-lt'lto nl' rohu tnťi intn trukturu " h )pnú J lniť požiadavk) na \ 'l'í.í HlH1Ú ~omunik~í iu \ nút rn~ h h J )\ "lflf I r: ic. ) # } I / /, ) I ) -- I ( hr / k 2 : Príkl d ri. na < 1 lot n m n TI F

44 Obsluha správ Vrstva spravujúca správy je v rámci architektúry TIF-u po tav ná nad transportnou vrstvou a slúži na ul'ahčenie a zjednotenie práce s aplikačnýrni právami prenášanými transportnou vrstvou. Táto vrstva umožňuje serializovať a deserializovať aplikačné správy do ' a z' podoby v akej sú prenášané transportnou vrstvou. Prenášané správy majú dva možné podporované formáty Formát XML dokumentu Formát pevných dížok Oba formáty správ sú určené spravy. ' na prenos tých istých dát. Líšia sa len formátom prenášanej Správa vo formáte XML dokumentu je textový reťazec obsahujúci validný XML dokument definovanej štruktúry. Jednotlivé prenášané dáta sú v tomto XML dokumente reprezentované ako hodnoty tagov tohto dokumentu. Jednotlivé tagy popisujú parametre správy, ktoré reprezentujú. </he;:,d> I. I Obrázok 26 : Správa vo formáte XML Správa vo formáte pevných dížok je textový reťazec obsahujúci dáta lineáme zoradené za sebou bez akýchkol'vek oddel'ovačov. Vytváranie a čítanie týchto správ je možné len za pomoci znalosti presnej definície správy, to znamená jednotlivých dátových typov, dížok a poradia prenášaných dát oboma komunikujúcimi stranami. Použitie tohto formátu je určené pre systémy s extrémnymi požiadavkami na výkonnost'. Vznikal potrebou zjednodušenia parsovania správ v natívnych implementáciách komponentov na tomto systéme a nutnosti maximálnej rýchlosti spracovávania správ. Vačšinou sa však pri vzájomnej komunikácii používajú správy formátu XML. Dáta prenášané správou sa rozdel'ujú na dve oddelené logické časti Hlavička správy Telo správy

45 správy obsahuje dáta povinné pri každej vzájomnej komunikácii. Patria sem položky, ktoré identifikujú samotnú správu, komunikujúce strany, časové razítka a r6zne systémové položky. Dáta hlavičky popisujú samotnú správu. Hlavička Telo správy obsahuje prenášané aplikačné dáta. Tieto aplikačné dáta sú jednoznačne popísané definíciou služby, ktorú daná správa obsluhuje. Táto definícia popisuje jednotlivé parametre požiadavky i odpovede, ich dátové typy ako aj jednotlivé vel'kosti a presnosti dát QoS Vrstva ktorá pridáva určitú množinu rozširujúcich funkčností nad spodnými vrstvami. Táto vrstva poskytuje nasledujúcu pridanú hodnotu: Identifikácia komunikujúcich strán Overovanie identity komunikujúcich strán Sémantická kontrola správy Error handling Logging Alerting Load Balancing & Error handling Identifikácia komunikujúcich strán je založená na automatickom doplňovaní atribútov identifikujúcich odosielatel'a správy do odchádzajúcich správ. Tieto identifikačné údaje následne slúžia na identifikovanie jednotlivých užívatel'ov služieb backendu ako aj pri logovaní požiadavkou. Digitálne podpisovanie správ slúži pre overenie identity vzájomne komunikujúcich strán. Overenie identity protil'ahlej komunikujúcej strany je důležité pri výmene citlivých údajov pre zabránenie neoprávneného využívania služieb neznámym konzumentom. Vo frameworku sa využíva symetrická šifra jednoznačne definovaná pre každú komunikujúcu dvojicu strán. Touto šifrou sa digitálne podpisujú správy prenášané frameworkom. Sémantická kontrola správ slúži na overenie obsahovej správnosti vymieňaných správ. Kontrola správnosti je založená na kontrole jednotlivých parametrov správy. Kontroluje sa dátový typ, vel'kosť a poprípade presnosť jednotlivých parametrov. Error handling poskytuje mechanizmus jednotného a presne definovaného ošetrenia chybových stavov vzniknutých na jednotlivých komponentoch frameworku alebo pripájaných frontendoch a backendoch. Tento mechanizmus zahrňuje presnú identifikáciu chyby, jej kategorizáciu a následné spracovanie pomocou ďalších QoS ako sú Logging a Alerting. Error handling zohl'adňuje pasívnost' I aktívnosť správy. Logging je nástroj na sledovanie činnosti jednotlivých komponentov frameworku. S ledovať je možné používanie jednotlivých backendov, transportnej vrstvy ako aj volania jednotlivých frontendov. Sledujú sa relevantné udalosti vzniknuté počas behu systému. Vďaka logovaniuje možné spatne dohl'adať dianie na jednotlivých komponentoch a poprípade i dohl'adať okolnosti vzniku prípadnej chyby.

46 Alerting je mechanizmus hlásenia vzniknutých chybových stavov na príslušné definované miesta, ktoré zaručia návrat systému do konzistentného stavu a postarajú sa o zistenie príčiny chyby a obmedzenie jej ďalšieho vzniknutia. Adresátom alertingu je vačšinou dohl'adové centrum a použitými nástrojmi sú špeciálne chybové fronty transportnej vrstvy alebo ová notifikácia o vzniknutej chybe. Error handling, logging a alerting sú vysoko účinné metódy pre správu, zotavovanie sa a následnú opravu vzniknutých chýb budovaného riešenia. Load Balancing a Error Handling sú v TIF-e primárne riešené s využitím možností, ktoré poskytuje produkt WebShere MQ. Využívajú sa tieto mechanizmy: Možnost' nasadenia viac aplikácií (alebo viac výpočtových vlákien jednej aplikácie), ktoré vyberajú správy z jednej fronty a následne ich spracovávajú. Tieto aplikácie možu bežať na róznych serverech. Za normálnych podmienok dochádza k rozprestretiu záťaže a v pripade výpadku jednej z aplikácií druhá funguje ako záloha zaisťujúca spracovanie všetkých požiadaviek. Možnost' distribúcie požiadaviek na vačší počet MQ Queue Managerov s využitím MQ Clusteringu. Pokial' je určitá fronta publikovaná do clusteru viacerých Queue Managerov, MQ infraštruktúra automaticky rozprestrie požiadavky do všetkých dostupných publikovaných front. V ďaka tomu dochádza k rozprestretiu záťaže na vačší počet Queue Managerov, ktorí možu bežať na róznych miestach a poskytovat' týmto spósobom zálohu riešenia. Kombinácia predchádzajúcich dvoch prístupov sa nakoniec osvedčila. Požiadavky sú smerované do dvoch Queue Managerov na róznych serveroch, nad každou frontou následne pracujú dve aplikácie, každá na zvláštnom serveri. V ďaka tomu dochádza k minimalizácii rizika výpadku l'ubovol'ného Queue Managera, l'ubovol'ného serveru i aplikácie. /QJ Component TIF Cluster Component Obrázok 27 : TIF Load Balancing & Backup Agenti Agenti sú univerzálne komponenty tvoriace vrchol vrstvy architektúry, ktoré slúžia na aktívne pripojenie existujúcich backendových komponentov do vytváraného systému

47 Tvoria posledný blok pred samotným integrovaným backendom. Vo vačšine prípadov sú pripojeníjedna kjednej k danému backendu. Agenti tvoria bránu k danému backendu. Agenti slúžia na jednotné integrovanie služieb backendu do servisne orientovanej architektúry. Služba backendu je následne prístupná jednotným spósobom nehl'adiac na skutočný komunikačný protokol backendu. Táto brána transformuje volanie unifikovanej služby na volanie služby backendu. TIF Agent Obrázok 28 : Zapojenie backendu pomocou agenta S daným backendom komunikujú za pomoci natívneho rozhrania daného backendu. Jednotlivé natívne rozhrania s implementované r6znymi Pluginmi, ktoré sa po nakonfigurovaní zasunú" do Agenta, čím je umožnená komunikácia Agenta s backendom pomocou natívneho rozhrania. Tento sp6sob stavby Agentov umožňuje jednoduché rozšírenie možností frameworku o podporu ďalších typových i atypických druhov backendov podl'a potrieb zákazníka. Pluginy riešia všetky otázky ohl'adom prepojenia backendu Zabezpečenie natívnej komunikácie s backendom Transf ormovanie natívnych dátových typov do dátových typov frameworku Obsluhu chybových stavov backendu Transakčnosť backendov Prehl'ad existujúcich Pluginov umožňujúcich integrovanie natívnych backendov Názov Pluginu Popis Plu2inu Plugin pre natívny prístup do serverovej aplikácie postavenej nad TIF Plugin for Oracle DB Oracle. TIF Plugin for SQL Plugin pre natívny prístup do serverovej aplikácie postavenej nad Server DB MS SQL Server. Plugin pre natívny prístup do serverovej aplikácie postavenej nad TIF Plugin for ODBC databázou dostupnou cez ODBC. Plugin pre natívny prístup do serverovej aplikácie postavenej bázy TIF Plugin for COM technológie Microsoft COM. Plugin umožňujúci volat' štandardné serverové komponenty v rámci TIF Plugin for EIB J2EE aplikačného serveru. TIF Plugin for Plugin pre natívny prístup do serverovej aplikácie s rozhraním na W ebservices bázy Web Services

48 TIF Plugin for S2S TIF Plugin for iflex Specifický plugin pre aplikáciu iflex Flexcube Connect. Sanchez Plu in Plugin for Optical Archive Š ecifický re DMS a likáciu eistream Ente rise. TIF Plugin for IBM Content Manager Špecifický plugin re DMS aplikáciu IBM Content Manager Konektory Klientské rozhrania umožňujúce infraštruktúry. zapojenie frontendových komponentov do komunikačnej Sú distribuované ako knižnice jednoducho použitel'né z kódu klientskej aplikácie. Volanie jednotlivých služieb je vel'mi jednoduché a odtieňuje klientskú aplikáciu od nutnosti znalosti princípov fungovania frameworku. Poskytuje taktiež všetky pridané hodnoty frameworku. Volanie služieb je pomocou konektorov zjednodušené na maximálnu možnú úroveň. Q '.>( == r;ff!j : ~. 'r--'.. ~ : :.... '.. ; :: :tif: : c:o.on.e čt0 r : [S L Q,2J.rv BE.... J.'. : LQJ cs.()f2j ~... ~~~.. ~... BE B:E LQ.J [JQ] BE Obrázok 29 : Zapojenie TIF Connector-u Umožňuje vygenerovanie Proxy" tried, ktoré vďaka predgenerovaným settovacím a gettovacím metódam urýchl'ujú vývoj klientskej aplikácie a zjednodušujú používanie Konektoru pri zmene služieb. Momentálne sú podporované trijazykové mutácie Konektorov TIF Connector for Java TIF Connector for C TIF Connector for COM

49 Tieto tri jazykové mutácie zaručujú dostatočne širokú využitel'nosť Konektoru v r6znych programovacích jazykoch a tým pádom poskytujú dostatočné možnosti integrácie frontendových aplikácií do riešenia Aktívne komponenty Aktívne komponenty je množina komponentov integračného frameworku umožňujúcich riešiť r6zne integračné úlohy. Momentálne je k dispozícii množina komponentov TIF Backend Simulator TIF Router TIF Inspector TIF Publisher TIF B2BGateway TIF Backend Simulator - komponent na simulovanie odpovedí správ podl'a obsahu (Content Based Simulation). TIF Backend Simulator na základe konfigurácie vyhodnocuje obsah správ a buď na danú správu simuluje odpoveď, alebo ju prepošle na ciel'ový backend, ktorý už danú správu obslúži. Tento komponent je vhodný pri vývoji nového backendu za situácie, keď je potreba volat' služby ešte neimplementované daným backendom. _ F,~, ~ ~ É99h J FE TtF Backend Simulator BE Obrázok 30 : Zapojenie TIF BESIM-u TIF Router - komponent vykonávajúci Content Based Routing. Prijímané správy, na základe definovaných pravidiel popisujúcich obsah správy, preposiela ďalej na príslušné ciel'ové backendy

50 BE FE BE [ J [_?~ BE Obrázok 31 : Zapojenie TIF Routera Tlf Inspector - komponent schopný aktívne načítávať dáta z daných backendov a následne takto získané dáta vo formáte volaní špeciálnych služieb. distribuovat' do integračnej infraštruktúry, v rámci ktorej mažu byť dáta spracované. TIF lnspector umožňuje riešiť replikačné úlohy. Data TtF lnspector TIF Obrázok 32 : Zapojenie TIF lnspectoru Tlf Publisher - Aktívny komponent vykonávajúci mikroworkflow nad prichádzajúcimi správami. Jednotlivé mikroworkflow procesy sú definované za pomoci zásuvníkových Java tried implementujúcich špecifickú funkčnost'. V rámci tohto mikroworkflow je možné takisto volat' ďalšie komponenty a využívat' služby nimi ponúkané

51 [Q] C?i?J BE ~ / LQJ C?QJ BE FE TIF Publisher Obrázok 33 : Zapojenie TIF Publisheru TIF B2BGateway- Komponent integračného frameworku slúžiaci na prepojenie konfederácie s jej obchodnými partnermi. Pomocou TIF B2BGateway je možné poskytnúť definované služby obchodným partnerom. Tieto služby majú presné definície a tvoria rozhranie poskytované organizáciou extemým partnerom. TIF B2B Gateway kladie vysoké požiadavky na bezpečnosť ponúkaného rozhrania a zároveň jednoduchost' použitia. Preto je súčasťou TIF B2B Gateway aj komponent TIF B2B Connector, ktorý slúži na jednoduchú a bezpečnú komunikáciu s TIF B2B Gateway zo strany partnerskej organizácie. '\. 'Jť / I/' gjt TIF 828 Connector.,. :~ trn Internet "\ )~--\ ~.. Sl TI F 828 Connector Nástroje Obrázok 34 : Použitie TIF B2B Gateway a TIF B2B Connectoru Nástroje ponúkané integračným frameworkom tvoria množinou podpomých programov pre ul'ahčenie a zjednodušenie práce s infraštruktúrou a integračným frameworkom samotným. Množinu nástrojov ponúkaných TIF-om je možné rozdeliť na nástroje pre vývoj a nástroje pre podporu samotného behu riešenia

52 Vývoj o o Beh o o o TIP Tester TIP User Rules Editor TIP Monitor TIP Remote Controll TIF Security Utils TIF Tester - program pre testovanie funkčností ponúkaných jednotlivými backendami. v Nástroj poskytuje grafické rozhranie pre zjednodušenie ovládania a efektívnu prácu. Casté využitie tohto nástroja spočíva pri vývoji nových služieb na backendoch. TIF User Rules Editor - nástroj pre spravovanie pravidiel pre Content Based Routing a Content Based Simulation. Grafické rozhranie zjednodušuje prácu s týmito pravidlami, umožňuje definíciu užívatel'ov oprávnených spravovat' pravidlá. TIF Monitor - aplikácia s webovým grafickým rozhraním určená pre monitoring transportnej vrstvy. Pomocou tohto nástroja je možné monitorovat' vyťaženie jednotlivých prenosových liniek transportnej vrstvy, zisťovať preťaženosť jednotlivých front. Zo zistených údajov je možné poprípade doladit' konfiguráciu transportnej vrstvy pre optimalizovanie zo strany požiadaviek na beh systému. TIP Remote Controll - nástroj pre vzdialené sledovanie činnosti bežiacich Agentov. Nástroj umožňuje sledovat' stav komponentov, štatistiky vykonávania jednotlivých služieb, chybovost' behu komponentov a umožňuje aj daný komponent zastavit' alebo reštartovať. TIF Security Utils - nástroj pre zjednodušenie administrácie zabezpečenia jednotlivých komponentov infraštruktúry Definície služieb Pre vytvorenie integračného riešenia je nutné určitým jednotným sposobom definovat' rozhrania jednotlivých služieb ponúkaných systémom. Táto definícia musí obsahovat' dostatočné množstvo metadát pre zaručenie použitel'nosti definície v rámci integračného frameworku. Konektory na základe definície služieb umožňujú volanie danej množiny služieb a sú schopné vytvoriť správnu správu volajúcu danú službu. Na základe tej istej definície konektor spracováva aj prípadnú odpoveď na požiadavku. Táto definícia je d6ležitá aj pre koncových Agentov, aby holi schopní zavolat' správne služby na backendoch a korektne pracovat' so správnymi dátovými typmi parametrov volania a vytvoriť odpovedajúcu odpoveď, akje požadovaná. Aktívne prvky TIF-u vďaka definícia služieb dokážu korektne pracovat' s jednotlivými správami a vykonávat' na nich definovanú funkčnost'. Definície služieb preto obsahujú nasledujúce položky Popis služby - názov, verzia, popisok, príznak aktívnosti

53 Popis jednotlivých parametrov služby - smer, dátový typ, presnosť, vel'kosť, povinnost' Informácie pre Agenta umožňujúce správne spracovanie služby na backende - napr. natívny dátový typ backendu, mapovanie na parametre služby atď. Definície služieb sú uložené do dvoch možných dátových úložisko XML súbor - súbory presnej štruktúry definujúce všetky potrebné atribúty služby pre jej úspešné použitie. Táto konfigurácia je uložená vačšinou u komponentu využívajúceho danú definíciu. Umožňuje definovat' pre daný komponent presný zoznam služieb. DB - definície jednotlivých služieb sú uložené v centrálnej databáze. Táto databáza eviduje u každej definície identifikátor backendu, ktorý danú službu poskytuje. Poskytuje možnost' centrálnej správy definícií na jednom mieste. Komponenty však k týmto definíciám nepristupujú, databáza sa využíva na generovanie XML definičných súborov. Databáza tvorí centrálne úložisko definícií služieb (metadata repository), ale nie je priamou súčasťou infraštruktúry a nevytvára riziko pri výpadkoch Použitie TIF slúži primáme na flexibilné prepojenie servisne orientovaných komponentov konfederácie (SOA). Tieto komponenty možu byť heterogénneho charakteru. Poskytuje možnost' rýchleho ajednoduchého rozšírenia systému o novo integrované komponenty. Skrátene povedané Configuration-based integration of heterogeneous shared services". Umožňuje taktiež vytváranie kompozitných služieb používajúcich pre svoj beh volanie ďalších dostupných služieb riešenia. ' i~j~ ' BE -- i'' i j~ FE /. ~/ FE TIF BE. BE. Obrázok 35 : Použitie TIF pre riešenie SOA Ďalším integračným scenárom riešitel'ným pomocou TIF-u je replikácia dát založená na udalostiach (Event Driven Architecture - EDA). Integračný scenár rieši problém nutnosti rýchlej distribúcie udalosti v systéme

54 \~RL ~r:,..,;_2j} v.,~ ~ Event BE ;$;._''.''~~i<,..,, i ~ I~ BE Event TIF Obrázok 36 : Použitie TIF pre riešenie EDA TIF taktiež umožňuje riešiť problémy Extract, Transform and Load (ETL). Tento pojem zahfňa prenos objemných dát vačšinou vo forme dávok, ktoré sa zreplikujú z jedného dátového zdroja do iného (viacerých) dátového zdroja. Pri prenose dát može dochádzať k ich transfonnácii. Data Data TIF Data Obrázok 37 : Použitie TIF pre riešenie ETL TIF podporuje integráciu Business to Business (B2B). Tento integračný scenár rieši problém prepojenia spoločnosti s jej obchodnými partnenni a sprístupnenie určitej množiny služieb pre obchodných partnerov

55 Partner Obrázok 38 : Použitie TIF pre riešenie B2B TIF poskytuje možnost' riešenia všetkých integračných scenárov v rámci jednej inštancie TIFu. Riešenie týchto scenárov pracuje vačšinou so zdiel'anou množinou zdrojov (infraštruktúry TIF -u i in:fraštruktúry organizác i e) Predpoklady pre možné použitie Pre úspešnú integráciu komponentov konfederácie za pomoci integračného frameworku TIF je nutné splnit' určité predpoklady Predpoklady kladené na backendy Backend musí poskytovat' rozhranie v natívnom jazyku, cez ktoré je umožnené volat' poskytované služby. U integrovaných komponentov sa predpokladá existencia servisných služieb pre možnost' monitorovania stavu a identity integrovaného komponentu. U poskytovaných služieb sa predpokladá existencia servisných parametrov, ktoré vypovedajú o výsledku volania služby a poskytujú podrobné inf ormácie o stave vzniknutých udalostií pri spracovaní požiadavky v komponente. Tieto požiadavky vznikli za účelom zvýšenia úrovne QoS integračného frameworku Predpoklady kladené na frontendy Schopnost' integrovat' a volat' TIF Connector slúžiaci na volanie služieb poskytovaných systémom Predpoklady kladené na dátové zdroje Poskytnutie rozdielových dát, ktoré sú aktívne načítané a posielané. Možnost' zapisovania (ukladania) výsledku replikovania dát do dátového zdroja. Schopnost' generovania udalostí pre úspešné riešenie EDA

56 3.8. Vlastnosti TIF Základné vlastnosti TIF je Enterprise Service Bus pre prepojenie, sprostredkovanie a spravovanie interakcie medzi koncovými bodmi konf ederácie. TIF je middleware. Je to software pre vzájomné prepojenie softwarových komponentov za účelom podpory distribuovaných aplikácií. Integračný framework založený na výmene správ pomocou asynchrónnych front. Formát správ je intemý, definovaný frameworkom. Správy majú charakter XML dokumentov. Systém integrovaný pomocou TIF-u splňuje charakteristiky Service Oriented Architecture. TIP poskytuje volaniajednotlivých backendov ako služby ponúkané systémom. Definície jednotlivých služieb majú formát XML súborov popisujúcich službu a jej jednotlivé parametre. v Dalšie vlastnosti Podpora synchrónnych správ - celkovo sa systém aj napriek asynchrónnemu posielaniu správ može javiť ako synchrónny. Táto vlastnost' je dosiahnutá vďaka koncovým bodom systému, ktoré zaobal'ujú asynchrónne posielanie správ a pomocou vhodného párovania správ sa komunikácia navonok javí ako synchrónna. Využíva konektory pre pripojovanie existujúcich aplikácií do systému - pre typické aplikácie poskytuje middleware sadu konektorov, ktoré dokážu komunikovat' s týmito aplikáciami pomocou ich natívneho rozhrania. Tieto konektory prekladajú dátové formáty koncových aplikácií do intemého formátu a opačne. Štandardizovaná bezpečnost' - middleware pre intemú komunikáciu medzi uzlami siete používa štandardizovanú bezpečnost' na úrovni transportnej i aplikačnej vrstvy. Pre komunikáciu s konkrétnymi koncovými aplikáciami je bezpečnost' zaručená konkrétnymi metódami zabezpečenia jednotlivých typov koncových aplikácií. Validácia dát - pre tok dát v systéme je doležitá i určitá kontrola dát a to nielen kontrola formátu dát, ktorá je důležitá hlavne pre transformáciu dátových formátov, ale aj kontrola správnosti roznych dátových typov. Kontrola dátových typov može mať za dosledok odl'ahčenie transportnej vrstvy, keďže chybné požiadavky sú odfiltrované už pri vznesení požiadavky na middleware a nie sú propagované až do koncových uzlov, kde by pri ich validácii zistené chyby museli byť propagované spat'. Validácia dátových typov prebieha na základe definícií služieb kde sú uvedené práve aj dátové typy posielaných dát. Správa chýb - pre správny chod systému je doležitá správa chýb. Spravovanie chýb je implementované na roznych úrovniach. Od propagácie chyby koncového bodu spat' do volajúcej aplikácie až po evidovanie chýb jednotlivých koncových systémov a následné preposielanie týchto chýb administrátorom daných systémov. Podpora Event handling - middleware podporuje publikovanie udalostí vznikajúcich na koncových aplikáciách. Konektory aktívnym poolovaním vyhl'adávajú propagované udalosti, ktoré sú pomocou aktívneho prvku middlewaru Publisher implementujúceho business logiku publikované do koncových aplikácií systému za pomoci volania služieb týchto aplikácií