Ar REST API visada tinka pramonei? Kada geriau rinktis eiles, brokerius ir įvykiais grindžiamą komunikaciją?

Klausimas, ar REST API tinka pramonei, šiandien jau nėra ginčas dėl pageidaujamo integracijos stiliaus. Tai sprendimas, kur projekte bus perkelti kaštai, vėlavimas ir eksploatacinė atsakomybė. Pramoninėje aplinkoje komunikacijos sąsaja labai greitai nustoja būti vien „techniniu sluoksniu“ ir pradeda veikti proceso tęstinumą, veiksmų atkartojamumą, audito galimybes ir reagavimo į gedimus būdą. REST pasiteisina ten, kur tikimasi paprastos užklausos, vienareikšmio atsakymo ir aiškios užklausos būsenos kontrolės. Problemos prasideda tada, kai sistema turi veikti nepaisant laikino vieno iš dalyvių nepasiekiamumo, kai pranešimai turi būti pristatyti su patvirtinimu arba kai vienas įvykis turi sukelti pasekmes keliose nepriklausomose srityse. Tuomet pasirinkimas tarp sinchroninės užklausos ir eilės, brokerio bei įvykių komunikacijos jau nebėra techniškai neutralus.

Tai ypač svarbu būtent dabar, nes vis daugiau pramoninių projektų sujungia valdymą, techninę priežiūrą, kokybės sistemas, gamybos ataskaitų teikimą ir išorines paslaugas į vieną priklausomybių grandinę. Jei architektūra bus grindžiama vien sinchroniniais iškvietimais, komanda dažnai gauna iš pažiūros paprastą sistemą, tačiau trapią didėjant integracijų skaičiui, esant nestabiliam tinklui ar reikalaujant tikslaus įvykių pėdsako. Tokio sprendimo kaina išryškėja ne funkcijų demonstravimo etape, o vėliau: kai procesus blokuoja nepasiekiamas komponentas, kai sunku atkurti incidento eigą, kai tenka rankiniu būdu derinti skirtingas sistemų būsenas ir ginčytis, ar operacija buvo įvykdyta, ar tik inicijuota. Produkto savininkui ir projekto vadovui praktinis kriterijus yra paprastas: reikia nuspręsti, ar konkretūs duomenų mainai yra „klausimas–atsakymas čia ir dabar“, ar veikiau „užregistruok faktą ir užtikrink tolesnį jo apdorojimą net esant trikdžiams“. Nuo šio atsakymo priklauso ne tik technologija, bet ir atsakomybės modelis tarp komandų.

Praktikoje tai gerai matyti mašinų sistemose, kur vienas operatoriaus veiksmas arba vienas proceso įvykis turi būti užfiksuotas, perduotas ir patvirtintas keliose vietose. Jei priežiūros programa siunčia sinchroninę užklausą paskesnėms paslaugoms ir laukia visų atsakymų, laikina vieno elemento problema gali sustabdyti visą seką, nors dalis verslo pasekmių turėtų įvykti nepriklausomai. Tuo tarpu brokeris arba eilė leidžia atskirti informacijos priėmimo momentą nuo jos apdorojimo momento, išsaugoti įvykio pėdsaką ir lengviau valdyti pakartojimą po klaidos. Tai nereiškia, kad įvykių komunikacija visada yra geresnė: jei reikia nedelsiant priimti sprendimą, kuris blokuoja tolesnį mašinos veikimą, arba operatorius turi iš karto gauti galutinį atsakymą, asinchroninis modelis be gerai suprojektuotų tarpinių būsenų gali padidinti neapibrėžtumą. Todėl jau projekto pradžioje verta matuoti ne tik atsako laiką, bet ir prarastų arba dubliuotų pranešimų skaičių, skirtingų būsenų suderinimo laiką ir galimybę po incidento atkurti įvykių seką.

