Mūsdienās daudzām uzņēmumu lietojumprogrammām nepieciešami vairāk nekā viens klients. Saskarnes, portāli, laika plānošana, integrācijas, fona apstrāde un tehniskā ekspluatācijas loģika tam pieder. Tieši tāpēc mēs REST-serverus un servisu neplānojam kā pēctecīgu pielikumu, bet kā tās pašas arhitektūras daļu.
API ar īstu nozīmi biznesā
REST-serveris mums nav tikai tehniska slāņa izpausme, bet kontrolēta lomu, procesu, datu un biznesa noteikumu ekspozīcija.
Windows- un Linux-dienesti reāliem procesiem
Sinhronizācija, importi, eksporti, laika plānošana, licences pārbaude vai paziņojumi darbosies stabilāk, ja tos apzināti izvietos servisos un pienācīgi uzraudzīs.
Monitoring, kļūdu ceļi un izvietošanas procesi
Sakārtotas žurnālfaili, atkārtota palaišana, konfigurācija, release-ceļi un pienākumu sadale ir daļa no dizaina, nevis tēma tikai pēc Go-live.
Kad servisu orientēts risinājums ir lietderīgs
- ja vairākiem klientiem jāpiekļūst tai pašai biznesa loģikai
- ja fona procesiem vairs nevajadzētu būt saistītiem ar atsevišķām darba vietām
- ja portāli, darbvirsmas klienti un trešo pušu sistēmas kontrolēti izmanto šo pašu datu bāzi
- ja versiju izlaide, ekspluatācija un tehniskā atbildība jāspēj mērogot
Nav API bez arhitektūras
Patiesā pievienotā vērtība neveidojas no viena endpointa, bet no servera izkārtojuma, kas konsekventi pārnes tiesības, procesus un datus ekspluatācijā.
REST-serveri un servisi kā tās pašas biznesa loģikas sastāvdaļa
Daudzos uzņēmumos API un fona pakalpojumi tiek izveidoti par vēlu un zem spiediena. Tad esošajam darbvirsmas risinājumam pēc tam pievieno saskarnes, kamēr biznesa noteikumi turpina būt paslēpti klientā. Tas gandrīz neizbēgami noved pie neatbilstībām: vieni un tie paši noteikumi eksistē vairākkārt, kļūdu atpazīšana kļūst sarežģītāka un ekspluatācija balstās uz speciālām zināšanām.
Mēs rīkojamies pretēji. Ja sistēmai nepieciešami portāli, integrācijas, importi, eksporti, licences pārbaudes vai fona apstrāde, atbildība starp klientu, REST-serveri un servisu jānosaka savlaicīgi. Kura loģika ir funkcionāli centrāla? Kuras darbības jāspēj reproducēt? Kā tiek protokolētas kļūmsituācijas? Kā vēlāk paplašināt datu plūsmas, nepiesaistoties atkal monolītam?
Īpaši Delphi-sistēmās šis punkts ir būtisks. Liela vērtīga biznesa loģika bieži jau atrodas esošajā kodā. Tie, kas no tā atvasina REST-serverus vai Linux- un Windows-servisus, nedrīkst vienkārši kopēt avota kodu, bet skaidri izdalīt kopējo funkcionālo bāzi no lietojuma. Tikai tad rodas API un servisi, kas runā to pašu valodu kā klients.
Servera loģika ar funkcionālu autoritāti
Endpointiem nevajadzētu tikai piegādāt datus, bet atspoguļot tos pašus noteikumus, tiesības un procesa soļus, kas ir spēkā arī pamatsistēmā.
Servisi atkārtotiem procesa soļiem
Importi, saskaņojumi, eksporti, sinhronizācijas un paziņojumi nepieder pie nejaušiem klienta blakusceļiem, bet gan pie novērojamiem pakalpojumiem.
Ekspluatāciju iekļaut plānošanā no sākuma
Monitorings, žurnālu reģistrēšana, restartēšanas uzvedība, konfigurācija un izlaiduma process pieder arhitektūras kodolam pakalpojumiem un REST-serveriem, nevis pie pēcapstrādes pēc ražošanas uzsākšanas.
Kam uzņēmumiem jāpievērš uzmanība attiecībā uz REST un pakalpojumiem
Visbiežāk nozīmīgā kļūda nav tehniska, bet strukturāla: projekts uzskata, ka ar API arhitektūras jautājums jau ir atrisināts. Patiesībā tas tikai sākas. API, portāli, darbvirsmas klienti un pakalpojumi ir jāsaskaņo ar vienu datu bāzi, vienām lomām un vieniem biznesa noteikumiem.
Ja šī līnija ir nostiprināta, paplašināšanas var plānot daudz drošāk. Portāls var piekļūt tai pašai servera loģikai, fonā strādājošie pakalpojumi var kontrolēti apstrādāt tos pašus objektus, un trešo pušu integrācijas paliek piesaistītas skaidrai biznesa vietai. Tieši no šādas perspektīvas mēs uzskatām Daudzplatformu klientus, servera loģiku un datu glabāšanu par vienotu sistēmu, nevis par vaļīgiem atsevišķiem moduļiem.
Beigu beigās labu REST- un pakalpojumu arhitektūru nenosaka tas, cik moderni tā skan, bet cik mierīgi to vēlāk ekspluatēt. Ja atbalsta gadījumi paliek izsekojami, kļūdu ceļi ir redzami un jaunas prasības vairs nebeidzas ar izņēmuma ceļiem mantojuma kodā, ir sasniegts reālais tehniskais ieguvums.
Kā atpazīt, ka REST un pakalpojumi jāgatavo arhitektoniski tīri
Tiklīdz vairāki klienti, integrācijas vai fonprocesi nepieciešami tajām pašām noteiksmēm, no API idejas rodas sistēmas jautājums. Tieši tur izšķiras, vai vēlāk būs darbības miers vai pastāvīga berze.
Biznesa noteikumi pieder kopējam kodolam
API un pakalpojumi kļūst pamatoti tikai tad, ja tie runā to pašu loģiku kā klients, portāls un datu modelis.
Žurnāli, restartēšana un kļūdu redzamība ir dizaina daļa
Tīru fonloģiku nevar atpazīt pēc endpointa, bet pēc mierīgas uzvedības reālajā darbībā.
Jaunas integrācijas paliek pārvaldāmas
Ja servera loģiku agrīni skaidri nošķir, portālus, eksportus un trešo pušu pieslēgumus var paplašināt daudz pārvaldāmāk.
Ko pirmā arhitektūras apsekošana attiecībā uz REST un pakalpojumiem vajadzētu sniegt
Lielākais sviras efekts bieži nav frameworkā, bet skaidrā atbildības sadalījumā starp klientu, serveri un fonprocesiem.
- novērtējumu par to, kura loģika jāatstāj biznesiski centrāla un kas jāievieto pakalpojumos
- pārskatu par lomām, datu plūsmām, žurnālu reģistrēšanu un tehniskajiem darbības stāvokļiem
- sākuma ceļu API, fonajām darba reizēm un integrācijām bez nekontrolētas paralēlas vides
Sakārtot servera loģiku pirms nekontrolētas izplešanās
Ja API, darbi vai portāli jau rada spiedienu, tagad ir īstais laiks skaidri nostiprināt kopējo biznesa kodolu.
BUJ par REST-serveriem un pakalpojumiem
Daudzas sistēmas neizdodas nevis API idejas dēļ, bet gan tāpēc, ka servera loģika vēlāk improvizēti tiek pievienota esošam darbvirsmas kodam. Mēs apzināti plānojam šīs komponentes kopā.
Kad uzņēmuma lietojumprogrammai papildus nepieciešams REST-serveris?
Tiklīdz vairākiem klientiem, portāliem, mobilajām piekļuvēm, ārējām integrācijām vai atdalītiem procesiem kontrolēti jāizmanto viena un tā pati domēna loģika.
Atbalstāt arī Windows- un Linux-pakalpojumus?
Jā. Fona procesi, laika plānošana, sinhronizācija, eksporti, licenču pakalpojumi un tehniskie pavadošie procesi ir daļa no mūsu tipiskajiem uzdevumiem.
Kā tiek nodrošināta domēna konsekvence starp klientu, REST un pakalpojumu?
Ar arhitektūru, kurā biznesa noteikumi nav paslēpti atsevišķās saskarnēs, bet paliek koplietojami un pārskatāmi.
Weitere Fragen gesammelt lesen
Diese Kurzantworten bleiben hier auf der Seite. Auf der zentralen FAQ-Landingpage ordnen wir das Thema zusaetzlich im Zusammenhang mit Architektur, Modernisierung, Plattformen und Betrieb ein.