Distribuované transakce

Distribuované transakce Štěpán Vacek Fakulta informatiky a managementu Univerzita Hradec Králové [email protected] Abstrakt: Tato práce se zaměřuje na problematiku distribuovaných transakcí v prostředí velkých organizací. Záměrně v názvu neuvádím databázových transakcí, protože infrastruktura podniku může být (a zpravidla je) daleko pestřejší. Počínaje databázemi přes messaging a konče proprietárními systémy různých dodavatelů. Je samozřejmé, že u většiny systémů bez ohledu na komunikační protokol jsou data většinou uložena v databázi. První část práce popisuje prostředí velké organizace s mnoha heterogenními systémy. Druhá část se věnuje vlastní definici transakce a v třetí části je popsán přístup při návrhu distribuovaných systémů, především s odkazem na moje vlastní praktické zkušenosti. Poslední část obsahuje praktické příklady použití a srovnání jednotlivých přístupů. Klíčová slova: distribuované transakce, podniková architektura, střední vrstva, podniková sběrnice služeb Abstrakt: This paper is focused on distributed transactions in enterprise environments. I don't purposely introduce database transactions because an infrastructure of companies may be much more different. From database systems through messaging platform to enterprise applications, delivered by various vendors. Naturally the most of systems, without dependencies on communication protocols, have data stored in a database. In the first part it is present an environment of enterprise with heterogeneous systems. The second one describes a definition of transaction and the third one describes an approach to design of distributed systems with reference to my own practical experience. The last part contains practical examples and comparing of particular approaches. Key words: distributed transaction, enterprise architecture, middleware, enterprise service bus

1. Heterogenní prostředí Podniková infrastruktura velké firmy je velice často tvořena mnoha vzájemně nekompatibilními systémy, které jsou nasazeny v heterogenním prostředí – ať už se jedná o hardware, software nebo různé technologicky platformy. Velký podíl na tom má nejen zlepšování technologií, ale především historický vývoj jednotlivých systémů. Firmy postupně investují do vývoje nebo nákupu programů nemalé prostředky, a proto nemohou nebo nechtějí jednoduše změnit většinu aplikací podle zrovna aktuálních trendů. Snaží se v maximální možné míře zvýšit návratnost svých investic (ROI – Return of investment). Právě v takovémto prostředí můžeme velmi efektivně uplatnit systémovou integraci, která využívá nástrojů EAI (Enterprise application integration) nebo principů SOA (Service-oriented architecture). Prostředky, které poskytují technologické řešení, obyčejně musí podporovat transakce – nejčastěji ty distribuované pro rozdílné zdroje a protokoly. Většinou jsou podporovány databáze, messaging (MOM – Message-oriented middleware) nebo distribuované komponenty (například EJB – Enterprise Java Beans, CORBA – Common Object Request Broker Architecture).

SYSTÉMOVÁ INTEGRACE 3/2010

17

Štěpán Vacek

2. Transakce Transakcí rozumíme logickou skupinu, která obsahuje více vzájemně závislých operací. Je důležité, aby transakce splňovala základní vlastnosti [3] označené akronymem ACID (Atomicity, Consistency, Isolation, Durability).  atomicita (atomicity) – Transakce by za každých okolností měla být zpracována jako celek, buď proběhnou úspěšně všechny operace, nebo žádná.  konzistence (consistency) – Systém musí zajistit, aby data byla konzistentní, což se samozřejmě týká i chybových stavů jako přerušené spojení nebo havárie serveru. Databáze v takovém případě implicitně provádí zrušení (rollback) všech nedokončených transakcí a potvrzená data jsou po spuštění databáze v případě potřeby obnovena do konzistentní podoby.  izolace (isolation) – Izolace transakce je důležitá při paralelním zpracování, kdy nad stejnou množinou dat může pracovat více procesů najednou. Systém rozlišuje několik úrovní izolace, kdy ve výchozím nastavení jsou data ostatním transakcím viditelná až po potvrzení změn.  trvalost (durability) – Potvrzené změny jsou trvalé. Při potvrzení transakce máme jistotu, že došlo k uložení do trvalého úložiště. Ale nikde už není určeno, že se data musí uložit pouze do datových souborů. Často bývají potvrzené transakce uloženy v transakčním žurnálu a do datových souborů jsou data zapisována kvůli výkonu asynchronně. V případě havárie je databáze schopná potvrzené transakce (uložené pouze v transakčním žurnálu) obnovit do konzistentního stavu. Transakční zpracování začíná buď explicitním označením začátku transakce, v případě aplikační vrstvy, nebo prvním dotazem manipulujícím s daty (DML – Data manipulation language). Poznámka: Příkazy pro změnu struktury databáze (DDL – Data definition language) jsou automaticky spouštěny v atomické transakci a potvrzují předchozí transakci.