Ši tema natūraliai susijusi su rizikos vertinimu pramoniniuose projektuose, nes komunikacijos būdo parinkimas daro įtaką klaidos pasekmėms, neatitikčių aptinkamumui ir galimybei įdiegti veiksmingas rizikos mažinimo priemones. Jei per sąsają perduodamos funkcijos, kurių neteisingas vykdymas gali lemti nepageidaujamą paleidimą, pavojingą būsenos pasikeitimą arba valdymo energija praradimą, klausimas nustoja būti vien informacinių technologijų srities ir pereina į mašinos sistemos projektavimo bei apsaugos priemonių vertinimo sritį. Būtent čia atsiranda riba, nuo kurios reikia nagrinėti ir susijusius klausimus, įskaitant apsaugą nuo netikėto paleidimo bei praktinį rizikos vertinimą pagal LST EN ISO 12100. Kitaip tariant, sprendimas dėl REST, eilės ar brokerio turėtų būti priimamas ne po integracijos demonstracijos, o tada, kai komanda geba įvardyti neteisingo arba pavėluoto pranešimo pasekmes procesui, saugai ir veiksmų atsekamumui.

Kur dažniausiai didėja kaštai arba rizika

Daugiausia klaidingų sprendimų kyla ne dėl „blogos technologijos“ pasirinkimo, o dėl to, kad REST API priskiriamos užduotys, kurioms jis nebuvo sukurtas. Pramonėje kaštai auga tada, kai užklausos–atsakymo sąsaja turi perimti komunikaciją, jautrią laikinam nepasiekiamumui, įvykių eiliškumui arba patikimo įvykdymo patvirtinimo poreikiui. Jei sistema turi tik nuskaityti esamą įrenginio būseną arba priimti komandą, kurios nebuvimą galima lengvai aptikti ir pakartoti be šalutinio poveikio, REST gali būti pakankamas. Tačiau jei rezultatas priklauso nuo to, ar pranešimas buvo pristatytas tiksliai vieną kartą, tinkama seka ir su galimybe po incidento atkurti istoriją, REST ribojimų apėjimo kaštai greitai viršija tariamą diegimo paprastumą. Praktikoje tai reiškia papildomą pakartojimų logiką, nuosavus buferiavimo mechanizmus, skirtingų būsenų derinimą ir sudėtingesnį atsakomybės nustatymą, kai įrenginys operaciją įvykdė vėliau nei tikėtasi arba atliko ją du kartus.

Projektavimo etape problema paprastai atrodo nekaltai: komanda daro prielaidą, kad tinklas bus stabilus, paslaugos nuolat pasiekiamos, o abiejose integracijos pusėse būsena bus vienareikšmė. Pramoninėje aplinkoje tokios prielaidos retai išlieka ilgai. Atsiranda ryšio pertrūkių, įrenginys paleidžiamas iš naujo, atnaujinama tarpinė sistema, o kartais tiesiog susidaro perkrova gamybinės pamainos metu. Tuomet architektūra, paremta vien sinchroniniais iškvietimais, pradeda perkelti riziką programoms ir operatoriams. Projekto kaina auga ne tik dėl programavimo pataisų, bet ir dėl atkuriamųjų bandymų, papildomų eksploatacinių procedūrų bei ginčų, kuri pusė „turėjo žinoti“, kad užklausa nebuvo įvykdyta. Praktinis sprendimo kriterijus paprastas: jeigu gavėjo nepasiekiamumas negali sustabdyti siuntėjo, o pranešimą būtina saugiai išsaugoti ir apdoroti vėliau, reikia rimtai svarstyti eilę, brokerį arba įvykių pagrindu veikiančią komunikaciją vietoje gryno REST.

Geras pavyzdys – priežiūros sistemos integracija su linija, kurioje viena sistema inicijuoja receptūros pakeitimą, o kelios kitos turi šį pakeitimą priimti, patvirtinti ir pritaikyti tinkamu ciklo momentu. Naudojant REST nesunku sukurti iškvietimą „nustatyti parametrus“, tačiau sunkiau užtikrinti, kad visi susiję elementai gavo tą pačią informaciją, kad senesnis pranešimas neperrašys naujesnio ir kad po gedimo bus galima nustatyti, kas matė kurią komandą. Įvykių brokeris arba eilė šią problemą sutvarko kitaip: pranešimas sistemoje tampa ilgalaikiu faktu, kurį galima sekti, apdoroti pakartotinai ir nepriklausomai pasiimti daugeliui gavėjų. Tai nėra vien techninis pasirinkimas. Nuo jo priklauso, ar gavus pretenziją dėl partijos, prastovos ar incidento bus įmanoma parodyti sistemos sprendimų eigą, taigi ir priskirti sutartinę, operacinę ar vidinę atsakomybę. Ten, kur svarbus atsekamumas, verta matuoti ne tik atsako delsą, bet ir pranešimų, kuriuos reikia siųsti pakartotinai, skaičių, būsenos suderinimo po gedimo laiką bei galimybę atkurti įvykių seką be rankinės rekonstrukcijos iš daugelio žurnalų.

