Metodologii de Dezvoltare a Serviciilor Web – Dezvoltare de Aplicații Mobile, Servicii Web, Arhitectură SOA - Tehnologie
Sari la conținut

Metodologii pentru Dezvoltarea Serviciilor Web – Dezvoltarea Aplicațiilor Mobile, Servicii Web, Arhitectura SOA

Reclame

Coulouris a definit sistemele distribuite ca fiind „sisteme în care componentele hardware și/sau software existente într-o rețea de calculatoare comunică și își coordonează acțiunile prin schimbul de mesaje”.

Acest concept a devenit popular în ultimii ani datorită mai multor factori. Primul factor care a promovat dezvoltarea sistemelor distribuite a fost apariția rețelelor locale de mare viteză. Un alt factor important a fost progresul tehnologic în performanța calculatoarelor personale și dezvoltarea de software care să susțină aplicații distribuite. Sistemele distribuite sunt legate de conceptul de Web și Internet. Odată cu evoluția Web-ului, și apariția de noi zone, interacțiuni, nevoi și aplicații, apare conceptul de Web 2.0. Acest termen a fost inventat de Tim O'Reilly în 2004 pentru a se referi la o a doua generație din istoria Web-ului bazată pe comunități de utilizatori și o gamă specială de servicii, precum rețelele sociale, blogurile, wiki-urile sau folksonomiile, care încurajează colaborarea și rapiditatea. schimbul de informații între utilizatori.

Primele arhitecturi care pot fi considerate orientate pe servicii (SOA) s-au bazat pe CORBA (Common Object Request Broker Architecture), care a acționat ca un strat de abstractizare pentru a interconecta diferitele elemente ale arhitecturii și a construi servicii. Alte tehnologii anterioare au fost DCOM (Distributed Component Object Model) sau RPC (Remote Procedure Protocol). Odată cu necesitatea de a proiecta și implementa eficient sisteme distribuite pe Web, apar mai multe provocări, unele axate pe dezvoltarea în sine (performanță, experiență utilizator etc.) și altele complementare, bazate pe reutilizarea și compatibilitatea serviciilor. Din aceste nevoi apar Serviciile Web, care oferă mecanisme standardizate de interconectare a diferiților utilizatori cu servere de informații.

ARHITECTURILE ORIENTATE PE SERVICII

Conform SOA (Service Oriented Architecture) sunt arhitecturi software care definesc utilizarea serviciilor pentru a susține cerințele afacerii, al căror obiectiv este realizarea cât mai puțin posibilă de cuplare între agenții software. Un serviciu este o unitate de lucru efectuată de un furnizor de servicii pentru a obține un rezultat final dorit de un consumator de servicii. Atât furnizorul de servicii, cât și consumatorul de servicii sunt roluri jucate de agenții software, nu de proprietarii de software. Într-un sens general, o arhitectură orientată spre servicii este o soluție software menită să permită unei întreprinderi să organizeze și să utilizeze diferite procese. Cu SOA, aplicațiile software nu mai sunt blocuri masive de funcții și procese. În schimb, aceste aplicații sunt formate din servicii modulare asamblate. Amintiți-vă că un serviciu este o simplă funcție software (cum ar fi anularea unui CD). Poate fi rulat la cerere de orice sistem, indiferent de sistem de operare, platformă, limbaj de programare sau locație geografică.

Ceea ce este revoluționar la SOA nu este conceptul în sine, care există de mult timp, ci faptul că poate fi implementat pe WWW (World Wide Web). În același mod în care paginile web se încarcă pe orice platformă, serviciile web funcționează în mod similar, indiferent de platformă, pe măsură ce sunt construite folosind
standarde universale.

FotografieIdeea de SOA provine direct din programarea orientată pe obiecte, care sugerează o relație între date și procesarea acestora. Astfel, ei definesc în mod oficial serviciile prin interfețe care sunt independente de platforma de bază și limbajul de programare. Aceste interfețe ascund particularitățile implementării lor, ceea ce le face independente de dezvoltator și limbaj de programare. Prin aceste arhitecturi, este posibilă proiectarea și implementarea sistemelor extrem de scalabile care reflectă logica afacerii și, în același timp, facilitează interacțiunea între diferite sisteme proprietare sau terțe. Motivul pentru care ne dorim ca altcineva să facă treaba pentru noi este că sunt experți. Utilizarea unui serviciu este de obicei mai ieftină și mai eficientă decât a-l face singur. Deci, cei mai mulți dintre noi înțelegem că nu putem fi experți în orice. Aceeași regulă poate fi aplicată pentru construirea de sisteme software.

