Construirea Aplicatiilor de tip SOA

1. Construirea Aplicatiilor de tip SOA Matei Petruţ-Bogdan 342C5 mateipetrutbogdan@gmail.com Protocoale de comunicaţie – Prezentări Laborator

2. SOA ? Protocoale de comunicaţie – Prezentări Laborator

3. SOA ? Termen introdus de Yefim Natis intr-o lucrare de cercetare (1994): “SOA este o arhitectura software care porneste de la o definitie de interfata si construieste intreaga topologie a aplicatiei ca o topologie de interfete, implementari de interfete si apeluri de interfete”

4. SOA ? The SOA implementation rely on a mesh of software services. http://en.wikipedia.org

5. SOA ? | Serviciu ? Serviciu ?

6. SOA ? | Serviciu ? • Nevoia de informație din domenii diverse • În context local informația este stocată sub diferite forme (documente, multimedia, metadate, etc) • În mod general informația este stocată în mod binar • De obicei există o colecție de date disponibile la un anumit moment de timp • Din această colecție doar o parte reprezintă informații • Exemplu : Baza de date este o colecție de date dar o cerere formulată în conformitate cu necesitățile reprezintă o informației

7. SOA ? | Serviciu ? In concluzie, un serviciu ...

8. SOA ? | Serviciu ? Pune la dispoziția utilizatorului informaţii • Este de două tipuri : • Local • La distanță (remote) • În esenţă este o aplicaţie ce oferă utilizatorului informaţii în urma apelării unor proceduri bine definite.

9. SOA ? The SOA implementation rely on a mesh of software services.

10. SOA ? Arhitectura simplă: • Browser • Web Server • Order-Processing • Database Server • Database

11. SOA ? Dorim sa mai adaugam o facilitate ?

12. SOA ? • Partea de procesare a comenzilor are nevoie de a procesa platile prin card de credit/ debit • Nu ne intereseaza cum proceseaza cardurile de credit/ debit, ne intereseaza doar rezultatul si cum sa ii trimitem datele  Black Box

13. SOA ?

14. REGULI SOA REGULI in dezvoltarea serviciilor

15. REGULI SOA 1. Componente interschimbabile

16. 1.COMPONENTE INTERSCHIMBABILE • O componenta trebuie sa acopere un rol bine definit • Format de intrare bine definit • Format de iesire bine deinit • Daca modificam logica interna unei componente, celalalte componente care interactioneaza cu aceasta nu trebuie modificate • Avand acestea definite, o componenta poate fi refolosita oriunde este nevoie, de catre oricine, daca respecta standardul de intrare/ iesire

17. REGULI SOA 2. Componente elementare

18. 2. COMPONENTE ELEMENTARE • Nici o componenta nu face mai mult decat este necesar, de exemplu: • Componenta de “Credit Checking” doar verifica plata cu cardul. Nu ofera si alte servicii. • Pentru alte servicii necesare se creeaza alte componente.

19. Componentele de baza SOA

20. COMPONENTE DE BAZA SOA • Furnizor de serviciu (Serviciu) - ofera procese in forma de servicii • Consumator de serviciu (Consumator) • serviciile oferite de furnizor sunt apelate de consumator • poate gasi descrierea serviciului intr-un registru de servicii si apoi poate sa se conecteze si sa invoce acel serviciu • Registru de Servicii (permise de Broker) – intre furnizor si consumator

21. COMPONENTE DE BAZA SOA Broker de servicii • Arhitectura sistemului poate deveni foarte complexa • Trebuie sa vedem ca totul merge comform planului de la un capat la celalalat (end-to-end) • Monitorizeaza fiabilitatea sistemului si anunta in cazul in care serviciile nu au performanta dorita sau au erori

22. COMPONENTE DE BAZA SOA Registrul SOA • Baza de date cu servicii: • Nume • Descriere • Autor • Drepturi • Publica servicii • Colecteaza metadate despre servicii • Ca o piata cu produse 9 octombrie 2014 Intergrarea Sistemelor Informatice 22

23. Gruparea Serviciilor pe nivele

24. GRUPAREA SERVICIILOR PE NIVELE

