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

2. 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
Conformarea la Standardele industriei. Componente software adresabile.
Exemplu Metodologie

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 dezvoltarea aplicatiilor SOA
Intr-o economie digitala dinamica, atat cererea pentru integrarea directa a proceselor intre parteneri de business ai diferitelor organizatii cat si nevoia de a interschimba informatii este in crestere.   Organizatiile isi  indreapta  privirea astfel spre aplicatii de tip SOA pentru a-si spori agilitatea business si productivitatea IT. Componentele folosite pentru o aplicatie SOA vin de la distribuitori de servicii diferiti. Procesul de dezvoltare a aplicatiilor SOA este unul complex si pretentios. Pentru a putea face o astfel de aplicatie este nevoie de un management al proiectului bazat pe planificare si control pentru a asigura o indreptare sistematica care controleaza si dezvolta o aplicatie SOA.

6. Provocari in dezvoltarea aplicatiilor SOA
1. Dificultatea de a indeplini toate cerintele utilizator. Aceasta problema apare deoarece aceste cerinte nu vin de la o singura sursa. Pot veni de la multiplii beneficiari care se pot afla in diverse colturi ale lumii.
2. Dificultatea de a lega diferite servicii deoarece nu toate sunt implementate folosind aceiasi tehnologie. Gazduirea serviciilor pe diferite platforme tehnologice contribuie la aceasta problema.
3. Dificultati in consumul de resurse al serviciilor datorat de diferitele servicii oferite; unele suporta doar interactiune asincrona,altele pot suporta si interactiuni sincrone.

7. Provocari in dezvoltarea aplicatiilor SOA
4. Dificultate in comunicarea serviciilor datorate diferitelor interfete : de exemplu schimb de mesaje bazate pe documente, parametri.
5. Diferite servicii au grade diferite de cuplare. Serviciile bazate pe documente sunt mai slab cuplate decat cele bazate pe parametri de exemplu.
6. Greutati in testarea aplicatiilor de tip SOA datorita necesitatii unei bune coordonari din partea tuturor providerilor de servicii (toate serviciile trebuie sa fie disponibile).

8. Abordare studiu
O abordare pentru a detemina cele mai bune metode de dezvoltare a aplicatiilor SOA o reprezinta un studiu agil al metodologiei pentru a se identifica golurile. Apoi trebuie studiata dezvoltarea de aplicatii de servicii Web pentru a se identifica pasii specifici tipurilor de servicii Web folosite si pentru a se determina caracteristicile acestor servicii precum si cele mai bune abordari.

9. Analiza componente software
O componenta reprezinta o secventa software reutilizabila: cod aplicatie incapsulat care poate fi combinat cu alte componente si care impreuna cu dezvoltarea de soft aditional poate produce aplicatia dorita. O componenta software reprezinta un pachet independent de servicii sofware reutilizabile. Componentele software reprezinta componentele reutilizabile ale unei aplicatii SOA. Relatia dintre componente sofware , servicii web si aplicatia SOA este prezentata in figura. Dezvoltarea serviciilor Web se bazeaza pe componente software care prin interfete publice sunt expuse ca servicii.

11. Dezvoltare agila de software
Dezvoltarea de sofware bazata pe componente este o abordare in care intreaga durata de viata a dezvoltarii , deploymentului si mentenantei este centrata pe conceptul de start-to-finish al ciclului de viata a componentei.

12. Dezvoltarea de servicii web
Se aduna toate cerintele utilizatorilor. => URD
Se analizeaza componentele business existente pentru reutilizare => Lista de componente
Se proiecteaza serviciul Web. => Diagrama Arhitecturala
Se implementeaza logica de businees cu ajutorul claselor de interfata si de implementare. Clasa de interfata este clasa unde interfata serviciului va fi expusa pentru consum si clasa de implementare este cea unde de fapt se va face implementarea serviciului derivat din componente software. => Application Layer. Componentele arhitecturii SOA

13. Dezvoltarea de servicii web
Se construieste WS-ul prin incapsularea componentei in WS.
Se face deployment la WS pe serverul tinta pe baza unui script de deployment. => Publicare Locala
Se testeaza si corecteaza WS folosindu-se  de clientul de web-service.
Se publica WS-ul => Lansare Oficiala

14. Fig.2: Web Services Development Workflows

15. Caracteristici WS si Best Practices
Realizarea de aplicatii SOA se bazeaza pe WS-uri. Este deci important sa intelegem bine caracteristicile WS-urilor, ce se poate si ce nu se poate implementa in WS-uri pentru a putea forma baza pentru cele mai bune abordari in dezvoltarea de WS-uri. Aceste caracteristici afecteaza proiectarea si implementarea WS-urilor.

