Arhitectura orientata pe servicii (soa) si servicii web (WS) Cristian Alexandru Pop

Arhitectura orientata pe servicii (SOA) si servicii web (WS)

Cristian Alexandru Pop

Inginerie software

Cuprins

1.Introducere 3

2.Arhitectura orientata pe servicii(SOA) 5

2.1Definitie 5

2.2Aspecte 6

2.3Integrarea SOA intr-un business 7

3.Servicii web 9

3.1Definitie 9

3.2Caracteristici 9

3.3Specificatii 10

4.Concluzii 12

5.Bibliografie 14

1. Introducere

Orice produs software de o dimensiune cel putin medie este facut pe baza unei arhitecturi software. Aceasta este o abstractizare high-level a structurii unuia sau mai multor sisteme software, impreuna cu documentatia aferenta lor. O astfel de structura trebuie sa defineasca elemente software, relatiile dintre acestea si proprietatiile lor.

Este numita arhitectura software, deoarece este reprezentarea in domeniul software a modalitatiile de proiectare a unei entitati. Asa cum arhitectura conventionala este folosita pentru a crea cladiri, asa si arhitectura software este folosita pentru a crea si defini scheletul unui sistem software. Odata implementat, un sistem software nu isi poate schimba arhitectura decat printr-un proces foarte costisitor, din punct de vedere al banilor si al timpului investit.
De cateva decenii, cei care lucreaza in IT incearca sa dezvolte arhitecturi sofware care sa poata tine pasul cu complexitatea software-ului, aflat in continua crestere. Arhitecturile traditionale nu asigura rezolvarea cu usurinta a problemelor din zilele acestea:

• 
  Adaugarea/modificarea cerintelor de business
  
• 
  Reducerea costului IT
  
• 
  Abilitatea de a absorbi si integra noi parteneri
  
• 
  Etc.
  

Aceasta industrie a condus la aparitia mai multor arhitecturi software, care au fost facute sa asigure procesare distribuita totala si utilizarea unor limbaje de programare care sa ruleze pe orice platforma, sa reduca substantial timpul de dezvoltare al aplicatiilor si sa produca o vasta gama de produse care sa faciliteze conectivitatea si integrarea aplicatiilor.

Un pattern arhitectural este o solutie generala/reutilizabila a unei probleme software comune intr-un anumit context. Un stil arhitectural defineste o familie de sisteme in ceea ce priveste organizarea structurala, componentele, conectorii si constrangerile dintre acestia.
Stiluri si pattern-uri arhitecturale[1] :

• 
  Blackboard
  
• 
  Client-server
  
• 
  CBSE
  
• 
  Data-centric
  
• 
  Event-driven
  
• 
  Layered architecture
  
• 
  Monolithic application
  
• 
  Peer-to-peer
  
• 
  Pipes and filters
  
• 
  Plugins
  
• 
  REST
  
• 
  Rule-based
  
• 
  Service oriented
  
• 
  Microservice oriented
  
• 
  Space-based
  

Coordonatorii de proiecte au avut mereu de rezolvat problema reducerii costurilor si maximizarea utilizarii tehnologiei existente, dar in acelasi timp acestia trebuiau sa se asigure ca produsele lor sunt conform cerintelor clientilor, ca prioritizeaza strategia de business si ca ofera competivitate altor dezvoltatori de sisteme software. Toate acestea sunt determinate de eterogenitate si schimbare[3].