2.1 Úroveň izolace Izolace je důležitá při souběžném přístupu k datům. Určuje, jakým způsobem se s daty v jednotlivých transakcích bude pracovat a jak budou data ovlivněna z dalších transakcí. Nastavením úrovně izolace se můžeme setkat s chováním, které podle [2] vykazuje tyto příznaky:  špinavé čtení (dirty reads) – Transakce může číst data, která byla zapsána jinou transakcí, ale ještě nedošlo k jejich potvrzení.  neopakovatelné čtení (non-repeatable reads/fuzzy reads) – Transakce čte opakovaně stejné hodnoty, ale dostává různé výsledky. Ty jsou ovlivněny potvrzenými změnami v jiných transakcích.  výskyt fantomů (phantom reads) – Transakce několikrát spustí dotaz, který vrací kolekci dat. Výsledná kolekce se v jednotlivých bězích liší, což je způsobeno vložením (a potvrzením) dat jinou transakcí. Úroveň izolace neovlivňuje jenom viditelnost změn, ale má zásadní dopad také na výkon aplikace. Při restriktivním přístupu, kdy jednotlivé transakce v maximální 18


Distribuované transakce

možné míře izolujeme, dochází k zamykání záznamů a konkurenční transakce musejí čekat. Tím hrozí uvíznutí (deadlock), protože transakce si vzájemně uzamknou data a čekají na uvolnění zámků. SQL standard (ANSI/ISO [13]) rozlišujeme několik základních typů izolace (podle zdrojů [2] a [3]):  sériové zpracování (serializable) – Pracuje s daty, jako kdyby jednotlivé transakce byly spuštěny za sebou. Pokud se transakce snaží změnit data, která jsou již modifikována jinou transakcí, dojde k chybě a nezáleží, jestli bylo provedeno potvrzení. Naopak při čtení ostatní transakce nemají možnost spuštěnou transakci ovlivnit. Tato vlastnost se používá především při sestavování složitých reportů, když potřebujeme konzistentní stav celého systému a jiná transakce nesmí změnit data pro zpracování.  čtení potvrzených (read commited) – Pokud je vyžadována změna řádku, který je modifikován jinou transakcí, aktuální transakce čeká, než dojde k ukončení předchozí transakce a uvolnění zámku (potvrzením nebo zrušením transakce). Teprve potom může být provedena změna a řádku je přiřazen nový zámek. Pracují-li dvě transakce se stejnými daty, může nastat uvíznutí, neopakovatelné čtení nebo se objevují fantomy.  čtení nepotvrzených (read uncommited) – Transakce může číst data ostatních transakcí, která ještě nebyla potvrzena. Dochází ke špinavému a neopakovatelnému čtení, mohou se objevovat fantomy.  opakovatelné čtení (repeatable read) – Opakovatelné čtení zajišťuje, že stejný dotaz nemůže vrátit rozdílné výsledky. Pokud dotaz přečte data, zajistí zachování aktuálního stavu pro budoucí použití (nejčastěji zámkem nebo verzováním). Nejsou ovšem řešeny fantomy. Standard ANSI/ISO však v detailech není příliš přesný, a proto každý systém může drobnosti implementovat po svém. Některé systémy mohou třeba obsahovat další úrovně izolace. Například rozhraní JDBC (Java Database Connectivity) kromě základních úrovní podporuje spuštění příkazu v samostatné transakci (transaction none). To má pozitivní dopad na výkon, protože systém nemusí pracovat s daty pro případné zrušení transakce a tvořit tak undo nebo roll-back segmenty. Messagingové systémy, jako implementace JMS (Java Message Service) nebo WebSphere MQ (Message Queue), díky svému konceptu front s izolační úrovní vůbec nepracují. Obvykle se rozlišuje pouze mezi lokální a distribuovanou transakcí. Různě se mohou chovat jednotlivé implementace například při routování (mezi servery) nebo propagaci zpráv (přemostění front).

