construirea aplicatiilor soa
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Construirea aplicatiilor SOAOita Nicoleta
342C5
CuprinsImportanta SOAStil arhitectural si principiiServicii webModel conceptual al SOANivelurile unei SOAProcesul de modelare a SOAPrincipii de design a aplicatiilor orientate pe
servicii
Importanta SOAExista 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:performantasecuritatescalabilitate
Serviciu webo resursa software cu o descriere externadescrierea 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 SOACoceptul 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 SOANivelul 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 SOANivelul 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 SOANivelul prezentare sau accesNivelul 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, valabilitateeste un process de background
Procesul de modelare a arhitecturii orientate pe servicii
Procesul de modelare a arhitecturii orientate pe serviciiConsta in trei pasi generali: identificare,
specificare, realizare a serviciilor, componentelor si fluxurilor.
Identificarea serviciilordescompunerea 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 serviciiAnaliza subsistemelor
specifica interdependentele dintre subsistemecazurile 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 componentelordetaliile componentelor care implementeaza
serviciile: date, reguli, servicii, profiluri configurabiletrimiterea de mesaje si specificatiile evenimentelor
Procesul de modelare a arhitecturii orientate pe serviciiAlocarea 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 serviciiDezvoltarea 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 serviciiCrearea cu succes a aplicatiilor orientate pe
servicii presupune:deciderea a caror functionalitati are sens sa fie
expuse ca serviciisepararea si modularizarea logicii de business
pentru a facilita refolosirea si flexibilitateafolosirea de servicii slab cuplate pentru a putea fi
dezvoltate rapid cand cerintele se schimbaproiectarea unei granularitati potrivite a serviciilorplanificarea si implementarea tuturor pasilor SODA
Principii de design ale aplicatiilor orientate pe serviciiDeciderea 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 complexaeste 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 serviciiSepararea si modularizarea logicii de interfata
serviciuluievitarea construirii logicii direct in implementarea
serviciuluiproiectarea fiecarui serviciu pentru a expune un bloc
modular de logica care calculeaza o functie discretaprotejeaza 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
Principii de design ale aplicatiilor orientate pe serviciiServicii slab cuplateprobabil 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 serviciiProiectarea unei granularitati potrivite a
serviciilorgranularitate fina: presupune efectuarea unei
singure, simple functiigranularitate aspra: presupune efectuarea
unei functii completeRegula 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!