SAMSUNG_062022 Advertisement SAMSUNG_062022 Advertisement SAMSUNG_062022 Advertisement

IBM Cloud Pak for Integration / Nástroje na úspešnú integráciu v podnikoch

0

Špeciálny projekt

Predstavme si nasledujúci scenár. Firma úspešne rastie a s ňou aj počet pridávaných informačných systémov. Postupne, jeden po druhom. Navzájom sa prepájajú a všetko vyzerá dobre. S rastúcim množstvom informačných systémov a ich novými verziami a zvyšujúcimi sa nárokmi však začínajú byť integrácie neprehľadné.

Narážame na viacero problémov:

• Dáta zo zdrojového systému sú potrebné v ďalších systémoch, ale v rôznych formátoch.
• Systémy podporujú rôzne protokoly.
• Rastie zložitosť prepojení. V extrémnom prípade, keď potrebujeme zintegrovať každý systém s každým, počet integračných scenárov a ich implementácií narastie až na n * n -1.
• Integrácie sú často implementované ako synchrónne volania a v prípade nedostupnosti niektorého zo systémov je obmedzená funkčnosť celku.

Niektoré tieto problémy pomáhal riešiť messaging. Ide o asynchrónnu komunikáciu, keď messagingový systém prenáša dáta pomocou správ a garantuje, že správu doručí raz a práve raz. Implementácia IBM sa volá MQ. MQ je veľmi robustný systém, ktorý ako prvý implementoval architektonické a dizajnové vzory, ktoré boli neskôr prevzaté inými messagingovými systémami. MQ stálo pri zrode protokolu MQTT. Dnes ide o základný stavebný kameň IoT (Internet of Things). Pôvodne však slúžil na komunikáciu s veľmi vzdialenými zariadeniami, ako sú napríklad ventily na plynovodoch, s veľmi malým prenosovým pásmom. 

Asynchrónnosť MQ má svoju krásu – uvediem príklad. Predstavme si bankovú mobilnú aplikáciu, ktorá nám napr. umožňuje, aby sme si vygenerovali PDF s pohybmi na účte. Používateľ v mobilnej apke (MA) zadá parametre a klikne na tlačidlo vygeneruj PDF. MA pošle MQ správu backend bankovému systému s požiadavkou na PDF. Ak je backend dosť rýchly (typicky do 3 sekúnd), odošle novú MQ správu do MA s vygenerovaným PDF. No ak je backend pomalší, prípadne nedostupný, správa do 3 sekúnd nepríde. MA v tomto prípade zobrazí správu: „Vaše PDF bude doručené do vašej schránky...“ MA sa teda v prvom prípade správa ako synchrónna, aj keď je implementovaná ako asynchrónna. A jej asynchrónnosť vypláva na povrch, až keď je to nevyhnutné.

Mohlo by sa teda zdať, že messaging rieši naše problémy. No nie všetky. Messaging pošle správu z A do B, ale v zásade mu je jedno, čo je obsahom. V našich integračných snahách sa však často potrebujeme rozhodovať aj na základe obsahu. Ak si napríklad žiadate o pracovnú cestu a váš hotel stojí menej ako xxx eur na noc, potom ide požiadavka rovno na príslušné oddelenie, ktoré spraví rezerváciu. Ak si však vyberiete hotel, ktorý je drahší ako xxx, ide MQ správa najprv na vášho nadriadeného a až po jeho schválení na rezervačné oddelenie.  Musíme sa teda pozerať aj na payload správy. V IBM sa tento integračný komponent volal Message Broker a ide o implementáciu Enterprise Service Bus (ESB) paternu. Ako postupne pribúdala funkcionalita, menilo sa aj meno a dnes hovoríme o ACE (App Connect Enterprise). ACE je téma na viacero článkov. Jeho primárne funkcie sú také, že sa pozerá na obsah správy (na payload správy) a umožňuje:

• Transformáciu dát

• Transformáciu protokolov

• Augmentáciu dát

• Smerovanie správ

Využíva na to zdroje, ktoré má pripojené vo forme databáz, MQ serverov, WebServiceov, filesystému, technologických adaptérov atď.

Ako to v skratke vyzerá? ACE poskytuje vizuálne nástroje, ktorými sa namapuje napr. MQ správa na opísaný dátový formát, definovaný napr. schémou XSD. Vizuálnymi nástrojmi sa vytvorí tzv. FLOW, do ktorého na začiatku správa vstúpi a na konci vystúpi. Tento flow je tvorený nodmi a prepojeniami medzi nimi. Každý node má nejakú špeciálnu úlohu. Napríklad rozhodovací na základe dát v správe rozhodne, ktorou cestou vo flowe pošle správu. Alebo databázový, keď sa node pripojí na databázu a na základe dát v správe vykoná jej update alebo z nej niečo nájde a augmentuje tým správu. Ďalší node môže z jednej správy vytvoriť dve a každú poslať inou cestou inému konzumentovi, napríklad pomocou WebService. Máme teda vizuálny nástroj, ktorý zároveň slúži aj ako grafická dokumentácia danej integrácie. ACE je postavený najmä na čo najvyššiu priepustnosť, keď potrebujeme, aby cez systém prešlo čo najviac správ za sekundu. IBM ACE je vysokovýkonná implementácia ESB. 

Z performance, ale aj z požiadaviek na vysokú dostupnosť sa ako MQ, ACE aj aplikačné servery, na ktorých sú zvyčajne hostované adaptéry, deployovali na virtuálne stroje.

Virtuálne stroje trpeli tým, že časť zdrojov bola vyčerpaná operačnými systémami, ktoré boli na každom virtuálnom stroji. Tento problém sa vyriešil až s príchodom kontajnerizácie. Inžinieri v Googli vyvinuli Kubernetes – platformu na orchestráciu kontajnerov. Red Hat OpenShift je distribúcia Kubernetes, ktorá poskytuje rozšírenú funkcionalitu a najmä bezpečnosť. Spoločnosť IBM kúpila Red Hat a všetky svoje produkty transformovala a modernizovala, aby mohli bežať aj ako kontajnerizované. Ako kontajnerizačnú platformu zvolila OpenShift.

IBM chce svoju ponuku sprehľadniť a vytvorila balíky produktov, ktoré spolu súvisia, a pomenovala ich Cloud Paky. Cloud Pak for Integration je balenie obsahujúce všetky potrebné nástroje na úspešnú integráciu v malých podnikoch aj nadnárodných spoločnostiach s použitím najmodernejšej kontajnerizačnej architektúry.

ÚVODNÉ FOTO ZDROJ: tirachardz - www.freepik.com

 

Zobrazit Galériu

Lucia Skovajsová, IBM Unit Manager eD system Slovensko

Všetky autorove články

Pridať komentár

Mohlo by vás zaujímať

Mohlo by vás zaujímať