Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Magisterská práce Event Driven Integration Pattern s podporou distribuovaných transakcí napříč heterogenní aplikační infrastrukturou Bc. Ondřej Michalčík Vedoucí práce: Ing. Müller Tomáš 18. června 2012

4

5 Poděkování Na tomto místě bych chtěl poděkovat panu Ing. Tomáši Müllerovi za jeho rady, užitečné nápady a připomínky k této práci. Poděkování patří také mé rodině, která mě po celou dobu studia podporovala.

6

7 Prohlášení Prohlašuji, že jsem tuto práci vytvořil samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některý zákonů (autorský zákon), nemám závažný důvod proti užití tohoto školního díla a k užití uděluji svolení. V Praze dne 18. června

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Ondřej Michalčík. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Ondřej Michalčík. Event Driven Integration Pattern s podporou distribuovaných transakcí napříč heterogenní aplikační infrastrukturou: Magisterská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

9 Abstract The goal of this thesis is to design and to implement a way of distribution exchange rates across the application infrastructure of client from the banking sector. The purpose of this project is to send a new exchange rate in transaction for all applications that work with the current exchange rate. Pattern, which performs the actual transfer of exchange rate is implemented on WebSphere ESB. To ensure that the operation will be transactional, it is used distributed transactions (XA transactions). The interesting aspect of this pattern is that the transaction takes place over three different application environments:.net, Java, Oracle. Keywords pattern ESB, XA transaction, middleware, web service, SOA, integration Abstrakt Cílem této práce je navrhnout a implementovat způsob distribuce kurzovního lístku napříč aplikační infrastrukturou klienta z bankovního sektoru. Účel tohoto projektu je transakční rozesílání nového kurzovního lístku všem aplikacím, které s kurzovním lístkem pracují. Patern, který obstarává samotný přenos lístků je implementován pro WebSphere ESB. Pro zajištění transakčnosti této operace je využito distribuovaných transakcí (XA transakcí). Tento transakční patern je zajímavý tím, že transakce probíhá nad aplikacemi ze třech různých prostředí:.net, Java, Oracle. ESB, XA transakce, middleware, webová služba, SOA, inte- Klíčová slova grační patern 9

10

11 Obsah Úvod 17 Motivace Cíl práce Struktura práce Použité technologie Enterprise Java WebSphere Application Server WebSphere ESB Oracle RDBMS Microsoft Windows Communication Foundation (WCF) Microsoft SQL Server Internet Information Services (IIS) Servisně orientovaná architektura (SOA) 25 3 Enterprise service bus (ESB) Co je to ESB? Proč potřebujeme ESB? Přínos ESB Základní komponenty ESB Paterny na bázi ESB Paterny funkční Paterny interakce XA Transakce Komponenty XA transakce Dvojfázový commit Analýza a návrh Analýza požadavků Analýza architektury Návrh demoverze řešení

12 7 Realizace Projekty Implementace mediačního paternu Testování Pozitivní testovací scénář Negativní testovací scénář - chyba v Java webové službě Negativní testovací scénář - chyba v.net webové službě Vyhodnocení testování Závěr 79 Literatura 81 A Seznam použitých zkratek 83 B Obsah přiloženého CD 85 12

13 Seznam obrázků 3.1 Nahodilá architektura[1] ESB architektura[1] Hlavní komponenty ESB[1] Přesun od synchronního volání vzdálené metody k asynchronní výměně zpráv[1] Cesta zprávy přes ESB architekturu[1] Point-to-point a publish-subscribe modely prenosu zpráv[1] Propojení služeb s ESB s využitím ESB endpointů[1] Základní komponenty správy zařízení ESB[1] Patern virtualizace služeb Patern zpřístupňování služby Patern Brána Integrace založená na zprávách Událostmi řízená integrace Jednosměrné doručení zprávy Synchronní čtení requestu Beztransakční synchronní update Synchronní update s globální transakcí Synchronní update se zpětnou vaznou Komponenty XA transakce Sekvenční diagram dvojfázového commitu Analýza paternu Schéma zprávy Diagram nasazení komponent Návrh paternu pro demoverzi Vlevo workspace javy, pravá část je řešení.net služby Implementace mediačního paternu Implementace mediačního paternu Mapování zprávy pro webové služby Mapování zprávy pro tabulku s metadaty Mapování zprávy pro tabulku s kurzem měny

14 8.1 Sekvenční diagram pozitivního testovacího scénáře Screenshot servletové aplikace s odesíláním kurzovního lístku s CZK Výpis z logu WebSphere aplikačního serveru Výpis z logu WebSphere ESB Výpis z logu.net webové služby Sekvenční diagram negativního testovacího scénáře s chybou v Java webové službě Screenshot servletové aplikace s odesíláním kurzovního lístku s USD Výpis z logu WebSphere aplikačního serveru Výpis z logu WebSphere ESB Sekvenční diagram negativního testovacího scénáře s chybou v.net webové službě Screenshot servletové aplikace s odesíláním kurzovního lístku s EUR Výpis z logu WebSphere aplikačního serveru Výpis z logu WebSphere ESB Výpis z logu.net webové služby

15 Seznam tabulek 8.1 Tabulka s vyhodnocením testovacích scénářů

16

17 Úvod Motivace Přístup k softwaru, tak jak jsme jej donedávna znali, se mění. S rostoucím počtem aplikací roste i potřeba vzájemné spolupráce či komunikace těchto aplikací. Programy, které byly využívány jako samostatné celky, bez jakékoli vazby na okolí již ztrácí uplatnění. Naopak se zvyšuje potřeba větších softwarových řešení, které integrují funkcionalitu více izolovaných aplikací. Pro drtivou většinu společností je výměna softwarového vybavení z několika důvodů nemyslitelná. Jednou z příčin je samozřejmě finanční náročnost takového rozhodnutí, ovšem v některých případech taková změna není možná, protože neexistuje adekvátní náhrada za stávající aplikace. V této diplomové práci je řešen projekt pro jednu z předních českých bank. V této společnosti mají podobný problém nastíněný v úvodním odstavci. Konkrétně se jedná o distribuci kurzovního lístku napříč aplikačním spektrem této banky. Protože finanční ústavy potřebují pracovat s aktuálními kurzovními lístky, je nutné tyto lístky aktualizovat od nadřazené autority. V naší republice je touto autoritou Česká národní banka. Při změně kurzů měn v České národní bance jsou jednotlivé tuzemské banky informovány o změně kurzovních lístků. V bance jsou poté nové kurzovní lístky staženy a uloženy v přechodné databázi. Aktuální stav je takový, že architektonický návrh šíření kurzovního lístku napříč aplikačním spektrem je neuniformní. To znamená, že každá z aplikací provádí update kurzovního lístku jiným způsobem. Dalším nepříjemným aspektem je, že část aplikací dokáže tuto aktualizaci provést transakčně a druhá část nikoliv. Z těchto důvodů je nutné do této infrastruktury zavést automatizovaný proces, který dokáže transakčně vykonat distribuci kurzovního lístku ke všem aplikacím. Pro tento účel se nabízí využít vhodný middleware 1, který bude schopen tuto činnost provádět. V současnosti zákazník již používá middleware, který je svou architekturou orientovaný na služby (SOA 2 ), a je jím WebSphere 1 Middleware je z architektonického hlediska střední vrstva, která slouží jako konverzní, překladatelská a integrační 2 Softwarová architektura orientovaná na služby. V takové architektuře je informační systém složen z komponent (služeb), které vykonávají diskrétní procesní funkce 17

18 Úvod ESB 3. Z tohoto důvodu je také neúčelné uvažovat o využití jiného middlewaru, a proto využijeme pro náš projekt stávající bankovní architekturu, která bude pouze rozšířena o náš nový patern. Cíl práce Cílem práce je zejména: Seznámení se s konceptem integrace na bázi Enterpise Service Bus (ESB) Nastudování atomických a kompozitních integračních paternů na bázi ESB Identifikace informačních systémů, které budou předmětem integrace Nastudování dostupné podpory a metod pro zajištění XA transakcí na platformách Microsoft WCF, IBM WebSphere, Oracle RDBMS Implementace patternu na ESB s podporou XA transakčního zpracování napříč heterogenními informačními systémy, provozovanými na platformách Microsoft WCF, IBM WebSphere, Oracle RDBMS Implementace mock verzí informačních systémů pro zajištění simulace chování paternu Praktické ověření korektní funkcionality paternu při dostupnosti všech či nedostupnosti jednotlivých informačních systémů Struktura práce Práce je rozdělena do následujících částí: Teoretický úvod: V této části práce budou vymezeny technologie, které budou využity pro implementaci (kapitola 1). Dále zde bude vysvětleno, co se skrývá pod pojmem SOA, ESB a jaké jsou integrační paterny na ESB. Kapitoly 2, 3 a 4. V neposlední řadě budou v 5. kapitole vysvětleny distribuované transakce (XA transakce). Analytická část: V 6. kapitole bude provedena analýza požadavků, distribučního paternu a zpráv, které budou šířeny přes distribuční kanál. V druhé části této kapitoly bude proveden návrh demoverze tohoto řešení, které bude sloužit jako důkaz o funkčnosti. 3 Enterprise Service Bus je podniková sběrnice služeb, která spojuje a zprostředkovává všechny komunikace a interakce mezi službami. WebShpere ESB je implementace ESB společností IBM 18

19 Struktura práce Realizace a testování: V 7. kapitole je popsán způsob implementace mediačního paternu podle analýzy. V následující kapitole jsou popsány jednotlivé testovací scénáře. Dále je zde provedeno hodnocení, zda tento patern splňuje testovací scénáře, a je tedy využitelný v praxi. 19

20