Majoritatea intreprinderilor din zilele acestea folosesc diferite sisteme/aplicatii care sunt facute pe baza unor arhitecturi software diferite si pe baza unor tehnologii diferite. Integrarea unor produse provenite de la mai multi furnizori pe mai multe platforme a fost mereu un cosmar pentru orice dezvoltator software. O abordare care rezolva aceste probleme ar fi achizitionarea de sisteme software de la un singur furnizor, toate fiind bazate pe aceleasi tehnologii, insa niciodata aceasta nu va fi luata in considerare, deoarece niciun furnizor nu poate singur sa asigure o gama completa de servicii pentru o intreprindere cu activitate complexa.
Globalizarea si e-business-ul accelereaza pasul de schimbare in domeniul IT. Globalizarea duce la aparitia unei competitii mult mai mare in orice sector IT, apoi durata de viata a produselor scade, deoarece orice companie incearca sa obtina un avantaj fata de competitorii ei si sa dezvolte noi sisteme cat mai bune. Nevoile si cerintele clientilor sunt intr-o continua schimbare, fapt ce accelereaza si mai mult nevoia de schimbare in IT. Orice afacere trebuie sa se adapteze rapid si sa foloseasca o infrastructura predispusa la schimbari pentru a putea supravietui pe piata IT.
Ca un rezultat, infrastructura sistemelor software s-a schimbat de la izolarea pe vericala a sistemelor din anii 1980, la cea orizontala, la ecosistemele de date folosite in prezent.


Figura 1. Evolutia infrastructurii [3]

2. Arhitectura orientata pe servicii(SOA)

   1. Definitie

Arhitectura orientata pe servicii prezinta o abordare de construire a unor sisteme distribuite care livreaza functionalitate ca servicii atat la utilizatorul tinta cat si la alte servicii. Practic acest stil arhitectural permite transformarea unei sistem intr-un set de servicii inlantuite sau task-uri de business, care pot fi accesate oricand printr-o retea. Aceasta poate fi atat locala cat si internetul sau poate fi chiar divizata tehnologic cuprinzand servicii hostate la locatii diferite.

SOA este evolutia sistemelor de calcul distribuite bazate pe mecanismul de comunicare request/reply sincron si asincron. Logica de business si functionalitatiile unei aplicatii sunt modularizate si prezentate sub forma unor servicii.
Un bun exemplu al unei aplicatii care este facuta dupa arhitectura orintata pe servicii ar fi orice aplicatie mare, care foloseste serviciile web de la Amazon. Aceasta ar avea instante de servere diferite pentru logica de business, pentru persistarea datelor, pentru load balancing, etc. Fiecare server furnizeaza un serviciu unic, in functie de rolul sau. Implementarea acestor servicii nu trebuie sa conteze, ele pot fi implementate in .Net sau J2EE si aplicatia care consuma serviciile sa fie facuta pe baza unei alte platforme, dar ele trebuie sa poata comunica si sa indeplineasca scopul final al aplicatiei.
In figura de mai jos, putem observa principiul care sta la baza unei astfel de arhitecturi: un service provider si un service consumer comunica prin mesaje pentru a rezolva o anumita cerinta de business. Consumer-ul trimite un request la provider. Acesta efectueaza procesarea necesara indeplinirii actiunii specificate in request si trimite inapoi un response. Consumer-ul primeste response-ul si il poate folosi ca un element de intrare pentru propria procesare sau il poate afisa direct utilizatorului. Deci, un service provider poate fi de asemenea si un service consumer. Comunicarea se poate face intr-o retea, dupa cum am specificat anterior.


Figura 2. Principiul de functionare al SOA

2. Aspecte

SOA cuprinde elemente care pot fi categorizate in:

• 
  Functionale
  
• 
  QoS (quality os service)
  

Figura 2. Elementele SOA [3]

Aspecte functionale [3]:

• 
  Transport: mecanismul folosit pentru a trimite mesaje (request/reply) de la provider la consumer, respectiv de la consumer la provider
  
• 
  Service Communication Protocol: este un mecanism de acord intre serviciul provider si cel consumer folosit pentru a comunica ce este cerut si ce este returnat
  
• 
  Service Description: este o schema care descrie ce este serviciul repectiv, cum trebuie el invocat/apelat si ce fel de informatie este necesara pentru a efectua cu succes un call la acel serviciu
  
• 
  Service: descrie serviciul care este facut disponibil
  
