Uz pakalpojumu orientēta arhitektūra (SOA) ir arhitektūras modelis programmatūras projektēšanā, kurā lietojumprogrammu komponenti sniedz pakalpojumus citiem komponentiem, izmantojot sakaru protokolu, parasti tīklā. Orientēšanās uz pakalpojumu principi ir neatkarīgi no jebkura produkta, pārdevēja vai tehnoloģijas.
SOA vienkārši atvieglo programmatūras komponentu darbību dažādos tīklos.
Tīmekļa pakalpojumi, kas ir veidoti atbilstoši SOA arhitektūrai, mēdz padarīt tīmekļa pakalpojumu neatkarīgāku. Tīmekļa pakalpojumi paši var apmainīties ar datiem, un, ņemot vērā pamatprincipus, uz kuriem tie ir izveidoti, viņiem nav nepieciešama nekāda veida cilvēku mijiedarbība un arī nav nepieciešamas nekādas koda izmaiņas. Tas nodrošina, ka tīkla tīmekļa pakalpojumi var netraucēti mijiedarboties.
SOA pamatā ir daži galvenie principi, kas ir minēti turpmāk
- Standartizēts pakalpojumu līgums - pakalpojumi atbilst pakalpojumu aprakstam. Pakalpojumam ir jābūt sava veida aprakstam, kas apraksta pakalpojuma būtību. Tas ļauj klienta lietojumprogrammām vieglāk izprast pakalpojuma darbību.
- Loose Coupling - mazāka atkarība viens no otra. Šī ir viena no galvenajām tīmekļa pakalpojumu īpašībām, kas tikai norāda, ka starp tīmekļa pakalpojumiem un klientu, kas izmanto tīmekļa pakalpojumu, jābūt pēc iespējas mazāk atkarīgai. Tātad, ja pakalpojuma funkcionalitāte jebkurā brīdī mainās, tam nevajadzētu izjaukt klienta lietojumprogrammu vai apturēt tās darbību.
- Pakalpojuma abstrakcija - pakalpojumi slēpj loģiku, ko tie ietver, no ārpasaules. Pakalpojumam nevajadzētu atklāt, kā tas izpilda savu funkcionalitāti; tai vienkārši jāpasaka klienta lietojumprogrammai, ko tā dara, nevis par to, kā tā dara.
- Pakalpojumu atkārtota izmantojamība - loģika tiek sadalīta pakalpojumos, lai maksimāli palielinātu atkārtotu izmantošanu. Jebkurā attīstības uzņēmumā atkārtota lietojamība ir liela tēma, jo acīmredzot negribētos tērēt laiku un pūles, lai atkal un atkal izveidotu vienu un to pašu kodu vairākās lietojumprogrammās, kurām tie nepieciešami. Tādējādi, tiklīdz ir uzrakstīts tīmekļa pakalpojuma kods, tam vajadzētu būt iespējai strādāt ar dažādiem lietojumprogrammu veidiem.
- Pakalpojuma autonomija - pakalpojumiem vajadzētu kontrolēt loģiku, ko tie iekapsulē. Pakalpojums zina visu par to, kādu funkcionalitāti tas piedāvā, un tāpēc tam vajadzētu arī pilnībā kontrolēt tajā esošo kodu.
- Pakalpojumu bezvalstniecība - ideālā gadījumā pakalpojumiem vajadzētu būt bezvalstniekiem. Tas nozīmē, ka dienestiem nevajadzētu slēpt informāciju no vienas valsts uz otru. Tas būtu jādara no klienta lietojumprogrammas. Piemērs var būt pasūtījums, kas veikts iepirkšanās vietnē. Tagad jums var būt tīmekļa pakalpojums, kas norāda konkrētas preces cenu. Bet, ja preces tiek pievienotas iepirkumu grozam un tīmekļa lapa pāriet uz lapu, kurā veicat maksājumu, atbildību par preces lapu, kas jāpārsūta uz maksājumu lapu, tīmekļa dienestam nevajadzētu uzņemties. Tā vietā tas jādara tīmekļa lietojumprogrammai.
- Pakalpojuma atklājamība - pakalpojumus var atrast (parasti pakalpojumu reģistrā). Mēs to jau redzējām UDDI koncepcijā, kas veic reģistru, kurā var glabāt informāciju par tīmekļa pakalpojumu.
- Pakalpojumu saliekamība - pakalpojumi sadala lielas problēmas mazās problēmās. Nekad nevajadzētu iegult visas lietojumprogrammas funkcionalitātes vienā pakalpojumā, bet gan sadalīt pakalpojumu moduļos ar atsevišķu biznesa funkcionalitāti.
- Pakalpojumu sadarbspēja - pakalpojumiem jāizmanto standarti, kas ļauj dažādiem abonentiem izmantot pakalpojumu. Tīmekļa pakalpojumos tiek izmantoti XML standarti un komunikācija, izmantojot HTTP, lai nodrošinātu, ka tā atbilst šim principam.