16. WSBP1.Stiluri
Cele mai comune tipuri de WS sunt cele bazate pe apeluri procedurale(RPC) si cele bazate pe documente.
RPC-urile ofera simplitate si suport pentru diverse unelte pe cand WS-urile bazate pe documente ofera flexibilitate superioara si sunt mai slab cuplate.

17. WSBP2.Mod de interactiune
sincron
asincron
cu solicitare de raspuns
cu notificare
Oricare din aceste moduri va afecta maniera in care se proiecteaza si implementeaza un WS.

18. WSBP3.Interactiune cu Clientul WS
Implementarea clientului WS este determinata de modul de interactiune folosit de WS. Daca WS-ul este asincron clientul va fi implementat folosind Java API pentru XML Messaging JAXM , altfel va fi folosit de exemplu Java API pentru XML pentru Apeluri procedurale (JAX-RPC).

19. WSBP4.Tipuri de implementari pentru WS Client
Implementarea clientului determinata de tipul de WS Client. In particular pentru serviciu RPC bazat pe Java exista 3 tipuri diferite de clienti WS:
static stub,
dinamic proxy
dinamic invocation proxy.
Fiecare optiune ofera alt nivel de flexibilitate.

20. WSBP4.Tipuri de implementari pentru WS Client
Cel mai putin flexibil este static stub la care orice schimbare adusa serviciului necesita reconstruirea clientului.
Cel mai flexibil este dinamic invocation proxy pentru ca clientul paseaza serviciul WSDL pentru construirea unui mesaj SOAP pentru invocarea serviciului. O schimbare nu necesita reconstruirea clientului.

21. WSBP5.Nivelul potrivit de granularitate
Granularitatea interfetei serviciului afecteaza  proiectarea si implementarea WS-ului.
De asemenea afecteaza performantele serviciului.
Cu cat granularitatea este mai fina cu atat performantele sunt mai scazute pentru ca aceasta aduce un overhead network-ului.

22. WSBP6.Interoperabilitate
Problemele de interoperabilitate pot fi cauzate de:
diferite standarde de mesaje SOAP utilizate,
diferite tipuri de algoritim de securitate pentru semnaturi digitale, criptare/decriptare si
variatiunile de standard WS oferite de diversi producatori.
Se recomanda folosirea tipurilor de date primitive pentru parametri ori de cate ori este posibil.
O alta recomandare este aceea de a nu folosi variante customizate de  SOAP serializat sau neserializat .

23. WSBP7.Tipuri de binding (legatura)
Folosirea de rpc/econded respectiv ordoc/literal este determinata de nevoile de interschimbare de informatii dintre clientul de WS si serviciu
Daca interschimbul este intensiv sau informatia schimbata este un fisier atunci doc/literal binding este preferat.
Daca datele interschimbate sunt relativ statice atunci rpc/encoding este preferat.

24. WSBP8.Performante pentru Cerere-Raspuns
WS-urile lucreaza intensiv. Acestea au nevoie de mai multa largime de banda si de CPU-uri puternice si memorie datorita nevoii de serializare si deserializare a mesajelor SOAP.

25. WSBP8.Performante pentru Cerere-Raspuns
Cele mai frecvente solutii pentru optimizarea timpilor de cerere si raspuns sunt:
Folosirea de data-caching pe client sau server.
Folosirea XML-ului in WS-uri bazate pe documente prin adoptarea decizilor de a trimite intregul document sau doar fragmente din acesta.
Operatie de decizie WS granulara.

26. WSBP9.Securitate
Exista diferite moduri de a securiza informatiile trimise intre emitatorul initial al mesajului SOAP si ultimul destinatarul final al mesajului prin numeroare noduri SOAP intermediare.
Diferite metode de securitate pot afecta modul in care WS-urile sunt proiectate si implementate.

27. Metode de securitate
Transport Level Security (TLS). Aceasta metoda se bazeaza pe mecanismul de securitate a transportului . Numai emitatorul initial al mesajului si destinatarul final sunt securizati. Nodurile intermediare nu sunt securizate. (cand se foloseste SSL sau HTTPS).
Message Level Security (MLS). Prin aceasta metoda mesajul poate fi securizat pe toata calea pe care o parcurge. Standarde precum XML Encryption0, XML Signature0, XML Key Management0, WS-Security0, SAML pot fi folosite pentru securizarea mesajului XML
Infrastructual Level Security. Aceasta metoda se bazeaza pe mecanismul de securitate oferit de platforma WS-ului.

28. WSBP10.Platforma si Tehnologia folosita pentru implementarea WS-urilor
Care este platforma tehnologica folosita?
Ce fel de aplicatie server este necesara?
Raspunsul la aceste intrebari duce la interoperabilitate crescuta intre servicii.

29. Conformarea la Standardele Industriei. Componente software adresabile
Conformitatea cu standardele industriei determina tipurile de servicii.  Aceasta duce la necesitatea unui XML bine format si a unui WS bazat pe document pentru serviciu.
Fiecare serviciu este idenficabil printr-un URL. Pentru a sti daca un serviciu este disponibil se va face un test de invocare a serviciului  care va arata disponibilitatea acestuia.

