Pagina 1

T3. SOA & WS

S ervice O riented A rchitectures &
W eb S ervicii [ C7 ]

3.1 SOA: Arhitecturi orientate spre servicii

3.2 Servicii web REST

Dezvoltare software multi-nivel

Dezvoltarea Aplicațiilor Multistrat

Pagina 2

Capitolul 3. Orientat spre servicii

Arhitecturi și servicii web

Curs_7

Pagina 3

Agenda Capitolul 3

● 3.1 SOA: Arhitecturi orientate spre servicii

○ Calcul orientat spre servicii
○ Principiile de proiectare SOA
○ Tipuri de servicii
○ Stiluri de servicii:
■ RPC.API, Resource API, Message API
■ Stiluri de servicii web: SOAP vs REST
● 3.2 Servicii Web REST
○ HTTP.APIs: RPC vs. RESTful
○ Principiile arhitecturale ale REST
○ Anatomie simplă a serviciului REST:
■ Obiecte de transfer de date și documente de resurse
■ Furnizori de servicii
3

Pagina 4

3.1 S ervice O riented A rchitectures

● S ervice O riented Computing Prezentare generală

○ Tipuri de aplicații pentru întreprinderi:
■ Monoliti
■ Bazat pe componente
■ Bazat pe servicii
○ Calcul orientat spre servicii - termeni specifici:
■ Arhitectură orientată spre servicii
■ Paradigma de proiectare orientată spre servicii
■ Logică soluție orientată spre servicii
■ Servicii
■ Compoziția serviciului
■ Inventarul de servicii

Pagina 5
Elemente de calcul orientate spre servicii

Pagina 6

Principiile de proiectare SOA

1) Contracte de servicii
2) Cuplaj liber de service
3) Abstracția serviciului
4) Reutilizarea serviciului
5) Autonomie de serviciu
6) Apatridia serviciului
7) Descoperirea serviciilor
8) Compozibilitatea serviciului

Pagina 7

Principiile de proiectare SOA

Pagina 8

Contracte de servicii
Standardizare și proiectare

● Contractele de servicii vor stabili:

○ Termeni de angajament.
○ Constrângeri tehnice și cerințe.
● Contractul de servicii constă în:
○ Descrieri de servicii: tehnice și non-tehnice
● Serviciile partajează contracte standardizate
○ „Serviciile din același inventar de servicii sunt în
respectarea acelorași standarde de proiectare a contractului. ”*
● Obiective:
○ Obțineți un nivel semnificativ de interoperabilitate.
○ Capacitatea serviciului de a fi înțeleasă intuitiv.

* Referință: Erl, Thomas, SOA: principiile proiectării serviciilor , PRENTICE HALL, 2008
8

Pagina 9

Cuplaj slab de service

Dependențe intra-servicii și consumatori

● Cuplarea reprezintă conexiunea și relațiile

între 2 componente.
● Nivelul de cuplare ~ Nivelul de dependență:
■ Cuplaj scăzut / slăbit.
■ Cuplaj ridicat.

● Serviciile sunt cuplate slab:

○ „Contractele de servicii impun o cuplare redusă a consumatorilor
cerințele și sunt ele însele decuplate de ale lor
medii înconjurătoare. ”
● Obiective: reduce cuplajul.

Pagina 10

Abstracție de serviciu
Ascunderea informațiilor și tipuri de meta-abstractizare

● Abstracție înseamnă ascunderea implementării serviciului și

detalii de proiectare.
● Informațiile despre servicii neesențiale sunt ascunse:
○ „Contractele de servicii conțin doar informații esențiale și
informațiile despre servicii sunt limitate la ceea ce este publicat
în contractele de servicii. ”
● Obiective:
○ Pentru a preveni accesul inutil la detaliile serviciului
care va crește nivelul de cuplare.

10

Pagina 11

Reutilizarea serviciului
Proiectare comercială și agnostică

● Faceți utilă capacitățile de servicii pentru mai mult de unul

scop / consumator.
● Serviciile sunt reutilizabile
○ „Serviciile conțin și exprimă logica agnostică și pot fi
poziționate ca resurse reutilizabile ale întreprinderii . ”
● Obiective:
○ Pentru a valorifica utilitatea serviciului.
○ Pentru a crește rentabilitatea investiției (returnarea investiției).

11

Pagina 12