Ši tema pereina į rizikos vertinimo pagal ISO 12100 sritį tada, kai klaidingas arba pavėluotas pranešimas gali pakeisti mašinos, proceso arba apsaugos priemonės veikimą. Tokiu atveju nebeužtenka klausti apie integracijos patogumą; reikia įvertinti pasekmes, aptinkamumą ir galimybę apriboti padarinius, o tai atitinka ISO 12100 žinomą praktiką. Jeigu komunikacija susijusi su sauga susijusiomis funkcijomis, blokavimais, paleidimo sąlygomis arba energijos būsenos patvirtinimais, projektinės atsakomybės riba persikelia iš programos lygmens į visos mašinos sistemos lygmenį. Panašiai ir vykdomosiose sistemose, taip pat hidraulinėse, klaidinga prielaida apie savalaikį informacijos pristatymą gali prieštarauti apsaugos priemonių ir saugių būsenų projektavimo principams, o tai natūraliai veda prie klausimų, siejamų su LST EN ISO 4413. Kitaip tariant, eilės ir brokeriai nėra „geresni iš principo“, tačiau jie tampa tinkamu pasirinkimu ten, kur projektas turi atlaikyti ryšio sutrikimą neprarandant kontrolės, istorijos ir atsakomybės už atliktus veiksmus.

Kaip prie to prieiti praktiškai

Praktikoje klausimas skamba ne taip, ar REST API yra geras ar blogas, o ar jis atitinka klaidos, delsos ir atsako nebuvimo pasekmes konkrečiame pramoniniame procese. Jeigu komunikacija daugiausia skirta duomenims nuskaityti, administraciniams veiksmams inicijuoti arba integracijai su verslo sistemomis, užklausos–atsako sąsaja dažnai būna paprasčiausias ir pigiausias sprendimas. Problema prasideda tada, kai projekte numatomas nenutrūkstamas informacijos apsikeitimas net ir vienai iš pusių laikinai nepasiekiamai esant, reikia tvarkingai apdoroti įvykius arba privaloma atkurti, kas, kada ir kokiu pagrindu inicijavo konkretų būsenos pakeitimą. Tokioje situacijoje REST pasirinkimas kaip numatytojo mechanizmo dažnai sumažina pradinę įėjimo kainą, bet padidina gedimų valdymo, būsenos suderinimo po pertrūkio ir incidento išaiškinimo sąnaudas. Tai momentas, kai eilės, brokeriai ir įvykių pagrindu veikianti komunikacija nustoja būti „architektūriniu priedu“ ir tampa projektinės rizikos bei operacinės atsakomybės mažinimo priemone.

Komandai ir vadovui tai reiškia, kad architektūrinį sprendimą reikia priimti remiantis keliomis išmatuojamomis proceso savybėmis, o ne rangovo pageidavimais. Naudingiausias kriterijus paprastas: reikia nustatyti, kas turi nutikti pranešimui, kai gavėjas siuntimo momentu neatsako. Jeigu teisingas atsakymas yra „nieko kritiško, operaciją galima saugiai pakartoti arba atmesti“, REST paprastai pakanka. Tačiau jeigu pranešimą būtina išsaugoti, pristatyti atnaujinus darbą, apdoroti tik vieną kartą arba įrodomai nustatyta tvarka, tuomet sinchroninė architektūra pradeda nebeatitikti proceso reikalavimų. Verta tai įrašyti dar prielaidų etape kaip priėmimo kriterijus: leistinas partnerio nepasiekiamumo laikas, pakartojimo būdas, deduplikavimo taisyklės, įvykių koreliacijos atsekamumo galimybė ir būsenos atkūrimo po gedimo būdas. Be tokių susitarimų projektas tik iš pažiūros pajuda greičiau, tačiau vėliau sugrįžta brangių integracijos pakeitimų, ginčų dėl atsakomybės apimties ir sunkiai uždaromų eksploatacinių neatitikčių pavidalu.