21 KAPITOLA 1 Použité technologie Tato kapitola se bude zabývat krátkým popisem jednotlivých technologií, které byly využity pro implementaci tohoto projektu. Z následujících odstavců bude vypuštěn enterprise service bus a distribuované transakce. Těmto budou věnovány samostatné kapitoly, protože se jedná o stěžejní části této diplomové práce a budou rozebrány detailněji. 1.1 Enterprise Java Java EE (Enterprise edition) je součást platformy Java určené pro vývoj a provoz podnikových aplikací a informačních systémů. Základem pro platformu Java EE je platforma Java SE, nad níž jsou definovány součásti tvořící Java EE. Enterprise aplikace je tedy běžná aplikace, na kterou jsou kladeny specifické nároky co se týče spolehlivosti, dostupnosti, robustnosti, výkonnosti. Typická je také potřeba obsloužit současně velké množství požadavků (klientů). Klasickými zástupci enterprise aplikací jsou moderní webové aplikace a řešení postavená na servisně orientované architektuře (SOA). Více o této technologii je publikováno na webových stránkách Java EE[7]. 1.2 WebSphere Application Server Aplikační server tvoří vrstvu mezi operačním systémem a aplikacemi. Podobně jako operační systém poskytuje základní funkce programům (například pro přístup k souborovému systému nebo ke správě procesů), poskytuje aplikační server často používané funkce enterprise aplikacím. Vytváří další vrstvu abstrakce z důvodu zjednodušení psaní aplikací. Příkladem takových funkcí mohou být: podpora transakčního zpracování požadavků, persistence objektů do databáze, výměna zpráv mezi aplikacemi a další. WebSphere aplikační 21

22 1. Použité technologie server je aplikační server vyvíjený společností IBM a další informace lze nalézt na stránkách infocentra IBM[12] a nebo wikipedie[13]. 1.3 WebSphere ESB IBM WebSphere ESB nabízí Enterprise Service Bus pro IT prostředí postavené na otevřených standardech, SOA, zasílání zpráv a webových služeb. Web- Sphere ESB podporuje širokou řadu protokolů jako JMS, MQ, EJB, Web- Services, REST, HTTP. Pracovní prostředí pro vývoj, vytváření a zprostředkování toku dat ve WebSphere ESB se nazývá WebSphere Integration Developer a je postaven na platformě Eclipse. WebSphere ESB má mnoho vestavěných uzlů, které podporují různé typy činností, jako je transformace dat, směrování, filtrování a vyhledávání v databázi. Tato část slouží pouze jako informace o použití této technologie v projektu, ale jak již bylo řečeno v úvodu kapitoly, technologii ESB je věnována samostatné kapitola této práce. 1.4 Oracle RDBMS Oracle RDBMS je databázový server, který je určen pro správu relačních databází. Tento server, který běží na více než osmdesáti platformách, je vlajkovou lodí společnosti Oracle. Nejnovější verzí, která je také využita v této práci, je 11g. Tato verze databázového serveru obsahuje i vlastní transakční manažer, takže je schopna pracovat v distribuovaných transakcích. O této a dalších funkcích tohoto databázového serveru se můžete dočíst na webových stránkách[11] s dokumentací k databázím Oracle. 1.5 Microsoft Windows Communication Foundation (WCF) Windows Communication Foundation je část.net frameworku, která poskytuje jednotný programovací model pro rychlý vývoj servisně orientovaných aplikací. Umožňuje vývojářům vytvářet bezpečná, spolehlivá a transakční řešení, která spolupracují již s existujícími. Pomocí WCF můžeme odesílat data jako asynchronní zprávy z jednoho koncového bodu do druhého. Koncový bod služby může být součástí trvale dostupné služby hostované na IIS, nebo to může být služba hostovaná v aplikaci. V souhrnu poskytuje WCF zvládnutelný přístup k vývoji webových služeb a jejich klientů. Více informací o Windows Communication Foundation lze nalézt na stránkách knihovny MSDN společnosti Microsoft[10]. 22

23 1.6. Microsoft SQL Server 1.6 Microsoft SQL Server Microsoft SQL Server je, podobně jako Oracle RDBMS, databázový server, který v průběhu práce na tomto projektu dospěl do verze Microsoft SQL Server Bohužel tato práce byla započata s nižší verzí a to Microsoft SQL Server Tento databázový server slouží ke správě relační databáze, ve které se ukládají data aplikací z platformy.net. Na stránkách[9] knihovny MSDN jsou uvedeny další informace o tomto databázovém serveru. 1.7 Internet Information Services (IIS) Intertet Information Services, dříve nazývaný Internet Information Server, je softwarový webový a aplikační server společnosti Microsoft. Tento produkt byl vytvořen pro operační systém Windows. Jedná se o druhý nejpoužívanější webový server po serveru Apache. IIS lze jednoduše doinstalovat jako doplněk operačních systémů Microsoft Windows. Na tomto aplikačním serveru lze hostovat jakékoliv webové aplikace a služby z prostředí.net. V této práci bude na IIS aplikačním serveru hostována služba WCF. Na stránkách[8] webového serveru IIS můžete nalézt další informace o tomto produktu. 23

24

25 KAPITOLA 2 Servisně orientovaná architektura (SOA) Co je to servisně orientovaná architektura, je pěkně vysvětleno ve článku Petra Leštiny na portálu BPM a IBM[4]: SOA představuje architektonický koncept, který nám umožní překonat překážky, s nimiž se nyní pracovníci IT potýkají. Jestliže dokážeme transformovat architekturu informačních technologií na servisně orientovanou, získáme přesný přehled o funkcionalitě, kterou máme prostřednictvím služeb k dispozici. To představuje značný potenciál pro další rozvoj, navíc založený na systémech, které již vlastníme a provozujeme. V rámci propojení služeb do procesů získáme celkový obraz fungování podnikových procesů. Tento obraz je nahlížený ze stejného úhlu pohledu jak businessem (procesní přístup), tak i oddělením IT (SOA přístup), což značně přispívá k transparentnosti IT a zjednodušení vzájemné komunikace. Z hlediska fungování firmy se tímto krokem dokončí celková transformace na procesní řízení, neboť až v této chvíli lze skutečně říci, že procesy lze vykonávat a kontrolovat od začátku až do konce. Díky architektuře orientované na služby (Service Oriented Architecture SOA) mohou podniky provázat jednotlivé procesy interní, ale i externí, spojující firmu s obchodními partnery, klienty a podobně. Výsledkem je pak skutečnost, že se společnosti mohou flexibilně přizpůsobovat a výrazně tak zefektivnit svoji činnost či zkrátit reakční doby na externí požadavky. Steve Mills, Senior Vice President and Group Executive v IBM Software Group komentoval myšlenku servisně orientované architektury následovně: Z pohledu IBM se jedná o hledání cest, jak za pomoci nejmodernějších technologií zajistit uspokojování nových potřeb a požadavků neustále se měnícího trhu. O SOA se hovoří již několik let, avšak jen málo společností plně chápe a využívá příležitosti, které tato architektura přináší. 25

26 2. Servisně orientovaná architektura (SOA) Jakkoliv jsou přínosy SOA v technické oblasti průlomové, tím hlavním je maximální kontrola managementu nad firemními procesy. Pro pracovníky IT oddělení přináší SOA zjednodušení a standardizaci stávající infrastruktury a snižuje tak složitost prostředí, se kterou se stávající IT oddělení potýkají. SOA klade silný důraz na znovupoužitelnost a tím podporuje efektivní využití stávajících aplikací. Hlavní přínosy SOA pro oblast podnikání: Transformace IT na procesně orientované a business podporující IT Využití stávajících aplikací pro další rozvoj Flexibilní propojení aplikací a řízení procesů skrze tyto aplikace Plná kontrola nad procesy a jejich monitoring v průběhu jejich celého životního cyklu Hlavní přínosy SOA pro oblast IT: Nezávislost na platformě, aplikaci či programovacím jazyku Aplikační služba je k dispozici prostřednictvím vysokoúrovňového rozhraní Zachování aplikační infrastruktury - je nutné pouze vytvořit rozhraní, pokud neexistuje Změní-li se aplikace, procesy a ostatní integrační rozhraní zůstávají zachovány Flexibilita při přidání nové aplikace (služby) a možnost kombinace s existujícími službami Možnost pružně měnit procesní zpracování v závislosti na podnikatelských potřebách Z hlediska historického vývoje představuje SOA poslední evoluční krok v oblasti celopodnikové integrace (Enterprise Application Integration) a přináší model znovupoužitenosti, reprezentace služeb a především standardů do oblasti podnikové integrace. 26

27 KAPITOLA 3 Enterprise service bus (ESB) Tato kapitola by měla čtenáři podat vysvětlení co je to ESB, kde se využívá, jaké standardy ESB implementuje, proč je výhodné ho využívat. Dále taky v této kapitole budou objasněny základní komponenty ESB. Pro zpracování této části bylo využito dokumentů: Představení ESB[1] a Definice ESB[5]. 3.1 Co je to ESB? Více než čtyřicet komerčních a open source produktů odkazují na ESB. Naneštěstí termín ESB znamená pro různé lidi odlišné věci, proto se často můžeme setkat se zmatenými výroky a desinterpretacemi. Problémem je, že dva produkty označované ESB jsou obvykle značně odlišné. Jako příklad můžeme použít Sonic ESB a IONA Artix ESB. Obě tyto implementace ESB podporují zprostředkovanou integraci aplikací pomocí XML zpráv. Ovšem tímto bodem podobnost obou produktů končí. Zatímco prvně jmenovaný je Message Oriented Middleware (MOM), tedy je založen na centrální službě zpráv, kterou řídí a přenáší zprávy, tak IONA Artix ESB není závislá na MOM a využívá distribuovaný model pro správu a řízení zpráv do koncových bodů jednotlivých služeb. Tento paradox se ještě podařilo prohloubit společnosti IBM, která nabízí dva velmi odlišné ESB produkty: WebSphere ESB: Tento produkt byl od základů navržen jako ESB. Je založen na základě centralizovaného modelu, který běží na WebSphere aplikačním serveru. WebSphere Message Broker: Je založen na bázi MOM a spoléhá na centralizovanou službu zpráv, která koordinuje, řídí a zprostředkovává komunikaci. 27

