1. Tomáš Kafka
ENTERPRISE SERVICE BUS

2. Zdroje
 David A. Chappell:
Enterprise Service
Bus (O’Reilly)

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. STATE OF UNION INTEGRATION
(PROČ ESB?)

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. 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. Moc hlav moc ví...
hodně spojů – zmatek v API

9. ESB: Cesta od n*(n-1)/2 k n

10. Centralizace škodí a neškáluje

11. Ř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

12. Centrální server

13. Hub and spoke:
centrální rules/routing engine

14. Rozděl a konfiguruj – piece of cake
DIVIDE ET IMPERA

15. ESB: úplná decentralizace

16. Message Oriented Middleware
MOM & COUPLING

17. 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 :))


18. 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

19. 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

20. Reliable messaging
Store and forward

21. 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í

22. Transakční odpověď

23. Request/reply pattern

24. Hierarchical topics
Wildcards –můžeme říct o která témata máme zájem

25. Odolnost proti změnám
XML A JINÁ HAVĚŤ

26. XML a dědičnost
PCČ - protokol verze 1 Zpřesněné PSČ – v. 2
<PostalCode> <PostalCode>
01730 01730
</PostalCode> <ExtendedPart>
ABX8
</ExtendedPart>
</PostalCode>

29. 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

31. A když je formátů moc?
Ustanovíme kanonický formát

32. ESB Invokace a routing

33. 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

34. Itinerary subprocess
 Služba pozastaví zpracování zprávy, pošle
jí „povinným kolečkem“, pak zpráva
pokračuje dál

35. 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

37. Pravidla jsou v lokální cache

38. DALŠÍ SLUŽBY?

39. 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

40. CO S EXISTUJÍCÍMI APLIKACEMI?

41. 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

42. Spoje všeho druhu
...trochu terminologie

43. Co najdeme v (ESB) kontejneru?
... to nemusíme vyvíjet sami – aneb kde bydlí služby

45. ESB PATTERNS

46. 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í

47. VETO

48. VETRO
 R = Route
 po transformaci následuje ještě routing
 data odešleme do aplikace, která je
zpracovává

49. 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

50. 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

51. Two-step XRef pattern

52. 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

53. 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

54. 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

56. 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

57. A TO JE VŠE, PŘÁTELÉ?

58. 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“)

59. Case study: postupné rozšiřování ESB

60. 1. Accidental architecture
(slušnější název pro chaos)

61. 2. ESB v jedné lokaci
vnější zdroje lze přepojit do ESB

62. 3. Rozšiřujeme ESB
adaptér na konkrétní aplikaci - odpadá dávkový FTP
přenos

63. 4. Leave and layer
jedeme na ESB, pro partnery máme SOAP adaptér

64. ESB a Java
NA ČEM TO POJEDE?

65. 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)

66. J2EE Connector Architecture
 Definuje „výplň“ mezi aplikací a ESB
 Connection management/pooling
 Transaction control
 Propagation of security context
 Worker threads management
 ...

67. 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

68. Kritika ESB
SVĚT NENÍ RŮŽOVÝ ...

69. 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“

70. 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!

71. 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

72. OTÁZKY