Construirea aplicatiilor SOA

1. Construireaaplicatiilor SOA Oita Nicoleta 342C5

2. Cuprins • Importanta SOA • Stilarhitecturalsiprincipii • Servicii web • Model conceptual al SOA • Nivelurileunei SOA • Procesul de modelare a SOA • Principii de design a aplicatiilor orientate peservicii

3. Importanta SOA • Exista o cerereuriasapentrudezvoltareasiimplementareasistemelor de tip SOA. • Metodele OOAD (Object Oriented Analysis and Design) curente nu adreseazacele 3 elementecheie ale unui SOA: servicii, fluxuri, componente. • Este nevoiesa fie adresate explicit tehnicilesiproceselenecesarepentru a identifica, specificasirealizaserviciile, fluxurilesistructuralor.

4. Stilarhitecturalsiprincipii • SOA descrie un set de sabloanepentru a creaservicii slab cuplate care, datoritaseparariiinterfetelor, implementarilorsiprotocoalelor, furnizeaza o mare flexibilitatein receptivitatea la cerinteleactuale de business functionalesi non-functionale: • performanta • securitate • scalabilitate

5. Serviciu web • o resursa software cu o descriereexterna • descriereaestedisponibilapentrucautarea, conectarea, invocarea de catre un consumator de servicii • furnizorul de serviciirealizeazaimplementareadescrieriiserviciuluisilivreazacerinteQoS (Quality of Service) consumatorului de servicii. • serviciileartrebui in mod ideal sa fie conduse de politici declarative, astfelincatsasuporte un stilarhitecturalreconfigurabil

6. Model conceptual al SOA

7. Model conceptual al SOA • Coceptulestebazatpe un stilarhitectural care defineste un model de interactiuneintretreipartiprimare: • furnizorul de servicii: publicadescriereaunuiserviciusifurnizeazaimplementareaaceluiserviciu • un consumator de servicii: • poatefolosi un URI (Uniform Resource Identifier) pentrudescriereadirecta a serviciului • poategasidescriereaserviciuluiintr-un registru de serviciisiapoipoatesa se conectezesisainvoceacelserviciu • Brokerul de serviciifurnizeazasimentineregistrul de servicii (desi in ziua de aziregistrelepublice nu maisunt in voga)

8. Nivelurileunei SOA

9. Nivelurileunei SOA • Nivelul operational • format din aplicatiiledejaexistente, “mostenite” • include aplicatii de tip CRM (Customer Relationship Management) si ERP (Enterprise Resource Planning), implementari ale sistemuluimaivechi, orientate obiect, aplicatiiinteligente • Nivelulcomponentelorintreprinderii: • foloseste de obiceiaplicatii server pentru a implementacomponentele, gestiuneavolumului de muncasiechilibrareatraficului

10. Nivelurileunei SOA • Nivelul de servicii: • cuprindeserviciilefondatesiexpuse: pot fidescoperitesau legate static siapoi invocate • furnizeaza un mecanismprin care se realizeazaservicii la rulare, folosindfunctionalitatea data de interfata • interfetelesuntexportate ca descrieri de serviciisiexpusepentru a fifolosite; ele pot existaizolatesau ca serviciicompuse • Nivelul de compunere a proceselor: • compunereaserviciilorexpuse la nivelul anterior • serviciilesunt “impachetate” intr-un flux siastfelactioneazaimpreuna ca o singuraaplicatie; acesteaplicatiisuportacazuri de utilizaresiprocesespecifice

11. Nivelurileunei SOA • Nivelulprezentaresauacces • Nivelulintegrare • permiteintegrareaserviciilorprinintroducereaunui set de capabilitati de baza: rutareinteligenta, mediereaprotocoalelorsialtemecanisme de transformare, de obiceidescrise ca ESB (Enterprise Service Bus) • Web Services Description Language (WSDL) specificaconectarea, ceeaceimplica o locatie la care serviciulestefurnizat; pe de alta parte, un ESB furnizeaza un mecanism de specificare a locatieiindependentapentruintegrare • Nivelul QOS: • furnizeazacapabilitatinecesarepentru a monitoriza, gestiona, mentine QOS: securitate, performanta, valabilitate • este un process de background

12. Procesul de modelare a arhitecturii orientate peservicii

13. Procesul de modelare a arhitecturiiorientate peservicii • Consta in treipasigenerali: identificare, specificare, realizare a serviciilor, componentelorsifluxurilor. • Identificareaserviciilor • descompunereadomeniului in ariilesisubsistemele sale, incluzanddescompunereaproceselorsaufluxului in subprocesesicazuri de utilizare • Clasificareaserviciilor • aceastaclasificareartrebuisa fie realizataca o ierarhie, care sareflectenaturacompusa a serviciilor: acesteaartrebuicompuse din componentemai fin granulate

