enterprise service bus (esb) - fit.vutbr.czrychly/public/docs/pdi.esb/pdi.esb.print.pdf ·...

Enterprise Service Bus (ESB)

Marek Rychlý

Vysoké ucení technické v BrneFakulta informacních technologií

Ústav informacních systému

Prednáška pro PDI8. prosince 2015

Marek Rychlý Enterprise Service Bus (ESB) — Prednáška pro PDI, 8. prosince 2015 1 / 32

Obsah

1 Cesta k ESBEnterprise Service Bus (ESB)Problémy „accidental architecture“

2 Enterprise Service Bus (ESB)ESB jako Message Oriented Middleware (MOM)Prechod od „accidental architecture“ k ESB


Cesta k ESBEnterprise Service Bus (ESB)

Enterprise Service Bus (ESB)Problémy „accidental architecture“

Enterprise Service Bus (ESB)Sbernice pro rozsáhlou decentralizovanou integraci aplikací.(propojení rozhraní autonomních systému ruzných formátu, technologií a lokací)

Pro asynchronní komunikaci pomocí zasílání zpráv.(predstavuje tzv. „Message-oriented Middleware“, MOM)

Pro implementaci pátere SOA architektury.(respektuje principy SOA, tj. volnou vazbu, standardizaci, znovupoužitelost, atd.)

Postavená na standardech komunikace a integrace komponent.(JMS, JCA, JBI, WS-*, SOAP, WSDL, XML, XSLT, XPath, XRef, XQuery, . . . )

Implementovaná mnoha zpusoby v mnoha produktech.(Windows Azure SB, Oracle ESB, JBoss ESB, Mule ESB, Spring Integration, . . . )

(diagram prevzat z „David A. Chappell: Enterprise Service Bus, 2004“)


http://oreilly.com/catalog/9780596006754/



Proc ESB?Globální podniky/organizace chtejí/musí integrovat lokální systémy.Postupná integrace zavedených rešení vede k „accidental architecture“.Prenos dat z jedné komponenty na druhou rešen hromadne a dávkove.(typicky automaticky jednou denne, nebo dokonce manuálne pres CSV atp.)






Problémy „accidental architecture“: Mnoho rozhraní

Postupná integrace vyžaduje tvorbu nových rozhraní a spojení.(napojení apl. C na A zn. zachování puvodních rozhraní A a pridání nového C-A)

Nejhorší prípad (každý s každým) pro n apl. je n(n � 1)=2 spojení.(pro 5 apl. je to 10 spojení, pro 13 je to 78, ale pro 100 už 4.950 spojení)

Velký pocet rozhraní zvyšuje náklady na jejich údržbu i riziko selhání.(problém závislostí napr. pri zavedení nové verze apl., bezpecnosti, atd.)






Problémy „accidental architecture“: ETL integrace (I)

Populární integrace pomocí Extract, Transform, & Load (ETL) via FTP.(apl. S periodicky exportuje do souboru, který si pres FTP stahuje a nacítá apl. W)






Problémy „accidental architecture“: ETL integrace (II)Zpoždení mezi integrací aplikací pres ETL muže zpusobit chybu.(než se propaguje zmena poctu kusu na centrálním skladu z pobocky na jinoupobocku, tak tam mezitím muže nekdo objednat/vrátit chybející kusy)

Bežne se reší nad-dimenzováním skladových zásob! zbytecné náklady






Problémy „accidental arch.“: Centrální „hub&spoke“

Rešení je zavést centrální komunikacní platformu/„hub“.(tj. middleware, centrální server nebo sbernici)

Problém je, že centrální „hub“ vyžaduje duveru zúcastnených.(není možné, pokud jsou úcastníci konkurenti, nebo nechtejí centralizovat data)






Další problémy a požadavky na middleware/ESB

Schopnost vytváret elektronické trhy.(e-marketplaces and vertical trading hubs)

Schopnost zavést monitoring a rízení vyžadované legislativou.(napr. v USA: Sarbanes-Oxley, the PATRIOT Act, and FCC regulations)

Schopnost reálného monitoringu soucinnosti systému a businessu.(tzv. Business Activity Monitoring, BAM; bez merení není rízení)

Eliminace zbytecného zpracování, transformace a predávání dat.(tzv. Straight-Through Processing, STP)

Schopnost (postupné) integrace „legacy“ systému.(nelze vše zborit a postavit znovu, je nutno integrovat postupne existující)

Bezpecnost a spolehlivost.(šifrování, podepisování, zarucené dorucení, transakce, selektivní autorizace, atd.)



