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!