2.2 Záchranné body Transakce může být rozdělena do několika částí pomocí záchranných bodů (savepoints), které umožňují zrušení části zpracování a návratu ke konkrétnímu bodu. Tyto body mají ovšem smysl pouze v případě, kdy existuje reálná možnost zotavení: buď alternativním zpracováním v kódu, nebo opakováním volání zdroje. Při jejich implementaci musíme být opatrní, aby nedošlo k zacyklení. Je důležité poznamenat, že použití záchranných bodů má svoje omezení. V současné době tuto vlastnost implementují především databáze a její použití je SYSTÉMOVÁ INTEGRACE 3/2010

19

Štěpán Vacek

poměrně striktní. Například Oracle podle [4] podporuje záchranné body pouze u rozhraní JDBC 3.0 (a vyšší) a jen pro lokální transakce. U messagingových systémů se s nimi nesetkáme vůbec a webové služby je zatím nepodporují.

3. Distribuované 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ími 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 (transaction manager), který prostřednictvím manažera zdrojů (resource manager) zajišťuje řízení koncového systému. Potvrzovacím komunikačním protokolem je obvykle dvoufázový commit (2PC – Two-phase Commit Protocol), který zabezpečí, že transakce rozprostřená do více zdrojů proběhne buď jako celek nebo neproběhne vůbec.

3.1 Koncept komunikace 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 [1]:  transakční klient (transaction client) – 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 (transaction manager) – Komponenta, která koordinuje potvrzení nebo zrušení transakce nad všemi zúčastněnými zdroji.  manažer zdroje (resource manager) – Řídí lokální část transakce z pohledu konkrétního zdroje. Jiné prameny [1] a [10] uvádějí mírně odlišné názvosloví, ale podstata je velmi podobná. Vždy záleží na tom, jakou úroveň detailu a z jakého pohledu (databáze nebo aplikační vrstva) vybraný zdroj danou problematiku popisuje. V praxi se můžeme nejčastěji setkat s těmito ekvivalenty: transakční klient (aplikace, klientská aplikace), transakční manažer (transakční koordinátor, globální koordinátor) a manažer zdroje (lokální manažer, uzel).

3.2 Dvoufázový commit Dvoufázový commit je úzce svázán se standardem X/Open Distributed Transaction Processing [14], 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í.

20



Obr. 1: Koncept 2PC (podle [1]) 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ěly bychom použít ovladač pro lokální transakce. Transakce je podle [1] 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. (Obr. 1, krok 1.)  S tímto identifikátorem transakce jsou následně volány všechny operace nad jednotlivými zdroji. (Obr. 1, krok 2. a 3.)  Po skončení zpracování odesílá klientská aplikace transakčnímu manažeru požadavek na potvrzení transakce. (Obr. 1, krok 4.)  Transakční manažer odešle požadavek na všechny zúčastněné zdroje, které nastaví status transakce na "PREPARED" (připraveno) a vrátí výsledek. (Obr. 1, krok 5.)  Pokud všechny zdroje úspěšně odpoví, pak transakční manažer označí transakci za potvrzenou a odesílá požadavek na potvrzení všem zdrojů. Pokud některý ze zdrojů neodpoví, potom manažer odešle požadavek na zrušení transakce. (Obr. 1, krok 6.) Pokud by při vlastním potvrzování (v Obr. 1, krok 6.) 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 SYSTÉMOVÁ INTEGRACE 3/2010

21

Štěpán Vacek

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í.