ESB jako Message Oriented Middleware (MOM)Prechod od „accidental architecture“ k ESB

Postupný vývoj middleware k ESB

ESB = „best-practices“ v Enterprise Application Integration (EAI).( „Mater artium necessitas“, tj. „nouze je matka vynalézavosti“; W. Horma, 1519)

Zobecnuje koncept Java Message Service (JMS) v Java EE.( „Point-to-Point Messaging queues“ a „Publish/Subscribe Messaging domains“)

Vychází z aplikacních serveru/kontejneru hostujících komponenty.(kontejner poskytuje prostredí/standardizované rozhraní pro komponenty)

Snaží se šetrit, dobre zduvodnit a optimalizovat náklady na IT.(prasknutí internetové bubliny, ekonomická krize, outsourcing IT, atd.)






JMS modely komunikace zasílání zpráv v ESB

(pub-sub vs. p2p a hierachie témat v pub-sub; diagramy prevzaty z „David A. Chappell: Enterprise Service Bus, 2004“)





ESB kontejner a jeho schopnostiIntegrované systémy jsou napojeny pres ESB kontejner.(kontejner hostuje systémy jako ESB komponenty a poskytuje rozhraní k ESB)

V jednom kontejneru muže být provozováno soucasne více komponent.(tyto komponenty spolu mohou komunikovat prímo, nemusí pres ESB)

(diagramy prevzaty z „David A. Chappell: Enterprise Service Bus, 2004“)





Rozhraní a obsah ESB kontejneru

ESB kontejner muže hostovatruzné druhy komponent.(vc. speciálních komponent promodifikaci a rízení ESB zpráv)

Kontejner poskytuje komponenteruzné druhy rozhraní.

(diagramy prevzaty z „David A. Chappell: Enterprise Service Bus,2004“)






ESB „endpoint“ – pripojení komponenty do kontejneru