28 3. Enterprise service bus (ESB) Otázkou stále zůstává co je ve skutečnosti ESB. Zkusíme proto zavést následující definici: ESB je middleware řešení, které umožňuje interoperabilitu mezi heterogenními prostředími pomocí modelu orientovaného na služby. To představuje spojení integrace enterprise aplikací (EAI 4 ) s různými kategoriemi aplikačních serverů. Tato definice je ovšem také nejasná a nepřesná, ale tak už to chodí na trhu s ESB produkty. Konkrétní možnosti, funkce a standarty podporované ESB, stejně jako jejich architektury, se u jednotlivých výrobců liší. Přesto existují určité standarty u jednotlivých implementací ESB. Většina ESB vykazuje následující vlastnosti: Servisně orientovaný middleware: Koncové aplikace jsou v tomto modelu implementovány jako služby. Normalizace: ESB jsou více normalizovány než předchozí generace technologií pro integraci enterprise aplikací. Zejména všechny podporují interoperabilitu aplikací od různých výrobců pomocí webových služeb. Virtualizace agentů služeb: ESB poskytují kontejnery služeb, které virtualizují služby a izolují aplikační kód od jeho protokolu. Dále umožňují volání metod, poskytují paterny pro výměnu zpráv, zajišťují požadavky na Quality of Service(QoS) a další věci týkající se infrastruktury. 3.2 Proč potřebujeme ESB? Výsledkem četné integrace point-to-point a EAI projektů vzniká tzv. nahodilá architektura. Tato nahodilá architektura se na jedné straně skládá z nespolehlivých point-to-point spojení mezi pevně svázanými aplikacemi a na druhé straně z tzv. ostrůvků integrace. Point-to-point přístup k integraci vede k nespolehlivosti, nejistotě a ke špatnému monitorování integračního prostředí. Problémem tohoto přístupu je také to, že aplikace jsou pevně svázány, což znamená, že pro jejich integraci je potřeba, aby jednotlivé aplikace znaly rozhraní pro volání metod, požadovaný protokol a rozuměly odesílanému formátu dat. Obecným problémem je, že proces a transformace dat jsou pevně zakódovány do logiky aplikace. Proto pokaždé, když dojde ke změně v jedné aplikaci, musí být upraveny i aplikace, které na ni mají vazby. Na obrázku 3.1 lze vidět příklad nahodilé architektury, která se skládá z pevně svázaných aplikací, propojených nespolehlivým point-to-point spojením. Proces, transformace dat a logika je pevně zakódována do aplikací. EAI přístup se snaží integrovat všechny druhy aplikací pomocí centralizovaného EAI brokeru. Jak můžeme pozorovat ve většině podniků, tento proces vede k výše zmíněným ostrůvkům integrace. Existují, protože v určitém 4 EAI (Enterprise Application Integration) 28

29 3.3. Přínos ESB Obrázek 3.1: Nahodilá architektura[1] časovém okamžiku i ty nejlépe financované EAI projekty selžou. Důvod tohoto selhání obvykle bývá neochota vedoucích pracovníků vzdát se kontroly nad svými zdroji díky jejich integraci nebo přesunutí do centralizované infrastruktury řízené organizací. Nicméně v tomto případě již alespoň tato částečná integrace z větší části odstraňuje nevýhody point-to-point řešení. Zůstává zde pořád jedna zásadní nevýhoda a to integrace se zbývajícími systémy kolem tohoto pomyslného ostrůvku. 3.3 Přínos ESB ESB staví servisně orientovanou infrastrukturu na integraci všech druhů izolovaných aplikací do decentralizované infrastruktury tzv. Service Bus (Sběrnice služeb). Obecně platí, že ESB je založen na některých artefaktech z EAI, jako jsou speciální směrování zpráv a jejich transformace. Vzhledem k decentralizované infrastruktuře, tento způsob nenutí jednotlivá oddělení integrovat aplikace do centralizovaného brokeru EAI, a tak nad nimi ztratit kontrolu. Tento způsob integrace naopak umožní jednotlivým oddělením poskytovat přístup k vybraným službám a byznys informacím, prosazovat vlastní bezpečnostní politiku a udržet si lokální autonomii. Protože infrastruktura ESB není jen decentralizovaná, ale také vysoce dis- 29

30 3. Enterprise service bus (ESB) tribuovaná a univerzální, umožňuje, aby všechny druhy aplikací byly postupně připojeny ke sběrnici. Poté jednotlivé integrační projekty mají za úkol přinést byznys funkce, implementované různými aplikacemi, jako znovupoužitelné byznys služby na ESB. Tyto jednotlivé služby by neměly být využívány pouze pro jeden integrační projekt, ale měly by sloužit jako znovupoužitelné ve větší škále projektů. Hlavní rozdíl ve srovnání s bývalým EAI řešením je, že integrační projekty sledují dlouhodobou strategii, která integruje všechny druhy enterprise aplikací jako enterprise služby do ESB. Obrázek 3.2: ESB architektura[1] Technicky vzato, hlavní rozdíl mezi ESB a bývalým EAI řešením je, že ESB nahrazuje všechny přímé aplikační propojení za spolehlivé, bezpečné a řiditelné virtuální kanály. Zavedením těchto virtuálních kanálů se aplikace stávají oddělenými, což vede k volné vazbě interakcí a aplikačních rozhraní. Budeme-li chtít využít standardizovanou výměnu zpráv mezi jednotlivými službami, ESB poskytuje využití datového formátu XML a protokol pro tuto výměnu SOAP. V důsledku těchto změn, procesní orchestrace a transformace dat může být logika přesunuta z aplikací do ESB. Z tohoto důvodu může také ESB poskytovat proces interakce mezi procesy společnosti a jeho byznys part- 30

31 3.4. Základní komponenty ESB nera kontrolovaným způsobem. Obrázek 3.2 znázorňuje výsledek refaktorování nahodilé architektury do ESB architektury. 3.4 Základní komponenty ESB V předchozí podkapitole byly objasněny přínosy ESB. Nyní bude vysvětleno, jakým způsobem jsou tyto přínosy realizovány. V této kapitole bude tedy nastíněn přehled základních složek ESB architektury a následně budou jednotlivé komponenty popsány. Na obrázku 3.3 jsou vyobrazeny hlavní komponenty ESB: Message Oriented Middleware (Middleware orientovaný na zprávy) MOM Kontejner služeb Správa zařízení Obrázek 3.3: Hlavní komponenty ESB[1] Middleware orientovaný na zprávy (MOM) Middleware orientovaný na zprávy je nejdůležitější součástí ESB, a proto bude popsán jako první. V této podkapitole bude objasněno, jaký přínos 31

32 3. Enterprise service bus (ESB) má využívání MOM, jak MOM funguje, jakým způsobem se budují virtuální kanály a konečně jaké jsou základní charakteristiky zprávy. Obrázek 3.4: Přesun od synchronního volání vzdálené metody k asynchronní výměně zpráv[1] Z obrázku 3.4 je patrné, že přímý komunikační kanál mezi aplikacemi je nahrazen virtuálním kanálem. Ve výsledku jsou veškerá volání vzdálených metod nahrazena asynchronní výměnou zpráv. Tímto zajistíme, že veškeré těsné vazby point-to-point aplikací jsou nahrazeny volnými vazbami mezi těmito aplikacemi. MOM poté v této architektuře zajišťuje posílání zpráv přes virtuální kanály do připojených aplikací, které zastupují jeden či více byznys procesů. Ve skutečnosti tento přenos zpráv neobstarává jeden MOM server, ale obvykle se jedná o síť serverů, přes které jsou připojeni jednotliví klienti. Tuto architekturu ilustruje obrázek 3.5. Každý z těchto serverů spravuje různé fronty a topiky, a je schopen zprávy uchovávat a předávat je dál. ESB architektura obvykle obsahuje mnoho MOM serverů, které jsou navzájem propojeny. MOM spolehlivě směruje zprávy skrz síť serverů, pomocí mechanizmu ulož a doruč (lépe je tento mechanizmus známý pod svým anglickým jménem store and forward). To znamená, že každý ze serverů na cestě zprávy, tuto zprávu uloží, a poté se pokouší zprávu odeslat následníkovi. Zpráva je smazána pouze, když server dostane potvrzení o přijetí zprávy od serveru nebo klienta, na který byla tato zpráva směrována. Využitím tohoto mechanizmu je garantováno doručení zprávy. Každý z klientů je připojen k jednomu z MOM serveru a běží v kontejneru služeb. Kontejner služeb umožňuje každému z klientů přijímat a odesílat zprávy. Nicméně není to jediná funkce těchto kontejnerů. Tyto kontejnery se starají o správu klientů, obstarávají transformaci příchozích zpráv na zprávy, 32

