Architektonické prístupy | Technologický blog

Technologické blogy z prostredia ANASOFTu

V dnešnej časti technologického blogu sa budeme rozprávať s jedným z návrhárov spoločnosti ANASOFT, Martinom Vozárom. Ten má viac než 20 ročné skúsenosti s vývojom aplikácií na mieru od tých malých až po veľké enterprise riešenia. Reč bude o distribuovanom prístupe k tvorbe aplikácií a jeho špecifikách.

Ako ste v tomto prípade postupovali a prečo?

Pre lepšiu predstavu je dôležité uvedomiť si, čo všetko taká aplikácia potrebuje robiť. V prvom rade potrebuje z externého systému získať údaje na spracovanie. Tieto si potrebuje uložiť do vlastnej lokálnej databázy a následne nad nimi spustiť biznis procesy, ku ktorým sa viaže aj používateľské rozhranie, ktorým obsluha systém ovláda. A následne je potrebné spracované údaje vrátiť naspäť do systému, z ktorého pochádzajú.

Z povahy aplikácie vyplýva, že robí množstvo odlišných operácií. Integračné resp. interface-ové operácie ako získanie dát z externého systému a ich vrátenie späť, backendové operácie súvisiace s lokálnym uložením a spracovaním údajov a frontendové operácie používateľského rozhrania pre zadávanie pokynov obsluhy a prezentovanie výsledkov.

A to si vyžaduje distribuovaný prístup?

Nevyžaduje, ale v tomto prípade to bola jedna z možností a ukázala sa ako dobrá. Samozrejme, bolo by možné technické riešenie, ktorým by vznikla jedna veľká monolitická aplikácia. V tomto prípade sme sa však rozhodli vytvoriť niekoľko samostatných aplikácií, z ktorých každá plnila veľmi špecifickú úlohu. Jednotlivé aplikácie tak medzi sebou fungovali na základe akýchsi signálov.

Môžeš uviesť konkrétnejší príklad?

Napríklad aplikácia, ktorá je zodpovedná za spätné odoslanie údajov do pôvodného veľkého systému, funguje tak, že v pravidelných intervaloch sleduje obsah dohodnutého adresára, a pokiaľ v ňom nájde súbory v dohodnutom formáte, spracuje ich a odošle ich do pôvodného systému. Takýto prístup má niekoľko výhod.

Bolo by možné technické riešenie, ktorým by vznikla jedna veľká monolitická aplikácia. V tomto prípade sme sa však rozhodli vytvoriť niekoľko samostatných aplikácií, z ktorých každá plnila veľmi špecifickú úlohu. Jednotlivé aplikácie tak medzi sebou fungovali na základe akýchsi signálov.

Ktoré sú tie najdôležitejšie?

Začína sa to už pri samotnom vývoji.  Takto samostatne navrhnutá aplikácia sa dá implementovať nezávisle od zvyšku systému. Môže na nej pracovať vývojár, ktorý nepotrebuje poznať žiadne ďalšie časti systému. Stačí mu vedieť, že má sledovať obsah adresára a akým spôsob údaje spracovať a preniesť do externého systému. Umožňuje to teda paralelný vývoj nad celým riešením.

Ďalšou výhodou je, že kód takýchto riešení ostáva pomerne čistý a dobre čitateľný. Aplikácia na spracovanie súborov sa zaoberá iba tým, čo je jej náplňou a ostatné časti systému, ostatné aplikácie, sa o vstupno-výstupné operácie a napojenia na okolité systémy nemusia vôbec zaujímať.

Takýto prístup zjednodušuje údržbu celého systému a aj hľadanie chýb. Ak napríklad neprechádzajú výsledné dáta naspäť do externého systému, je logické začať hľadať chybu práve v aplikácii, ktorá zodpovedá za ich prenos.

V prípade, že externý systém nebeží, ovplyvňuje to práve iba túto jednu aplikáciu a ostatné časti systému môžu bežať nezávisle ďalej. Navyše ak sa nájde chyba v aplikácii, ktorá odovzdáva dáta do externého systému, stačí opraviť kód práve tejto jednej aplikácie a túto pretestovať a nasadiť. Ostatné časti systému, ostatné dielčie aplikácie, ostávajú bez zmeny.

Za zmienku tiež stojí vyššia paralelnosť vývojárskych prác a možnosť využívať viac špecifické odbornosti vývojárov. Nie každému vývojárovi rovnako dobre sedí každý druh vývojárskej práce. Niekto sa lepšie uplatní pri tvorbe používateľského rozhrania, a niekto naopak pri databázových operáciách či rozhraniach medzi rôznymi systémami. Vývoj jednej veľkej aplikácie by znamenal, že rôzni vývojári zdieľajú spoločný kód a musia sa v ňom aspoň základne orientovať. Aj v častiach, ktoré sa ich práce netýkajú. Pri samostatných aplikáciách má každý svoje vlastné „ihrisko“ a dôležité je len správne nastaviť prepojenie jednotlivých častí riešenia.

V prípade, že externý systém nebeží, ovplyvňuje to práve iba túto jednu aplikáciu a ostatné časti systému môžu bežať nezávisle ďalej. Navyše ak sa nájde chyba v aplikácii, ktorá odovzdáva dáta do externého systému, stačí opraviť kód práve tejto jednej aplikácie a túto pretestovať a nasadiť.

Má takýto distribuovaný prístup aj svoje negatíva?

Ako všetky prístupy aj tento má svoje špecifiká a zámerne to nenazývam negatíva.

V prvom rade je veľmi dôležitý správny návrh celého riešenia, aby vo výsledku všetko spolu hralo tak ako má. Takže si to vyžaduje trochu viac času pri príprave, ale pre riešenia podobného typu je to potrebné.

Dôležitou vecou je tiež nastavenie správnych štandardov vývoja naprieč všetkými aplikáciami a na rôznych úrovniach. Okrem menných konvencií zohráva pri takejto architektúre dôležitú úlohu správne logovanie. Hoci sú jednotlivé aplikácie samostatné a samostatne aj logujú aktivity, ktoré vykonávajú, netreba zabúdať, že plnia nejakú spoločnú úlohu.

V prípade, že sa celý proces niekde zasekne, je dôležité vedieť efektívne dohľadať, kde došlo k prvotnému problému a ako sa ten následne šíril celým systémom. Preto je dôležité mať nastavenie logovania tak, aby pokiaľ je to možné jednotlivé aplikácie logovali na spoločné miesto a okrem logovania špecifík danej aplikácie logovali aj nejaký biznis atribút, povedzme číslo udalosti, ktorý je spoločný naprieč celým systémom.

Ak si predstavíme napríklad distribuovaný systém na spracovanie faktúr, potom jednotlivé časti systému by mali logovať okrem iného číslo faktúry, s ktorou operáciu vykonávajú. Uvedeným spôsobom je potom možné chybu hľadať rýchlo v centrálnom logu a rozpoznať súvislosti týkajúce sa tej istej operácie (faktúry) naprieč celým systémom.

Ďakujem za rozhovor

Rozhovor spracoval Boris Rybár / Manažér tímu softvérového vývoja