1 / 43

DEZVOLTAREA APLICATIILOR SOA INTR-O FIRMA

DEZVOLTAREA APLICATIILOR SOA INTR-O FIRMA. Raluca Georgian 341 C5. Cuprins. Generalitati Provocari in dezvoltatea aplicatiilor SOA Abordare studiu Analiza componente software Dezvoltare Agila de software Dezvoltare de WS- uri Caracteristici WS- uri si Best Practices

alamea
Download Presentation

DEZVOLTAREA APLICATIILOR SOA INTR-O FIRMA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DEZVOLTAREA APLICATIILOR SOA INTR-O FIRMA Raluca Georgian 341 C5

  2. Cuprins • Generalitati • Provocari in dezvoltateaaplicatiilor SOA • Abordarestudiu • Analizacomponente software • DezvoltareAgila de software • Dezvoltare de WS-uri • Caracteristici WS-urisi Best Practices • Conformarea la Standardeleindustriei. Componente software adresabile. • ExempluMetodologie

  3. SOA reprezinta o arhitectura software care defineste cum trebuie create serviciile pentru a putea indeplini cerintele utilizatorilor. Aceste servicii au urmatoarele caracteristici: -sunt componente business refolosibile -sunt slab cuplate -contin componente de tip SOA avand ca scop oferirea de servicii ca aplicatii dedicate utilizator sau alte servici prin retele eterogene.

  4. Implementarea aplicatiilor SOA este posibila prin realizarea de servicii Web.Un serviciu web este o componenta software avand un set de functii business specifice, care sunt descrise, publicate sau invocate pe internet folosindu-se de standarde XML cum ar fi SOAP,WSDL sau UDDI. Dezvoltarea aplicatiilor SOA presupune dezvoltarea de componente software pentru reutilizarea de soft si pentru incapsularea componentelor software ca si servicii Web pentru aplicatii dedicate utilizator sau pentru alte servicii consumator. Totusi exista goluri in metodologia actuala de dezvoltare de componente software pentru ca aceasta nu include factorii de dezvoltare si design specifici pentru servicii Web.

  5. Provocari in dezvoltareaaplicatiilor SOA Intr-o economiedigitaladinamica, atatcerereapentruintegrareadirecta a proceselorintreparteneri de business aidiferitelororganizatii cat sinevoia de a interschimbainformatiieste in crestere.  Organizatiileisiindreaptaprivireaastfelspreaplicatii de tip SOA pentru a-sisporiagilitatea business siproductivitatea IT. Componentelefolositepentru o aplicatie SOA vin de la distribuitori de serviciidiferiti. Procesul de dezvoltare a aplicatiilor SOA esteunul complex sipretentios. Pentru a putea face o astfel de aplicatieestenevoie de un management al proiectuluibazatpeplanificaresi control pentru a asigura o indreptaresistematica care controleazasidezvolta o aplicatie SOA.

  6. Provocari in dezvoltareaaplicatiilor SOA 1. Dificultatea de a indeplinitoatecerinteleutilizator. Aceastaproblemaaparedeoareceacestecerinte nu vin de la o singurasursa. Pot veni de la multipliibeneficiari care se pot afla in diverse colturi ale lumii. 2. Dificultatea de a legadiferiteserviciideoarece nu toatesuntimplementatefolosindaceiasitehnologie. Gazduireaserviciilorpediferiteplatformetehnologicecontribuie la aceastaproblema. 3. Dificultati in consumul de resurse al serviciilordatorat de diferiteleserviciioferite; unelesuportadoarinteractiuneasincrona,altele pot suportasiinteractiunisincrone.

  7. Provocari in dezvoltareaaplicatiilor SOA 4. Dificultate in comunicareaserviciilordatoratediferitelorinterfete : de exempluschimb de mesajebazatepedocumente, parametri. 5. Diferiteservicii au grade diferite de cuplare. Serviciilebazatepedocumentesuntmai slab cuplatedecatcelebazatepeparametri de exemplu. 6. Greutati in testareaaplicatiilor de tip SOA datoritanecesitatiiuneibunecoordonari din parteatuturorproviderilor de servicii (toateserviciiletrebuiesa fie disponibile).

  8. Abordarestudiu O abordarepentru a deteminacelemaibunemetode de dezvoltare a aplicatiilor SOA o reprezinta un studiuagil al metodologieipentru a se identificagolurile. Apoitrebuiestudiatadezvoltarea de aplicatii de servicii Web pentru a se identificapasiispecificitipurilor de servicii Web folositesipentru a se determinacaracteristicileacestorserviciiprecumsicelemaibuneabordari.

  9. Analizacomponente software O componentareprezinta o secventa software reutilizabila: cod aplicatieincapsulat care poateficombinat cu altecomponentesi care impreuna cu dezvoltarea de soft aditionalpoate produce aplicatiadorita. O componenta software reprezinta un pachet independent de serviciisofwarereutilizabile. Componentele software reprezintacomponentelereutilizabile ale uneiaplicatii SOA. Relatiadintrecomponentesofware , servicii web siaplicatia SOA esteprezentata in figura. Dezvoltareaserviciilor Web se bazeazapecomponente software care prininterfetepublicesuntexpuse ca servicii.

  10. Dezvoltareagila de software Dezvoltarea de sofwarebazatapecomponenteeste o abordare in care intreagadurata de viata a dezvoltarii , deploymentuluisimentenanteiestecentratapeconceptul de start-to-finish al ciclului de viata a componentei.

  11. Dezvoltarea de servicii web • Se adunatoatecerinteleutilizatorilor. => URD • Se analizeazacomponentele business existentepentrureutilizare => Lista de componente • Se proiecteazaserviciul Web. => DiagramaArhitecturala • Se implementeazalogica de businees cu ajutorulclaselor de interfatasi de implementare. Clasa de interfataesteclasaundeinterfataserviciuluivafiexpusapentruconsumsiclasa de implementareesteceaunde de fapt se va face implementareaserviciuluiderivat din componente software. => Application Layer. Componentelearhitecturii SOA

  12. Dezvoltarea de servicii web • Se construieste WS-ulprinincapsulareacomponentei in WS. • Se face deployment la WS peserverultintapebazaunui script de deployment. => PublicareLocala • Se testeazasicorecteaza WS folosindu-se  de clientul de web-service. • Se publica WS-ul => LansareOficiala

  13. Fig.2: Web Services Development Workflows

  14. Caracteristici WS si Best Practices Realizarea de aplicatii SOA se bazeazape WS-uri. Este deci important saintelegembinecaracteristicile WS-urilor, ce se poatesice nu se poateimplementa in WS-uripentru a putea forma bazapentrucelemaibuneabordari in dezvoltarea de WS-uri. Acestecaracteristiciafecteazaproiectareasiimplementarea WS-urilor.

  15. WSBP1.Stiluri • Celemaicomunetipuri de WS suntcelebazatepeapeluriprocedurale(RPC) sicelebazatepedocumente. • RPC-urileoferasimplitatesisuportpentru diverse uneltepecand WS-urilebazatepedocumenteoferaflexibilitatesuperioarasisuntmai slab cuplate.

  16. WSBP2.Mod de interactiune • sincron • asincron • cu solicitare de raspuns • cu notificare Oricare din acestemodurivaafectamaniera in care se proiecteazasiimplementeaza un WS.

  17. WSBP3.Interactiune cu Clientul WS Implementareaclientului WS estedeterminata de modul de interactiunefolosit de WS.   Daca WS-ulesteasincronclientulvafiimplementatfolosind Java API pentru XML Messaging JAXM , altfelvafifolosit de exemplu Java API pentru XML pentruApeluriprocedurale (JAX-RPC).

  18. WSBP4.Tipuri de implementaripentru WS Client Implementareaclientuluideterminata de tipul de WS Client. In particular pentruserviciu RPC bazatpe Java exista 3 tipuridiferite de clienti WS: • static stub, • dinamic proxy • dinamic invocation proxy. Fiecareoptiuneofera alt nivel de flexibilitate.

  19. WSBP4.Tipuri de implementaripentru WS Client • Celmaiputinflexibileste static stub la care oriceschimbareadusaserviciuluinecesitareconstruireaclientului. • Celmaiflexibilestedinamic invocation proxy pentru ca clientulpaseazaserviciul WSDL pentruconstruireaunuimesaj SOAP pentruinvocareaserviciului. O schimbare nu necesitareconstruireaclientului.

  20. WSBP5.Nivelul potrivit de granularitate • Granularitateainterfeteiserviciuluiafecteazaproiectareasiimplementarea WS-ului. • De asemeneaafecteazaperformanteleserviciului. • Cu cat granularitateaestemaifina cu atatperformantelesuntmaiscazutepentru ca aceastaaduce un overhead network-ului.

  21. WSBP6.Interoperabilitate • Problemele de interoperabilitate pot ficauzate de: • diferitestandarde de mesaje SOAP utilizate, • diferitetipuri de algoritim de securitatepentrusemnaturidigitale, criptare/decriptaresi • variatiunile de standard WS oferite de diversiproducatori. • Se recomandafolosireatipurilor de date primitive pentruparametriori de cateoriesteposibil. • O altarecomandareesteaceea de a nu folosivariantecustomizate de  SOAP serializatsauneserializat .

  22. WSBP7.Tipuri de binding (legatura) • Folosirea de rpc/econdedrespectivordoc/literal estedeterminata de nevoile de interschimbare de informatiidintreclientul de WS siserviciu • Dacainterschimbulesteintensivsauinformatiaschimbataeste un fisieratunci doc/literal binding estepreferat. • Dacadateleinterschimbatesuntrelativstaticeatuncirpc/encoding estepreferat.

  23. WSBP8.Performante pentruCerere-Raspuns WS-urilelucreazaintensiv. Acestea au nevoie de maimultalargime de bandasi de CPU-uriputernicesimemoriedatoritanevoii de serializaresideserializare  a mesajelor SOAP.

  24. WSBP8.Performante pentruCerere-Raspuns Celemaifrecventesolutiipentruoptimizareatimpilor de cereresiraspunssunt: • Folosirea de data-caching pe client sau server. • Folosirea XML-ului in WS-uribazatepedocumenteprinadoptareadecizilor de a trimiteintregul document saudoarfragmente din acesta. • Operatie de decizie WS granulara.

  25. WSBP9.Securitate • Existadiferitemoduri de a securizainformatiiletrimiseintreemitatorul initial al mesajului SOAP siultimuldestinatarul final al mesajuluiprinnumeroarenoduri SOAP intermediare. • Diferitemetode de securitate pot afectamodul in care WS-urilesuntproiectatesiimplementate.

  26. Metode de securitate • Transport Level Security (TLS). Aceastametoda se bazeazapemecanismul de securitate a transportului . Numaiemitatorul initial al mesajuluisidestinatarul final suntsecurizati. Nodurileintermediare nu suntsecurizate. (cand se foloseste SSL sau HTTPS). • Message Level Security (MLS). Prinaceastametodamesajulpoatefisecurizatpetoatacaleape care o parcurge. Standardeprecum XML Encryption0, XML Signature0, XML Key Management0, WS-Security0, SAML pot fifolositepentrusecurizareamesajului XML • Infrastructual Level Security. Aceastametoda se bazeazapemecanismul de securitateoferit de platforma WS-ului.

  27. WSBP10.Platforma siTehnologiafolositapentruimplementarea WS-urilor • Care esteplatformatehnologicafolosita? • Cefel de aplicatie server estenecesara? • Raspunsul la acesteintrebari duce la interoperabilitatecrescutaintreservicii.

  28. Conformarea la StandardeleIndustriei. Componente software adresabile • Conformitatea cu standardeleindustrieideterminatipurile de servicii.  Aceasta duce la necesitateaunui XML bine format si a unui WS bazatpe document pentruserviciu. • Fiecareserviciuesteidenficabilprintr-un URL. Pentru a stidaca un serviciuestedisponibil se va face un test de invocare a serviciului  care vaaratadisponibilitateaacestuia.

  29. Nevoile WS-urilor • WS-urilesuntfolositepentru a solutiona diverse nevoisiobiective de business. • Factoriicetrebuieluati in consideraresunt: • refolosireacomponentelor de business, • integrareadiferitelorplatforme IT si a diferitelortehnologii, • integraredirecta business-to-business (B2B) intreparteneripentru a facilitainterschimbul de informatii. • Intelegereanevoilor de baza conduce la descoperireatipului de WS cevafifolosit.

  30. ArhitecturapeLayere a WS-urilor • Nevoia de abstractizareierarhicapentru WS-urideterminarelatiile slab-cuplateintreservicii. • Analizalacunelormetodologiei software-ulpentruservicii Web (WS), studiulcaracteristicilor Web Services şicelemaibunepracticidiscutate anterior se completeazăreciproc. Aceastaformeazăbazapentruextindereametodologiei software-ului existent cu celemaibunepracticipentruservicii de Web (WSBP).

  31. ArhitecturapeLayere a WS-urilor • Efortul major consta in parcurgereatuturoractivităţilorşisarcinilor definite pentrufiecarefaza a ciclului de viaţă a software-uluiprinanalizamodului in care celemaibunepracticipentruservicii Web arputeafiutilizate. • Fazeleidentificatesunt: identificareacerințelor, analiză, proiectare, implementare, testareșiincarcarepe server.

  32. Identificareacerintelor • Obiectivulacesteietapeeste de a înţelegecerinţeleafaceriişitraducereaacestoraîncerințe WS înceeacepriveștecaracteristicile, condițiilefuncționaleși non-funcţionaleşirestricţiile WS. WSBP13 oferăliniidirectoarepentruidentificarea Web Services, clasificandnevoileînservicii Web. Determinacaracteristicilenecesarepentruserviciile Web. • Defineşteutilizareamodelelorpentruserviciile Web respective.

  33. Analiza • Obiectivulacesteietapeeste de a determinacerințelesuplimentareşi a traduce cerințeleînmodeleconceptuale. Analizaarhitecturalaestefăcutapentru a definistructura la nivelînaltşi a identificainterfeţeleserviciilor Web . WSBP1, WSBP2, WSBP5, WSBP6, WSBP10 furnizeazaorientări de analizăpentruurmătoareleactivități:

  34. Analiza. Activitati • Analizagranularitatiiinterfetelorserviciilor WEB • Selectareaplatformeitehnologicepentruimplementareacadrului de lucru • Definireaarhitecturilorposibile de servicii WEB. Identificareacomponentelorarhitecturale care vor fi expuse ca WS-urisiprincipaleleinformatii care vor fi schimbate cu clientul

  35. Proiectarea • Obiectivulacesteietapeeste de a detaliaproiectareaserviciului WEB. In aceastafaza se detaliazainterfata WS-ului. • Este luata in considerareinterfataintreseviciusi client, adicaasincron/sincronsaurpc/document. • Suntluate in considerarecelemaibunepracticipentruserviciile WEB corespunzatoarepentru WSBP1, WSBP2, WSBP3, WSBP5, WSBP6, WSBP7 .

  36. Implementarea • Obiectivulacesteietapeeste de a face codificareareala a serviciilor Web. • Este realizataimpachetareacomponentelor API in interfaţăServiciilor Web. • Sunt generate WS de testare client şi WSDL. • WS vorfiimplementateînserverul de aplicaţieţintă. • Celemaibunepracticipentru WS referitoare la WSBP1 furnizeazaorientăripentrupunereaînaplicare a serviciilor Web.

  37. Testarea • Obiectivulacestei faze esteefectuareaunui test complet de servicii Web, inclusivcerințelefuncționaleși non-funcţionale. • Celemaibunepractici WS pentru WSBP1 pana la WSBP10 furnizeazaorientăripentrutestarea de servicii Web.

  38. Incarcareape server • Obiectivulacestei faze esteincarcareacorespunzatoare a serviciului Web înserverul de aplicaţietinta. • Pentru a validaincarcareacorespunzatoare a WS, clientul Ws-uluiparticipa la incarcare. • Pentru WSBP1, utilizatorulvaspecificadacapublicareaserviciului WEB estenecesara in interiorulorganizatieisauesteextinsa la partenerii de afacerisaupentruutilizariexterne. • Aceastavadeterminadecizia de aveaacces pubic sauprivatpentru a servinevoilorcompaniei.

  39. Figura 3. MetodologiaExtinsa In figura se prezinta o vederegeneralaasupraciclului de viata a metodologieiextinse care incorporeazacelemaibunepractici WS in diferite faze ale ciclului de viata.

  40. Figura 3. MetodologiaExtinsa

  41. WSBP= Web Service Best Practice

  42. Bibliografie • Lucas Jelema -Oracle SOA 11g Handbook –Implement an Enterprisewide Service Oriented Arhitecture. • http://www.fibre2fashion.com/industry-article/9/807/web-services-implementation-methodology-for-soa-application6.asp

More Related