3.3 Historický vývoj V minulosti se ke koordinaci transakcí využívaly především transakčně-procesní monitory (TPM – Transaction Processing Monitor), které dokázaly zpracovat velké množství požadavků napříč různými typy systémů a platforem včetně mainframů. V těchto případech pro realizaci distribuovaných transakcí sloužily právě TPM – mezi jejichž zástupce patří například IBM IMS, IBM CICS nebo Oracle Tuxedo (dříve BEA). Není ovšem výjimkou, že velké organizace v oblasti bankovnictví, pojišťovnictví nebo státní správy stále ještě dnes využívají programy napsané v COBOLu. A stejně tak se v těchto organizacích stále často používají TPM. Díky rozšiřujícím adaptérům mohou být součástí podnikové infrastruktury na bázi SOA a poskytovat rozhraní třeba pro webové služby nebo messaging. Postupem času se začala zlepšovat podpora distribuovaných transakcí v databázích (vystupujících v roli transakčního manažeru) nebo v aplikačních serverech. Obecně sice nemají takový výkon jako TPM, které jsou k tomuto použití přímo určeny, ale pokud to není nezbytně nutné, nemusíme licencovat další software a vývoj je podstatně jednodušší. V dnešní době tedy máme na výběr ze široké palety transakčních manažerů, které jsou nasazeny na různých místech, včetně samostatných jednoúčelových knihoven (JBossTM/Arjuna nebo JOTM) – ty bývají obvykle přímo součástí aplikace. S rostoucím významem systémové integrace se řízení transakcí přesouvá na integrační vrstvu, která v sobě obsahuje různé typy transakčních manažerů. Nejčastěji v podobě vlastní knihovny nebo jako součást transportní vrstvy (MOM, TPM). Díky tomu můžeme způsob zpracování transakcí ovlivnit už při návrhu integračních aplikací, které jsou posléze nasazeny v podnikové sběrnici služeb (ESB – Enterprise Service Bus). Ta realizuje volání koncových aplikací a zajišťuje kompozici služeb, transformace dat nebo konvergenci protokolů. Zároveň ESB poskytuje infrastrukturní služby pro logování, monitoring, cachování, bezpečnost nebo centralizovanou správu nastavení. V minulosti se transakční aplikace, které měnily data ve více systémech, převážně navrhovaly jako synchronní a krátce běžící (short-running). Jejich odezva byla v řádech milisekund nebo sekund – delší jen zcela výjimečně. V současné době je situace trochu jiná a kromě jednoduchých operací, u kterých převažuje čtení, se často při návrhu převede zpracování na asynchronní komunikaci. Důvod je jednoduchý. Velké podniky mají mnoho heterogenních aplikací, vzrostlo množství zpracovávaných dat a obchodní procesy (podporované aplikacemi) jsou daleko složitější, což vede k náročnějšímu zpracování v programech. Daleko větší množství systémů je náchylnější k chybám a výpadkům. Rovněž se při velké zátěži může prodloužit doba odezvy, což obvykle vede k nedostupnosti aplikace (vyprší čas pro zpracování – timeout). 22



Velký důraz je proto ze strany zadavatele kladen na kvalitní návrh. Z obchodního pohledu je naprosto klíčové, aby systém mohl zpracovat požadavek i v případě, že některá ze zúčastněných aplikací není v danou chvíli dostupná (to se nepochybně týká jen operací, které lze odložit na později). Dobře navržená asynchronní transakce garantuje zpracování a je dokončena v nejkratším možném čase, což v praxi může znamenat několik sekund, ale také hodin nebo dnů. Doba se přímo úměrně prodlužuje, pokud je například vyžadována interakce uživatele (tzv. human-task).

4. Praktické příklady V poslední části tohoto článku bych rád představil a porovnal tři přístupy, které jsou velmi často používány pro návrh aplikací využívající distribuované transakce. Výčet není samozřejmě úplný, ale poskytne dostatečnou představu o odlišnostech jednotlivých variant. Je důležité si uvědomit, že každý z přístupů je vhodný pro jiný typ aplikací a klade jiné požadavky na architekturu systému z pohledu složitosti analýzy (návrhu), rozdělení do vrstev nebo použitý software.

