En tjänstorienterad arkitektur (SOA) är ett arkitektoniskt mönster i datorprogramvarudesign där applikationskomponenter tillhandahåller tjänster till andra komponenter via ett kommunikationsprotokoll, vanligtvis via ett nätverk. Principerna för serviceorientering är oberoende av alla produkter, leverantörer eller tekniker.
SOA gör det bara lättare för programvarukomponenter över olika nätverk att arbeta med varandra.
Webbtjänster som byggs enligt SOA-arkitekturen tenderar att göra webbtjänster mer oberoende. Webbtjänsterna själva kan utbyta data med varandra och på grund av de underliggande principerna som de skapas på behöver de inte någon form av mänsklig interaktion och behöver inte heller ändra kod. Det säkerställer att webbtjänsterna i ett nätverk kan interagera med varandra sömlöst.
SOA bygger på några viktiga principer som nämns nedan
- Standardiserat serviceavtal - Tjänster följer en tjänstebeskrivning. En tjänst måste ha någon form av beskrivning som beskriver vad tjänsten handlar om. Detta gör det lättare för klientapplikationer att förstå vad tjänsten gör.
- Lös koppling - Mindre beroende av varandra. Detta är en av de viktigaste egenskaperna hos webbtjänster som bara säger att det bör vara så mindre beroende som möjligt mellan webbtjänsterna och klienten som åberopar webbtjänsten. Så om servicefunktionaliteten ändras när som helst bör den inte bryta klientapplikationen eller hindra den från att fungera.
- Serviceabstraktion - Tjänster döljer logiken de inkapslar från omvärlden. Tjänsten ska inte avslöja hur den utför sin funktionalitet; den ska bara berätta för klientapplikationen om vad den gör och inte om hur den gör det.
- Återanvändbarhet av tjänster - Logik är uppdelad i tjänster med avsikt att maximera återanvändning. I vilket utvecklingsföretag som helst är återanvändbarhet ett stort ämne eftersom man uppenbarligen inte vill spendera tid och ansträngning på att bygga samma kod om och om igen i flera applikationer som kräver dem. Därför, när koden för en webbtjänst har skrivits, bör den ha förmågan att fungera med olika applikationstyper.
- Service Autonomy - Tjänster bör ha kontroll över logiken de inkapslar. Tjänsten vet allt om vilken funktionalitet den erbjuder och bör därför också ha fullständig kontroll över koden den innehåller.
- Tjänstlöshet - Helst bör tjänster vara statslösa. Detta innebär att tjänster inte ska hålla information från en stat till en annan. Detta måste göras från klientapplikationen. Ett exempel kan vara en beställning på en shoppingwebbplats. Nu kan du ha en webbtjänst som ger dig priset på en viss artikel. Men om artiklarna läggs till i en kundvagn och webbsidan navigerar till den sida där du betalar, bör inte ansvaret för priset på artikeln som ska överföras till betalningssidan göras av webbtjänsten. Istället måste det göras av webbapplikationen.
- Tjänstupptäckbarhet - Tjänster kan upptäckas (vanligtvis i ett tjänstregister). Vi har redan sett detta i UDDI-konceptet, som utför ett register som kan innehålla information om webbtjänsten.
- Servicekomposibilitet - Tjänster bryter stora problem i små problem. Man bör aldrig bädda in all applikationsfunktionalitet i en enda tjänst utan istället dela upp tjänsten i moduler, var och en med en separat affärsfunktionalitet.
- Serviceinteroperabilitet - Tjänster bör använda standarder som gör det möjligt för olika abonnenter att använda tjänsten. I webbtjänster används standarder som XML och kommunikation via HTTP för att säkerställa att de överensstämmer med denna princip.