33 3.4. Základní komponenty ESB které jsou srozumitelné pro klienty. Většina klientů je také schopna si přechodně zprávy uložit, než jsou schopni tyto zprávy předat dál. Obrázek 3.5: Cesta zprávy přes ESB architekturu[1] V předcházejících odstavcích bylo zmíněno, že MOM server se stará o správu front a topiků. Pomocí těchto architektonických prvků je realizován point-topoint a publish-subscribe model přenosu zpráv. Tyto dva modely jsou znázorněny na obrázku 3.6. Dále bude popsáno, jak se od sebe tyto modely, které jsou využívány pro budování virtuálních kanálů, liší. Point-to-point propojení aplikací využívá pro přenos zpráv fronty. Pokud tedy potřebujeme propojit dvě aplikace mezi sebou virtuálním kanálem, využijeme právě tohoto modelu přenosu zpráv. Odesílatel zprávy odešle zprávu do fronty, která je vytvořena na MOM serveru a je tímto serverem spravována. Server tuto zprávu dočasně uloží (tento princip byl popsán výše). Příjemce zprávy se naopak připojí k frontě a zkontroluje, zda tato fronta obsahuje nějaké zprávy. Pokud fronta obsahuje zprávy, příjemce vyzvedne nejstarší zprávu umístěnou do fronty. Může nastat situace, kdy na jedné frontě naslouchá více příjemců (může se například jednat o několik instancí stejné aplikace). Poté je zpráva doručena pouze tomu příjemci, který se na ni dotáže první. Opačný případ nastane, když potřebujeme distribuovat zprávu k více příjemcům. Stejně jako u předchozí varianty odesílatel odešle zprávu na MOM server, ale tentokrát ne do fronty, ale do topiku. Server tuto zprávu opět dočasně uloží. Příjemci zprávy se dotazují, zda topik obsahuje zprávu. Tento topik je tvořen soukromými frontami pro každého příjemce a z toho vyplývá, že každý z příjemců obdrží zprávu umístěnou do tohoto topiku. Prostřednictvím inteligentního propojení front a topiků, které jsou spravovány různými MOM servery, můžeme vytvořit virtuální kanály mezi byznys procesy poskytovanými v různých zeměpisných oblastech. Jak již bylo výše zmíněno, 33

34 3. Enterprise service bus (ESB) Obrázek 3.6: Point-to-point a publish-subscribe modely prenosu zpráv[1] MOM servery obstarají spolehlivé doručení zpráv. Na zprávu je z pohledu ESB pohlíženo jako na jednotku transakce. Z důvodu nahrazení přímého volání metod, za posílání zpráv mezi aplikacemi, je nutné, aby zpráva obsahovala nejen byznys data, které si klienti mezi sebou předávají, ale také další dodatečné informace. Proto všechny zprávy obsahují hlavičku, vlastnosti zprávy a byznys data. Hlavička zprávy obvykle obsahuje identifikaci zprávy a informace o směrování této zprávy. Vlastnosti zprávy obsahují například informace o kódování této zprávy, údaje o tom, kam má být směrována odpověď na tuto zprávu a další. ESB je založeno na standardizované výměně zpráv, proto jsou zprávy posílány v normalizovaném formátu. To znamená, že pokud budeme vyžadovat provolání určité služby, bude zpráva transformována z normalizované formy, do formy, která je srozumitelná této službě, a naopak. Protože SOAP protokol má dříve zmíněné vlastnosti zprávy a je standardizován, tak je využíván u většiny ESB pro posílání zpráv přes síť. Na druhou stranu SOAP protokol není povinný protokol, který musí ESB implementovat, tak se objevují ESB, které používají proprietární protokoly. Nicméně používání těchto protokolů vede k závislosti na výrobci ESB a tedy opět k ostrůvkům integrace. Část zprávy, která nese byznys data je obvykle ve formátu XML. I v tomto případě platí, že XML není povinný formát, ale důvodem pro jeho využití bývá snadná transformace z tohoto formátu do jiného, jednoduché směrování podle obsahu zprávy a také podpora tohoto formátu ve většině programovacích 34

35 3.4. Základní komponenty ESB a integračních prostředích, ať už se jedná o knihovny nebo API Kontejner služeb Kontejnerem služeb se v kontextu ESB myslí umožnění volat všemožné aplikace jako služby. Pomocí tohoto kontejneru jsou aplikace propojeny s topiky a frontami, které poskytuje MOM, a tento kontejner také provádí transformace dat pro koncové aplikace. Tyto aplikace mohou být vystaveny jako služby a tedy spravovány tímto kontejnerem, nebo to mohou být jakékoliv volně stojící aplikace, které jsou obaleny tímto kontejnerem. To způsobí, že se navenek k této aplikaci můžeme stavět jako ke kterékoliv jiné službě. Takto může být zapouzdřena různá funkcionalita, jako je: nahrát a stáhnout soubor z FTP serveru, odeslat a přijmout , provolat metodu na EJB, provolat jednoduchou webovou službu a další. Každá takto vystavená služba je reprezentována ESB endpointem (v češtině koncovým bodem). Každý endpoint má jedinečnou adresu, která na něho odkazuje, a je zaregistrován ve správě infrastruktury. Z tohoto důvodu mohou být tyto endpointy využity ke směrování zpráv a ke kompozici složitějších byznys procesů. Obrázek 3.7: Propojení služeb s ESB s využitím ESB endpointů[1] Jak již víme, kontejner služeb spravuje klienta, který umožňuje přijímání a odesílání zpráv do front a topiků a umožňuje přímo spravovat aplikace 35

36 3. Enterprise service bus (ESB) nebo je alespoň obalovat. Vedle této funkce umožňuje spravovat ESB endpointy. Tyto endpointy poté slouží jako prostředníci mezi klientem a byznys funkcionalitou jednotlivých aplikací. ESB endpointy jsou podobné jako servlety v J2EE, to znamená, že mají standardizované rozhraní, které se skládá ze vstupního a výstupního bodu. Kontejner služeb umisťuje všechny příchozí zprávy do fronty vstupního bodu a zprávy, které by měly být odeslány do fronty výstupního bodu. Každý ESB endpoint vlastní svou službu. Volání služby je prováděno při každém vyvolání události, které tuto službu potřebuje pro zpracování požadavku. Pro rozhodování, který z endpointů obslouží zprávu je využito parametrů v ESB kontextu. Služby obsahují logiku, která zpracuje zprávu a může poslat novou nebo chybovou zprávu zpět do MOM. Kód takové služby může například transformovat XML zprávu do objektu jazyka JAVA a zavolat metodu, která je umístěna v JAVA aplikaci. Tímto způsobem lze obsloužit všechny druhy integračních úloh. Vhodným nastavením konfiguračních parametrů můžeme integrovat všechny druhy aplikací Správa zařízení ESB je založen na vysoce distribuované a decentralizované infrastruktuře, která se skládá z mnoha kontejnerů služeb. Tyto kontejnery poskytují byznys funkcionalitu koncových aplikací jako služby. Dále je ESB tvořeno middlewarem orientovaným na zprávy, který všechny kontejnery služeb propojuje, a tím také propojí mezi sebou jednotlivé byznys procesy, tak že mezi nimi vytvoří virtuální kanály. Taková infrastruktura musí být určitým způsobem řízena, proto potřebujeme kontejnery služeb a MOM servery konfigurovat, řídit a monitorovat. Vzhledem k rozmanitosti koncových aplikací, počínaje jednoduchými EJB, nasazovanými přes deployment archivy, přes transformační nástroje vyžadující XSLT skripty, až po BPEL nástroje, které vyžadují definice procesů, budeme pravděpodobně potřebovat různé MOM servery. Na každý z těchto serverů budou kladeny rozdílné požadavky týkající se konfigurace, nasazování a správy. Základní myšlenkou ESB je mít decentralizovanou infrastrukturu, která ovšem bude centrálně řízená. Každé ESB proto musí mít silnou a univerzální správu zařízení. Tato správa zařízení je v podstatě složena z centrálního úložiště, sítě řídících serverů, rozhraní pro správu MOM serverů a kontejnerů služeb, nástroje pro řízení a sledování sítě. V centrálním úložišti jsou uloženy všechny druhy ESB artefaktů, včetně konfigurací ESB endpointů pro kontejnery služeb, konfigurace topiků a front pro MOM servery, deployment deskriptory, archivy pro deploy a XSLT skripty. Centrální repozitář také obsahuje seznam služeb a jejich endpoitů, BPEL procesy a informace o směrování zpráv. Protože správa zařízení monitoruje všechny komponenty, tak jsou zde uložena také data z monitorování. 36

37 3.4. Základní komponenty ESB Obrázek 3.8: Základní komponenty správy zařízení ESB[1] Správa zařízení je postavena na síti serverů pro správu. Tyto jednotlivé servery jsou propojeny s centrálním úložištěm. Každý z MOM serverů a kontejnerů služeb je připojen k jednomu ze správcovských serverů. Servery pro správu konfigurují připojené komponenty, nasazují na ně soubory, monitorují je, a tedy v podstatě tyto komponenty řídí. Konfigurací se rozumí nastavení topiků a front MOM serverů a enpointů služeb v kontejnerech služeb. Nicméně další aspekty, jako je zpracování chyb, audit, QoS a bezpečnost mohou být také řízeny těmito servery. Nastavení v podstatě závisí na možnostech MOM serverů a kontejnerů služeb. Možností nasazovat se myslí, že servery pro správu mohou nahrávat nejrůznější soubory do kontejnerů služeb. Když tedy potřebujeme nasadit EJB modul, tak dojde k nasdílení jar knihovny, pro konfiguraci transformačních nástrojů servery nasdílí XSLT skripty, apod. Vedle těchto činností dokáží tyto servery řídit životní cyklus připojených komponent. Je tedy možné tyto komponenty zapínat, vypínat, restartovat, případně provádět další činnosti definované v životním cyklu komponenty. Poslední komponentou, kterou se budeme zabývat, jsou Nástroje správy. Pomocí nich lze vidět podrobný popis služeb uložených v centrálním repozitáři, včetně jejich endpointů a odkazů na ně. Pomocí těchto informací můžeme vytvářet automatizované enterprise procesy. Dále zde můžeme nastavovat orchestraci jednotlivých služeb, například pomocí BPEL. Dále tyto nástroje využívají administrátoři k již výše zmíněným úkonům, jako jsou řízení životního cyklu procesů, správa topiků a front, a další. 37