Autonomia serviciului
Prelucrarea limitelor și controlul

● Autonomia reprezintă capacitatea de auto-guvernare:

capacitatea de a acționa independent .
○ Autonomie de execuție (execuție).
○ Autonomie în timp de proiectare (guvernare).
● Serviciile sunt autonome
○ „Serviciile exercită un nivel ridicat de control asupra lor
mediu de execuție care se află în runtime. ”
● Obiective:
○ Sporiți fiabilitatea executării serviciului.

12

Pagina 13

Serviciu de apatridie
Design apatrid

● Managementul de stat reprezintă managementul

date temporare, specifice activității / sesiunii:
○ Amânare : mutarea temporară a informațiilor de stat.
○ Delegație : activarea responsabilității statului
management către o altă componentă a arhitecturii.
● Serviciile minimizează starea de stare:
○ „Serviciile reduc consumul de resurse prin amânarea
gestionarea informațiilor de stat atunci când este necesar. ”
● Obiective:
○ Pentru a crește scalabilitatea.
○ Pentru a îmbunătăți proiectarea serviciilor agnostice.
○ Pentru a îmbunătăți refolosirea serviciului.

13

Pagina 14

Descoperirea serviciilor
Interpretabilitate și comunicare

● Ipotezele de descoperire constau în:

○ Comunicarea informațiilor despre resurse abstracte:
meta-informații.
○ Management centralizat al meta-informațiilor și
documentație (cataloage de servicii).
○ Format consistent pentru meta-informații partajate.
○ Acces la meta-informații (centralizate).
● Serviciile pot fi descoperite:
○ „Serviciile sunt completate cu metadate comunicative
prin care pot fi descoperite și interpretate în mod eficient. ”
● Obiective:
○ Serviciile sunt resurse extrem de descoperibile.
○ Descriere clară și consecventă a serviciilor descoperibile.
14

Pagina 15

Compozibilitatea serviciului : Compoziție

Proiectarea membrilor și compoziții complexe

● Agregarea componentelor presupune componenta

descompunerea pentru a recompune noi
configurații.
● Serviciile sunt compozibile:
○ „Serviciile sunt participanți efectivi la compoziție,
indiferent de dimensiunea și complexitatea compoziției. ”
● Obiective:
○ Pentru a valorifica reutilizarea serviciului .
○ Pentru a crește extensibilitatea viitoare a serviciilor.

15

Pagina 16

Tipuri comune de servicii

în cadrul arhitecturilor orientate spre servicii

● Servicii de orchestrare (Solution Logic).

● Servicii de sarcini (logică de afaceri).
● Servicii entitate (date).
● Servicii utilitare.

16

Pagina 17

Tipuri de servicii

17

Pagina 18

Studiu de caz:
Colaborare pentru servicii de afaceri

● Proiectare colaborare:
○ PlanningProjectBusinessWorkflowService [Compus
Serviciu]
○ ConsolidatingProjectCurrentReleaseViewDomainService
[Serviciul de activități]
○ AuditingPlanificareProiectBusinessWorkflowService
[Serviciul de activități]
○ ProjectEntityRepository [Serviciul entității]
○ ProjectEntityFactory [Serviciul utilitar]
● Strategii practice de implementare:
○ Caz_1: colaborare fațadă locală
○ Caz_2: colaborare la distanță fațadă HTTP (ca HTTP
Servicii de primăvară)
18

Pagina 19

Stiluri comune de servicii

● Stiluri arhitecturale :
○ API RPC: Apel de procesare la distanță.
○ API de resurse: gestionarea resurselor.
○ Mesaj API: comunicare asincronă.

● Stiluri de implementare :
○ Comunicare la distanță HTTP | RMI (stilul serviciilor de primăvară)
○ Mesaje HTTP (stil REST *).
○ Mesaje Simple Object Access Protocol (SOAP).
○ Mesaje Java Messaging Services (JMS).
○ Mesaje SMTP (Simple Mail Transfer Protocol).

* Transfer reprezentativ de stat - REST

19

Pagina 20

Stiluri de servicii web

● SOAP: Protocol simplu de acces la obiecte
● REST: Transfer reprezentativ de stat

20

Pagina 21

3.2 REST Web Services ca API-uri HTTP

● API-ul REST.RPC definește Apel de procesare la distanță prin HTTP

