Transcript Construirea aplicatiilor SOA

Oita Nicoleta
342C5
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
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.
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
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
Model conceptual al SOA
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)
Nivelurile unei SOA
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
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
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
Procesul de modelare a arhitecturii
orientate pe servicii
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
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
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
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.
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
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?
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 intrun format specificat, cel mai adesea bazat pe XML
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
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.
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.
Intrebari?
… Va multumesc!