Enterprise Service Bus

2,346 views

Published on

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
2,346
On SlideShare
0
From Embeds
0
Number of Embeds
442
Actions
Shares
0
Downloads
45
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Enterprise Service Bus

  1. 1. Tomáš Kafka ENTERPRISE SERVICE BUS
  2. 2. Zdroje  David A. Chappell: Enterprise Service Bus (O’Reilly)
  3. 3. Co to je ESB? Architektura Implementace  Sada otevřených  Loose coupling protokolů  Decentralized XML, XSLT   Standards-based JMS, JCA, JBI  WS-*  Začlenění existujících  SOAP, WSDL  systémů  Technologie  Obecně napsané Sonic ESB  služby, které se jen IBM Websphere ESB  instanciují a konfigurují Apache Synapse   komunikují zprávami ... 
  4. 4. STATE OF UNION INTEGRATION (PROČ ESB?)
  5. 5. Proč ESB? • Velké podniky chtějí integrovat • někdy i musejí (povinná státní regulace, odevzdávání dat konkurenci/vládě) • Dávkové systémy přinášejí ztráty • globální firma nemůže na noc vypnout IS • Převažují slepence – accidental architecture • přenos dat manuálním uploadem • přenos „na flashdisku“
  6. 6. Nevýhody ad-hoc řešení  Nespolehlivost  Nikdo nezná nároky – preventivní naddimenzování systémů V procesech přicházíme o užitečná  (a zpeněžitelná) data Obtížné monitorování stavu systému  Obtížný troubleshooting  Náklady (např. IT personál co ručně  kopíruje data)
  7. 7. Moc hlav moc ví... hodně spojů – zmatek v API
  8. 8. ESB: Cesta od n*(n-1)/2 k n
  9. 9. Centralizace škodí a neškáluje
  10. 10. Řešení s centrálním serverem  Úzké hrdlo systému  Single point of failure  Aliance a unie nechtějí aby majitel centrálního uzlu věděl o všech datech
  11. 11. Centrální server
  12. 12. Hub and spoke: centrální rules/routing engine
  13. 13. Rozděl a konfiguruj – piece of cake DIVIDE ET IMPERA
  14. 14. ESB: úplná decentralizace
  15. 15. Message Oriented Middleware MOM & COUPLING
  16. 16. Abstract decoupling Před ESB S ESB a MOM  Producer  Producer  má „zadrátovaného“  má pojmenovaný endpoint konzumenta  je mu jedno jestli na něm někdo poslouhá  Consumer  Message Oriented  je pevně propojen s Middleware producentem  V případě změn:  propojení se nastavuje v konfiguraci, i za běhu code   Konzument recompile   má zase pojmenovaný redeploy  endpoint (debug :)) 
  17. 17. 2 messaging models Publish & subscribe Point to point  Producent = publisher  Producent publikuje do fronty  pošle zprávu do topicu  Middleware spravuje  Middleware spravuje frontu (fronta je topic (je perzistentní) perzistentní)  Konzumenti  Konzument si vyzvedává  přihlásí se k odběru topicu, zprávy z fronty chodí jim zprávy  pokud ne, mohou se  s persistentním připojením hromadit, to je jim dojdou i zprávy, které normální, například když je promeškali, když byli konzumentem dávkový offline systém
  18. 18. MOM message  Header Message  identifikace zprávy Header  routovací informace  Properties Properties  metadata konkrétní aplikace (QTY = 100)  Body Body  tělo zprávy, v ESB většinou XML zpráva
  19. 19. Reliable messaging Store and forward
  20. 20. MOM a transakce  Veškerá komunikace je asynchronní – neexistují transakce napříč službami, jen na rozhraní „služba – middleware“ a „middleware – služba“  Transakční middleware:  Begin  pošli několik souvisejících zpráv do fronty/topicu  Commit  MOM teď ručí za to, že má všechny zprávy a doručí je všem příjemcům  Příjemci opět transakčně dostanou všechny zprávy najednou  Pokud se např. odpojí, middleware na jejich straně přenos zruší, a příště přenese transakci znovu, klient se nic nedozví
  21. 21. Transakční odpověď
  22. 22. Request/reply pattern
  23. 23. Hierarchical topics Wildcards –můžeme říct o která témata máme zájem
  24. 24. Odolnost proti změnám XML A JINÁ HAVĚŤ
  25. 25. XML a dědičnost PCČ - protokol verze 1 Zpřesněné PSČ – v. 2 <PostalCode> <PostalCode> 01730 01730 </PostalCode> <ExtendedPart> ABX8 </ExtendedPart> </PostalCode>
  26. 26. Na vše ale dědičnost nestačí  Co když se změní formát zprávy úplně?  přidáme routování podle obsahu zprávy  CBR – Content Based Routing
  27. 27. A když je formátů moc? Ustanovíme kanonický formát
  28. 28. ESB Invokace a routing
  29. 29. Itinerary based Routing  Každá zpráva si s sebou od vstupu do systému nese v hlavičce svůj itinerář  Služba dostane zprávu, zpracuje jí, a pošle jí k dalšímu endpointu na cestě  Routovací služby slouží jako výhybky – mohou itinerář upravit
  30. 30. Itinerary subprocess  Služba pozastaví zpracování zprávy, pošle jí „povinným kolečkem“, pak zpráva pokračuje dál
  31. 31. Content based routing  Výhybka dle typu zprávy  Pravidla jako ...  XSLT + skriptovací jazyk (JavaScript)  Rules engine  XML strom reprezentující kritéria pro volbu cesty  BPEL4WS –standardizovaný dialekt XML
  32. 32. Pravidla jsou v lokální cache
  33. 33. DALŠÍ SLUŽBY?
  34. 34. Typy ESB služeb Category Functions Invocation Support for synchronous and asynchronous transport protocols, service mapping (locating and binding) Routing Addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing Mediation Adapters, protocol transformation, service mapping Messaging Message processing, message transformation and message enhancement Process Implementation of complex business processes Choreography Service Coordination of multiple implementation services exposed as a single, aggregate service Orchestration Complex Event Event interpretation, correlation, pattern matching Processing Other Quality of Security (encryption and signing), reliable delivery, transaction management Service Management Monitoring, audit, logging, metering, admin console, BAM
  35. 35. CO S EXISTUJÍCÍMI APLIKACEMI?
  36. 36. Co s existujícími aplikacemi?  Nasadíme na ně adaptéry  pro aplikaci se tváří jako původní protistrana, ale data dále jdou ve formě zpráv do ESB  Cokoliv jde adaptovat lidé v systémech  dávkové systémy  FTP push  File drop service (data ve společném  adresáři)  stávající síťové aplikace
  37. 37. Spoje všeho druhu ...trochu terminologie
  38. 38. Co najdeme v (ESB) kontejneru? ... to nemusíme vyvíjet sami – aneb kde bydlí služby
  39. 39. ESB PATTERNS
  40. 40. VETO  Validate  ověříme zda jsou data validní, pokud ne, pošleme pryč  Enrich  volitelně dopočítáme data která v původní zprávě nejsou (část PSČ + adresa -> celé PSČ)  Transform  konverze do cílového/kanonického formátu  Operate  vlastní zpracování cílovou aplikací
  41. 41. VETO
  42. 42. VETRO  R = Route  po transformaci následuje ještě routing  data odešleme do aplikace, která je zpracovává
  43. 43. Two-step XRef pattern  Služba toho dělá moc  XSLT zpracování  zároveň doplnění o data z databáze (přes JDBC-XSLT extensions)  Tight coupling mezi XSLT a databází  obtížná údržba  musíme vyvíjet specializovanou službu  Řešení? Rozdělíme na dvě služby
  44. 44. Two-step XRef pattern – rozdělení na dvě služby Služba 1 Služba 2  Použijeme službu, která  Použijeme už hotovou v konfiguraci dostane službu pro XSLT XRef pozice v XML, kam zpracování, jen ji dosadí výsledky nakonfuigurujeme databázových dotazů příslušným stylesheetem (JDBC)  Obě služby jsou znovupoužitelné, obecné , veškeré nastavení je v konfiguraci, ne v kódu
  45. 45. Two-step XRef pattern
  46. 46. Portál  Typická aplikace – pobočky po světě, ředitelství chce mít přehled  Požadujeme rychlou manipulaci s (především agregátními) daty z centra
  47. 47. Forward cache  Do důležitých míst toku zpráv vložíme služby, které budou data odchytávat a posílat na centrálu – do aggregation service  Na centrále je datový sklad pro přijaté zprávy  Jde vlastně o push do cache  Tím docílíme nízké latence při dotazech a zpracování, nemusíme se asynchronně ptát na stav všech poboček
  48. 48. Federated Query  Chceme se (z centra) dotazovat na data  těch je moc na to aby šly všechny cachovat  Pošleme dotaz na ESB:  paralelní request/reply všem kdo mají data, která chceme  anebo vytvořím zprávu s dotazem, vyplním jí itinerář zdroji dat, nastavím sebe jako cílového adresáta, a pošlu na ESB  itinerář může obsahovat split/join – splitovací a joinovací službu
  49. 49. Federated Query  Real-time response  ptáme se systémů, o kterých víme, že nám odpoví brzy – interaktivní dotazování  odpovědi cestou cachujeme, aby následné dotazy mohly být rychlejší  Long duration request  odpověď může přijít třeba až zítra  portálová aplikace musí podporovat user sessions – uživatel zadá dotaz, později se přihlásí znovu a vidí výsledky
  50. 50. A TO JE VŠE, PŘÁTELÉ?
  51. 51. A to je vše, přátelé?  Víceméně ano, umíme:  adaptovat existující aplikace na ESB  převést data na vstupu do XML a opatřit je itinerářem  převést data na výstupu zpět do původního formátu  přepsat centrální Workflow/Business rules do distribuovaného routování asynchronních zpráv  veškeré zpracování dat provést nakonfigurovanými instancemi velmi obecných služeb („služba pro převod XML podle XSLT z konfigurace“)
  52. 52. Case study: postupné rozšiřování ESB
  53. 53. 1. Accidental architecture (slušnější název pro chaos)
  54. 54. 2. ESB v jedné lokaci vnější zdroje lze přepojit do ESB
  55. 55. 3. Rozšiřujeme ESB adaptér na konkrétní aplikaci - odpadá dávkový FTP přenos
  56. 56. 4. Leave and layer jedeme na ESB, pro partnery máme SOAP adaptér
  57. 57. ESB a Java NA ČEM TO POJEDE?
  58. 58. Java Business Interface  Specifikace popisující interface mezi ESB službami  JBI kontejner obsahuje JBI service engines, v těch běží služby  Komunikace pomocí Normalized Message Service, NMS se pak pomocí Binding Component připojuje k téměř všem protokolům (SOAP, JMS, EDI, ...)  Využití existujících J2EE standardů (JTA – Java Transaction API, JMS, JAAS (bezpečnost), JAXB – databinding between Java and XML)
  59. 59. J2EE Connector Architecture  Definuje „výplň“ mezi aplikací a ESB  Connection management/pooling  Transaction control  Propagation of security context  Worker threads management  ...
  60. 60. Java Management eXtensions (JMX)  Vzdálený management a monitorování service kontejnerů  Adaptéry na management konzole velkých firem  API pro přístup k vlastnostem služeb, spouštění/zastavování, změně konfigurace, odebírání notifikací od služby  Komunikace přes ESB MOM – nemusíme dělat vyhrazené spoje pro management
  61. 61. Kritika ESB SVĚT NENÍ RŮŽOVÝ ...
  62. 62. Obecné problémy s ESB  Může dobře fungovat v rámci jedné, centrálně řízené, společnosti  Problém ale nastává při spojování existujících ESB systémů  Konektory mezi některými implementacemi neexistují, nebo jsou s nimi problémy  Kanonické formáty jednotlivých ESB jsou specifické, spojování vyžaduje spoustu konverzí  Nekompatibilní MOM – lze použít jen funkčnost „nejmenšího společného jmenovatele“
  63. 63. Dobrý sluha, zlý pán?  Spojování systémů je i s ESB netriviální  „There is no silver bullet“  I zde musíme dát pozor na vendor lock-in!
  64. 64. Míříme na správný cíl?  Dávkové zpracování často v praxi dobře stačí  Netřeba zatracovat jen kvůli marketingu ESB  Real-time systém umožní snížit rezervy, jet na hranici např. skladových zásob  Ale ztráty při chybách a neočekávaných situacích tím rostou!  Pozor na hype  vždy je na místě cost-benefit analýza
  65. 65. OTÁZKY

×