4.1 Aplikační server Mezi klasický a poměrně často využívaný přístup řízení distribuovaných transakcí patří nasazení komponenty nebo aplikace (vystupující jako transakční klient) na aplikační server. Ten v sobě obvykle obsahuje transakční manažer, který zajišťuje zpracování distribuovaných transakcí. U podnikových systémů, které jsou postaveny na třívrstvé architektuře, většinou využíváme i jiné zdroje aplikačního serveru jako connection pooling, remoting nebo podporu webových aplikací a služeb. Využití transakčního manažera je v tomto případě nejjednodušší řešením. Velkou výhodou je především vzájemná kompatibilita komponent aplikačního serveru a jednotná správa, často realizovaná prostřednictvím webové konzole. Máme-li placenou podporu aplikačního serveru, pak se tato podpora vztahuje i na transakční manažer. V případě potíží se máme kam obrátit, což zvláště u kritických chyb je velmi důležité. Pokud bychom použili transakční manažer třetí strany (jiný dodavatel nebo open source), dodavatel aplikačního serveru nám nemusí v případě chyby při distribuované transakci pomoci. Další výhodou je úzká vazba na ostatní služby serveru, které může transakční manažer využít: messaging, monitorování, logování nebo rozšiřující ovladače a adaptéry (např. pro přemostění komunikace s TPM). Nevýhodou je synchronní komunikace, která je bez MOM nebo složitého programování potřeba. Pokud je některý ze zdrojů v době zpracování požadavku nedostupný, je vrácena chyba a požadavek je nutné opakovat. U obchodního případu ovšem nemáme jistotu, že danou obchodní transakci (nákup zboží nebo objednání služby) nerealizuje zákazník někde jinde.


23

Štěpán Vacek

Obr. 2: Aplikační server řídí transakce (vlastní) Na obrázku je znázorněno, jak aplikace nasazená na aplikačním serveru odesílá požadavek prostřednictvím transakčního manažera (krok 1.). Ten v rámci transakce zajistí komunikaci s koncovými systémy (krok 2a, 2b), přičemž celé spojení je realizováno synchronně.

4.2 MOM Použití messagingu nám dovoluje převést synchronní komunikaci na asynchronní zpracování prostřednictvím front, které garantuje zpracování. MOM se většinou využívá v prostředí, kde je vyžadována střední vrstva a middleware zajišťuje komunikaci heterogenních systémů. Také může implementovat jednoduchou transportní logiku, využívány jsou především komunikační vzory (point-to-point a publish-subscribe [7]), filtrování nebo (podmíněná) replikace zpráv. V poslední době se vlastnosti MOM používají také pro generování událostí, které slouží jako základ pro architekturu založenou na událostech (EDA – Event driven architecture) a monitoring obchodních aktivit (BAM – Business activity monitoring). MOM je dodáván jako samostatný produkt (messaging server) nebo bývá součástí aplikačního serveru, případně ESB. Je důležité zmínit, že koncové aplikace si musejí načtení a zpracování požadavků zajistit ve vlastní režií. Stejně tak není řešena konvergence rozdílných protokolů (SOAP/HTTP, XML/JMS, JDBC apod.) nebo transformace datových struktur.

Obr. 3: Asynchronní zpracování prostřednictvím MOM (vlastní) Obrázek zobrazuje aplikaci nasazenou na aplikačním serveru, která odesílá synchronně požadavek do fronty na messagingový server (krok 1.) a ten provede replikaci zprávy do další fronty. Každá z front je zpracovávána samostatně jednou koncovou aplikací, z nichž kterákoliv si může požadavek vyzvednout v jiném čase (krok 2a, 2b). Celý postup lze na úrovni messagingového serveru realizovat 24



několika způsoby, buď použitím topiku již zmiňovanou replikací zpráv (tato funkcionalita ovšem nemusí být podporována všemi servery). Praktickým příkladem nasazení MOM může být velká finanční instituce, kde v současné době působím jako integrační specialista. Messaging je zde využíván pro zajištění komunikace vzájemně nekompatibilních systémů a platforem, počínaje Java EE přes .NET a konče mainframy. Kromě synchronní komunikace slouží MOM i pro asynchronní replikace dat mezi jednotlivými systémy, přičemž data jsou vyměňována prostřednictvím zpráv ve formátu XML (Extensible Markup Language).

4.3 ESB Jedním z posledních trendů v oblasti systémové integrace je ESB, které slouží jako platforma pro realizaci SOA a navázaných služeb, jako EDA nebo BAM. Páteřní síť pro komunikaci tvoří většinou MOM, který obstarává distribuci požadavků mezi heterogenními systémy. Kromě výhod spojených s MOM, zajišťuje ESB konvergenci protokolů a transformace struktury dat. Integrační procesy (někdy nazývané flow) reprezentují aplikace nasazené na úrovni ESB a vykonávají složitější integrační logiku: směrování podle obsahu (content-based routing), transformace datových struktur, kompozici požadavků nebo složitější orchestraci. ESB dovoluje zpracovat požadavky na jednotlivé systémy samostatně nebo jako distribuovanou transakci, k čemuž slouží zabudovaný transakční manažer (obvykle součást ESB nebo MOM).

