DEZVOLTAREA APLICATIILOR SOA INTR-O FIRMA

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.

10
(No Transcript)
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. gt URD
• Se analizeaza componentele business existente
  pentru reutilizare gt Lista de componente
• Se proiecteaza serviciul Web. gt 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. gt 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. gt Publicare
  Locala
• Se testeaza si corecteaza WS folosindu-se  de
  clientul de web-service.
• Se publica WS-ul gt 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 si cele mai bune practici discutate
  anterior se completeaza reciproc. Aceasta
  formeaza 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
  activitatilor si sarcinilor definite pentru
  fiecare faza a ciclului de viata 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, analiza, proiectare, implementare,
  testare ?i incarcare pe server.

33
Identificarea cerintelor

• Obiectivul acestei etape este de a întelege
  cerintele afacerii si traducerea acestora în
  cerin?e WS în ceea ce prive?te caracteristicile,
  condi?iile func?ionale ?i non-functionale si
  restrictiile WS. WSBP13 ofera linii directoare
  pentru identificarea Web Services, clasificand
  nevoile în servicii Web. Determina
  caracteristicile necesare pentru serviciile Web.
• Defineste utilizarea modelelor pentru serviciile
  Web respective.

34
Analiza

• Obiectivul acestei etape este de a determina
  cerin?ele suplimentare si a traduce cerin?ele în
  modele conceptuale. Analiza arhitecturala este
  facuta pentru a defini structura la nivel înalt
  si a identifica interfetele serviciilor Web .
  WSBP1, WSBP2, WSBP5, WSBP6, WSBP10 furnizeaza
  orientari de analiza pentru urmatoarele
  activita?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
  interfata Serviciilor Web.
• Sunt generate WS de testare client si WSDL.
• WS vor fi implementate în serverul de aplicatie
  tinta.
• Cele mai bune practici pentru WS referitoare la
  WSBP1 furnizeaza orientari 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-functionale.
• Cele mai bune practici WS pentru WSBP1 pana la
  WSBP10 furnizeaza orientari pentru testarea de
  servicii Web.

39
Incarcarea pe server

• Obiectivul acestei faze este incarcarea
  corespunzatoare a serviciului Web în serverul de
  aplicatie 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.
• http//www.fibre2fashion.com/industry-article/9/80
  7/web-services-implementation-methodology-for-soa-
  application6.asp