(ca în SOA: Task Services, Utility Services, Orchestrated
Servicii ):
○ URL-urile sunt puncte finale pentru metodele de pe server.
○ API de acces constă în:
■ Acțiuni GET și POST HTTP
○ Parametri IN pentru a trimite DTO-uri:
■ codificat în acțiuni GET: solicitați adresa URL
segmente-cale / anteturi / cookie-uri
■ codificat în acțiuni POST: Corpul cererii
○ Parametrii OUT pentru a primi DTO-uri:
■ codificat în Response Body.

21

Pagina 22

REST Servicii Web ca API-uri HTTP

● REST.Resource API definește resursele accesibile (ca în

SOA: entități din serviciile entității )
○ Structurile de date ale resurselor sunt definite ca:
■ Reprezentări de entități JSON / XML (de ex. Din
Bază de date);
■ Fișiere media;
■ Fișiere .txt simple.
○ Resource Access API definește manipularea resurselor:
CRUD prin acțiuni HTTP:
■ Creați-POST,
■ Read-GET,
■ Update-PUT,
■ Șterge-ȘTERGE.
22

Pagina 23

Principiile arhitecturale ale

Servicii Web REST

● Resurse și URI-uri :
○ resursele sunt piesa centrală a arhitecturilor REST: ar putea fi
structuri bazate pe date (sau servicii pure de procesare);
○ resursele trebuie să aibă identificatori unici pe bază de web ca URI-uri.
● Reprezentări :
○ o resursă ar avea o singură stare, dar ar putea fi accesibilă
cu mai multe formate : XML, JSON, HTML, CSV, XLS, TXT.
● Adresabilitate :
○ fiecare informație sau funcționalitate valoroasă a unui serviciu web
aplicația ar trebui să fie accesibilă ca resursă cu un URI;
○ URI-urile și reprezentările accesibile publicului ar trebui să acopere toate
acțiuni posibile pe resursele web ca API CRUD.

23

Pagina 24

Principiile arhitecturale ale REST Web

Servicii

● Conectivitate :
○ dependențe de resurse (funcționale sau compoziție de date
dependențe) ar trebui descrise ca un grafic de legătură cu
HTTP-URI-uri;
○ reprezentările accesibile publicului ar trebui să acopere toate linkurile către
alte resurse conexe: API-ul de localizare a graficului.
● Interfață uniformă :
○ Resursele și serviciile trebuie gestionate în același mod de către
o interfață uniformă : folosind elementele protocolului HTTP.
● Apatridia :
○ Serverul nu ar trebui să gestioneze sesiunile din partea clientului: resursă
statele se află pe server și vor fi partajate de clienți, așa că
că starea cererii rămâne pe responsabilitatea clientului .

24

Pagina 25

Principiile REST vs. Principiile SOA

Principiile SOA Principiile REST

Contracte de servicii Interfață uniformă

Cuplaj de serviciu URI-uri (link-uri URI - URL-uri)

Conectivitate

Abstracție de serviciu Reprezentarea resurselor (formate)

Reutilizarea serviciului Resurse și interfață uniformă

Autonomia serviciului (Arhitecturi Microservice)

Serviciu de apatridie Apatridia

Descoperirea serviciilor Adresabilitate și conexiune

Compozibilitatea serviciului Conectare și URI-uri

25

Pagina 26

Anatomie simplă a serviciului REST

Componente pentru serviciul de date Rest

● Fațadă de servicii (web) :

○ API URL resursă rest-xml / json ;
● Implementarea serviciului (web) :
○ entități de domeniu cu adnotări @XML pentru maparea DTO
documente ca resurse REST;
○ componente de afaceri cu adnotări REST pentru:
■ harta URL a serviciului de date web ;
■ mapează adresele URL ale resurselor REST pe documentele DTO;
■ mapează solicitările de resurse REST-HTTP pe
java-business-metode.

26

Pagina 27

Obiect de transfer / transport de date DTO

Model de proiectare pentru arhitectura REST

● Flux de lucru pentru construirea și ciclul de viață al transferului de date / transport:

○ Curățarea datelor
○ Cartografiere / formatare date
○ Serializarea datelor
○ Schimb de date
● Tipuri de format DTO bazate pe Java :
○ Document DTO
■ XML DTO
■ JSON DTO
■ XLS DTO
■ CSV DTO

27