Geras pavyzdys – linija arba darbo vietų grupė, kurioje aukštesnio lygio sistema perduoda užduotis, o valdikliai ir darbo vietos pateikia informaciją apie įvykdymą, broką, blokavimus arba perėjimus tarp darbo režimų. Jei kiekvienas įvykis iš karto „apklausiamas“ per REST, net ir trumpam praradus ryšį labai greitai atsiranda neatitikimas tarp faktinės būsenos ir būsenos, matomos programoje. Gamybos požiūriu tai baigiasi rankiniu duomenų sutikrinimu, kokybės požiūriu – partijos istorijos spraga, o eksploatacijos priežiūros požiūriu – neaiškumu, ar konkretus nurodymas buvo įvykdytas, ar tik išsiųstas. Brokeris su ilgalaikiu pranešimų saugojimu neišsprendžia visko, tačiau aiškiau paskirsto atsakomybę: siuntėjas perdavė įvykį, tarpinė sistema jį išsaugojo, gavėjas jį patvirtino arba ne. Tai esminis skirtumas analizuojant prastovos priežastis ir aiškinantis, ar klaida kilo dėl proceso logikos, tinklo gedimo, ar dėl neteisingos operatoriaus veiksmų sekos. Būtent todėl sprendimas dėl komunikacijos modelio daro įtaką ne tik diegimo kainai, bet ir paleidimo, techninio aptarnavimo bei audito trukmei.

Ši tema pereina į praktinį rizikos vertinimą tada, kai pranešimas jau nebėra vien informacija, o tampa mašinos, proceso arba apsaugos priemonės veikimo sąlyga. Jei nuo teisingo būsenos perdavimo priklauso galimybė paleisti įrenginį, atnaujinti darbą po sustabdymo, atblokuoti seką arba patvirtinti saugią energijos būseną, tuomet integracijos sprendimas tampa didesnės svarbos projektinio sprendimo dalimi. Tokiu atveju reikia vertinti ne tik komunikacijos prieinamumą, bet ir jos praradimo, vėlavimo, dubliavimo bei klaidingo interpretavimo pasekmes; čia natūraliai atsiranda metodika, žinoma iš ISO 12100 rizikos vertinimo. Savo ruožtu ten, kur komunikacija susijusi su netikėto paleidimo prevencijos sąlygomis, informacinio sluoksnio negalima laikyti sprendimų, skirtų energijos atjungimui ir saugiai būsenai užtikrinti, pakaitalu. Tai riba, ties kuria tema jau susiliečia su apsaugos nuo netikėto paleidimo analize ir plačiau – su mašinos sistemos projektavimu, peržengiančiu vien funkcionalumo ribas. Kitaip tariant, REST pramonei tinka tada, kai proceso lygmeniu jo ribotumai sąmoningai priimami; jei taip nėra, tinkamesni tampa eilėmis pagrįsti ir įvykių komunikacijos mechanizmai, nes jie geriau atitinka tęstinumo, atsekamumo ir gedimų pasekmių kontrolės reikalavimus.

Į ką atkreipti dėmesį diegiant

Dažniausia diegimo klaida yra ta, kad REST API arba įvykių komunikacijos pasirinkimas laikomas vien techniniu sprendimu, nors pramonėje tai yra sprendimas, turintis eksploatacinių ir organizacinių pasekmių. REST nenustoja veikti vien todėl, kad naudojamas gamybos ceche, tačiau labai greitai išryškėja jo ribotumai ten, kur sistema turi sugerti ryšio pertraukas, netolygias apkrovas, laikiną paslaugų nepasiekiamumą ir būtinybę vėliau atkurti įvykių eigą. Jei architektūra numato, kad kiekvienas atsakas turi ateiti iš karto ir iš pirmo karto, projektas tampa trapus. Pasekmės paprastai nuspėjamos: auga integracijos sąnaudos, daugėja apeinamųjų mechanizmų, o atsakomybė už neteisingą proceso būseną išsisklaido tarp sistemų tiekėjų. Kita vertus, eilės ir brokeriai problemos neišsprendžia automatiškai; jie įveda savas rizikas, tokias kaip uždelstas apdorojimas, pranešimų dubliavimas, būtinybė tvarkyti seką ir sudėtingesnė stebėsena. Todėl klausimas nėra, ar REST visada tinka pramonei, o ar konkretus procesas toleruoja šios komunikacijos formos ypatybes neperkeldamas rizikos gamybai, eksploatacijos priežiūrai ir atitikčiai.

