Palvelinarkkitehtuuri
REST-palvelin ja palvelut yleiskatsauksena
Monet yrityssovellukset tarvitsevat nykyään enemmän kuin yhden clientin. Rajapinnat, portaalit, ajastus, integraatiot, taustaprosessointi ja tekninen operointilogiikka kuuluvat kokonaisuuteen. Juuri siksi suunnittelemme REST-serverit ja palvelut emme jälkikäteen lisättäväksi liitteeksi, vaan saman arkkitehtuurin osaksi.
API:t, joilla on todellinen liiketoimintamerkitys
REST-serveri ei ole meille vain tekninen kerros, vaan roolien, prosessien, datan ja liiketoimintasääntöjen hallittu esille tuominen.
Windows- ja Linux-palvelut todellisia prosesseja varten
Synkronointi, importit, exportit, ajastus, lisenssitarkistus tai ilmoitukset toimivat vakaammin, kun ne on tietoisesti erotettu palveluihin ja valvottu siististi.
Monitorointi, virhepolut ja deployment
Siistit lokit, uudelleenkäynnistys, konfigurointi, release-polut ja vastuut ovat osa suunnittelua, eivät vasta Go-liven jälkeinen aihe.
Milloin palveluorientoitunut rajaus on järkevä
- kun useiden clientien täytyy käyttää samaa liiketoimintalogiikkaa
- kun taustaprosesseja ei enää haluta sitoa yksittäisiin työasemiin
- kun portaalit, desktop ja kolmannen osapuolen järjestelmät käyttävät hallitusti samaa tietopohjaa
- kun releasen, käytön ja teknisen vastuun on pysyttävä skaalautuvina
Ei API:ta ilman arkkitehtuuria
Varsinainen lisäarvo ei synny yksittäisestä endpointista, vaan serverirajauksesta, joka siirtää oikeudet, prosessit ja datan johdonmukaisesti käyttöön.
REST-serverit ja palvelut osana samaa liiketoimintalogiikkaa
Monissa yrityksissä API:t ja taustapalvelut syntyvät liian myöhään ja paineen alla. Silloin olemassa olevaa desktop-kantaa laajennetaan jälkikäteen rajapinnoilla, samalla kun business-säännöt pysyvät piilossa clientissa. Tämä johtaa lähes väistämättä epäjohdonmukaisuuksiin: sama sääntö on olemassa useaan kertaan, virhekuvia on vaikeampi jäljittää ja käyttö nojaa erityistietoon.
Me kuljemme päinvastaista reittiä. Jos järjestelmä tarvitsee portaaleja, integraatioita, importteja, exportteja, lisenssitarkistuksia tai taustaprosessointia, vastuunjako clientin, REST-serverin ja palvelun välillä on selvitettävä varhain. Mikä logiikka on liiketoiminnallisesti keskeistä? Mitkä toiminnot on oltava toistettavia? Miten virhetilanteet lokitetaan? Miten datavirtoja voidaan myöhemmin laajentaa ilman, että jäädään taas riippuvaisiksi monoliitista?
Erityisesti Delphi-järjestelmissä tämä kohta on tärkeä. Paljon arvokasta business-logiikkaa on usein jo olemassa olevassa kannassa. Kun siitä johdetaan REST-serveriä tai Linux- ja Windows-palveluja, ei pitäisi vain kopioida lähdekoodia, vaan irrottaa yhteinen liiketoiminnallinen perusta sovelluksesta siististi. Vasta silloin syntyy API:t ja palvelut, jotka puhuvat samaa kieltä kuin client.
Serverilogiikka liiketoiminnallisella auktoriteetilla
Endpointien ei pidä vain toimittaa dataa, vaan mallintaa samat säännöt, oikeudet ja prosessivaiheet, jotka pätevät myös ydinjärjestelmässä.
Palvelut toistuviin prosessivaiheisiin
Importit, täsmäytykset, viennit, synkronoinnit ja ilmoitukset eivät kuulu satunnaisiin clientin sivupolkuihin, vaan havainnoitaviin palveluihin.
Ota tuotanto huomioon alusta alkaen
Monitorointi, lokitus, uudelleenkäynnistyskäyttäytyminen, konfigurointi ja julkaisuprosessi kuuluvat palveluissa ja REST-palvelimissa arkkitehtuurin ytimeen, eivätkä jälkityöhön go-liven jälkeen.
Mihin yritysten tulisi kiinnittää huomiota REST- ja palveluissa
Tärkein virhe ei useimmiten ole tekninen, vaan rakenteellinen: projekti kuvittelee, että API ratkaisee arkkitehtuurikysymyksen. Todellisuudessa se vasta alkaa siitä. API:en, portaalien, työpöytäclientien ja palveluiden on ymmärrettävä sama tietopohja, samat roolit ja samat toiminnalliset säännöt.
Kun tämä linja on kunnossa, laajennuksia voidaan suunnitella huomattavasti turvallisemmin. Portaali voi käyttää samaa palvelinlogiikkaa, taustapalvelut voivat hallitusti käsitellä samoja objekteja ja kolmannen osapuolen integraatiot pysyvät kytkettyinä toiminnallisesti selkeään kohtaan. Juuri tästä näkökulmasta tarkastelemme monialustaclienteja, palvelinlogiikkaa ja tiedonhallintaa yhtenä kokonaisuutena emmekä irrallisina yksittäisinä rakennuspalikoina.
Lopulta hyvä REST- ja palveluarkkitehtuuri ei näy siinä, miten modernilta se kuulostaa, vaan siinä, kuinka rauhallisesti sitä voidaan myöhemmin operoida. Kun tukitapaukset pysyvät jäljitettävinä, virhepolut ovat näkyviä ja uudet vaatimukset eivät enää päädy poikkeusreittejä pitkin vanhaan koodiin, varsinainen tekninen hyöty on saavutettu.
Mistä tunnistaa, että REST- ja palvelut on arkkitehtonisesti valmisteltava siististi
Heti kun useat clientit, integraatiot tai taustaprosessit tarvitsevat samat säännöt, API-ideasta tulee järjestelmäkysymys. Juuri siinä ratkaistaan, syntyykö myöhemmin rauha vai jatkuva kitka.
Toiminnallisten sääntöjen kuuluu olla yhteisessä ytimessä
API:t ja palvelut ovat kantavia vasta, kun ne puhuvat samaa logiikkaa kuin client, portaali ja tietomalli.
Lokit, restart ja virheiden näkyvyys ovat osa suunnittelua
Siistin taustalogiiikan tunnistaa ei endpointista, vaan rauhallisesta käytöksestä todellisessa tuotantokäytössä.
Uudet integraatiot pysyvät hallittavina
Kun palvelinlogiikka jaetaan varhain siististi, portaaleja, vientiputkia ja kolmannen osapuolen kytkentöjä voidaan laajentaa selvästi kontrolloidummin.
Mitä ensimmäisen arkkitehtuurikartoituksen tulisi tuottaa REST- ja palveluille
Suurin vipu ei usein ole frameworkissa, vaan vastuiden siistissä jaossa clientin, palvelimen ja taustaprosessien välillä.
- luokittelun siitä, minkä logiikan on pysyttävä toiminnallisesti keskitettynä ja mikä kuuluu palveluihin
- näkymän rooleihin, datavirtoihin, lokitukseen ja teknisiin käyttötiloihin
- aloituspolun API:lle, taustajobeille ja integraatioille ilman hallitsematonta rinnakkaismaailmaa
Jäsennä palvelinlogiikka ennen kuin se villiintyy
Jos API:t, jobit tai portaalit jo painavat päälle, nyt on oikea hetki vetää yhteinen toiminnallinen ydin siististi kohdalleen.
UKK: REST-palvelimet ja palvelut
Moni järjestelmä ei kaadu API-ajatukseen, vaan siihen, että palvelinlogiikka liitetään myöhemmin improvisoiden olemassa olevaan työpöytäkantaan. Me suunnittelemme nämä osat tietoisesti yhdessä.
Milloin yrityssovellus tarvitsee lisäksi REST-palvelimen?
Heti kun useiden klienttien, portaalien, mobiilikäyttöjen, ulkoisten integraatioiden tai irtikytkettyjen prosessien tulee käyttää hallitusti samaa toiminnallista logiikkaa.
Tuetteko myös Windows- ja Linux-palveluja?
Kyllä. Taustaprosessit, ajastus, synkronointi, viennit, lisenssipalvelut ja tekniset oheisprosessit kuuluvat tyypillisiin tehtäviimme.
Miten toiminnallinen johdonmukaisuus säilyy klientin, REST ja palvelun välillä?
Arkkitehtuurilla, jossa liiketoimintasäännöt eivät ole piilotettuina yksittäisiin käyttöliittymiin, vaan ne pysyvät yhteiskäyttöisinä ja jäljitettävinä.
Lue lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät täällä sivulla. Keskus-UKK-laskeutumissivulla jäsennämme aiheen lisäksi arkkitehtuurin, modernisoinnin, alustojen ja käytön yhteydessä.