Jak funguje ESB

Při nasazování podnikových systémů upřednostňuje stále více středních a velkých organizací architekturu orientovanou na služby SOA (Service Oriented Architecture). Vývojáři a IT oddělení podle principů SOA navrhují, implementují a provozují informační systémy složené z komponent, které vykonávají diskrétní procesní funkce.

Komponenty zvané služby je možné podle potřeby distribuovat přes geografické a podnikové hranice, nezávisle škálovat a rekonfigurovat do nových podnikových procesů. Taková flexibilita je výhodná jak pro IT oddělení, tak pro celý podnik.

Základ IT infrastruktury založené na SOA tvoří stále častěji podniková sběrnice služeb ESB (Enterprise Service Bus), která spojuje a zprostředkovává všechny komunikace a interakce mezi službami. Zároveň dovoluje služby a procesy rychle měnit, snadno je připojovat, zviditelnit a řídit. Protože ESB má značný vliv na náklady spojené s vývojem a provozem daného podnikového systému, je účelné dobře porozumět její struktuře a funkcím.

Schéma na obr. 1 ukazuje příklad architektury SOA použité pro integraci a mediaci vícekanálového finančního kapitálového procesu. Jde o kombinaci již existujících (legacy) systémů opatřených rozhraním, díky němuž fungují jako služby, a nově vytvořených služeb. Ze schématu je patrné, že objednávka z burzy je nejprve zpracována službou pro správu objednávek. Poté prochází transformací dat, aby vyhověla požadavkům kapitálového systému, a ověřením, zda vyhovuje příslušným předpisům a vyhláškám (služba compliance). Dále je zpracována službou pro zpracování obchodu a poté dojde k samotnému převodu finančních prostředků. Nakonec je objednávka zapsána jako dokončená transakce logovací službou. Přitom nejde o jednu integrovanou aplikaci – celý proces je vykonáván jako sekvence heterogenních procesních kroků koordinovaných infrastrukturou ESB. V tomto případě poskytuje sběrnice ESB konektivitu a směrování toku dat mezi službami, transformuje XML data, čímž umožňuje komunikaci služeb s rozdílnými rozhraními, a zajišťuje posloupnost vykonávání jednotlivých služeb tak, aby odpovídala danému podnikovému procesu.

Služby, komunikace a mediace

Jedním z průkopníků ESB je společnost Sonic Soft ware, která kromě produktové realizace (Sonic ESB) také formalizovala popis jejích funkcí pomocí schémat založených na standardizovaném modelovacím jazyku UML (Unified Modeling Language). UML Class schémata slouží k architektonické definici ESB, která je užitečná pro porozumění principům ESB a diskuzi s podnikovými SOA architekty. Základem architektury SOA je podpora služeb a jejich komunikace. Na obr. 2 je UML Class schéma s přehledem ESB struktur podporujících služby, komunikaci a mediaci (tj. zpracování zpráv na sběrnici). ESB služby (levá část schématu na obr. 2) mohou být různých typů. Typické ESB služby pro mediaci jsou: transformace XML, směrování podle obsahu (Content-Based Routing) a uživatelsky definovaná mediace (User Defined Mediation). Služba transformace XML provádí datovou konverzi z jednoho XML dokumentu do druhého podle specifikace XSLT. Služba směrování podle obsahu řídí přenos zpráv ke koncovým bodům jiných služeb, přičemž se řídí nastavenými směrovacími pravidly. Služba uživatelsky definované mediace vykonává funkce jako logování nebo uživatelsky definované validace, které doplňují základní procesní logiku. Procesní (business) služby pro provádění základní procesní logiky spojuje uživatelsky definovaná ESB služba. ESB služby vykonávají svou činnost v rámci ESB kontejneru. Tento kontejner slouží k vytvoření instancí ESB služeb a poskytuje rozhraní pro jejich správu. Umožňuje také správu komunikačních protokolů a kvůli lepší škálovatelnosti dovoluje vykonávat služby více vlákny. Standardně také umožňuje vykonávat distribuované procesy.

Připojené business služby