38

39 KAPITOLA 4 Paterny na bázi ESB Patern je znovupoužitelná šablona, která pomáhá urychlit proces implementace a integrace řešení. V této kapitole bude popsána řada paternů, které zapouzdřují běžné řešení v propojení aplikací. Tyto návrhové vzory budeme dále dělit na dvě skupiny: Paterny funkční Paterny interakce Další informace, které nebudou obsaženy v této kapitole, lze dohledat na portále developerworks[3], který byl využit také jako zdroj pro sepsání této kapitoly. 4.1 Paterny funkční Potřeby propojení aplikací jsou bohaté a rozmanité, a vyžadují základní infrastrukturu, která umožní flexibilitu adresování různých aplikací a architektur. Ačkoliv každá implementace může být unikátní, můžeme najít společné znaky (způsob adresace, vzorce chování, atd.)pro větší okruh problémů. Identifikováním těchto společných znaků si můžeme vyjasnit naše myšlení, o jakou aplikaci se jedná, jak může být použita a oblasti, ve kterých se bude vyvíjet. Mimo jiné nám tato analýza může pomoci popsat a formulovat schopnosti aplikací a možnosti jejich využití při řešení byznys problémů. Dále budou popsány paterny, které řeší zvláštní soubor byznys požadavků. Budeme je rozdělovat do šesti hlavních kategorií mediačních paternů: Virtualizace služby Zpřístupňování služby 39

40 4. Paterny na bázi ESB Brána Integrace založená na zprávách Zpracování souborů Událostmi řízená integrace Virtualizace služeb Paterny virtualizace služeb popisují, jakým způsobem můžeme poskytovat opravdovou volnou vazbu mezi službami. Tyto paterny se rovněž zabývají požadavky na mediaci (směrování, protokol konverze, transformace dat, logování, a další) mezi službami. Obrázek 4.1: Patern virtualizace služeb Paterny virtualizace služeb zapouzdřují užší definici ESB a typicky se používají k řešení mnoha různých požadavků, včetně: 40 Volná vazba - prezentace stávajících služeb jako virtuální služby na ESB Poskytnutí fasády, která zahrnuje transformaci, obohacování dat, atd.

41 4.1. Paterny funkční Poskytnutí fasády, k zajištění poskytování standardních rozhraní pro nestandardní služby Poskytování standardních služeb pro správu nástrojů (logování, bezpečnost, monitorování, atd.) Obvykle se tyto paterny využívají pro služby definované pomocí WSDL a postavené na protokolu SOAP/HTTP nebo SOAP/JMS. Příklady využití tohoto návrhového vzoru: Jednoduchá proxy služeb Přepínač služeb Překladač služby Normalizátor služeb Jednoduchá proxy služeb Tento patern umožňuje maximální odstranění vazby mezi konzumentem služby a jejím poskytovatelem tím, že zavádí další úrovně dereference do volání služby. Ve své nejzákladnější podobě tento návrhový vzor skrývá skutečné umístění endpointu služby. Použití paternu: Přístup ke službě je poskytován přes kontrolní bod, aniž by bylo odhaleno skutečné umístění služby klientům Pro každé volání služby je nutné použít nějaké formy kontroly (řízení přístupu, autorizace, logování, atd.) Přepínač služeb Přepínač služeb umožňuje vícenásobnou implementaci stejného rozhraní služby. Všechny tyto implementace jsou umístěny na stejném endpointu a nabízejí různou kvalitu této služby, nebo její chování. Každý požadavek klienta může být směrován do jednotlivých implementací na základě několika faktorů: konkrétní potřeby klienta, hodnota klienta v organizaci (požadavek na kvalitu služby), geografické polohy, nebo jednoduše na základě zatížení systému. Použití paternu: Existence více implementací konkrétní služby (všechny sdílejí stejné rozhraní) Různé implementace poskytují různou kvalitu služeb Žádosti od různých klientů mají být směrovány na konkrétní implementace podle předem stanovených kritérií 41

42 4. Paterny na bázi ESB Překladač služby Překladač služby umožňuje, aby jediná implementace služby byla přístupná přes různá rozhraní. Použití paternu: Stávající rozhraní poskytuje více funkcí, než chceme vystavit Hodnoty některých parametrů na rozhraní služby jsou dané byznys požadavky Rozhraní musí být upraveno, tak aby bylo v souladu s lokálními požadavky Konzumenti služby očekávají využití jiného rozhraní Normalizátor služeb Tento patern umožňuje vícenásobnou implementaci stejné služby, kde každá služba má jiné rozhraní. Požadavky klienta jsou poté směrovány podobně jako v případě přepínače služeb. Použití paternu: Existuje více implementací určité služby s různým rozhraním Různé implementace poskytují různou kvalitu služeb Žádosti od různých klientů mají být směrovány na konkrétní implementace podle předem stanovených kritérií Zpřístupňování služby Tato kategorie paternů řeší problém zapouzdření funkčnosti a prezentace této funkcionality pomocí servisně orientovaného rozhraní. Toto představuje přechod od tradičních představ o integraci byznys aplikací do architektury orientované na služby. Přechod umožňuje využívat staré služby a aplikace v novém stylu bez nutnosti radikálních změn. Tento patern tedy umožní vytvoření pseudo služeb, které budou odvozeny z funkcí realizovaných pomocí různých technologií napříč celým podnikem. Vytvoříme jednotný a ucelený přehled o službách pro konzumenty těchto služeb. Příklady využití tohoto paternu: 42 Jednoduchá fasáda Komplexní fasáda Klientský přístup

43 4.1. Paterny funkční Obrázek 4.2: Patern zpřístupňování služby Jednoduchá fasáda Ve své nejjednodušší podobě je tento vzor velmi podobný jednoduché proxy, s tím rozdílem, že v tomto případě požadavky od konzumenta nejsou vykonávány poskytovatelem služby, ale existující aplikací, která je zpřístupněna pomocí zpráv, adaptérů nebo API. Adaptéry mohou být implementovány přímo v aplikaci, ale často jsou to ESB komponenty. Tento patern se stejně jako virtualizace služeb může rozšířit o směrování, transformaci a normalizaci dat Komplexní fasáda Na rozdíl od předchozí jednoduché fasády, tento patern buduje integrační logiku z bohatších funkcí ESB, případně integruje více zdrojů funkčnosti do takzvaných virtuálních služeb na ESB. Tento vzor se často využívá pro budování vyšší úrovně byznys služeb ze služeb nižší úrovně a menších aplikací. Integrační logika může být postavena mnoha různými způsoby, ale mezi typickými příklady jsou: posloupnost volání, více requestů s agregací odpovědi nebo šíření informací. 43

44 4. Paterny na bázi ESB Klientský přístup Tento patern poskytuje vstupní body pro klienty, kteří nejsou schopni pracovat v servisně orientovaném přístupu. Nejčastěji se toto provádí pomocí adaptérů a umožňuje stávajícím aplikacím podílet se na zavádění enterprise architektury založené na SOA Brána Brána je součástí ESB, které poskytuje funkce na pomezí ESB a jeho okolí. Tyto funkce se poté vztahují na všechny příchozí a případně i odchozí zprávy. Obvykle využívají data ze standardních hlaviček, aby určily, jakou akci provedou, ale nemusí rozumět kompletnímu formátu zprávy. Brána poté zavolá přímo službu, pro kterou je tato zpráva určena nebo tuto zprávu předá další komponentě pro zpracování. Obrázek 4.3: Patern Brána Mezi funkce brány patří: Žádost o směrování Ověření Povolení přístupu 44

45 4.1. Paterny funkční Protokol konverze Korelace odpovědi Příklady využití tohoto paternu: Bezpečnostní brána Konektor služby Prostředník Bezpečnostní brána Tento vzor je poněkud zvláštním příkladem brány, protože přebírá veškeré nestandardní zabezpečení z hlavní infrastruktury a provádí autentizaci, autorizaci a případně i audit před voláním skutečného cíle. V tomto režimu je téměř vždy důvěryhodný vztah mezi branou a ostatními částmi ESB tak, aby bezpečnostní model u zbylých částí ESB mohl být zjednodušen. Bezpečnostní brány mohou být umístěny v jiné zóně zabezpečení než zbytek ESB a mohou poskytovat připojení k externím službám. Tento model podporuje širokou škálu vstupních bezpečnostních protokolů a zároveň zjednodušuje bezpečnost ostatních složek ESB Konektor služby Konektor poskytuje nejjednodušší způsob připojení existujících služeb do ESB pokud jsou tyto služby založeny na principech SOA. Konektor (Brána) zavádí kontrolu v podnikové architektuře a může přinést řadu ad hoc služeb, bez nutnosti vývoje individuálních mediačních flow pro každou službu. Zprávy tedy vstupují do konektoru a jsou směrovány k poskytovateli služby, poskytovateli fasády nebo k dalšímu mediačnímu flow Prostředník Prostředník rozšiřuje paterny o možnost využití standardních mediací pro všechny příchozí (a nebo odchozí) zprávy. Tyto standardní, obsahově nezávislé mediace jsou vyvinuty pouze jednou v bráně a poté mohou být aplikovány na všechny procházející zprávy. Většinou je na tomto místě prováděna validace zpráv, logování, audit, ověřování nebo schvalování. Dále se tyto mediace mohou využívat univerzálně nebo selektivně na základě vlastností brány nebo na základě údajů v příchozí zprávě (obvykle v hlavičce této zprávy). 45

