1. Construirea aplicatiilor SOA
Oita Nicoleta
342C5

2. Cuprins Importanta SOA Stil arhitectural si principii Servicii web
Model conceptual al SOA
Nivelurile unei SOA
Procesul de modelare a SOA
Principii de design a aplicatiilor orientate pe servicii

3. Importanta SOA
Exista o cerere uriasa pentru dezvoltarea si implementarea sistemelor de tip SOA.
Metodele OOAD (Object Oriented Analysis and Design) curente nu adreseaza cele 3 elemente cheie ale unui SOA: servicii, fluxuri, componente.
Este nevoie sa fie adresate explicit tehnicile si procesele necesare pentru a identifica, specifica si realiza serviciile, fluxurile si structura lor.

4. Stil arhitectural si principii
SOA descrie un set de sabloane pentru a crea servicii slab cuplate care, datorita separarii interfetelor, implementarilor si protocoalelor, furnizeaza o mare flexibilitate in receptivitatea la cerintele actuale de business functionale si non-functionale:
performanta
securitate
scalabilitate

5. Serviciu web o resursa software cu o descriere externa
descrierea este disponibila pentru cautarea, conectarea, invocarea de catre un consumator de servicii
furnizorul de servicii realizeaza implementarea descrierii serviciului si livreaza cerinte QoS (Quality of Service) consumatorului de servicii.
serviciile ar trebui in mod ideal sa fie conduse de politici declarative, astfel incat sa suporte un stil arhitectural reconfigurabil

6. Model conceptual al SOA

7. Model conceptual al SOA
Coceptul este bazat pe un stil arhitectural care defineste un model de interactiune intre trei parti primare:
furnizorul de servicii: publica descrierea unui serviciu si furnizeaza implementarea acelui serviciu
un consumator de servicii:
poate folosi un URI (Uniform Resource Identifier) pentru descrierea directa a serviciului
poate gasi descrierea serviciului intr-un registru de servicii si apoi poate sa se conecteze si sa invoce acel serviciu
Brokerul de servicii furnizeaza si mentine registrul de servicii (desi in ziua de azi registrele publice nu mai sunt in voga)

8. Nivelurile unei SOA

9. Nivelurile unei SOA Nivelul operational
format din aplicatiile deja existente, “mostenite”
include aplicatii de tip CRM (Customer Relationship Management) si ERP (Enterprise Resource Planning), implementari ale sistemului mai vechi, orientate obiect, aplicatii inteligente
Nivelul componentelor intreprinderii:
foloseste de obicei aplicatii server pentru a implementa componentele, gestiunea volumului de munca si echilibrarea traficului

10. Nivelurile unei SOA Nivelul de servicii:
cuprinde serviciile fondate si expuse: pot fi descoperite sau legate static si apoi invocate
furnizeaza un mecanism prin care se realizeaza servicii la rulare, folosind functionalitatea data de interfata
interfetele sunt exportate ca descrieri de servicii si expuse pentru a fi folosite; ele pot exista izolate sau ca servicii compuse
Nivelul de compunere a proceselor:
compunerea serviciilor expuse la nivelul anterior
serviciile sunt “impachetate” intr-un flux si astfel actioneaza impreuna ca o singura aplicatie; aceste aplicatii suporta cazuri de utilizare si procese specifice

11. Nivelurile unei SOA Nivelul prezentare sau acces Nivelul integrare
permite integrarea serviciilor prin introducerea unui set de capabilitati de baza: rutare inteligenta, medierea protocoalelor si alte mecanisme de transformare, de obicei descrise ca ESB (Enterprise Service Bus)
Web Services Description Language (WSDL) specifica conectarea, ceea ce implica o locatie la care serviciul este furnizat; pe de alta parte, un ESB furnizeaza un mecanism de specificare a locatiei independenta pentru integrare
Nivelul QOS:
furnizeaza capabilitati necesare pentru a monitoriza, gestiona, mentine QOS: securitate, performanta, valabilitate
este un process de background

12. Procesul de modelare a arhitecturii orientate pe servicii

13. Procesul de modelare a arhitecturii orientate pe servicii
Consta in trei pasi generali: identificare, specificare, realizare a serviciilor, componentelor si fluxurilor.
Identificarea serviciilor
descompunerea domeniului in ariile si subsistemele sale, incluzand descompunerea proceselor sau fluxului in subprocese si cazuri de utilizare
Clasificarea serviciilor
aceasta clasificare ar trebui sa fie realizata ca o ierarhie, care sa reflecte natura compusa a serviciilor: acestea ar trebui compuse din componente mai fin granulate

