Enterprise service bus - Enterprise service bus

Všechny zákaznické služby komunikují stejným způsobem s ESB: ESB přeloží zprávu na správný typ zprávy a odešle zprávu správnému zákaznickému servisu.

An podnikový servisní autobus (ESB) implementuje komunikační systém mezi vzájemně interagujícími softwarovými aplikacemi v a architektura orientovaná na služby (SOA). Představuje a softwarová architektura pro distribuované výpočty a je speciální variantou obecnějších klient-server model, kde se jakákoli aplikace může chovat jako server nebo klient. ESB podporuje agilitu a flexibilitu, pokud jde o komunikaci na vysoké úrovni mezi aplikacemi. Jeho primární použití je v integrace podnikových aplikací (EAI) heterogenních a komplexních služebních oblastí.

Architektura

Koncept podnikové servisní sběrnice je analogický s autobus koncept nalezen v architektura hardwaru počítače v kombinaci s modulárním a souběžným designem vysoce výkonných počítačových operačních systémů. Motivací pro vývoj architektury bylo najít standardní, strukturovaný a obecný koncept popisu implementace volně vázaných softwarových komponent (tzv. služby ), u nichž se očekává, že budou v síti nezávisle nasazeny, spuštěny, heterogenní a nesourodé. ESB je také běžným vzorem implementace pro architektura orientovaná na služby, včetně vnitřně přijatého síťového designu Celosvětová Síť.

Pro koncepty nebo implementace podnikové sběrnice služeb neexistují žádné globální standardy.[1] Většina poskytovatelů middleware orientovaný na zprávy přijali koncept podnikové sběrnice služeb jako de facto standard pro architekturu orientovanou na služby. Implementace použití ESB událost-řízený a na zprávách založený middleware na bázi standardů v kombinaci s fronty zpráv jako technologické rámce.[2] Někteří výrobci softwaru však označují stávající middleware a komunikační řešení za ESB, aniž by přijali zásadní aspekt konceptu sběrnice.

Funkce

ESB uplatňuje koncepci moderního designu operační systémy nezávislým službám běžícím v sítích různorodých a nezávislých počítačů. Stejně jako souběžné operační systémy poskytuje ESB kromě přijetí, překladu a směrování požadavků klientů také komoditní služby k odpovídajícím odpovídacím službám.

Hlavní povinnosti ESB jsou:

  • Směřujte zprávy mezi službami
  • Monitorujte a kontrolujte směrování výměny zpráv mezi službami
  • Vyřešte spor mezi komunikujícími komponentami služby
  • Řiďte nasazení a správu verzí služeb
  • Marshal využití nadbytečných služeb
  • Poskytovat komoditní služby, jako je zpracování událostí, transformace a mapování dat, řazení a řazení zpráv a událostí, zabezpečení nebo zpracování výjimek, převod protokolu a vynucování správné kvality komunikační služby.

Dějiny

První publikované použití pojmu „podnikový autobus“ je připisováno Royi W. Schulteovi ze skupiny Gartner Group 2002 a knize Enterprise Service Bus David Chappell. I když si za vytvoření této fráze připisuje uznání řada společností, Schulte v rozhovoru uvedl, že poprvé tuto frázi uslyšel od společnosti jménem Sonic, a dále řekl: „Nejpřímějším předkem ESB byl romský produkt společnosti Candle od roku 1998 “, ale produkt společnosti Sonic z roku 2002 byl prvním ESB na trhu.[3]

  • Služba - označuje ne iterativní a samostatně prováděné programy, které komunikují s jinými službami prostřednictvím výměny zpráv
  • Sběrnice - používá se obdobně jako hardware počítače autobus
  • Enterprise - koncept byl původně vyvinut za účelem snížení složitosti integrace podnikových aplikací v rámci podniku; omezení se stalo zastaralým, protože moderní internetová komunikace již není omezena na právnickou osobu

ESB jako software

ESB je implementován v softwaru, který funguje mezi obchodními aplikacemi a umožňuje komunikaci mezi nimi. V ideálním případě by ESB měla být schopna nahradit veškerý přímý kontakt s aplikacemi na sběrnici, aby veškerá komunikace probíhala přes ESB. K dosažení tohoto cíle musí ESB zapouzdřit funkčnost nabízenou jeho komponentními aplikacemi smysluplným způsobem. K tomu obvykle dochází při použití model podnikových zpráv. Model zpráv definuje standardní sadu zpráv, které ESB vysílá a přijímá. Když ESB obdrží zprávu, směruje ji do příslušné aplikace. Protože se tato aplikace vyvinula bez stejného modelu zprávy, musí ESB zprávu transformovat do formátu, který aplikace dokáže interpretovat. Softwarový adaptér plní úkol uskutečňovat tyto transformace, analogicky k fyzickému adaptér.[4]