46 4. Paterny na bázi ESB Integrace založená na zprávách Paterny založené na zprávách odpovídají v některých ohledech funkčnosti struktuře virtualizačních vzorů. Je zde však zásadní rozdíl v tom, jak o těchto paternech přemýšlíme. V servisně orientovaném modelu jsme obvykle zaměřeni na poskytování služeb mnoha nezávislým klientům. To znamená, že se na problém díváme z pohledu poskytovatele služby ke konzumentovi této služby. V modelu založeném na zprávách jsme více zaměřeni na data, která proudí systémem a na množinu akcí, které jsou na tyto data aplikovány. Tímto přístupem získáme více možností, jak nahlížet na poskytovatele služeb a jejich konzumenty. Obrázek 4.4: Integrace založená na zprávách V následujících podkapitolách budou uvedeny příklady využití tohoto paternu Směrovač zpráv Tento vzor se využívá, aby poskytoval silnou úroveň oddělení mezi aplikacemi a službami, které si vyměňují data tím, že umožní směrovat data odeslaná z jedné aplikace do více potencionálních cílů. Můžeme rozlišit tři základní typy směrovačů: 46 Kontextové směrovače - vybírají cíl na základě identity odesilatele, nebo podle nějakého aspektu v hlavičce zprávy Obsahové směrovače - výběr cílového bodu probíhá na základě byznys dat, které jsou obsaženy ve zprávě Zátěžové směrovače - směrování je závislé na zatížení aplikací nebo služeb, které mají zprávu obdržet

47 4.1. Paterny funkční Překladač zpráv Překladač zpráv umožňuje formát dat z jedné aplikace mapovat na formát dat jiné aplikace bez potřeby znalosti této transformace dat jakoukoli z aplikací. Tento patern obsahuje všemožné transformace dat, od přímých mapování až po komplexní transformace, které zahrnují hledání a křížové odkazy Most Tento patern mapuje data z jednoho dopravního mechanizmu na jiný, aniž by došlo ke změně formátu či obsahu zprávy. Musí také zajistit mapování mezi různými režimy adresování, které mohou být použity v jednotlivých systémech zpracovávající zprávy. Častým příkladem využití tohoto vzoru je propojení JMS implementací od různých výrobců Agregátor zpráv Agregátor řeší potřebu slučování zpráv, z jedné nebo více aplikací či služeb, do jednoho uceleného kusu dat a šířit ho dále jako novou zprávu. Realizace tohoto vzoru může jednoduše spojovat různé zdroje dat, nebo může obsahovat nějakou sofistikovanější škálu možností jak data mapovat. Agregátor musí být také schopen ošetřit případ špatné vstupní zprávy a také případ, kdy některý ze zdrojů dat neodpoví a tato informace musí být šířena k aplikacím nebo službám, které očekávají odpověď Událostmi řízená integrace Obrázek 4.5: Událostmi řízená integrace 47

48 4. Paterny na bázi ESB Tato skupina vzorů je postavena na vyšší úrovni abstrakce než všechny předcházející. Událostí se rozumí zaznamenaná věc, která se stala uvnitř nebo vně našeho systému. Může signalizovat problém, příležitost nebo odchylku. Tyto události jsou poté obvykle šířeny jako zprávy a můžeme tedy na jejich zpracování využít veškerých výše zmíněných paternů. Dále budou jmenovány příklady vzorů z této skupiny Distributor událostí Tento model poskytuje distribuci událostí (s odpovídajícím zařazením podle témat a obsahu události) do všech aplikací nebo služeb, které se přihlásily k odběru události tohoto tématu nebo obsahu dat v této události. Data událostí jsou poslána do ESB a to poskytne doručení události do všech přihlášených služeb Filtr událostí Tento vzor umožňuje filtrovat a transformovat události vstupující do ESB a dále jsou šířeny do nástrojů pro zpracování událostí. Tyto nástroje mohou detekovat komplexní události, nebo to může být systém, který je schopen monitorovat byznys události. Tyto paterny podporují jednosměrnou komunikaci a jednají čistě jako pre-procesor pro nástroje na zpracování událostí. Nejčastěji se tento vzor používá pro poskytování vstupních míst pro data z různých senzorů, akčních členů a adaptérů. 4.2 Paterny interakce Interakční paterny popisují, na abstraktní úrovni, chování interakcí mezi službami či aplikacemi ve smyslu synchronního/asynchronního volání, úrovně zajištění doručení zpráv, hlídání timeoutů a ošetření chybových stavů. V podstatě se jedná o nastavení chování interakcí mezi jednotlivými endpointy. Tyto vzory nejsou implementovány samostatně, ale v kombinaci s dalšími architektonickými paterny, a dohromady tvoří specifické mediační vzory. V současné době je identifikováno těchto pět interakčních paternů: 48 Jednosměrné doručení zprávy Synchronní čtení requestu Beztransakční synchronní update Synchronní update s globální transakcí Synchronní update se zpětnou vaznou

49 4.2. Paterny interakce Jednosměrné doručení zprávy Záměrem tohoto interakčního vzoru je zajistit, aby veškeré requesty byly spolehlivě dodány a zpracovány. Dále se tento vzor postará, aby všechny komunikace byly zajištěny, každá komponenta spolehlivě hlásila chyby, zprávy byly po selhání ukládány, ESB žádné zprávy neodmítalo a všechny se snažilo zpracovat, chyby jsou zachytávány a ukládány společně s obsahem zpráv. Obrázek 4.6: Jednosměrné doručení zprávy Synchronní čtení requestu Obrázek 4.7: Synchronní čtení requestu Tento vzor poskytuje jednoduchý mechanizmus pro zpracování requestu. Aplikace, které odesílaly request, mají nastaven časový limit, po který čekají 49

50 4. Paterny na bázi ESB na odpověď. ESB má tento limit nastaven na kratší dobu, aby poskytoval aplikacím standardizovanou chybovou odpověď o překročení doby čekání. U tohoto paternu nejsou zprávy ukládány Beztransakční synchronní update Obrázek 4.8: Beztransakční synchronní update Záměrem tohoto paternu je poskytnout aktualizační mechanizmus, který ovšem negarantuje doručení a zpracování zprávy a ve které musí aplikace, která zprávu odesílá, převzít odpovědnost za zpracování chyb. Při pozitivním scénáři (tedy pokud nenastane žádná chyba) se tento vzor chová obdobně jako předchozí. Pokud ovšem ESB odhalí v odpovědi chybu, nebo tato odpověď není doručena ve stanoveném časovém intervalu, tak tuto chybu šíří směrem ke klientovi, který je vlastníkem requestu. Ten potom podle své vnitřní logiky akci opakuje nebo jen tuto chybu zpracuje Synchronní update s globální transakcí Tento vzor poskytuje mechanizmus, který transakčně zpracuje zprávu, případně zprávy, plující přes ESB. K tomuto je potřeba, aby všichni účastníci (tedy odesílatel zprávy, ESB a poskytovatel služby pro kterou je zpráva určena) podporovali dohodnutý protokol pro koordinaci transakce. Příkladem takového protokolu může být WS-AtomicTransaction. Další informace o transakčním zpracování budou probrány v následující kapitole. 50

51 4.2. Paterny interakce Obrázek 4.9: Synchronní update s globální transakcí Synchronní update se zpětnou vazbou Tento vzor přináší na rozdíl od předchozích potvrzovací mechanizmus. Aplikace, která odesílá zprávu je informována o tom, zda byl request přijat a také o jeho zpracování. Při přijetí zprávy ESB informuje odesílatele o úspěšném (či neúspěšném přijetí, pokud je zpráva nějakým způsobem poničena). A dále i poskytovatel služby, kterému je zpráva určena, posílá opět přes ESB odpověď, která oznamuje výsledek operace update (ať úspěšný nebo neúspěšný). Po přijetí odpovědi aplikace opět posílá potvrzení o přijetí zpět na ESB. Pro zpracování chyb můžeme opět použít stejnou komponentu na ESB jako ve vzoru Jednosměrného doručení zprávy. Obrázek 4.10: Synchronní update se zpětnou vaznou 51

52

53 KAPITOLA 5 XA Transakce Distribuovaná transakce je operace, která v rámci jedné transakce pracuje najednou s více rozdílnými zdroji. Ty jsou buď fyzicky umístěny (z pohledu hardwaru) na několika serverech nebo se jedná o rozdílné serverové instance volitelně i od různých dodavatelů (Oracle, Microsoft, IBM a další). Výjimkou však nejsou ani heterogenní typy zdrojů jako databáze, messaging, distribuované komponenty nebo proprietární (balíková) řešení. Důležitá je především kontrola distribuované transakce napříč jednotlivými systémy. Nejčastěji se k tomuto účelu využívá transakční manažer, který prostřednictvím manažera zdrojů zajišťuje řízení koncového systému. Potvrzovacím komunikačním protokolem je obvykle dvoufázový commit, který zabezpečí, že transakce rozprostřená do více zdrojů proběhne buď jako celek nebo neproběhne vůbec. XA je standard specifikovaný The Open Group pro zpracování distribuovaných transakcí. Technickou specifikaci ke standardu, která byla využita pro zpracování této kapitoly, můžete nalézt na webových stránkách[2] konsorcia The Open Group. K sepsání této kapitoly, byl využit také článek Štěpána Vacka Distribuované transakce[6]. 5.1 Komponenty XA transakce Zpracování distribuovaných transakcí je výrazně složitější než těch lokálních a zasahuje do něj několik komponent: Aplikační program - Klientská aplikace spouští celou transakci a registruje ji u transakčního manažera, který ji přidělí unikátní identifikátor. Ten pak slouží při komunikaci s jednotlivými zdroji. Transakční manažer - Komponenta, která koordinuje potvrzení nebo zrušení transakce nad všemi zúčastněnými zdroji. 53