• 
  Business process: este o colectie de servicii, apelate intr-o secventa particulara cu un anumit set de reguli, pentru a indeplini o cerinta de business. Acesta poate fi considerat ca un serviciu distinct, de aceea apare idea ca procesele de business pot fi compuse din servicii de granularitati diferite.
  
• 
  Service Registry: un depozit de servicii si descriptori de informatii care pot fi folositi de catre providerii de servicii pentru a isi publica serviciile si de catre consumerii de servicii pentru a le descoperii. Registrul poate furniza si alte functii speciale serviciilor care au nevoie de un repository centralizat.
  

Aspecte de calitate:

• 
  Policy: este set de conditii sau reguli pe care un service provider trebuie sa le respecte cand face disponibil un serviciu catre consumeri.
  
• 
  Security: este un set de reguli care pot fi folosite la identificarea, autorizarea si controlul accesului la servicii pentru consumeri
  
• 
  Transaction: este un set de atribute care pot fi aplicate unui grup de servicii pentru a livra un rezultat consistent. Exemplu: daca un grup de servicii este cuprins din doua sau mai multe servicii si este folosit pentru a indeplini o functie de business, atunci toate seviciile trebuie sa isi poata efectua activitatea si in cazul in care unul a esuat rezultatele colectate de la restul nu vor fi luate in considerare
  
• 
  Management: este un set de atribute care ar putea fi aplicate pentru a organiza serviciile care vor produce informatii si cele care le vor consuma.
  

3. Integrarea SOA intr-un business

Cei de la IBM au identificat 5 puncte cheie, bazate pe experinte reale cu clienti, care au rolul de a imbunatatii activitatea unei business prin folosirea unei solutii SOA in ceea ce priveste cerintele software. Fiecare dintre acestea este cuplat cu un scenariu sau abordare care implementeaza o anumita tehnologie [6].

Puncte cheie:

• 
  Oamenii: acest punct se bazeaza pe experienta utilizatorului in colaborare, interactiunea consistenta dintre oameni sau procese, astfel imbunatatind productivitatea
  
• 
  Procesul: acesta ajuta companiile sa urmareasca ce se intampla in cadrul propriei activitati, putand astfel sa isi imbunatateasca modelul de business
  
• 
  Informatia: se pot urmarii informatiile intr-un mod consistent si vizibil pentru a determina ce zone ale afacerii au nevoie de inovare sau chiar se pot descoperii relatii intre anumite departamente
  
• 
  Conectivitatea: se poate folosi infranstructura pentru a conecta oameni, procesele si informatiile companiei. Avand conexiuni SOA flexibile intre servicii, se poate lua un proces de business si se poate livra fara efort la departamente care au nevoie de procesul respectiv.
  
• 
  Refolosirea serviciilor: permite folosirea unor resurse deja existente pentru a crea un nou software si pentru a asigura consistenta in cadrul companiei. Astfel, se pot salva bani si timp de development. Totodata, nu va mai exista problema duplicarii functionalitatii de la o aplicatie la alta, deoarece toate vor functiona pe aceeasi platforma.
  

Figura 2. Puncte cheie

Scenarii:

• 
  Crearea serviciilor: ele trebuie sa fie flexibile si reutilizabile, bazate pe un anumit comportament al business-ului
  
• 
  Conectivitatea serviciilor: legarea oamenilor, proceselor si a informatiei intr-un flow continuu de mesaje care pot fi accesate de oriunde, oricand
  
• 
  Interactiunea si colaborarea serviciilor: serviciile trebuie sa poata fi accesate prin diferite dispozitive: bowser, PC, mobile
  
• 
  Management-ul procesului de business: combinarea capabilitatilor software cu expertiza de business pentru a accelera procesul de imbunatatire si a facilita inovarea business-ului
  
• 
  Informatia ca serviciu: ofera accesul la informatii prin structuri de date eterogene
  
• 
  SOA design: alinierea modelului de business si solutii IT la un set de regului, metode si artefacte
  