Připojené služby (pravá část schématu na obr. 2) vykonávají procesní logiku aplikací integrovaných pomocí ESB. Mezi typy procesních služeb patří webové služby, převzaté (legacy) systémy, aplikace založené na JMS (Java Message Service) a všechny druhy aplikací provozovaných na aplikačním serveru. Všechny typy procesních služeb mohou prostřednictvím ESB navzájem komunikovat a s ESB službami vykonávat mediaci. Například služba pro správu objednávek na obr. 1 je připojená služba, která se spojuje pomocí HTTP připojení. Naproti tomu služba compliance, služba pro zpracování obchodu a služba pro převod prostředků jsou procesní služby, které byly spojeny s ESB přímo jako uživatelsky definované ESB služby.

Komunikace a ESB procesy

Prostřední část schématu na obr. 2 znázorňuje klíčovou schopnost procesních i ESB služeb komunikovat a vykonávat ESB proces – sekvenci kroků aktivujících služby nebo jiné ESB procesy. Kapitálový proces na obr. 1 je pětikrokovým ESB procesem. ESB služba zasílá a přijímá zprávy prostřednictvím odkazů na koncové vstupní a výstupní body ESB služeb či ESB procesů. Například ESB služba (jako je služba compliance na obr. 1) může nastavit svůj výstup tak, aby odkazoval na vstupní koncový bod další služby (v našem případě Služby pro zpracování obchodu), která tyto zprávy přijme. Alternativně mohou koncové body ESB odkazovat na jiný ESB proces. ESB proces je definován ESB itinerářem obsahujícím sekvenci procesních kroků. Každý procesní krok může vyvolat jednu (nebo několik) ESB služeb, jiných ESB procesů nebo externí webovou službu. ESB itinerář je doručován spolu s příslušející ESB zprávou, čímž vzniká kompletně distribuované a zároveň velmi spolehlivé prostředí pro zpracování ESB procesu. Neexistuje v něm žádný centrální engine pro provádění itineráře – každý ESB kontejner může samostatně zpracovat příslušný krok v ESB itineráři a směrovat následující krok. Tím je zajištěno jak efektivní vykonávání procesních kroků bez nutnosti komunikovat s centrálou, tak spolehlivost, protože zpracování může pokračovat, i když dojde k určitým výpadkům konektivity. U každé ESB služby může dojít ke změně jejího vstupního a výstupního bodu bez toho, aby došlo ke změně jejich implementace.

Koncový bod ESB umožňuje ESB službám zasílat a dostávat zprávy se specifikovanou QoS (Quality-of-Service) – například „best eff ort“ nebo „guaranteed, once-and-only-once“. Připojení rozpozná, který podpůrný kanál zpráv je použitý koncovým bodem ESB pro propojení s procesní nebo ESB službou. Tento kanál zpráv může používat nativní ESB propojení nebo může pro externí systémy využít webovou službu, propojení JMS nebo adaptér JCA (J2EE Connector Architecture). ESB propojení využívá uživatelsky konfigurovatelnou asynchronní a synchronní sémantiku včetně „publish-and-subscribe“, „send-and forget“ a „request-reply“. ESB propojení mezi službou pro správu objednávek a kapitálovým procesem v příkladu na obr. 1 je request-reply webové služby. Pokud procesní nebo ESB služba potřebuje změnit způsob, kterým se připojuje, může toho dosáhnout, aniž by bylo nutné měnit její implementaci. V případě, že služby vyžadují odlišné typy propojení, poskytuje ESB mediaci mezi odlišnými protokoly. Třída ESB zpráv spolu se zasílací a přijímací vazbou mezi koncovými body vytvářejí základní strukturu k tomu, aby jedna služba mohla poslat zprávu druhé ESB službě prostřednictvím dispečera ESB služeb. Dispečer spravuje zasílání a přijímání ESB zpráv mezi ESB službami a externími koncovými body – ve schématu na obr. 1 realizuje šipky mezi jednotlivými procesními kroky. Tento dispečer také spravuje ESB procesy. Pro ESB služby a ESB procesy mohou být vytvářeny standardizované definice WSDL (Web Services Definition Language). To dovoluje použití standardních nástrojů a integraci s dalšími komponentami infrastruktury SOA, jako je registr UDDI. Například na obr. 1 je celý kapitálový proces vystaven jako webová služba.