Obr. 4: ESB řídí distribuovanou transakci (vlastní) Obrázek znázorňuje aplikaci nasazenou na aplikačním serveru, která synchronně odesílá požadavek na integrační vrstvu (krok 1.). Díky konvergenci protokolu na úrovni ESB může být požadavek předán například přes webovou službu nebo REST (Representational State Transfer). ESB požadavek interně převede prostřednictvím messagingu na asynchronní komunikaci a klientské aplikaci odpoví, že požadavek byl přijat ke zpracování. Následně v samostatném flow provede zpracování požadavku v transakci prostřednictvím transakčního manažera (krok 2., 3a, 3b). Součástí zpracování může být i další logika, jako transformace nebo konverze struktury zprávy. Tento přístup je implementován třeba při změnách nastavení hlasových a datových služeb přes internetovou samoobsluhu u jednoho tuzemského mobilního operátora, kde jsem působil jako integrační architekt. Zákazník zadá přes webové rozhraní SYSTÉMOVÁ INTEGRACE 3/2010

25

Štěpán Vacek

požadavek, který je synchronně předán střední vrstvě (využívající ESB) a ta vrátí potvrzení o jeho přijmutí. Požadavek je následně postoupen ke zpracování do jednotlivých systémů a po úspěšném dokončení je zákazníkovi odesláno potvrzení (formou textové zprávy na mobilní telefon). Celá transakce může trvat od několika sekund až po jednotky hodin, v závislosti na typu požadavku, zatížení systému nebo omezení (výpadku nebo odstávce některých komponent). V případě chyby je možný manuální zásah administrátora (aplikace), který může transakci dokončit

4.4 Porovnání jednotlivých přístupů Aplikační server (s transakčním manažerem) je vhodný především pro transakce, které je potřeba realizovat v relativně krátké době. Zpracování je synchronní a transakce musí být provedena v jasně definovaném časovém intervalu nad všemi zdroji. Neodpoví-li některý ze zdrojů ve stanoveném čase (timeout), dojde ke zrušení celé transakce. Zároveň dochází po celou dobu čekání na odpověď k blokování vlákna, které tak nemůže být využito jiným procesem (negativní dopad na výkon celého systému). Právě z tohoto důvodu je u dlouhotrvajících transakcí synchronní zpracování prostřednictvím transakčního manažera prakticky nepoužitelné. Omezeni jsme rovněž vlastním rozhraním XA, které jednotlivé zdroje pro distribuované transakce musí implementovat – to může být zvláště u proprietárních (balíkových) řešení problém. Domnívám se, že MOM je vhodné použít v těchto případech: buď chceme zajistit spojení systémů v heterogenním prostředí (synchronní/asynchronní), potřebujeme garantovat zpracování nebo je výhodné použít nativní funkčnost MOM (popsanou v části 4.2.). Ve všech uvedených případech messaging slouží jako transportní vrstva, která svoji povahou neudržuje přímé spojení mezi publikujícím a konzumentem. U synchronního zpracování je nutné po vložení požadavku do fronty korelována odpověď (obvykle) na další frontě. Pokud odpověď nepřijde do předem stanovené doby, musíme tento stav (chybu) ošetřit na aplikační úrovni. Většinou zpracování převádíme na asynchronní v případě, že je nutné garantovat zpracování požadavku, ale samotná rychlost nemusí být nutně klíčová. Máme jistotu, že ke zpracování dojde, ale nevíme přesně za jakou dobu1. Při velkém zatížení je nutné zajistit ochranu proti hromadění nezpracovaných požadavků ve frontě. Buď použitím monitorovacího mechanismu, který může být součástí MOM, nebo vyvinutím vlastního řešení. MOM se využívá zejména pro jednoduchou integraci heterogenních systémů, bez požadavků na konvergenci protokolu a složitější integrační logiku. Implementace distribuované transakce v rámci ESB je vhodná v případě, kdy chceme klientskou aplikaci z pohledu architektury postavit do role konzumenta služby a zpracování kompletně řídit v rámci ESB. Transakční zpracování může mít složitější charakter, včetně rozpadu na asynchronní zpracování a komplexní integrační logiku (např. komunikace s dalšími systémy, zpracování statických/dynamických podmínek, vytvoření úkolu pro uživatele). Je důležité uvést, že ESB se hodí pouze pro velké projekty, protože náklady na vytvoření a údržbu 1

