Na integrace se často díváme jako na propojení dvou či více služeb: volání API, reakce na webhook, přenos dat z bodu A do bodu B. To vše je samozřejmě pravda, ale můžeme na integrace nahlížet i z podstatně širší perspektivy, jako na budování systému ze systémů. Abychom se ještě víc přiblížili perspektivě, kterou vývojáři důvěrně znají, pojďme se podívat na to, v čem se principy datových integrací blíží principům objektově orientovaného programování.
V čem jsou si integrace a OOP podobné
Stejně jako systémy, i objekty v OOP komunikují s okolím prostřednictvím rozhraní. To umožňuje jejich zapouzdření a v obou případech funguje velice podobně. K udržitelnosti kódu v OOP kromě zapouzdření objektů napomáhá také omezení jejich zodpovědnosti. I v případě systémů bychom měli mít na paměti právě omezení jejich zodpovědnosti.
V případě OOP i propojených systémů vzniká ekosystém entit (objektů nebo systémů), které spolu vzájemně komunikují k dosažení nějakého cíle. Tyto entity mají své role a zapojují se do společných procesů.
Jeden zásadní rozdíl: prostředí
Zásadní rozdíl mezi OOP a integracemi systémů spočívá v prostředí a prostředcích, které má vývojář k dispozici. U OOP běží všechny objekty v jednom běhovém prostředí – sdílejí paměť, nástroje pro logování, debugging, správu výjimek a další mechanismy, které zajišťují stabilní komunikaci a kontrolu nad celým procesem.
U integrací nic takového po ruce nemáme. Jediné společné prostředí je síť, která může kdykoliv selhat. Volaná služba může být například nedostupná, autentizace zase může expirovat. To znamená, že při návrhu integrací musíme počítat s mnohem vyšší mírou nejistoty. Podceňovat tuto nejistotu u integrací znamená vystavit řešení neustále hrozbě selhávání procesů.
Potřebujeme integrační „runtime“
Abychom mohli s integrovanými systémy pracovat podobně jako s objekty v OOP, potřebujeme nad sítí vytvořit vrstvu, která nám potřebnou spolehlivost procesů zajistí. Navíc nám dodá nástroje, které zde oproti programování v rámci jedné aplikace chybí.
V rámci integrační vrstvy chceme mít k dispozici opakování volání nedostupných API, logování a monitoring, a také prostředky pro debugování, jako je krokování asynchronních procesů. Neměli bychom opomíjet ani řízení rychlosti datových toků, respektive volání API systémů. To platí především pro dávkové procesy, protože bez této ochrany můžeme ohrozit dostupnost služby, v nejhorším případě pak riskujeme ban.
Závěr
Principy objektově orientovaného programování nám ukazují, že komplexní systémy se dají udržet přehledné a spolehlivé, pokud mají jasně definované rozhraní, omezenou zodpovědnost a běhové prostředí, které jim poskytuje potřebné nástroje.
U integrací je situace složitější, protože společné prostředí chybí. Právě proto má smysl přemýšlet o integrační platformě jako o „runtime pro datové toky“. Tedy jako o vrstvě, která nad sítí vytvoří spolehlivé prostředí a dodá vývojářům komfort, na který jsou zvyklí z programování uvnitř jedné aplikace.
Orchesty je platforma postavená přesně s tímto cílem. Umožňuje navrhovat integrace jako modulární komponenty, které spolupracují v jednotném prostředí. Neřeší jen spojení mezi body A a B, ale poskytuje vývojářům kontrolu nad tokem dat, monitoringem a spolehlivostí procesů.
Výsledkem je architektura, která nestojí na jednotlivých můstcích, ale na pevném základu. Tvoří tak systém ze systémů, který se dá dlouhodobě rozvíjet a udržovat.