Uslužno orijentirana arhitektura (SOA) arhitektonski je obrazac u dizajnu računalnog softvera u kojem komponente aplikacije pružaju usluge ostalim komponentama putem komunikacijskog protokola, obično putem mreže. Načela usmjerenosti na usluge neovisna su o bilo kojem proizvodu, dobavljaču ili tehnologiji.
SOA samo olakšava međusobnu suradnju softverskih komponenata putem različitih mreža.
Web usluge koje su izrađene prema SOA arhitekturi obično čine web usluge neovisnijima. Sami web servisi mogu međusobno razmjenjivati podatke i zbog temeljnih principa na kojima su stvoreni, ne trebaju nikakvu ljudsku interakciju, a također ne trebaju nikakve izmjene koda. Osigurava da web usluge na mreži mogu neometano komunicirati jedna s drugom.
SOA se temelji na nekim ključnim principima koji su spomenuti u nastavku
- Standardizirani ugovor o usluzi - Usluge se pridržavaju opisa usluge. Usluga mora imati nekakav opis koji opisuje o čemu se radi. To klijentskim aplikacijama olakšava razumijevanje usluge.
- Labava sprega - Manje ovisnosti jedni o drugima. Ovo je jedna od glavnih karakteristika web usluga koja samo navodi da bi trebala postojati što manja ovisnost između web usluga i klijenta koji se poziva na web uslugu. Dakle, ako se funkcionalnost usluge promijeni u bilo kojem trenutku, ne bi trebala slomiti klijentsku aplikaciju ili zaustaviti njen rad.
- Apstrakcija usluge - Usluge skrivaju logiku koju kapsuliraju od vanjskog svijeta. Usluga ne bi trebala izlagati kako izvršava svoju funkcionalnost; trebao bi samo reći klijentskoj aplikaciji o tome što radi, a ne o tome kako to radi.
- Ponovna upotreba usluge - Logika je podijeljena na usluge s namjerom da maksimizira ponovnu upotrebu. U bilo kojoj je razvojnoj tvrtki ponovna upotrebljivost velika tema jer očito ne bi bilo potrebno trošiti vrijeme i trud gradeći isti kôd iznova i iznova u više aplikacija koje ih zahtijevaju. Dakle, kad je kod za web uslugu napisan, trebao bi imati mogućnost rada s različitim vrstama aplikacija.
- Autonomija usluge - Usluge bi trebale imati kontrolu nad logikom koju inkapsuliraju. Usluga zna sve o tome koju funkcionalnost nudi i stoga bi također trebala imati potpunu kontrolu nad kodom koji sadrži.
- Apatridnost službe - idealno bi bilo da službe imaju apatrid. To znači da službe ne bi smjele zadržavati podatke iz jedne države u drugu. To bi trebalo učiniti bilo iz klijentske aplikacije. Primjer može biti narudžba na web mjestu za kupnju. Sada možete imati web uslugu koja vam daje cijenu određenog predmeta. Ali ako se artikli dodaju u košaricu, a web stranica prijeđe na stranicu na kojoj izvršavate plaćanje, web usluga ne bi trebala snositi odgovornost za cijenu predmeta koji će se prenijeti na stranicu za plaćanje. Umjesto toga, to mora učiniti web aplikacija.
- Otkrivenost usluge - Usluge se mogu otkriti (obično u registru usluga). To smo već vidjeli u konceptu UDDI, koji vrši registar koji može sadržavati informacije o web usluzi.
- Sastavljivost usluga - Usluge velike probleme razgrađuju u male probleme. Nikada ne treba ugrađivati svu funkcionalnost aplikacije u jednu uslugu, već je treba razbiti na module koji imaju zasebnu poslovnu funkcionalnost.
- Interoperabilnost usluge - Usluge bi trebale koristiti standarde koji omogućavaju raznim pretplatnicima upotrebu usluge. U web uslugama koriste se standardi kao XML i komunikacija putem HTTP-a kako bi se osiguralo da su u skladu s ovim načelom.