54 5. XA Transakce Manažer zdroje - Řídí lokální část transakce z pohledu konkrétního zdroje. Obrázek 5.1: Komponenty XA transakce 5.2 Dvojfázový commit Dvoufázový commit je úzce svázán se standardem X/Open Distributed Transaction Processing, který je spravován konsorciem Open Group. Tento standard popisuje rozhraní XA, které definuje způsob komunikace mezi transakčním manažerem a jednotlivými zdroji, jež se podílejí na distribuované transakci. V rámci transakce mohou být volány různé systémy, které rozhraní XA implementují. Je důležité vědět, že pokud výrobce systému podporuje XA rozhraní, většinou rozděluje ovladač pro lokální a distribuovanou transakci. Odlišnost je především v náročnosti zpracování, protože distribuovaná transakce vyžaduje složitější logiku na straně zdroje a zpracování je proto pomalejší. Pokud tedy nepotřebujeme podporu distribuovaných transakcí, měli bychom použít ovladač pro lokální transakce. XA transakce je realizována v těchto krocích: Klientská aplikace začíná zpracování a zavolá transakční manažer, který vygeneruje pro transakci unikátní identifikátor. 2. S tímto identifikátorem transakce jsou následně volány všechny operace nad jednotlivými zdroji. 3. Po skončení zpracování odesílá klientská aplikace transakčnímu manažeru požadavek na potvrzení transakce.

55 5.2. Dvojfázový commit 4. Transakční manažer odešle požadavek na všechny zúčastněné zdroje, které posílají transakčnímu manažeru hlasy ( COMMIT nebo ROLL- BACK ), podle toho v jakém stavu se jednotlivé zdroje nachází. 5. Pokud všechny zdroje odpoví hlasem COMMIT, pak transakční manažer označí transakci za úspěšnou a odesílá požadavek na commit všem zdrojů. Pokud některý ze zdrojů neodpoví, nebo pošle hlas ROLL- BACK, potom manažer odešle požadavek na rollback celé transakce. Obrázek 5.2: Sekvenční diagram dvojfázového commitu Pokud by při vlastním comittování u některého ze zdrojů došlo k pádu systému, může se zotavit. Má zaznamenaný stav a unikátní identifikátor transakce, který následně ověří u transakčního manažera pokud se identifikátor nepodaří ověřit, provede se automaticky zrušení. Ve vybraných systémech je v případě potřeby možný také manuální zásah administrátora (tato vlastnost je dostupná u databází nebo messagingu). Distribuované transakce mají několik nevýhod. Mohou být navrženy jako dlouhotrvající (long-running) a pokud databáze přiřazuje zámky na úrovni stránky nebo tabulky, může dojít k čekání a v krajním případě i uvíznutí transakcí. Další nevýhodou je limitace ze strany dodavatelů balíkových řešení, protože ne každý produkt musí nutně podporovat XA rozhraní. 55

56

57 KAPITOLA 6 Analýza a návrh V předchozích kapitolách jsme vytvořili teoretický základ k tomu, abychom byli schopni zanalyzovat problém a navrhnout řešení. V této kapitole budeme postupovat od analýzy požadavků, přes návrh databázových tabulek, až k návrhu samotného integračního paternu a jednoduchých mock aplikací a služeb, které tento patern otestují. 6.1 Analýza požadavků Analýza požadavků byla vytvořena na základě dialogu se zákazníkem. Jednotlivé požadavky odpovídají jeho byznys potřebám a byly tímto zákazníkem schváleny Funkční požadavky FP01 : Distribuce kurzovního lístku napříč heterogenní aplikační infrastrukturou Byl identifikován pouze jediný funkční požadavek, protože se jedná o distribuční patern a v tomto případě jsou mnohem důležitější nefunkční požadavky, které se zákazníkovi dlouhodobě nedaří naplnit Nefunkční požadavky NP01 : Použít WebSphere ESB jako middleware NP02 : Použít WebSphere aplikační server NP03 : Řešení musí běžet v clusteru NP04 : Použít standard XA transakcí 57

58 6. Analýza a návrh NP05 : Použít XA transakce v prostředí JAVA aplikací NP06 : Použít XA transakce v prostředí.net aplikací NP07 : Použít XA transakce v prostředí Oracle RDBMS NP08 : Dostupnost řešení musí být 24/7 6.2 Analýza architektury Z funkčních požadavků vyplývá jediný účel tohoto projektu a to je rozdistribuování kurzovního lístku, který poskytuje ČNB, do aplikací, které s tímto lístkem pracují. Tedy úkolem tohoto projektu je navrhnout střední vrstvu, která bude poskytovat funkcionalitu k šíření kurzovního lístku. Podobu integračního paternu také velice ovlivňují nefunkční požadavky na toto řešení. Aplikační infrastruktura banky je velice heterogenní, a proto je nutné transakčně distribuovat lístek do tří odlišných prostředí: JAVA,.NET, Oracle RDBMS. Protože veškeré aplikace, které pracují s kurzovním lístkem, podporují standard XA transakcí, byl tento standard vybrán pro transakční šíření kurzovního lístku. Z důvodu neustálé aktuálnosti kurzovních lístků, je na toto řešení kladen požadavek vysoké dostupnosti. Tento požadavek je reflektován v nefunkčních požadavcích na klastrové řešení a nepřetržitou dostupnost. Architektonická analýza bude dále rozdělena do dvou částí: Analýza distribučního paternu Analýza zpráv Analýza distribučního paternu V této části analýzy bylo využito poznatků ze čtvrté kapitoly o paternech, které se využívají na ESB. Výsledek provedení této analýzy si lze prohlédnout na obrázku 6.1, a v dalších odstavcích bude tento obrázek rozebrán. Nejdříve popíšeme okolí ESB, tedy odkud přichází událost do mediace na ESB a kam se tato událost naopak šíří z ESB. Celý životní cyklus aktualizace kurzovního lístku začíná změnou kurzu měny v České národní bance (dále jen ČNB), a odtud je tato změna šířena do databáze, určené pro uchovávání změn v kurzovních lístcích, vydávaných ČNB. Dále je nutné, aby veškeré změny z této databáze byly šířeny jako nové události ke zpracování do ESB. Vytváření nových událostí může být realizováno JDBC adaptérem, nebo specializovaným softwarem, který bude číst žurnál změn této databáze a při jeho změně bude vytvářet nové události. 58

59 6.2. Analýza architektury Obrázek 6.1: Analýza paternu 59

60 6. Analýza a návrh Na opačné straně ESB jsou umístěny aplikace a databáze, který pracují s kurzovním lístkem, a pro svou správnou činnost vyžadují aktuální kurzovní lístek. Jak již bylo zmíněno výše, tak aplikace jsou jak z prostředí Javy, tak také z prostředí.net. Všechny tyto aplikace poskytují pro účely distribuce kurzovního lístku webovou službu, která provede aktualizaci kurzů v příslušném úložišti dané aplikace. Rozdílným způsobem bude probíhat šíření zpráv do databáze Oracle. Zápis do databáze bude zprostředkovávat JDBC adaptér, který bude nasazen přímo na ESB. Tento adaptér již do databáze posílá přímo SQL příkazy, takže se zprávy budou překládat na tyto příkazy. Formátům a překladům zpráv je věnována další podkapitola. Od popisu okolí ESB se konečně dostáváme k samotnému distribučnímu paternu, který bude provozován na ESB. Celý vzor začíná vstupním rozhraním, které přijímá zprávy s událostmi, vyvolanými změnou v databázi pro kurzovní lístky. Je tedy zřejmé, že tento distribuční patern bude vycházet ze vzorů událostmi řízené integrace. Jak již ale bylo napsáno v teoretické části, tak tyto vzory využívají dalších elementárních paternů pro realizaci distribuce událostí. Po převzetí události vstupním rozhraním je tato zpráva šířena do všech větví tohoto mediačního vzoru. Každá z větví odpovídá jednomu konzumentovi této zprávy, tedy koncové aplikaci očekávající aktualizaci kurzovního lístku. Tato architektura počítá s případným rozšířením počtu konzumentů kurzovního lístku, protože v tomto případě by to pouze znamenalo rozšíření tohoto paternu o další větev, a tato změna by neměla žádný dopad na stávající implementaci. Každá z těchto větví v podstatě slouží jako konektor k aplikaci, s kterou má komunikovat. Tyto konektory se skládají z překladu zprávy na formát, který je očekáván webovou službou dané aplikace. Dále tento konektor provede vyhledání endpointu webové služby v repozitáři služeb (důvod vychází z paternu virtualizace služeb v kapitole 4). Posledním krokem je zavolání webové služby s touto zprávou, a tedy předání kurzovního lístku pro použití v dané aplikaci. Na obrázku znázorňujícím tento patern si můžete také všimnout hranic, ve kterých probíhá distribuovaná transakce. Dále je také vidět, že veškerá volání webových služeb, ať už se jedná o vstupní rozhraní mediačního paternu nebo volání služeb jednotlivých aplikací, jsou zabezpečena username token, což je v podstatě uživatelské jméno a heslo. Tyto účty pro jednotlivé služby jsou uloženy jako technologické účty v repozitáři uživatelů Analýza zpráv V předchozí analýze byla vystavěna architektura pro šíření zprávy. Nyní ještě chybí zanalyzovat obsah zprávy, která bude ditribuována přes ESB. Schéma této zprávy je znázorněno na obrázku 6.2. Zpráva v sobě nese informace o změně kurzu v ČNB, platnost tohoto kurzovního lístku a měny, kterým se mění jejich kurz. Ve zprávě mohou být 60