14. Procesul de modelare a arhitecturii orientate pe servicii
Analiza subsistemelor
specifica interdependentele dintre subsisteme
cazurile de utilizare sunt expuse ca servicii in interfata subsistemului
analiza unui subsistem presupune crearea de modele ale obiectelor pentru a reprezenta designul si taskurile interne ale subsistemelor continute
Specificare componentelor
detaliile componentelor care implementeaza serviciile: date, reguli, servicii, profiluri configurabile
trimiterea de mesaje si specificatiile evenimentelor

15. Procesul de modelare a arhitecturii orientate pe servicii
Alocarea serviciilor
consta in asignarea serviciilor subsistemelor care au fost identificate.
de obicei se face presupunerea ca subsistemele au o corespondenta 1-1 cu componentele intreprinderii.
Realizarea serviciilor :
se hotaraste care subservicii vor fi folosite pentru a realiza un anumit serviciu si care servicii vor fi construite de la baza
include integrare, transformare folosind servicii web

16. Principii de design ale aplicatiilor orientate pe servicii
Dezvoltarea aplicatiilor orientate pe servicii (Service-Oriented Development of Applications = SODA) este o metoda sau abordare care construieste aplicatii folosind servicii software.
SODA este compatibila cu limbaje de programare variate, mai ales orientate obiect.

17. Principii de design ale aplicatiilor orientate pe servicii
Crearea cu succes a aplicatiilor orientate pe servicii presupune:
deciderea a caror functionalitati are sens sa fie expuse ca servicii
separarea si modularizarea logicii de business pentru a facilita refolosirea si flexibilitatea
folosirea de servicii slab cuplate pentru a putea fi dezvoltate rapid cand cerintele se schimba
proiectarea unei granularitati potrivite a serviciilor
planificarea si implementarea tuturor pasilor SODA

18. Principii de design ale aplicatiilor orientate pe servicii
Deciderea a caror functionalitate sa fie expusa ca un serviciu:
aproape orice tip de logica de business poate fi implementata sau expusa ca un serviciu web in SOA, de la o singura, triviala functie pana la o aplicatie complexa
este nevoie ca datele sa fie private?
functionalitatea bazata pe logica de business se poate schimba frecvent?
este nevoie ca datele sa fie partajate intre departamente sau locatii ale unei intreprinderi sau cu parteneri externi?

19. Principii de design ale aplicatiilor orientate pe servicii
Separarea si modularizarea logicii de interfata serviciului
evitarea construirii logicii direct in implementarea serviciului
proiectarea fiecarui serviciu pentru a expune un bloc modular de logica care calculeaza o functie discreta
protejeaza clientul de functionalitati schimbatoare in logica businessului si faciliteaza implementarea rapida a regulilor schimbate in serviciu
implementarea unui serviciu ar trebui sa contina doar apelul catre logica de business pentru a lua datele de care are nevoie in a converti sau asambla datele returnate intr-un format specificat, cel mai adesea bazat pe XML

20. Principii de design ale aplicatiilor orientate pe servicii
Servicii slab cuplate
probabil cel mai critic element intr-un sistem SOA
are impact direct asupra agilitatii aplicatiei: abilitatea de a fi scalata usor, usurinta in schimbare, de incredere
cuplarea stransa presupune ca daca functia A este foarte dependenta de functia B, schimbarile asupra uneia determina schimbari si asupra celeilalte
cuplarea slaba evita cat mai multe dependente posibile la toate nivelele aplicatiei, permitand componentelor si serviciilor sa opereze fara sa fie nevoie de informatii de la alte componente sau servicii

21. Principii de design ale aplicatiilor orientate pe servicii
Proiectarea unei granularitati potrivite a serviciilor
granularitate fina: presupune efectuarea unei singure, simple functii
granularitate aspra: presupune efectuarea unei functii complete
Regula importanta: construirea unei serii de obiecte si componente de nivel scazut, cu granularitate fina si apoi construirea unui serviciu granulat aspru din acestea.

22. Principii de design ale aplicatiilor orientate pe servicii
un serviciu granulat fin poate fi folosit de multe ori, dar poate cauza si un overhead mare la rulare
un serviciu granulat aspru care incapsuleaza un proces complet va fi cel mai folositor celor care planifica o aplicatie completa si va avea nevoie de o singura accesare a bazei de date la rulare
Serviciile care sunt prea aspru granulate pot fi limitate in refolosire. Trebuie sa existe in mod clar un echilibru intre cele doua.

23. Intrebari?
… Va multumesc!