Ce este SOA? Orientat spre servicii ArchiPrincipii de tectură

SOA doar face mai ușor pentru componentele software din diferite rețele să lucreze între ele.

Serviciile web care sunt 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 care stau la baza cărora 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.

Orientat spre servicii Archiprincipii (SOA).

Există 9 tipuri de principii de proiectare SOA care sunt menționate mai jos

1. Contract de servicii standardizat

Serviciile respectă o descriere a serviciului. Un serviciu trebuie să aibă un fel de descriere care să descrie despre ce este vorba. Acest lucru face ca aplicațiile client să înțeleagă mai ușor ce face serviciul.

2. Cuplaj liber

Less dependenta unul de altul. Aceasta este una dintre principalele caracteristici ale serviciilor web care afirmă doar că ar trebui să existe cât mai puțină dependență posibil între serviciile web și clientul care invocă serviciul web. Deci, dacă funcționalitatea serviciului se modifică în orice moment, nu ar trebui să rupă aplicația client sau să o oprească să funcționeze.

3. Abstracția serviciului

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 să spună aplicației client ce face și nu cum o face.

4. Reutilizarea serviciului

Logica este împărțită în servicii cu intenția de a maximiza reutilizarea. În orice companie de dezvoltare, reutilizarea este un subiect important, deoarece, evident, nu ar dori să petreceți timp și efort pentru a construi 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 funcționa cu diferite tipuri de aplicații.

5. Autonomie de serviciu

Serviciile ar trebui să aibă control asupra logicii pe care o încapsulează. Serviciul știe totul despre funcționalitățile pe care le oferă și, prin urmare, ar trebui să aibă și control complet asupra codului pe care îl conține.

6. Apatridia de serviciu

În mod ideal, serviciile ar trebui să fie apatride. 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ă la pagina în care efectuați plata, responsabilitatea prețului articolului care urmează să fie transferat către pagina de plată nu ar trebui să fie făcută de serviciul web. În schimb, trebuie făcută de aplicația web.

7. Descoperirea serviciului

Serviciile pot fi descoperite (de obicei într-un registru de servicii). Am văzut deja acest lucru în conceptul UDDI, care realizează un registru care poate deține informații despre serviciul web.

8. Compabilitatea serviciului

Serviciile despart marile probleme în mici probleme. Nu ar trebui niciodată să încorporați toate funcționalitățile unei aplicații într-un singur serviciu, ci, în schimb, împărțiți serviciul în module, fiecare cu o funcționalitate de afaceri separată.

9. Interoperabilitatea serviciului

Serviciile ar trebui să utilizeze standarde care permit diverșilor abonați să utilizeze serviciul. În serviciile web, standardele ca XML iar comunicarea prin HTTP este folosită pentru a se asigura că respectă acest principiu.