14. Procesul de modelare a arhitecturiiorientate peservicii • Analizasubsistemelor • specificainterdependenteledintresubsisteme • cazurile de utilizaresuntexpuse ca servicii in interfatasubsistemului • analizaunuisubsistempresupunecrearea de modele ale obiectelorpentru a reprezentadesignulsitaskurile interne ale subsistemelorcontinute • Specificarecomponentelor • detaliilecomponentelor care implementeazaserviciile: date, reguli, servicii, profiluriconfigurabile • trimiterea de mesajesispecificatiileevenimentelor

15. Procesul de modelare a arhitecturiiorientate peservicii • Alocareaserviciilor • consta in asignareaserviciilorsubsistemelor care au fostidentificate. • de obicei se face presupunerea ca subsistemele au o corespondenta 1-1 cu componenteleintreprinderii. • Realizareaserviciilor : • se hotaraste care subserviciivorfifolositepentru a realiza un anumitserviciusi care serviciivorficonstruite de la baza • include integrare, transformarefolosindservicii web

16. Principii de design ale aplicatiilor orientate peservicii • Dezvoltareaaplicatiilor orientate peservicii (Service-Oriented Development of Applications = SODA) este o metodasauabordare care construiesteaplicatiifolosindservicii software. • SODA estecompatibila cu limbaje de programarevariate, mai ales orientate obiect.

17. Principii de design ale aplicatiilororientate peservicii • Crearea cu succes a aplicatiilor orientate peserviciipresupune: • deciderea a carorfunctionalitati are senssa fie expuse ca servicii • separareasimodularizarealogicii de business pentru a facilitarefolosireasiflexibilitatea • folosirea de servicii slab cuplatepentru a puteafidezvoltate rapid candcerintele se schimba • proiectareauneigranularitatipotrivite a serviciilor • planificareasiimplementareatuturorpasilor SODA

18. Principii de design ale aplicatiilororientate peservicii Deciderea a carorfunctionalitatesa fie expusa ca un serviciu: • aproapeorice tip de logica de business poatefiimplementatasauexpusa ca un serviciu web in SOA, de la o singura, trivialafunctiepana la o aplicatiecomplexa • estenevoie ca datelesa fie private? • functionalitateabazatapelogica de business se poateschimbafrecvent? • estenevoie ca datelesa fie partajateintredepartamentesaulocatii ale uneiintreprinderisau cu parteneriexterni?

19. Principii de design ale aplicatiilororientate peservicii Separareasimodularizarealogicii de interfataserviciului • evitarea construirii logicii direct in implementarea serviciului • proiectareafiecaruiserviciupentru a expune un bloc modular de logica care calculeaza o functiediscreta • protejeazaclientul de functionalitatischimbatoare in logicabusinessuluisifaciliteazaimplementarearapida a regulilorschimbate in serviciu • implementareaunuiserviciuartrebuisacontinadoarapelulcatrelogica de business pentru a luadatele de care are nevoie in a convertisauasambladatelereturnateintr-un format specificat, celmaiadeseabazatpe XML

20. Principii de design ale aplicatiilororientate peservicii Servicii slab cuplate • probabilcelmai critic element intr-un sistem SOA • are impact direct asupraagilitatiiaplicatiei: abilitatea de a fiscalatausor, usurinta in schimbare, de incredere • cuplareastransapresupune ca dacafunctia A estefoartedependenta de functia B, schimbarileasuprauneiadeterminaschimbarisiasupraceleilalte • cuplareaslabaevita cat maimultedependenteposibile la toateniveleleaplicatiei, permitandcomponentelorsiserviciilorsaoperezefarasa fie nevoie de informatii de la altecomponentesauservicii

21. Principii de design ale aplicatiilororientate peservicii Proiectareauneigranularitatipotrivite a serviciilor • granularitatefina: presupuneefectuareauneisingure, simple functii • granularitateaspra: presupuneefectuareauneifunctii complete • Regulaimportanta: construireauneiserii de obiectesicomponente de nivelscazut, cu granularitatefinasiapoiconstruireaunuiserviciugranulataspru din acestea.

22. Principii de design ale aplicatiilororientate peservicii • un serviciugranulat fin poatefifolosit de multeori, darpoatecauzasi un overhead mare la rulare • un serviciugranulataspru care incapsuleaza un procescompletva fi celmaifolositorcelor care planifica o aplicatiecompletasivaaveanevoie de o singuraaccesare a bazei de date la rulare • Serviciile care suntpreaaspru granulate pot filimitate in refolosire. Trebuiesaexiste in mod clar un echilibruintreceledoua.

23. Intrebari? … Vamultumesc!