25. GRUPAREA SERVICIILOR PE NIVELE • Nivelul operational • include aplicatii de tip CRM (Customer Relationship Management) si ERP (Enterprise Resource Planning), implementari ale sistemului mai vechi, orientate obiect, aplicatii inteligente • Nivelul componentelor intreprinderii: • foloseste aplicatii server pentru a implementa componentele, gestiunea volumului de munca si echilibrarea traficului

26. GRUPAREA SERVICIILOR PE NIVELE • Nivelul de servicii: • cuprinde serviciile fondate si expuse: pot fi descoperite sau legate static si apoi invocate • furnizeaza un mecanism prin care se realizeaza servicii la rulare, folosind functionalitatea data de interfata • interfetele sunt exportate ca descrieri de servicii si expuse pentru a fi folosite; ele pot exista izolate sau ca servicii compuse • Nivelul 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

27. GRUPAREA SERVICIILOR PE NIVELE • Nivelul prezentare sau acces • Nivelul integrare • permite 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 integrare • Nivelul QOS: • furnizeaza capabilitati necesare pentru a monitoriza, gestiona, mentine QOS: securitate, performanta, valabilitate • este un process de background

28. Procesul de modelare a arhitecturii orientate pe servicii

29. Procesul de modelare Consta in trei pasi: • Identificarea serviciilor • Clasificarea serviciilor • Realizarea serviciilor

30. PROCES DE MODELARE 1.Identificare serviciilor • descompunerea domeniului in ariile si subsistemele sale, incluzand descompunerea proceselor sau fluxului in subprocese si cazuri de utilizare

31. PROCES DE MODELARE 2.Clasificare Serviciilor • clasificare ar trebui sa fie realizata ca o ierarhie, care sa reflecte natura compusa a serviciilor • detaliile componentelor care implementeaza serviciile: date, reguli, servicii, profiluri configurabile • trimiterea de mesaje si specificatiile evenimentelor

32. PROCES DE MODELARE 3.Realizarea Serviciilor • construirea unei serii de obiecte si componente de nivel scazut, cu granularitate fina si apoi construirea unui serviciu granulat aspru din acestea.

33. SOFTWARE AS A SERVICE

34. SOFTWARE AS A SERVICE • Odata cu izolarea servicilor si definirea interfetei de intrare/iesire devine posibila vanzarea servicilor • Ex: O firma are un serviciu de calculat impozitul anual al angajatilor. Face acest serviciu public si percepe o taxa pentru folosirea lui de catre firme externe si obtine o noua sursa de profit • Clientul plateste pentru fiecare folosire a aplicatiei • Se observa un trend ascendent in servicii accesibile pe internet in urma unei sume de bani

35. Avantaje

36. AVANTAJE • Companie mare  mult cod duplicat • Se poate reclicla codul in mai multe proiecte (Resurse refolosite) • Interactiunea cu serviciile unei companii externe • Posibilitatea de a standardiza interfata de access la serviciile oferite • Se poate ascunde ce este in spate • Adaptabilitate– se pot face schimbari ale sistemului cu un minim de efort si complexitate, in mai putin timp si cu mai putini bani

37. Dezavantaje

38. DEZAVANTAJE Servicii slab cuplate ! • probabil cel mai critic element intr-un sistem SOA • are impact direct asupra abilitatii 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 celeilalte • cuplarea 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 servicii

39. IN CONCLUZIE ...

40. IN CONCLUZIE • Crearea cu succes a aplicatiilor orientate pe servicii presupune • separarea si modularizarea logicii de business pentru a facilita refolosirea si flexibilitatea • folosirea de servicii slab cuplate pentru a putea fi dezvoltate rapid cand cerintele se schimba • proiectarea unei granularitati potrivite a serviciilor • planificarea si implementarea tuturor pasilor din procesul de modelare • Companie mare  mult cod duplicat • Se poate reclicla codul in mai multe proiecte (Resurse refolosite) • Interactiunea cu serviciile unei companii externe (SAS) • Posibilitatea de a standardiza interfata de access la serviciile oferite • Adaptabilitate– se pot face schimbari ale sistemului cu un minim de efort si complexitate, in mai putin timp si cu mai putini bani Protocoale de comunicaţie – Prezentări Laborator

41. Va mulţumesc! • Referinte: • “Service Oriented Architecture for Dummies” by Judith Hurwitz, Robin Bloor,Carol Baroudi and Marcia Kaufman • http://www.wikipedia.org Protocoale de comunicaţie – Prezentări Laborator