Palvelinarkkitehtuuri
REST-palvelimet ja -palvelut – yleiskatsaus
API. Palvelut. Operointi.
REST-palvelin ja -palvelut saman järjestelmäarkkitehtuurin toiminnallisena laajennuksena.
Monet yrityssovellukset vaativat nykyään enemmän kuin yhden clientin. Rajapinnat, portaalit, ajastettu suoritus, integraatiot, taustankäsittely ja tekninen operointilogiikka kuuluvat tähän. Juuri siksi suunnittelemme REST-palvelimet ja -servicet eivät jälkiasennuksina, vaan osana samaa arkkitehtuuria.
API:t, joilla on aito toimialallinen merkitys
REST-palvelin ei meille ole pelkkä tekninen kerros, vaan kontrolloitu roolien, prosessien, tietojen ja liiketoimintasääntöjen paljastaminen.
Windows- ja Linux-palvelut todellisia prosesseja varten
Synkronointi, tuonnit, viennit, ajastukset, lisenssintarkistus tai ilmoitukset toimivat vakaammin, kun ne on tietoisesti ulkoistettu serviceihin ja asianmukaisesti valvottu.
Monitoring, virhepolut ja käyttöönotto
Siistit lokit, uudelleenkäynnistys, konfigurointi, julkaisupolut ja vastuut ovat osa suunnittelua, eivät vasta Go-live -vaiheen aihe.
Milloin service-orientoitunut jako on järkevä
- kun useat client-sovellukset tarvitsevat pääsyn samaan toiminnalliseen logiikkaan
- kun taustaprosesseja ei haluta sitoa yksittäisiin työasemiin
- kun portaalit, työpöytäasiakkaat ja kolmannen osapuolen järjestelmät käyttävät hallitusti samaa tietopohjaa
- kun julkaisujen, operoinnin ja teknisen vastuun pitää pysyä skaalautuvina
Ei API:ta ilman arkkitehtuuria
Todellinen lisäarvo ei synny yksittäisestä päätepisteestä, vaan palvelinrakenteesta, joka siirtää oikeudet, prosessit ja tiedot johdonmukaisesti operointiin.
REST-palvelimet ja palvelut osana samaa toiminnallista logiikkaa
Monissa yrityksissä API:t ja taustapalvelut syntyvät liian myöhään ja paineen alla. Silloin olemassa olevaa työpöytäasennuskantaa laajennetaan jälkikäteen rajapinnoilla, samalla kun liiketoimintasäännöt pysyvät edelleen clientissä. Tämä johtaa lähes väistämättä epäjohdonmukaisuuksiin: sama sääntö esiintyy useaan kertaan, virhetilanteiden jäljitys vaikeutuu ja operointi lepää erikoistiedon varassa.
Me kuljemme päinvastaista tietä. Jos järjestelmä tarvitsee portaalit, integraatiot, tuonnit, viennit, lisenssintarkistukset tai taustankäsittelyn, vastuut clientin, REST-palvelimen ja palvelun välillä on selvitettävä varhain. Mikä logiikka on toiminnallisesti keskeistä? Mitkä toiminnot täytyy olla toistettavissa? Miten virhetilanteet kirjataan? Miten tietovirtoja voidaan myöhemmin laajentaa ilman että jäädään jälleen monoliitin vangiksi?
Erityisesti Delphi-järjestelmissä tämä on tärkeä kohta. Paljon arvokasta liiketoimintalogiikkaa on usein jo olemassa olevassa järjestelmässä. Se, joka johtaa siitä REST-palvelimia tai Linux- ja Windows-servicejä, ei saa yksinkertaisesti kopioida lähdekoodia, vaan irrottaa yhteisen toiminnallisen perustan puhtaasti sovelluksesta. Vasta sitten syntyy API:eja ja palveluja, jotka puhuvat samaa kieltä kuin client.
Palvelinlogiikka, jolla on toimialallinen auktoriteetti
Päätepisteiden ei tulisi vain toimittaa dataa, vaan kuvata samoja sääntöjä, oikeuksia ja prosessivaiheita, jotka pätevät myös ydinjärjestelmässä.
Palvelut toistuviin prosessivaiheisiin
Tuonnit, vertailut, viennit, synkronoinnit ja ilmoitukset eivät kuulu satunnaisiin asiakasohjelman sivupolkuihin, vaan seurattaviin palveluihin.
Käytön suunnittelu alusta alkaen
Monitorointi, lokitus, uudelleenkäynnistyskäyttäytyminen, konfiguraatio ja julkaisuprosessi kuuluvat palveluiden ja REST-palvelimien arkkitehtuurin ytimeen, eivätkä ne saa jäädä käyttöönottovaiheen jälkeiseksi korjaustyöksi.
Mihin yritysten tulisi kiinnittää huomiota REST-ratkaisuissa ja palveluissa
Tärkein virhe on yleensä rakenteellinen, ei tekninen: projekti luulee, että API ratkaisee arkkitehtuurikysymyksen. Todellisuudessa se alkaa vasta siellä. API:t, portaalit, työpöytäasiakkaat ja palvelut on saatava ymmärtämään sama tietopohja, samat roolit ja samat liiketoimintasäännöt.
Kun tämä linja on selvä, laajennukset voi suunnitella paljon turvallisemmin. Portaali voi käyttää samaa palvelinlogiikkaa, taustapalvelut voivat kontrolloidusti käsitellä samoja objekteja ja kolmannen osapuolen integraatiot pysyvät kiinnitettyinä yhteen selkeään toiminnalliseen kohtaan. Tästä näkökulmasta käsittelemme Monialustaiset clientit, palvelinlogiikan ja tietojen säilytyksen yhtenä järjestelmänä, ei irrallisina rakennuspalikoina.
Lopulta hyvä REST- ja palveluarkkitehtuuri ei määräydy sen moderniuden mukaan, vaan sen mukaan, kuinka vaivattomasti sitä voi myöhemmin ylläpitää. Kun tukitapaukset pysyvät jäljitettävinä, virhepolut ovat näkyvissä ja uudet vaatimukset eivät enää päädy vanhaan koodiin poikkeusreitteinä, saavutetaan todellinen tekninen hyöty.
Mistä huomaa, että REST ja palvelut on valmisteltava arkkitehtonisesti huolellisesti
Heti kun useampi asiakasohjelma, integraatio tai taustaprosessi tarvitsee samoja sääntöjä, API-ajatuksesta muodostuu järjestelmäkysymys. Juuri siinä ratkaistaan, syntyykö myöhemmin rauha vai jatkuva kitka.
Toimintasäännöt kuuluvat yhteiseen ytimeen
API:t ja palvelut ovat käyttökelpoisia vasta, kun ne noudattavat samaa logiikkaa kuin asiakasohjelma, portaali ja tietomalli.
Lokitus, uudelleenkäynnistykset ja virheiden näkyvyys kuuluvat suunnitteluun
Hyvin toteutettu taustalogiikka ei ilmene endpointista, vaan vakaana käyttäytymisenä tuotantokäytössä.
Uudet integraatiot pysyvät hallittavina
Kun palvelinlogiikka erotellaan puhtaasti varhaisessa vaiheessa, voi portaalit, viennit ja kolmannen osapuolen liitännät laajentaa huomattavasti hallitummin.
Mitä ensimmäisen arkkitehtuurikartoituksen tulisi tuottaa REST-ratkaisuille ja palveluille
Suurin vaikutin ei usein ole frameworkissa, vaan vastuuiden selkeässä jakautumisessa asiakasohjelman, palvelimen ja taustaprosessien välillä.
- luokitus siitä, mikä logiikka täytyy pitää toiminnallisesti keskitettynä ja mikä kuuluu palveluihin
- näkymä rooleihin, tietovirtoihin, lokitukseen ja teknisiin käyttötiloihin
- aloituspolku API:lle, taustatehtäville ja integraatioille ilman hallitsematonta rinnakkaisjärjestelmää
Jäsennä palvelinlogiikka ennen villiintymistä
Jos API:t, taustatehtävät tai portaalit aiheuttavat jo painetta, nyt on oikea hetki määrittää yhteinen toiminnallinen ydin selkeästi.
Usein kysytyt kysymykset REST-palvelimista ja palveluista
Monet järjestelmät eivät kaadu API-ideaan, vaan siihen, että palvelinlogiikka liitetään myöhemmin improvisoidusti olemassa olevaan työpöytäsovelluskantaan. Suunnittelemme nämä osat tietoisesti yhdessä.
Milloin yrityssovellus tarvitsee lisäksi REST-palvelimen?
Heti kun useat asiakasohjelmat, portaalit, mobiilikäytöt, ulkoiset integraatiot tai irrotetut prosessit haluavat käyttää hallitusti samaa liiketoimintalogiikkaa.
Tuetteko myös Windows- ja Linux-palveluja?
Kyllä. Taustaprosessit, ajastukset, synkronointi, vienti, lisenssipalvelut ja tekniset tukiprosessit kuuluvat tyypillisiin tehtäviimme.
Miten liiketoimintalogiikan johdonmukaisuus säilyy asiakasohjelman, RESTn ja palvelun välillä?
Arkkitehtuurin avulla, jossa liiketoimintasäännöt eivät ole piilotettuina yksittäisiin käyttöliittymiin vaan ovat yhteiskäytössä ja jäljitettävissä.
Lue lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät tällä sivulla. Keskisellä UKK-aloitussivulla käsittelemme aiheen lisäksi arkkitehtuurin, modernisoinnin, alustojen ja käytön yhteydessä.