Construirea aplicatiilor SOA

  • View
    46

  • Download
    0

Embed Size (px)

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 Presentation

Text of Construirea aplicatiilor SOA

Slide 1

Construirea aplicatiilor SOAOita Nicoleta 342C5CuprinsImportanta 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 principiiSOA 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 serviciifurnizorul 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 serviciuBrokerul 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 operationalformat din aplicatiile deja existente, mosteniteinclude aplicatii de tip CRM (Customer Relationship Management) si ERP (Enterprise Resource Planning), implementari ale sistemului mai vechi, orientate obiect, aplicatii inteligenteNivelul 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 invocatefurnizeaza un mecanism prin care se realizeaza servicii la rulare, folosind functionalitatea data de interfatainterfetele sunt exportate ca descrieri de servicii si expuse pentru a fi folosite; ele pot exista izolate sau ca servicii compuseNivelul 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 integrarepermite 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 integrareNivelul 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 utilizareClasificarea 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 subsistemelorspecifica 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 continuteSpecificare 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 serviciuimplementarea 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 celeilaltecuplarea 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 serviciiPrincipii 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 rulareun 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!