Palvelukeskeinen arkkitehtuuri (SOA) on tietokoneohjelmistosuunnittelun arkkitehtuurimalli, jossa sovelluskomponentit tarjoavat palveluita muille komponenteille tietoliikenneprotokollan kautta, tyypillisesti verkon kautta. Palvelukeskeisyyden periaatteet ovat riippumattomia tuotteista, toimittajista tai tekniikoista.
SOA vain helpottaa eri verkkojen ohjelmistokomponenttien työskentelyä keskenään.
SOA-arkkitehtuurin mukaisesti rakennetut verkkopalvelut tekevät verkkopalvelusta itsenäisemmän. Verkkopalvelut itse voivat vaihtaa tietoja keskenään, ja koska ne luodaan perusperiaatteista, ne eivät tarvitse minkäänlaista ihmisen vuorovaikutusta eivätkä myöskään tarvitse koodimuutoksia. Se varmistaa, että verkon verkkopalvelut voivat olla vuorovaikutuksessa keskenään saumattomasti.
SOA perustuu joihinkin keskeisiin periaatteisiin, jotka mainitaan jäljempänä
- Standardoitu palvelusopimus - Palvelut noudattavat palvelukuvausta. Palvelulla on oltava jonkinlainen kuvaus, joka kuvaa palvelun tarkoitusta. Tämä helpottaa asiakassovellusten ymmärtämistä palvelun toiminnasta.
- Löysä kytkentä - Vähemmän riippuvuutta toisistaan. Tämä on yksi verkkopalvelujen pääominaisuuksista, jossa vain todetaan, että verkkopalvelujen ja verkkopalvelua käyttävän asiakkaan välillä tulisi olla mahdollisimman pieni riippuvuus. Joten jos palvelun toiminnallisuus muuttuu milloin tahansa, sen ei pitäisi rikkoa asiakassovellusta tai estää sitä toimimasta.
- Palvelun abstraktio - Palvelut piilottavat kapseloimansa logiikan ulkomaailmalta. Palvelun ei tulisi paljastaa, miten se suorittaa toimintansa; sen pitäisi vain kertoa asiakassovellukselle, mitä se tekee, eikä siitä, miten se tekee sen.
- Palvelujen uudelleenkäytettävyys - logiikka on jaettu palveluihin tarkoituksena maksimoida uudelleenkäyttö. Kaikissa kehitysyrityksissä uudelleenkäytettävyys on iso aihe, koska ei tietenkään halua käyttää aikaa ja vaivaa saman koodin rakentamiseen uudestaan ja uudestaan useissa sovelluksissa, jotka vaativat niitä. Siksi, kun verkkopalvelun koodi on kirjoitettu, sillä pitäisi olla kyky toimia erilaisten sovellustyyppien kanssa.
- Palvelun itsenäisyys - Palveluilla tulisi olla hallinto kapseloimaansa logiikkaan. Palvelu tietää kaiken siitä, mitä toimintoja se tarjoaa, ja sen pitäisi siksi myös hallita täysin sen sisältämää koodia.
- Palveluttomuus - Ihannetapauksessa palvelujen tulisi olla kansalaisuudettomia. Tämä tarkoittaa, että palvelujen ei pidä salata tietoja valtiosta toiseen. Tämä olisi tehtävä joko asiakassovelluksesta. Esimerkki voi olla ostosivustolla tehty tilaus. Nyt sinulla on verkkopalvelu, joka antaa sinulle tietyn tuotteen hinnan. Mutta jos tuotteet lisätään ostoskoriin ja verkkosivu siirtyy sivulle, jolla suoritat maksun, verkkopalvelu ei saisi olla vastuussa maksusivulle siirrettävän tuotteen hinnasta. Sen sijaan se on tehtävä verkkosovelluksen toimesta.
- Palvelu löydettävyys - Palvelut voidaan havaita (tavallisesti Service Registry). Olemme jo nähneet tämän UDDI-konseptissa, joka suorittaa rekisterin, johon mahtuu tietoja verkkopalvelusta.
- Palvelujen yhteensopivuus - Palvelut jakavat suuret ongelmat pieniksi ongelmiksi. Älä koskaan upota sovelluksen kaikkia toimintoja yhdeksi palveluksi, vaan jaa palvelu moduuleiksi, joista jokaisella on erillinen liiketoimintatoiminto.
- Palvelujen yhteentoimivuus - Palvelujen tulisi käyttää standardeja, jotka sallivat eri tilaajien käyttää palvelua. Verkkopalveluissa XML-standardeja ja HTTP-viestintää käytetään standardien varmistamiseksi, että ne noudattavat tätä periaatetta.