ESB kontejner nabízí ruzné zpusobypripojení hostovaných komponent(nativní JMS, HTTP&SOAP proWeb-services, ruzné adaptéry vc.file/DB-adapters ci JMS pro C++/C#/.NET)

ESB však podporuje jen asynchronníkomunikaci/zasílání zpráv.(synchronní komunikaci lze nasimulovat,ale je to nespolehlivé/hrozí timeout)






Napojení ruzných komponent/systému na ESB






Message Oriented Middleware (MOM)

ESB funguje jako MOM.(API a protokol komunikace s MOM po vzoru JMS, vizte modely komunikace na str. 13)






MOM a volná vazba rozhraní propojených komponent

Komunikace zasíláním zpráv umožnuje volnou vazbu (loose coupling).(komunikující komponenta zná pouze sbernici, nikoliv protistranu komunikace)

Sbernice zajišt’uje dorucení zpráv ve vhodném formátu.(kompatibilita vysílajícího a prijímacího rozhraní transformací zpráv na sbernici)

Rozhraní komponenty je nezávislé na jeho použití protistranou.(každé komponente pak stací pouze jedno rozhraní; tedy máme celkem n rozhranípro n komponent, ve srovnání s n(n� 1)=2 rozhraními prímé komunikace na str. 6)






Spolehlivé dorucení zpráv v MOM/ESBSbernice využívá úložište pruchozích zpráv pro jejich spolehlivé dorucení.(zpráva je uložena a dorucena jedenkrát, až je príjemce pripraven a podarí se to)

Odesílatel se muže spolehnout na jisté asynchronní dorucení v ESB.(implementace/inspirace ze standardu WS-ReliableMessaging)

(P2P a pub-sub komunikace; diagramy prevzaty z „David A. Chappell: Enterprise Service Bus, 2004“)





Lokální transakce nad zprávami v MOM/ESB

Spolehlivé dorucení umožnuje transakcní komunikaci s ESB.(transakce vždy odesílatel-ESB nebo príjemce-ESB, nikoliv odesílatel-príjemce)

V jedné transakci lze sdružit odeslání a príjem nekolika zpráv.(je to skutecne transakce, tj. pro komunikovaná data platí ACID)

Transakci lze provést dvoufázove, napr. v kombinaci s DB operací.(tzn. do transakce lze zahrnout jiné zdroje, napr. transakcní databáze, ty však musírespektovat „XOpen/XA two-phase-commit transaction protocol“)






Request/reply komunikace v MOM/ESB

U asyn. zprávy s požadavkem odpovedi, je nutno vedet kam odpovídat.(zpráva obsahuje hlavicku „replyTo“ s adresou príjemce odpovedi)

Odpoved’ muže obdržet ten kdo se tázal, nebo i úplne nekdo jiný.(lze tak zprávu skrz príjemce zpracovat a preposlat jinam)






VETO a VETRO integracní vzoryVETO = V + E + T + O

Validate overíme zda je zpráva validní, jinak odmítnemeEnrich doplnení obsahu zprávy o chybející data

(napr. údaje zákazníka z jeho ID, mesto z PSC, atp.)Transform konverze zprávy do cílového (nebo kanonického) formátu

Operate vlastní zpracování zprávy cílovou aplikací/komponentouVETRO = VETO + R

Route po transformaci zprávu smerujeme ke správnéaplikaci/komponente






Validate, Enrich & Transform; Two-Step XRef PatternPro VET využívá ESB formát XML zpráv a nástroje pro práci s XML.(pro validaci XML Schema/Schematron, obohacení XRef a transformaci XSLT)

Snaha rozdelit komponenty vykonávající více z VETRO operací.(pak je možno využít standardní komponenty pro jednotlivé operace)

„Two-Step XRef Pattern“ pro prípravu XML a jeho doplnení o data.(XML se pripraví ze vstupu transformací XSLT a pak doplní pomocí XRef)

(pred a po aplikaci vzoru; diagramy prevzaty z „David A. Chappell: Enterprise Service Bus, 2004“)





Smerování (routing) zpráv v ESB

Podobne jako pro VET, tak i pro R ve VETRO je standardní komponenta.(napr. komponenta Mediator se smerovacími pravidly, ci BPEL proces s popisemorchestrace, tj. postupného volání jednotlivých služeb/komponent/aplikací ESB)

Smerování na základe itineráre ve zpráve ci posouzením obsahu zprávy.(tzv. „Itinerary-based Routing“, IBR, vs. „Content-based Routing“, CBR)

Pri IBR je možno itinerár upravovat/doplnovat pri pruchodu ESB.(komponenty-aplikace ESB naplánují do itineráre, co se se zprávou dále stane)






Paralelní zpracování zpráv v ESBCBR a IBR muže zprávu také duplikovat/rozdelit pro paralelní zpracování.(zpráva ci její cásti jsou pak zpracovávány v rámci ESB soubežne)

Paralelní zpracování (a jeho výsledky) je možno opet spojit.(opacnou operací/komponentou k „split“ je „join“)






Prechod od „accidental architecture“ k ESB (I)Na zacátku je „accidental architecture“.(tzn. prímá propojení aplikací; ETL s periodickou synchronizací a daty v CSV ci, vlepším prípade, v XML; skryté závislosti a manuální predávání dat mimo systém)

Obtížná správa, monitoring a rízení, další integrace) neudržitelné.






Prechod od „accidental architecture“ k ESB (II)

ESB se zavede v jednom míste a transparentne pri pohledu zvencí.Pro napojení na stará (legacy) rozhraní se využijí adaptéry.






Prechod od „accidental architecture“ k ESB (III)

Postupne (a za behu) se zavádí ESB do sousedních oblastí.Zvencí je celé rešení transparentní a bez (vetších) výpadku.






Prechod od „accidental architecture“ k ESB (IV)

ESB lze zavádet postupne i v rámci jedné oblasti.(aplikace mohou stále ješte komunikovat prímo s aplikacemi ostatních oblastí)

Zachování prímé komunikace vhodné pro težko adaptovatelná rozhraní.(nebo napr. pri potrebe synchronní komunikace stylu RPC, nebo napojení partneru,na které nemáme vliv, tedy nemužeme lehce adaptovat)






Prechod od „accidental architecture“ k ESB (V)

Nakonec je celá organizace integrovaná pomocí ESB.Partnerské aplikace mimo organizaci pak komunikují také s ESB.






Shrnutí a záver

ESB je rešení pro integraci rozsáhlých systému organizací.(geograficky rozsáhlé, s autonomními cástmi, heterogenní, atp.)

ESB využívá zavedených a overených technologií.(JMS, JCA, JBI, WS-*, SOAP, WSDL, XML, XSLT, XPath, XRef, XQuery, . . . )

ESB není rešení vhodné pro všechny, použití je treba zvážit.(nevýhodou je treba vyšší režie na komunikaci, tedy ztráta výkonu)


enterprise service bus (esb) - fit.vutbr.czrychly/public/docs/pdi.esb/pdi.esb.print.pdf ·...

Documents