Projektavimo etape verta taikyti paprastą vertinimo kriterijų: kas tiksliai nutiks procesui, jei pranešimas nepasieks gavėjo, pasieks du kartus arba pasieks per vėlai. Jei pasekmė yra tik pavėluotas duomenų atnaujinimas ataskaitų sistemoje, REST gali būti pakankamas. Tačiau jei atsako nebuvimas blokuoja seką, verčia įsikišti rankiniu būdu, lemia operacijos vykdymo istorijos praradimą arba apsunkina nustatymą, kas ir kuo remdamasis priėmė sprendimą, sinchroninė architektūra pradeda generuoti sąnaudas jau paleidimo etape. Tokiu atveju komunikacija, pagrįsta eile arba brokeriu, paprastai geriau paskirsto atsakomybę: siuntėjas patvirtina perdavimą, gavėjas apdoroja savo tempu, o komanda gali stebėti susikaupusius pranešimus, pakartotinius bandymus ir klaidas. Projekto vadovui tai reiškia būtinybę matuoti ne tik paslaugos prieinamumą, bet ir tokius rodiklius kaip pranešimo užsilaikymo laikas, pakartotinių bandymų dalis, neapskaitytų pranešimų skaičius ir laikas, reikalingas įvykių istorijai atkurti po incidento.

Praktikoje problema ypač išryškėja ten, kur viena integracija vienu metu pradeda atlikti kelis vaidmenis. Pavyzdžiui: aukštesnio lygio sistema siunčia užduotį į darbo vietą, gauna įvykdymo patvirtinimą ir kartu įrašo būseną, nuo kurios priklauso tolesnis linijos paleidimas. Kol kalbame apie verslo duomenų mainus, kelių sekundžių vėlavimas gali būti priimtinas. Tačiau jei tas pats komunikacijos kelias pradeda daryti įtaką vykdomajam sprendimui procese, jis nustoja būti neutraliu IT priedu. Tuomet netinkamai parinktas mechanizmas lemia ne tik prastovų kainą, bet ir atsakomybę už tai, ar sistema nuspėjamai reaguoja į ryšio praradimą, paslaugos paleidimą iš naujo arba pranešimo dublikatą. Tai momentas, kai tema natūraliai pereina į mašinos sistemos projektavimo sritį, peržengiančią vien funkcionalumą: reikia nuspręsti, kurias gedimo pasekmes leidžiama toleruoti, o kurias būtina atskirti nuo integracijos sluoksnio.

Riba tampa dar svarbesnė, kai komunikacija ima apimti sąlygas, susijusias su funkcine sauga arba rizikos vertinimu. Jei nuo teisingo duomenų apsikeitimo priklauso saugios būsenos sąlygos įvykdymas, leidimas atnaujinti darbą, pavojingos energijos išnykimo patvirtinimas ar kita apsauginę reikšmę turinti funkcija, vien geros integravimo praktikos nepakanka. Tokiu atveju reikia aiškiai nustatyti, ar nagrinėjamas elementas lieka tik informaciniu sluoksniu, ar jau patenka į valdymo sistemų elementų, atsakingų už saugos funkcijas, projektavimo sritį. Čia kyla esminiai klausimai, susiję su LST EN ISO 13849-1 ir praktiniu rizikos vertinimu pagal ISO 12100, tačiau tik tada, kai jau apibrėžtos funkcijos ir gedimo pasekmės. Komandai tai reiškia pareigą atskirti tai, ką galima realizuoti per eilę, brokerį ar REST, nuo to, ko negalima grįsti vien tik bendros paskirties komunikacija. Jei ši riba nenustatoma pačioje pradžioje, vėliau tai kainuoja projekto pakeitimais, ginčais priėmimo metu ir sunkiai pagrindžiama atsakomybe už priimtus sprendimus.