Interfețele sunt foarte importante, dacă nu sunt bine definite sau nu funcționează, sistemul nu funcționează. Integrarea mai multor interfețe este costisitoare și, de asemenea, crește potențialul de erori în aplicațiile distribuite. Interfețele de la distanță sunt cea mai lentă parte a celor mai multe aplicații distribuite. Cu toate acestea, în loc să construim noi interfețe pentru fiecare aplicație, este mai logic să reutilizați interfețele generice pentru toate aplicațiile.

Deci, deoarece avem doar câteva interfețe generice disponibile, trebuie să includem în mesaje semantică specifică aplicației. Putem trimite orice fel de mesaj prin interfețele noastre, dar există câteva reguli de urmat pentru a spune că o arhitectură este orientată spre servicii.

– În primul rând, mesajele trebuie să fie descriptive, nu instructive, deoarece furnizorul de servicii este responsabil pentru rezolvarea problemei. De exemplu, ar fi similar cu situația de a merge la restaurant și a-i spune ospătarului ce ai vrea să bei și preferințele tale, dar nu ar trebui să explicăm bucătarului cum să-ți pregătești preparatele, pas cu pas.

‐ În al doilea rând, furnizorii de servicii nu vor putea înțelege solicitarea dumneavoastră dacă mesajele lor nu sunt scrise într-un format, structură și vocabular ușor de înțeles de toți cei implicați. Astfel, limitarea vocabularului și structurii mesajelor este a
necesare unei comunicări eficiente. Cu cât mesajul este mai restrâns, cu atât mai ușor de înțeles.

- În al treilea rând, posibilitatea de extindere este de o importanță vitală. Lumea este un loc în continuă schimbare, la fel și mediul în care trăiește software-ul. Aceste modificări necesită modificări corespunzătoare în software-ul de sistem, consumatori de servicii, furnizori și mesajele pe care le schimbă. Dacă mesajele nu sunt extensibile, consumatorii și furnizorii sunt blocați la o anumită versiune a serviciului. Constrângerea și extensibilitatea sunt profund legate, aveți nevoie de amândouă, iar creșterea uneia înseamnă a reduce cealaltă. Ideal este realizarea unui echilibru corect.

– În al patrulea rând, o SOA trebuie să aibă un mecanism care să permită consumatorului să descopere un furnizor de servicii în contextul unui serviciu căutat de consumator. Mecanismul ar trebui să fie flexibil și nu un registru centralizat.

- În al cincilea rând, serviciul apatrid: Fiecare mesaj pe care un consumator îl trimite unui furnizor trebuie să conțină toate informațiile necesare pentru ca furnizorul să-l proceseze. Această restricție face un furnizor de servicii mai scalabil, deoarece furnizorul nu trebuie să stocheze informații despre stare între cereri. Acesta poate fi numit un „serviciu de producție în masă”, deoarece fiecare cerere poate fi tratată generic. Această restricție oferă, de asemenea, mai multă vizibilitate, deoarece orice software de monitorizare poate inspecta independent o solicitare și poate extrage intenția acesteia. Acest lucru permite, de asemenea, o recuperare ușoară după defecțiuni parțiale, deoarece nu există stări intermediare, ceea ce face serviciul mai fiabil.

- În al șaselea rând, cererile idempotente (fără modificări): cererile duplicate primite de un agent software au același efect ca o singură solicitare. Această cerință permite furnizorilor și consumatorilor să crească fiabilitatea globală a serviciu, pur și simplu repetând cererea dacă a existat vreo eșec.

Deci putem spune că SOA nu este un instrument, ci un set de standarde pentru construirea de noi aplicații, mai dinamice și mai puțin dependente. SOA facilitează accesul la logica de afaceri și la informații prin mai multe servicii într-un mod sistematic și poate, de asemenea, orchestra mai multe servicii la distanță pentru a compune unul singur. majoritatea definițiile identifică utilizarea Serviciilor Web, pe care o vom vedea în capitolul următor, în implementarea unei arhitecturi orientate pe servicii. Cu toate acestea, poate fi implementat folosind orice altă tehnologie bazată pe servicii.