61 6.3. Návrh demoverze řešení vloženy změny více než jedné měny, což bude v případě změny více kurzů v jeden časový okamžik znamenat menší zátěž pro přenosový kanál. Obrázek 6.2: Schéma zprávy V předchozí kapitole byla zmínka o transformaci zprávy pro různé aplikace a databáze. Co se týká aplikací, a jejich webových služeb, není nutno tuto zprávu nijak výrazně upravovat, protože všichni konzumenti podporují stejný typ zprávy. V těchto zprávách se pak pro různé konzumenty musí lišit jen použitý namespace. V případě zápisu do databáze je manipulace se zprávou obtížnější. V databázi pro kurzovní lístek existují dvě tabulky. První z nich uchovává datum změny a období platnosti kurzovního lístku a druhá informace související s kurzem měny, tedy tu část zprávy, která je obalena v elementu Mena. Protože zápis do této databáze se provádí přes JDBC konektor, je nutné tuto zprávu rozdělit na dva nezávislé SQL insert příkazy. 6.3 Návrh demoverze řešení Projekt řešící problematiku distribuce kurzovního lístku vznikl proto, aby byla prokázána funkčnost transakčního šíření kurzovního lístku do různorodých aplikačních prostředí. Z tohoto důvodu se v demoverzi nebude pracovat s ost- 61

62 6. Analýza a návrh rými konzumenty kurzovního lístku, a ani na druhé straně nebudou události produkovány ze změn v databázi. Pro potřeby demoverze bylo rozhodnuto, že vytváření událostí bude obstarávat jednoduchá J2EE servletová aplikace, a konzumenty budou jednoduché webové služby, které budou umožňovat zalogovat (případně uložit do databáze) kurzovní lístek. Návrh je zobrazen na obrázku 6.4, který je velmi podobný obrázku z kapitoly analýzy paternu. Dalším krokem tohoto návrhu je určit, kde budou jednotlivé komponenty nasazeny. Pro tento účel byl vytvořen diagram, který je vidět na obrázku 6.3. Veškeré komponenty, které jsou napsané v Javě a běží na virtuálním stroji Javy, jsou nasazeny na WebSphere aplikační server. Na tomto serveru také běží WebSphere ESB a na něm nasazený mediační patern, který zprostředkovává přenos kurzovního lístku. Webová služba, která má simulovat aplikaci v.net, je nasazena na aplikační server IIS, a je připojena k vlastnímu datovému zdroji. Tímto zdrojem je Microsoft SQL server. Posledním konzumentem kurzovního lístku, který ještě nebyl zmíněn je Oracle RDBMS. Komunikace s touto databází je provedena pomocí konektoru obsaženého přímo v mediačním paternu. Obrázek 6.3: Diagram nasazení komponent 62

63 6.3. Návrh demoverze řešení Obrázek 6.4: Návrh paternu pro demoverzi 63

64 6. Analýza a návrh Diagram nasazení zde neplní pouze informativní roli o nasazení komponent, ale byl vytvořen také z důvodu konfigurace distribuované transakce. V diagramu lze vyčíst, že se jedná o tři různorodé prostředí, a proto by bylo na místě uvažovat o třech transakčních manažerech zdrojů. Pro oraclovskou část nepotřebujeme vlastní manažer zdroje, protože o transakční zpracování se postará JDBC konektor nasazený na WebSphere ESB a je tedy možné pro obě prostředí, tedy javu a oracle, použít stejný transakční manažer zdrojů. Tento manažer zdrojů je již součástí WebSphere aplikačního serveru a konfiguruje se v konfiguračním manažeru aplikačního serveru. Podobně je tomu u aplikačního serveru IIS, který je ovšem součástí operačního systému Microsoft Windows, proto se také tento manažer zdroje konfiguruje v rámci operačního systému. Poslední komponentou nutnou pro funkčnost XA transakcí je transakční manažer. V našem případě bude transakční manažer také komponentou operačního systému, protože všechny aplikační servery běží pod stejným operačním systémem a to Microsoft Windows. Poslední věcí, kterou je nutné před samotnou implementací navrhnout je typ a schéma přenášené zprávy. Nejběžnějšími zprávami, které se šíří přes ESB jsou XML zprávy, proto také v našem případě využijeme tohoto standardu. Obsah a datové typy elementů zprávy, reprezentující kurzovní lístek, lze vidět na XML schématu níže. Výhodou definice zprávy v XML schématu je ta, že zprávu lze jednoduše validovat pomocí standardních komponent ESB. Formáty zpráv webových služeb v javě a v.net se od původní zprávy liší pouze v použitém namespace. Toto opatření je zde použito pro oddělení implementace mezi aplikací vyvolávající událost a konzumenty této události. Při jakékoliv implementační změně u aplikace produkující zprávu, tedy i ve změně struktury této zprávy, není nutno měnit implementaci konzumenta zprávy, pouze provedeme přemapování zprávy v integračním paternu. Zprávy šířené do databáze oracle, budou pro použití konektoru překládány na dva SQL inserty, protože jak již bylo řečeno v analýze, data se propisují do dvou tabulek. Tyto dva SQL příkazy budou mít následující podobu: INSERT INTO metadatalistku (ID, DATUMZMENY, PALTNOSTOD, PLATNOSTDO) VALUES (id, datumzmeny, platnostod, platnostdo ) INSERT INTO kurz (ID, KODMENY, JEDNOTKAMENY, NAKUP, PRODEJ, MEDIAN) VALUES (id, kodmeny, jednotkameny, nakup, prodej, median ) 64

65 6.3. Návrh demoverze řešení XML schéma přenášené zprávy <?xml version=" 1. 0 " encoding="utf 8"?> <xs:schema xmlns:xs=" h t t p : //www. w3. org /2001/XMLSchema" xmlns:ns1=" h t t p : //ws. dto. exchange. l i s t. xy. cz /v1 " targetnamespace=" h t t p : //ws. dto. exchange. l i s t. xy. cz /v1 " elementformdefault=" q u a l i f i e d " attributeformdefault=" u n q u a l i f i e d "> <x s : e l e m e n t name=" KurzovniListek "> <xs: complextype> <x s : s e q u e n c e> <x s : e l e m e n t name="datumzmeny" type=" xs:datetime " /> <x s : e l e m e n t name=" PlatnostOD " type=" xs:datetime " /> <x s : e l e m e n t name=" PlatnostDO " type=" xs:datetime " /> <x s : e l e m e n t name=" KurzyMen "> <xs: complextype> <x s : s e q u e n c e> <x s : e l e m e n t name="mena" maxoccurs=" unbounded "> <xs: complextype> <x s : s e q u e n c e> <x s : e l e m e n t name="kodmeny"> <xs:simpletype> < x s : r e s t r i c t i o n base=" x s : s t r i n g "> <x s : l e n g t h value=" 3 " /> </ x s : r e s t r i c t i o n> </ xs:simpletype> </ x s : e l e m e n t> <x s : e l e m e n t name=" JednotkaMeny " type=" x s : i n t e g e r " /> <x s : e l e m e n t name=" Nakup " type=" x s : d e c i m a l "> <x s : e l e m e n t name=" Prodej " type=" x s : d e c i m a l "> <x s : e l e m e n t name=" Median " type=" x s : d e c i m a l "> </ x s : s e q u e n c e> </ xs: complextype> </ x s : e l e m e n t> </ x s : s e q u e n c e> </ xs: complextype> </ x s : e l e m e n t> </ x s : s e q u e n c e> </ xs: complextype> </ x s : e l e m e n t> </ xs: schema> 65

66

67 KAPITOLA 7 Realizace Tato kapitola bude zaměřená na implementaci klíčových a implementačně zajímavých částí řešení. Mezi tyto části bezesporu patří celý integrační patern. Další důležitou částí tohoto projektu bylo také zprovoznění DTC (Distributed Transaction Coordinator) pod operačním systémem Microsoft Windows. Ovšem návod na zprovoznění tohoto transakčního manažeru by tuto práci zbytečně natahoval, tak je tento návod k nalezení na přiloženém CD nosiči. 7.1 Projekty Obrázek 7.1: Vlevo workspace javy, pravá část je řešení.net služby Na obrázku 7.1 lze vidět, že pro vývoj tohoto řešení byla využita dvě vývojová prostředí, a to WebSphere Integration Developer a Microsoft Visual Studio. Ve workspace WebSphere Integration Developer můžeme vidět sedm projektů: 67

68 7. Realizace CWYBC_JDBC - pomocný projekt pro překlady XML zpráv do SQL příkazů EventDrivenIntegrationLib - pomocný projekt pro integrační patern, který obsahuje wsdl soubory všech webových služeb, které jsou z paternu volány, dále obsahuje XML schémata zpráv, které jsou v paternu použity, a také jsou zde uloženy jednotlivé mapování EventDrivenIntegrationPatern_V1_0 - projekt obsahuje samotný integrační patern ExchangeListReceiver_V1_0 - projekt obsahující webovou službu, která přijímá kurzovní lístek (služba simulující Java aplikace) ExchangeListReceiverEAR_V1_0 - projekt sloužící k vytváření deployment archivu z projektu ExchangeListReceiver_V1_0 ExchangeListSender_V1_0 - projekt obsahuje servletovou aplikaci, která slouží k vytváření událostí (tedy odesílání kurzovního lístku do mediačního paternu) ExchangeListSenderEAR_V1_0 - projekt sloužící k vytváření deployment archivu z projektu ExchangeListSender_V1_0 Posledním projektem na obrázku je projekt ExchangeListReceiverNet_V1_0, který implementuje konzumenta kurzovního lístku pro prostředí.net. 7.2 Implementace mediačního paternu Obrázek 7.2: Implementace mediačního paternu Obrázek 7.2 znázorňuje implementaci mediačního paternu. Zelené hranice kolem komponent označují části paternu, které běží v transakčním zpracování. Na obrázku lze dále vidět vstupní rozhranní přijímající kurzovní lístek, dvě výstupní rozhraní pro webové služby (Java,.NET) a jeden konektor do Oracle databáze. 68