Každá velká česká firma má v sobě muzeum IT. Mainframe z devadesátých let, který nikdo neumí restartovat. COBOL program, jehož autor je pět let v důchodu. A někde mezi tím desítka Java aplikací, které spolu potřebují komunikovat. Přesně tohle řešíme s naším SOA přístupem — a tady je, co jsme se naučili.
Problém: systémový gulᚶ
Náš typický klient — řekněme střední pojišťovna — má zhruba tento technologický landscape: core pojistný systém na AS/400, CRM v .NETu, accounting v SAP, pár Java webových aplikací a Excel makra, která drží všechno pohromadě. Doslova.
Point-to-point integrace vypadá na začátku jednoduše. Systém A potřebuje data ze systému B? Napíšeme connector. Systém C potřebuje data z A i B? Další dva connectory. Ale se 20 systémy máte potenciálně 190 integrací a nikdo neví, co kam teče.
ESB jako centrální nervový systém¶
Enterprise Service Bus není sexy technologie — žádný startup o ESB nenapíše blogpost na Medium. Ale pro enterprise integraci je to základ. Používáme Oracle Service Bus (OSB), protože většina našich klientů je v Oracle ekosystému.
ESB nám dává jednoduché věci: message routing, protocol mediation (SOAP, JMS, file, FTP), transformace (XSLT, XQuery) a hlavně — centrální bod pro monitoring a logging. Když něco nefunguje, podíváte se na jedno místo, ne na dvacet logů.
Kanonický datový model — investice, která se vrátí¶
Každý systém má svůj datový model. CRM má Customer s adresou jako string. Core systém má KLIENT s adresou rozdělenou na ulici, město, PSČ. SAP má DEBITOR s úplně jinou strukturou. Pokud budete transformovat data přímo mezi systémy, utopíte se v kombinacích.
Proto definujeme kanonický datový model (CDM) — společný jazyk, do kterého a ze kterého se všechno transformuje. Ano, je to práce na začátku. Ano, schůzky nad datovým modelem jsou nudné. Ale každý nový systém, který integrujete, potřebuje jen jednu transformaci (do/z CDM) místo N transformací do každého dalšího systému.
WSDL-first přístup¶
Možná to zní staromódně, ale WSDL kontrakty děláme vždy first, ne code-first. Proč? Protože kontrakt je dohoda mezi týmy. Backendový tým v Praze a frontend tým v Brně potřebují jasnou specifikaci, na které se dohodli před tím, než začnou kódovat.
XSD schémata validujeme přes Schematron pro business rules, které nejdou vyjádřit v XSD. Verze services řídíme přes namespace (v1, v2) a staré verze udržujeme minimálně rok po nasazení nové. Zpětná kompatibilita je v enterprise klíčová — nemůžete říct klientovi „přepiš si to, vydali jsme novou verzi”.
Bezpečnost: WS-Security¶
V regulovaném prostředí (banky, pojišťovny) nestačí HTTPS. Potřebujete WS-Security pro message-level security — šifrování payloadu, digitální podpisy, SAML tokeny. Oracle Service Bus toto řeší nativně, ale konfigurace je… řekněme netriviální.
Na posledním projektu jsme strávili dva týdny jen nastavením vzájemné autentizace mezi OSB a mainframovým systémem přes X.509 certifikáty. Funguje to, ale není to pro slabé povahy. Dokumentace pro IBM MQ + Oracle OSB interoperabilitu je sporadic, řečeno diplomaticky.
Monitoring a governance¶
Nasadit SOA je jedna věc. Spravovat ji je věc druhá. Bez governance se vám za rok SOA landscape zvrhne ve stejný chaos, ze kterého jste se snažili uniknout.
Máme jednoduchá pravidla: každá služba má vlastníka (business i technického), SLA kontrakt s definovaným response time a availability, a je registrovaná v service repository. Používáme Oracle Enterprise Repository, ale upřímně — i sdílený Confluence prostor je lepší než nic.
Co bych udělal jinak¶
REST. Vím, že jsem v minulém článku obhajoval SOAP. A pro komplexní enterprise integrace to stále platí. Ale pro jednodušší services — lookup data, notifikace, jednoduché CRUD — bych dnes volil REST. Není důvod tahat SOAP overhead tam, kde nepotřebujete WS-* stack.
A testing. Automatizované testování SOA služeb jsme začali řešit pozdě. SoapUI testy by měly být součástí CI pipeline od prvního dne. Regresní testy pro integrační body jsou kritické — stačí malá změna v jednom systému a celá integrace se rozsype.
SOA není mrtvá¶
V komunitě se mluví o tom, že SOA je přežitek. Pro startupy možná. Ale pro českou pojišťovnu s mainframem z roku 1995 je poctivá SOA integrace přes ESB stále nejpraktičtější cesta, jak dát dohromady systémy, které spolu nikdy neměly mluvit. A to je přesně to, co děláme.