O arhitectură orientată spre servicii (SOA) este un model arhitectural în proiectarea software-ului computerului în care componentele aplicației furnizează servicii către alte componente printr-un protocol de comunicații, de obicei pe o rețea. Principiile orientării către servicii sunt independente de orice produs, furnizor sau tehnologie.
SOA simplifică lucrul între componentele software din diferite rețele.
Serviciile web construite conform arhitecturii SOA tind să facă serviciul web mai independent. Serviciile web în sine pot face schimb de date între ele și, din cauza principiilor de bază pe care sunt create, nu au nevoie de niciun fel de interacțiune umană și, de asemenea, nu au nevoie de modificări de cod. Se asigură că serviciile web dintr-o rețea pot interacționa între ele fără probleme.
SOA se bazează pe câteva principii cheie menționate mai jos
- Contract de servicii standardizat - Serviciile aderă la o descriere a serviciului. Un serviciu trebuie să aibă un fel de descriere care descrie despre ce este vorba. Acest lucru face mai ușor pentru aplicațiile client să înțeleagă ce face serviciul.
- Cuplare slabă - Dependență mai mică una de cealaltă. Aceasta este una dintre caracteristicile principale ale serviciilor web, care afirmă doar că ar trebui să existe o dependență cât mai mică posibilă între serviciile web și clientul care invocă serviciul web. Deci, dacă funcționalitatea serviciului se schimbă în orice moment, nu ar trebui să întrerupă aplicația client sau să o oprească din funcționare.
- Abstracție de servicii - Serviciile ascund logica pe care o încapsulează din lumea exterioară. Serviciul nu ar trebui să expună modul în care își execută funcționalitatea; ar trebui doar să spună aplicației clientului despre ce face și nu despre cum o face.
- Reutilizarea serviciilor - Logica este împărțită în servicii cu intenția de a maximiza refolosirea. Reutilizarea în orice companie de dezvoltare este un subiect important, deoarece, evident, nu s-ar dori să cheltuiți timp și efort construind același cod din nou și din nou în mai multe aplicații care le necesită. Prin urmare, odată ce codul pentru un serviciu web este scris, acesta ar trebui să aibă capacitatea de a lucra cu diferite tipuri de aplicații.
- Autonomia serviciilor - Serviciile ar trebui să aibă control asupra logicii pe care o încapsulează. Serviciul știe totul despre funcționalitatea pe care o oferă și, prin urmare, ar trebui să aibă, de asemenea, control complet asupra codului pe care îl conține.
- Apatridia serviciului - În mod ideal, serviciile ar trebui să fie apatrid. Aceasta înseamnă că serviciile nu ar trebui să rețină informații de la un stat la altul. Acest lucru ar trebui făcut fie din aplicația client. Un exemplu poate fi o comandă plasată pe un site de cumpărături. Acum puteți avea un serviciu web care vă oferă prețul unui anumit articol. Dar dacă articolele sunt adăugate într-un coș de cumpărături și pagina web navighează către pagina în care efectuați plata, responsabilitatea prețului articolului care urmează să fie transferat pe pagina de plată nu ar trebui să o facă serviciul web. În schimb, trebuie realizat de aplicația web.
- Descoperire servicii - Serviciile pot fi descoperite (de obicei într-un registru de servicii). Am văzut deja acest lucru în conceptul UDDI, care efectuează un registru care poate conține informații despre serviciul web.
- Compozibilitatea serviciilor - Serviciile împart mari probleme în mici probleme. Nu trebuie să încorporați niciodată toate funcționalitățile unei aplicații într-un singur serviciu, ci, în schimb, să împărțiți serviciul în module fiecare cu o funcționalitate de afaceri separată.
- Interoperabilitatea serviciului - Serviciile ar trebui să utilizeze standarde care să permită abonaților diferiți să utilizeze serviciul. În serviciile web, standardele precum XML și comunicarea prin HTTP sunt utilizate pentru a se asigura că este conform cu acest principiu.