ESB se spoléhají na přesnou konstrukci modelu podnikových zpráv a správné navrhování funkcí nabízených aplikacemi. Pokud model zprávy není úplně zapouzdřit funkčnost aplikace, pak další aplikace, které si tuto funkci přejí, budou muset obejít sběrnici a vyvolat neshodné aplikace přímo. Tímto způsobem porušujete zásady modelu ESB a vylučujete mnoho výhod používání této architektury.

Krása ESB spočívá v jeho platformně-agnostické povaze a schopnosti integrovat se s čímkoli za jakýchkoli podmínek. Je to důležité Správa životního cyklu aplikace prodejci skutečně využívají všechny možnosti ESB ve svých integračních produktech a zároveň si je osvojují SOA. Proto výzvy a příležitosti pro EAI prodejci mají poskytnout integrační řešení, které je levné, snadno konfigurovatelné, intuitivní, uživatelsky přívětivé a otevřené všem nástrojům, které si zákazníci vyberou.

ESB úl komoditních komponent

Vlastnosti

KategorieFunkce
Vyvolánípodpora synchronních a asynchronních transportních protokolů, mapování služeb (lokalizace a vazba)
Směrováníadresovatelnost, statické / deterministické směrování, směrování podle obsahu, směrování podle pravidel, směrování podle zásad
Zprostředkováníadaptéry, transformace protokolu, mapování služeb
Zprávyzpracování zpráv, transformace zpráv a vylepšení zpráv
Procesní choreografie ¹implementace komplexních podnikových procesů
Orchestrace služby ²koordinace více implementačních služeb vystavených jako jediná agregovaná služba
Složité zpracování událostíinterpretace událostí, korelace, porovnávání vzorů
jiný kvalita služebzabezpečení (šifrování a podepisování), spolehlivé doručení, správa transakcí
Řízenímonitorování, audit, protokolování, měření, administrátorská konzole, BAM (BAM není schopnost správy, jinými slovy, ESB nereaguje na konkrétní prahovou hodnotu. Jedná se o schopnost obchodních služeb, která se objevila u koncových uživatelů.)
Agnosticismusobecný agnosticismus vůči operačním systémům a programovacím jazykům; například by měl umožňovat interoperabilitu mezi Jáva a .SÍŤ aplikace
Konverze protokolukomplexní podpora standardů služeb aktuálních komunikačních protokolů
Vzory pro výměnu zprávpodpora různých poslanců (Vzory pro výměnu zpráv ) (například: synchronní požadavek / odpověď, asynchronní požadavek / odpověď, odeslání a zapomenutí, publikování / přihlášení k odběru)
Adaptéryadaptéry pro podporu integrace se staršími systémy, případně na základě standardů, jako je JCA
Bezpečnostnístandardizovaný model zabezpečení pro autorizaci, autentizaci a audit používání ESB
Proměnausnadnění transformace datových formátů a hodnot, včetně transformačních služeb (často prostřednictvím XSLT nebo XQuery ) mezi formáty odesílající aplikace a přijímající aplikace
Validaceověření proti schématům pro odesílání a přijímání zpráv
Správa věcí veřejnýchmožnost jednotného uplatňování obchodních pravidel
Obohaceníobohacující zprávy z jiných zdrojů
Rozdělit a sloučitrozdělení a kombinování více zpráv a zpracování výjimek
Abstrakcezajištění jednotné abstrakce napříč více vrstvami
Směrování a transformacepodmíněné směrování nebo transformace zpráv na základě ne centralizované politiky (bez nutnosti centrálního nástroje pro pravidla)
Komoditní službyzajišťování běžně používaných funkcí jako sdílených služeb v závislosti na kontextu

¹ Někteří nepovažují procesní choreografii za funkci ESB. Například viz M.Richards.[5]

² Zatímco procesní choreografie podporuje implementaci komplexních obchodních procesů, které vyžadují koordinaci více podnikání služby (obvykle využívající BPEL ), orchestrace služby umožňuje koordinaci několika implementačních služeb (nejvhodněji vystavených jako agregovaná služba), které slouží jednotlivým požadavkům.