• 
  Administrarea SOA: stabileste si impune development-ul SOA si procesul de runtime. Defineste reguli, procese si unelte care pot observa cine detine un serviciu, cine il poate folosi, cum poate el fi folosit si cand va fi disponibil la departamente care au nevoie de acesta.
  
• 
  Securitatea si management-ul SOA: descoperirea, monitorizarea, securizarea, schimbarea si ciclul de viata al serviciior ca parte a ITSM (IT Service Management).
  

3. Servicii web

   1. Definitie

Un serviciu web este o aplicatie software definita de un URI, a carei interfata si legaturi pot fi definite, descrise si descoperite ca artefacte XML. Un serviciu web suporta interactiuni directe cu alti agenti software folosind mesaje bazate pe XML, comunicarea fiind facuta prin protocoale bazate pe internet.
Serviciile web de baza combina puterea a doua tehnologii: XML si HTTP.

Web service = XML + tranport protocol (HTTP)

2. Caracteristici

Serviciile web [3]:

• 
  Sunt autonome: pe partea client nu este nevoie de niciun software aditional. Un limbaj de programare cu XML si support HTTP este destul pentru a realiza comunicarea cu serviciul in cauza. Pe partea server este suficient un server web si un servlet care sa puna la dispozitie functionalitatea dorita.
  
• 
  Sunt auto-descriptive: nici server-ul, nici clientul nu stiu nimic in afara de formatul si continutul mesajelor trimise si receptionate => cuplare mica
  
• 
  Sunt modulare: practic serviciile web sunt tehnologii pentru a face deploy si a da acces la functionalitati de business prin internet, ele pot fi implementate folosind J2EE, CORBA sau alte tehnologii standard
  
• 
  Pot fi publicate, localizate si accesate prin internet:
  

Standardele folosite pentru a putea face acestea sunt:

• 
  Simple Object Access Protocol (SOAP): un RPC bazat pe XML si protocol de transmitere/receptionare mesaje
  
• 
  Web Service Description Langage (WSDL): este limbajul standard folosit pentru a descrie servicii. Acestea dispun de interfete auto-definitorii care sunt definite in documente XML independente de platforma.
  
• 
  Universal Description, Definition and Integration (UDDI), un registru care poate fi folosit pentru a identifica si invoca un serviciu
  

• 
  Sunt independente si interoperabile de limbajul de programare folosit: interactiunea dinte provider-ul de servicii si consumer este facuta astfel incat sa fie complet independenta de limbaj si plaforma. Aceasta interactiune necesita un document WSDL pentru a defini interfata si a descrie serviciul, impreuna cu un protocol de internet (HTTP). Interoperabilitatea este atinsa deoarece provider-ul si consumer-ul nu stiu ce platforma sau limbaj foloseste celalalt.
  
• 
  Sunt deschise si bazate pe standarde: XML si HTTP sunt fundatia tehnica pentru serviciile web. O mare parte a acestora a fost facuta pe baza unor proiecte open-source.
  
• 
  Sunt dinamice: folosind UDDI si WSDL decrierea si descoperirea serviciilor web poate fi automatizata
  
• 
  Sunt compensabile: serviciile web pot fi aggregate pentru a alcatui noi servicii mai complexe
  

Diferite servicii pot fi folosite in conjunctie pentru a asigura functionalitatea unei aplicatii software mari. Arhitectura orientata pe servicii nu tine cont de modularizarea unei aplicatii, ci de modalitatea de a compune o aplicatie prin integrarea unor servicii distribuite/componente software.

Figura 3. Colaborarea serviciilor web [3]

3. Specificatii

Exista 3 specificatii ale serviciilor web [8]:

• 
  SOAP
  
• 
  REST
  
• 
  JSON
  

SOAP (Simple Object Access Protocol):

• 
  a fost original parte a specificatiti care includea WSDL si UDDI
  
• 
  acum este folosit fara acestea: nu mai este nevoie de identificarea serviciului si mesajele SOAP sunt harcode-ate sau generate fara un repository
  

Figura 3. Interactiune SOAP