30. Nevoile WS-urilor
WS-urile sunt folosite pentru a solutiona diverse nevoi si obiective de business.
Factorii ce trebuie luati in considerare sunt:
refolosirea componentelor de business,
integrarea diferitelor platforme IT si a diferitelor tehnologii,
integrare directa business-to-business (B2B) intre parteneri pentru a facilita interschimbul de informatii.
Intelegerea nevoilor de baza conduce la descoperirea tipului de WS ce va fi folosit.

31. Arhitectura pe Layere a WS-urilor
Nevoia de abstractizare ierarhica pentru WS-uri determina relatiile slab-cuplate intre servicii.
Analiza lacunelor metodologiei software-ul pentru servicii Web (WS), studiul caracteristicilor Web Services şi cele mai bune practici discutate anterior se completează reciproc. Aceasta formează baza pentru extinderea metodologiei software-ului existent cu cele mai bune practici pentru servicii de Web (WSBP).

32. Arhitectura pe Layere a WS-urilor
Efortul major consta in parcurgerea tuturor activităţilor şi sarcinilor definite pentru fiecare faza a ciclului de viaţă a software-ului prin analiza modului in care cele mai bune practici pentru servicii Web ar putea fi utilizate.
Fazele identificate sunt: identificarea cerințelor, analiză, proiectare, implementare, testare și incarcare pe server.

33. Identificarea cerintelor
Obiectivul acestei etape este de a înţelege cerinţele afacerii şi traducerea acestora în cerințe WS în ceea ce privește caracteristicile, condițiile funcționale și non-funcţionale şi restricţiile WS. WSBP13 oferă linii directoare pentru identificarea Web Services, clasificand nevoile în servicii Web. Determina caracteristicile necesare pentru serviciile Web.
Defineşte utilizarea modelelor pentru serviciile Web respective.

34. Analiza
Obiectivul acestei etape este de a determina cerințele suplimentare şi a traduce cerințele în modele conceptuale. Analiza arhitecturala este făcuta pentru a defini structura la nivel înalt şi a identifica interfeţele serviciilor Web . WSBP1, WSBP2, WSBP5, WSBP6, WSBP10 furnizeaza orientări de analiză pentru următoarele activități:

35. Analiza. Activitati
Analiza granularitatii interfetelor serviciilor WEB
Selectarea platformei tehnologice pentru implementarea cadrului de lucru
Definirea arhitecturilor posibile de servicii WEB. Identificarea componentelor arhitecturale care vor fi expuse ca WS-uri si principalele informatii care vor fi schimbate cu clientul

36. Proiectarea
Obiectivul acestei etape este de a detalia proiectarea serviciului WEB. In aceasta faza se detaliaza interfata WS-ului.
Este luata in considerare interfata intre seviciu si client, adica asincron/sincron sau rpc/document.
Sunt luate in considerare cele mai bune practici pentru serviciile WEB corespunzatoare pentru WSBP1, WSBP2, WSBP3, WSBP5, WSBP6, WSBP7 .

37. Implementarea
Obiectivul acestei etape este de a face codificarea reala a serviciilor Web.
Este realizata impachetarea componentelor API in interfaţă Serviciilor Web.
Sunt generate WS de testare client şi WSDL.
WS vor fi implementate în serverul de aplicaţie ţintă.
Cele mai bune practici pentru WS referitoare la WSBP1 furnizeaza orientări pentru punerea în aplicare a serviciilor Web.

38. Testarea
Obiectivul acestei faze este efectuarea unui test complet de servicii Web, inclusiv cerințele funcționale și non-funcţionale.
Cele mai bune practici WS pentru WSBP1 pana la WSBP10 furnizeaza orientări pentru testarea de servicii Web.

39. Incarcarea pe server
Obiectivul acestei faze este incarcarea corespunzatoare a serviciului Web în serverul de aplicaţie tinta.
Pentru a valida incarcarea corespunzatoare a WS, clientul Ws-ului participa la incarcare.
Pentru WSBP1, utilizatorul va specifica daca publicarea serviciului WEB este necesara in interiorul organizatiei sau este extinsa la partenerii de afaceri sau pentru utilizari externe.
Aceasta va determina decizia de avea acces pubic sau privat pentru a servi nevoilor companiei.

40. Figura 3. Metodologia Extinsa
In figura se prezinta o vedere generala asupra ciclului de viata a metodologiei extinse care incorporeaza cele mai bune practici WS in diferite faze ale ciclului de viata.

41. Figura 3. Metodologia Extinsa

42. WSBP= Web Service Best Practice

43. Bibliografie
Lucas Jelema -Oracle SOA 11g Handbook –Implement an Enterprisewide Service Oriented Arhitecture.