Tato řešení se často zaměřují na nízkoúrovňové funkce ESB, jako je připojení, směrování a transformace, a pro implementaci orchestrace vyžadují kódování nebo skriptování.[6] Vývojáři pracující na projektové nebo taktické úrovni, např. Jen se snažící vyřešit problém, často tíhnou k lehkým technologiím sběrnice služeb, ale mezi těmito iniciativami a podnikovou architekturou, jejímž cílem je optimalizovat infrastrukturu napříč více projekty, často existuje napětí.[7]

Pokud zprostředkovatel zpráv, software ESB, přeloží zprávu z jednoho formátu do jiného, ​​pak jako u každého překladu dojde k problému sémantiky zprávy. Například záznam lze přeložit z JSON do XML, ale stejnou sadu polí lze interpretovat odlišně různými aplikacemi, konkrétně v případě různých rohových případů, které jsou obvykle známé pouze vývojářům, kteří mají s aplikací rozsáhlé zkušenosti který je připojen k ESB. U známých rohových případů se počet testů, které pokrývají všechny rohové případy, exponenciálně zvyšuje s každou aplikací, která je připojena k ESB, protože každá aplikace připojená k ESB musí být testována proti každé jiné aplikaci, která je připojena k ESB.

Klíčové benefity

  • Stupnice od bodových řešení po celopodnikové nasazení (distribuovaná sběrnice)
  • Více konfigurace než integrační kódování
  • Žádný centrální systém pravidel, žádný centrální makléř
  • Snadné zasunutí a zasunutí a volný spojovací systém

Klíčové nevýhody

  • Pomalejší rychlost komunikace, zejména u těch již kompatibilních služeb
  • Jediný bod selhání, může snížit veškerou komunikaci v Enterprise
  • Vysoká složitost konfigurace a údržby

produkty

Viz také: Porovnání softwaru pro obchodní integraci

Pozoruhodné produkty zahrnují:

Viz také

Reference

  1. ^ Lapeira, Raul. „ESB je architektonický styl, softwarový produkt nebo skupina softwarových produktů?“. Artefaktové poradenství. Archivovány od originál dne 8. 8. 2014. Citováno 2010-04-16. První věc, kterou by architekt ESB měl mít na paměti, je, že od roku 2010 neexistuje žádný globální standard pro ESB.
  2. ^ Curry, Edwarde. 2004. „Middleware zaměřený na zprávy“[trvalý mrtvý odkaz ]. v Middleware pro komunikaci, vyd. Qusay H. Mahmoud, 1-28. Chichester, Anglie: John Wiley and Sons. doi:10.1002 / 0470862084.ch1. ISBN  978-0-470-86206-3
  3. ^ „Rozdíl mezi zprostředkovatelem zpráv a ESB“. Citováno 2017-07-19.
  4. ^ http://shop.oreilly.com/product/9780596006754.do
  5. ^ Richards, Marku. „Role Enterprise Service Bus (prezentace)“. Citováno 2009-06-04. Nepovažuji procesní choreografii za součást ESB, pokud považujeme ESB za middleware pro vysokorychlostní zasílání zpráv. Procesní choreografii však považuji za součást platformy ESB *. Naštěstí většina prodejců ESB odděluje tyto hlavní komponenty do různých produktů, ale balí je do konsolidované nabídky ESB. V nejpřísnějším slova smyslu tedy ne, nepovažoval bych to za součást ESB. Jedná se o související schopnost.
  6. ^ Feraga, Matthias (6. června 2011). „Jak: výběr mezi lehkými a tradičními ESB“. Octo. Citováno 23. dubna 2014.
  7. ^ Fulton, Larry (12. září 2007). „Naučte se, jak přijmout lehké ESB“. Fo2014.

Další čtení

  • David Chappell, „Enterprise Service Bus“ (O’Reilly: červen 2004, ISBN  0-596-00675-6)
  • Binildas A. Christudas, „Service-Oriented Java Business Integration“ (Packt Publishers: únor 2008, ISBN  1-84719-440-0; ISBN  978-1-84719-440-4)
  • Michael Bell, „Service-Oriented Modeling: Service Analysis, Design, and Architecture“ (2008 Wiley & Sons, ISBN  978-0-470-14111-3)

externí odkazy