Jak funguje ESB
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama

Jak funguje ESBJak funguje ESB

 

Jak funguje ESB

Google       Google       4. 8. 2006       16 315×

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.

Reklama
Reklama

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.

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

Tagy:
ESB
Hlasování bylo ukončeno    
0 hlasů
Google
(fotka) Lukáš ChurýLukáš je šéfredaktorem Programujte, vyvíjí webové aplikace, fascinuje ho umělá inteligence a je lektorem na FI MUNI, kde učí navrhovat studenty GUI. Poslední dobou se snaží posunout Laser Game o stupeň výše a vyvíjí pro něj nové herní aplikace a elektroniku.
Web     Twitter     Facebook     LinkedIn    

Nové články

Obrázek ke článku Malware KONNI se úspěšně skrýval 3 roky. Odhalil ho bezpečnostní tým Cisco Talos

Malware KONNI se úspěšně skrýval 3 roky. Odhalil ho bezpečnostní tým Cisco Talos

Bezpečnostní tým Cisco Talos odhalil celkem 4 kampaně dosud neobjeveného malwaru, který dostal jméno KONNI. Ten se dokázal úspěšně maskovat od roku 2014. Zpočátku se malware zaměřoval pouze na krádeže citlivých dat. Za 3 roky se ale několikrát vyvinul, přičemž jeho současná verze umožňuje útočníkovi z infikovaného počítače nejenom krást data, ale i mapovat stisky na klávesnici, pořizovat screenshoty obrazovky či v zařízení spustit libovolný kód. Pro odvedení pozornosti oběti zasílali útočníci v příloze také obrázek, zprávu a výhružkách severokorejského režimu či kontakty na členy mezinárodních organizací.

Reklama
Reklama
Obrázek ke článku Pouze jedna z deseti lokálních firem ví o pokutách plynoucích z GDPR

Pouze jedna z deseti lokálních firem ví o pokutách plynoucích z GDPR

Trend Micro, celosvětový lídr v oblasti bezpečnostních řešení a VMware, přední světový dodavatel cloudové infrastruktury a řešení pro podnikovou mobilitu, oznámily výsledky výzkumu mezi českými a slovenskými manažery zodpovědnými za ochranu osobních údajů, který zjišťoval, jak jsou připraveni na nové nařízení o ochraně osobních údajů (GDPR). Většina firem v České republice a na Slovensku nad 100 zaměstnanců je již s novým nařízením GDPR obeznámena. Výzkum provedený ve spolupráci s agenturou Ipsos ukázal, že téměř 8 firem z 10 o nařízení ví, přičemž jeho znalost je o něco vyšší na Slovensku (89 %) než v České republice (69 %).

Obrázek ke článku Vyděračský software Locky se vrací, tváří se jako potvrzení platby, odhalil tým Cisco Talos

Vyděračský software Locky se vrací, tváří se jako potvrzení platby, odhalil tým Cisco Talos

Jeden z nejznámějších ransomwarů, Locky, se vrací. Po většinu roku 2016 patřil mezi nejrozšířenější vyděračské softwary. Ke svému šíření využíval emailové kampaně s infikovanými přílohami. Ransomware Locky byl rozesílán prostřednictvím botnetu (internetový robot zasílající spamy) Necurs. Jeho aktivita na konci roku 2016 téměř upadla a spolu s ní i šíření ransomwaru Locky. Před několika týdny se Necurs opět probudil a začal posílat spamy nabízející výhodný nákup akcií. Dne 21. dubna zaznamenal bezpečnostní tým Cisco Talos první velkou kampaň ransomwaru Locky prostřednictvím botnetu Necurs za posledních několik měsíců.

Obrázek ke článku Dovozci baterií mění logistiku, letadlo nahrazuje námořní doprava

Dovozci baterií mění logistiku, letadlo nahrazuje námořní doprava

Dovozci baterií do mobilů či notebooků upouštějí od letecké přepravy zboží. V letošním roce plánují dovézt až 80 % produktů lodí. Přitom před 5 lety byla většina baterií do mobilních přístrojů dovezených do České republiky přepravována letadlem. Za proměnou způsobu transportu akumulátorů stojí zpřísnění pravidel pro leteckou přepravu, která přinášejí vyšší náklady i náročnou agendu.

Reklama autora

loadingtransparent (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();
Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032017 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý