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 ...
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)
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
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
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í
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
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
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
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
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í
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
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
55.
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
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“)
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
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