Pagina 28

PoJEE: Obiect de transport de date

Diagrama structurală a clasei

28

Pagina 29

DTO bazat pe modelul de domeniu

Strategii de implementare

● Strategii structurale :
○ Generați DTO-uri din structuri de entități - utilizați tipuri de entități
pentru a defini tipurile DTO.
○ Generați DTO utilizând structuri dedicate EntityView -
Folosiți EntityView Types ca sistem de tastare distinct pentru
definiți structurile DTO.
● Strategii de fabrică
○ Fabrica de metode - Implementarea metodelor de producere a DTO
static în cadrul claselor de entități;
○ Fabrica de clase (alături de fabricile de entități) pentru a găzdui DTO
producând metode.
● Constructori de documente
○ Convertiți instanțele DTO în formate XML / JSON folosind
Biblioteci JAXB / JSON.
29

Pagina 30

Resurse REST și clienți web

Serviciu Web REST

WebClient Resurse REST

Resurse REST
ȘTERGE
OBȚINE JSON / XML
Entități de date
ȘTERGE
OBȚINE JSON / XML RestURL
Entități de date Resurse REST
A PUNE POST

A PUNE POST RestURL

ȘTERGE
OBȚINE JSON / XML
Entități de date

Resurse REST

A PUNE
POST

ȘTERGE
OBȚINE JSON / XML
Entități de date

Solicitări URL
A PUNE
POST
RESURSE Resurse ca
Documente JSON / XML 30

Pagina 31

REST Web Backend

Serviciu Web REST

metoda java metoda java

Resurse REST
Cartografiere RS
RESTService-Class
ȘTERGE
OBȚINE JSON / XML
Entități de date
metoda java metoda java
RestURL
Resurse REST
A PUNE POST

ȘTERGE
RestURL
OBȚINE JSON / XML Entitate JPA
Entități de date

Resurse REST

A PUNE
POST
Entitate JPA
ȘTERGE
OBȚINE JSON / XML
Entități de date

Cartografiere JAXB Entitate JPA

A PUNE
POST

31

Pagina 32

Diverse:

● Arhitecturi
○ REST Oriented Computing
○ Arhitectură orientată REST
● Limbi de descriere API RESTful
○ Specificație OpenAPI (fost Swagger) - specificație
pentru definirea interfețelor
○ OData - Protocol pentru definirea API-urilor REST
○ RAML - Limbaj de modelare API RESTful
○ RSDL (RESTful Service Description Language)
● Limbi de interogare RESTful
○ RSQL (legătură1)
○ Spring Query DSL (legătură2, link3)
○ GraphQL
○ RESTSQL
32

Pagina 33

Ref.: Resurse SOA

● Erl, Thomas, SOA: principii de proiectare a serviciilor , PRENTICE HALL,

2008
● Daigneau, Robert, Modele de proiectare a serviciilor: proiectare fundamentală
soluții pentru SOAP / WSDL și servicii Web odihnitoare , Pearson
Educație, Inc, 2012
● Arnon Rotem-Gal-Oz, SOA Patterns , Manning Publications, 2012

33

Pagina 34

REFERINȚELE CURSULUI
● Modele de proiectare
○ [Evans, 2004] Eric Evans, Proiectare bazată pe domeniu: abordarea complexității în inima
software , Addison-Wesley, 2004 [PoDDD]
○ [Fowler și colab., 2002] Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt,
Robert Mee, Randy Stafford, Patterns of Enterprise Application Architecture , Addison
Wesley, 2002 [PoEAA ]
○ [Yener & Theedom, 2015] Murat Yener, Alex Theedom, Professional Java® EE Design
Patterns, John Wiley & Sons, Inc., 2015
○ [Alur și colab., 2003] Deepak Alur, John Crupi, Dan Malks, Core J2EE Patterns. Cel mai bun
Practici și strategii de proiectare , ediția a II-a, Prentice Hall, 2003 [ PoJEE ]
● Primăvară și JEE
○ [Cosmina et.al., 2017] Iuliana Cosmina, Rob Harrop, Chris Schaefer, Clarence Ho, Pro
Primăvara 5: Un ghid aprofundat al cadrului de primăvară și instrumentele sale, Apress, 2017
○ [Goncalves, 2013] Antonio Goncalves, Beginning Java EE 7, Apress Media, LLC,
2013

34