V praxi se mi osvědčilo při definici doby odezvy uvádět charakteristiku "v nejlepším možném čase" a přiložit poznámku, jak dlouho zpracování obvykle trvá. 26



infrastruktury jsou poměrně vysoké. Jako nevýhodu zároveň vidím i nedostatek kvalifikovaných specialistů, protože podle mého názoru je velkých projektů postavených na ESB v České republice velmi málo – navíc je často vyžadována znalost konkrétní platformy (Oracle Service Bus, WebSphere Message Broker, TIBCO ActiveMatrix a další). Při rozhodování, který z uvedených přístupů pro distribuci transakce zvolit, se dostáváme do složité situace a je třeba si položit mnoho otázek. V potaz musíme vzít samozřejmě i to, jestli vyvíjíme samostatný systém nebo aplikaci, která bude součástí rozsáhlejší infrastruktury v organizaci. Osobně považuji za velmi důležité položit si především tyto otázky:  Jaké konkrétní principy a technologie v systému chceme využít?  Vyskytuje se v infrastruktuře ve fázi přípravy architektury systému nějaká komponenta, která již stejnou nebo podobnou funkcionalitu obsahuje?  Podporuje zvolený přístup konektivitu pro všechny systémy a platformy (hardwarové, softwarové), které chceme v projektu integrovat?  Existují v cílovém prostředí nějaké omezení, v podobě interních směrnic, zavedených standardů, doporučení nebo legislativy, které by definovalo funkční nebo nefunkční požadavky na systém?  Jaké náklady je možné vynaložit na zvolené řešení – včetně nákladů na hardware (procesor, paměť), software (licence) a služby (podpora, konzultace, školení zaměstnanců)?

5. Shrnutí Distribuované transakce jsou v literatuře převážně popisovány ve vazbě na databázové systémy, ovšem současná podniková architektura je daleko složitější a většinou transakce zasahují do několika různých zdrojů. V článku jsem se proto neomezil jenom na databáze, ale popisuji distribuované transakce v prostředí heterogenních systémů. Součástí článku je i charakteristika vybraných přístupů k návrhu, které mohou výrazně ovlivnit architekturu distribuovaných transakcí: logika transakcí řízena aplikačním serverem, asynchronní zpracování prostřednictvím MOM a složitější logika realizovaná pomocí ESB. Přínosy článku vidím kromě popisu heterogenního prostředí především v množství praktických příkladů a závěrečném srovnání.

Literatura [1] [2]

[3]

[4]

KRAFZIG, Dirk; BANKE, Karl; SLAMA, Dirk. Enterprise SOA: ServiceOriented Architecture Best Practices. 2005. 408 s. ISBN 0-13-146575-9. Oracle Database: Administrator's Guide [online]. 10g Release 2. Oracle, May 2006 [cit. 2010-05-12]. Dostupné z WWW: . Oracle Database: Database Concepts [online]. 10g Release 2. Oracle, October 2005 [cit. 2010-05-12]. Dostupné z WWW: . Oracle Database: JDBC Developer's Guide and Reference [online]. 10g Release 2.


27

Štěpán Vacek

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

28

Oracle, March 2010 [cit. 2010-05-12]. Dostupné z WWW: . Java Message Service (JMS) Specification. Sun Microsystems Inc. Version 1.1. April 2002 [cit. 2010-05-31]. Dostupné z WWW: . JSR-000907. Java Transaction API (JTA) Specification. Sun Microsystems Inc. Version 1.1. February 2007 [cit. 2010-05-12]. Dostupné z WWW: . ANSI/ISO/IEC International Standard (IS). Database Language SQL. July 1992. 686 s. [cit. 2010-08-29]. Distributed Transaction Processing (DTP): The XA Specification. The Open Group, C193. February 1992. ISBN 1-87263-024-3. [cit. 2010-08-29]


Distribuované transakce

Recommend Documents