REST (Representation State Transfer):

• 
  este mai folosit de developeri
  
• 
  are un stil mai simplu
  
• 
  este mai usor de folosit decat SOAP
  
• 
  se trimite un volum de date mai mic pentru comunicare
  

Figura 3. Interactiune REST

JSON (JavaScript Object Notation):

• 
  primele doua specificatii folosesc XML pentru comunicare, acesta foloseste un subset de JavaScript
  

Figura 3. Interactiune JSON

4. Concluzii

Desi conceptul de SOA nu este fundamental nou, el difera de tehnologiile distribuite existente prin faptul ca furnizorii o accepta si trebuie sa aiba o aplicatie sau o platforma care sa permita lucrul cu SOA. Arhitectura orientata pe servicii defineste un set omniprezent de standarde care asigura o mai buna reutilizare a bunurilor si investitiilor existente in intreprindere si permite crearea aplicatiilor peste unele noi sau care exista deja.

Aceasta defineste urmatoarea generatie de arhitectura software prin acceptarea provocarii aduse de unirea business-ului cu nevoile tehnologice ale unui sistem. Tinta este crearea unor solutii de business mai eficiente, prin utilizarea acestei paradigme.
SOA permite efectuarea de schimbari la aplicatii, tinand clientii sau consumerii izolati schimbarile aparute in implementare (black-box, niciun consumer nu poate vedea implementarea efectiva a serviciului, ci doar API-ul acestuia). Totodata, permite upgradarea serviciilor individuale sau a serviciilor pentru clienti. Nu este necesar sa se rescrie complet o aplicatie sau sa se tina un sistem existent care nu se adreseaza la o noua cerinta de business.
Arhitectura orientata pe servicii ofera o flexibilitate mai buna in construirea aplicatiilor si a proceselor de business, asigurand o maniera de management agila si se poate folosi de infrastructura aplicatiilor existente pentru a compune noi servicii. Acestea pot fi identificate folosind UDDI si pot fi accesate conform API-ului lor specific, identificat de WSDL. Dezvoltarea, asumarea costurilor si riscurile de implementare sunt scazute. SOA este si o arhitectura si un model de programare, o noua modalitate de a construi un software de buna calitate.
SOA asigura crearea unor componete reutilizabile, o incapsulare totala a serviciilor, o cuplare mica a acestora (serviile nu depind unele de altele), se pot atinge diverse nivele de granularitate a serviciilor si datorita independentei platformei folosite se pot integra numeroase servicii folosind limbaje de programare diferite.
Paradigma separarii serviciilor in aplicatii separate este dusa la extrem de o variatie a arhitecturii orientate pe servicii, si anume micro-serviciile [7]. Acesta este implementarea moderna a SOA si reprezinta procese care comunica intr-o retea pentru a indeplinii un anumit scop. Acestea folosesc protocoale agnostice care ajuta la incapsularea limbajelor de programare si a framework-urilor folosite.

5. Bibliografie

1. 
   Arhitectura software, https://en.wikipedia.org/wiki/Software_architecture#Characteristics
   
2. 
   Arhitectura orientata pe servicii pentru e-business, http://ubiquity.acm.org/article.cfm?id=1159403
   
3. 
   Pattern-uri: Arhitectura orientata pe servicii si servicii web, http://sske.cloud.upb.ro/sskemw/images/0/00/Patterns_Service-Oriented_Architecture_and_Web_Services.pdf
   
4. 
   O introducere in SOA, https://www.javaworld.com/article/2071889/soa/what-is-service-oriented-architecture.html
   
5. 
   Definirea SOA, https://www.service-architecture.com/articles/web-services/service-oriented_architecture_soa_definition.html
   
6. 
   Nou in SOA si servicii web, https://www.ibm.com/developerworks/webservices/newto/index.html
   
7. 
   Microservicii, https://en.wikipedia.org/wiki/Microservices
   
8. 
   Servicii web, https://www.service-architecture.com/articles/web-services/web_services_explained.html