Lo Parliamo di SOA (Service Oriented Architecture) Antonio Pintus, Marco Marongiu
Chi siamo Antonio Pintus  è laureato in Informatica e studente di Dottorato di Ricerca in Informatica con argomenti relati...
Di cosa parliamo... <ul><li>Sistemi eterogenei, non progettati per parlare fra loro, da integrare, di qualunque dimensione...
Service Oriented Architecture (SOA): introduzione (1) <ul><li>In un recente passato, i sistemi enterprise, spesso si diffe...
Service Oriented Architecture (SOA): introduzione (2) <ul><li>Inizialmente nata come soluzione software per l'integrazione...
Vantaggi di SOA <ul><li>Interoperabilità tra sistemi eterogenei </li></ul><ul><li>Standardizzazione delle interazioni </li...
Svantaggi di SOA <ul><li>l'aggiunta di un certo numero di livelli di indirezione porta ad una maggiore lentezza </li></ul>...
Concetti base <ul><li>Servizi </li></ul><ul><ul><li>insieme di componenti software che implementano una funzionalità  </li...
Componenti base <ul><li>Infrastruttura </li></ul><ul><ul><li>Comunemente è l' Enterprise Service Bus (ESB) , il cui ruolo ...
Il concetto di Servizio (1) <ul><li>Un servizio è un modulo software, autonomo e indipendente dalla piattaforma, indipende...
Il concetto di Servizio (2) <ul><li>I servizi diventano quindi le unità “atomiche” per il design e l'implementazione di ar...
Interoperabilità e disacoppiamento (loose-coupling) (1) <ul><li>Web Services: la tecnologia dei Web Service è rapidamente ...
Interoperabilità e disacoppiamento (loose-coupling) (2) <ul><li>I web service sono un sistema  sincrono </li></ul><ul><li>...
Enterprise Service Bus (ESB) <ul><li>Realizza la comunicazione fra i servizi </li></ul><ul><li>Permette l'invocazione dei ...
Enterprise Service Bus (ESB) Applicazioni Enterprise Applicazioni  Java .NET, ... Mainframe, Applicazioni legacy BPEL orch...
Service Orchestration <ul><li>Un'orchestrazione di servizi descrive come essi possono interagire tra di loro a livello di ...
Service Coreography <ul><li>Ogni servizio conosce solo il suo “compito” e come passare ai servizi che lo seguono nella cat...
API <ul><li>In questo caso si utilizzano i prodotti di un vendor che mette a disposizione una API e dei tool di sviluppo p...
Esempi
Architettura di esempio Enterprise Service Bus (ESB) SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (...
Esempio: flusso non integrato <ul><li>qualcuno inserisce un ticket di fault su TT </li></ul><ul><li>S1 vede il fault, lo p...
Coreografia (con messaggi one-way) S1 S2 Enterprise Service Bus (ESB) SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON...
Coreografia (ottimizzato) S1 S2 Adapter SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (FM)
Messaggi asincroni S1 S2 FM.OPEN SMS.IN FM.CLOSE TT.FAULT.OPEN SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault...
Un altro approccio: Web Services (1) <ul><li>Tutti i servizi sono realizzati: </li></ul><ul><ul><ul><ul><li>O come Web Ser...
Un altro approccio: Web Services (2) S1 S2 Enterprise Service Bus (ESB) SMS gateway WS (GW) Trouble Ticket WS (TT) Monitor...
Riferimenti [1] Michael P. Papazoglou,  “Web Services: Principles and Technology” , Pearson Prentice Hall, 2007 [2] Nicola...
Grazie per l'attenzione.
Upcoming SlideShare
Loading in …5
×

Parliamo di SOA

5,520 views

Published on

Seminario tenuto da Antonio Pintus e Marco Marongiu avente come obbiettivo una introduzione ragionata a SOA.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,520
On SlideShare
0
From Embeds
0
Number of Embeds
569
Actions
Shares
0
Downloads
189
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Insert your notes here.
  • Parliamo di SOA

    1. 1. Lo Parliamo di SOA (Service Oriented Architecture) Antonio Pintus, Marco Marongiu
    2. 2. Chi siamo Antonio Pintus è laureato in Informatica e studente di Dottorato di Ricerca in Informatica con argomenti relativi a &quot;Service Oriented Architecture&quot;. Lavora come Software Engineer presso il CRS4 (Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna). pintux[AT]pintux.it Marco Marongiu è laureato in Matematica. Lavora come System Administrator per Tiscali nella sede di Sa Illetta a Cagliari. Attualmente il suo compito principale è la gestione sistemistica dell'infrastruttura SOA di Tiscali, basata su prodotti TIBCO. Scrive inoltre su riviste e siti web specializzati, in Italia e all'estero. mmarongiu[AT]tiscali.com
    3. 3. Di cosa parliamo... <ul><li>Sistemi eterogenei, non progettati per parlare fra loro, da integrare, di qualunque dimensione </li></ul><ul><li>Sistemi distribuiti di grandi dimensioni, fuori dal controllo di una singola organizzazione </li></ul><ul><li>Sistemi in ambito “business”, ma ultimamente la SOA si sta utilizzando anche in ambito scientifico </li></ul>
    4. 4. Service Oriented Architecture (SOA): introduzione (1) <ul><li>In un recente passato, i sistemi enterprise, spesso si differenziavano (di fatto creando notevoli incompatibilità tra di essi) per l'adozione di tutta una serie di diversi protocolli, interfacce, tecnologie e prodotti commerciali </li></ul><ul><li>Nonostante ci siano stati tutta una serie di approcci per rendere più interoperabili questi sistemi, è sinora mancato una effettiva definizione ed impiego di standard </li></ul>
    5. 5. Service Oriented Architecture (SOA): introduzione (2) <ul><li>Inizialmente nata come soluzione software per l'integrazione di sistemi eterogenei in ambito Business-to-Business (B2B) </li></ul><ul><li>Giunta a poter essere considerata, da un punto di vista più astratto, come un' architettura , un modello di programmazione ed un paradigma con lo scopo di raggiungere un disacoppiamento (o basso livello di accoppiamento ) nel design di applicazioni distribuite costituite da agenti software ( servizi ) interagenti tra loro </li></ul><ul><li>Modello pervasivo, oltre che inter-enterprise, anche intra-enterprise e a tutti i livelli, dal management al settore IT </li></ul>
    6. 6. Vantaggi di SOA <ul><li>Interoperabilità tra sistemi eterogenei </li></ul><ul><li>Standardizzazione delle interazioni </li></ul><ul><li>Astrazione dai dettagli implementativi </li></ul><ul><li>Scalabilità </li></ul><ul><li>Adattività ai rapidi cambiamenti delle esigenze di business </li></ul><ul><li>Monitoring </li></ul><ul><li>Governance </li></ul><ul><li>Libertà nella scelta delle piattaforme di sviluppo </li></ul>
    7. 7. Svantaggi di SOA <ul><li>l'aggiunta di un certo numero di livelli di indirezione porta ad una maggiore lentezza </li></ul><ul><li>Complessità: sviluppare, fare il debugging e mantenere sistemi distribuiti con un basso livello di accoppiamento tra le componenti è piuttosto complesso </li></ul><ul><li>Spesso l'adozione di questo modello impone un adattamento anche nell'organizzazione delle persone </li></ul>
    8. 8. Concetti base <ul><li>Servizi </li></ul><ul><ul><li>insieme di componenti software che implementano una funzionalità </li></ul></ul><ul><li>Interoperabilità </li></ul><ul><ul><li>capacità di sistemi diversi di comunicare fra loro </li></ul></ul><ul><li>Disaccoppiamento (loose coupling) </li></ul><ul><ul><li>condizione di dipendenza ridotta o assente fra diversi componenti di un sistema distribuito </li></ul></ul>
    9. 9. Componenti base <ul><li>Infrastruttura </li></ul><ul><ul><li>Comunemente è l' Enterprise Service Bus (ESB) , il cui ruolo è permettere l'interoperabilità </li></ul></ul><ul><li>Architettura </li></ul><ul><ul><li>ad alto livello: i sistemi, i servizi, le interfacce, il bus </li></ul></ul><ul><li>Processi </li></ul><ul><ul><li>Sequenza di azioni da eseguire per implementare una certa funzionalità di business (ne parleremo in concreto più avanti) </li></ul></ul>
    10. 10. Il concetto di Servizio (1) <ul><li>Un servizio è un modulo software, autonomo e indipendente dalla piattaforma, indipendente dal linguaggio di programmazione usato e progettato per consentire una interazione di tipo Machine-to-Machine (M2M) attraverso la rete. </li></ul><ul><li>E' un'astrazione software di un processo reale </li></ul><ul><ul><li>In particolare potrebbe essere un servizio orientato al Business-to-Business (B2B) </li></ul></ul><ul><li>Fornitore del servizio (Service Provider ): la parte che fornisce e rende disponibile il servizio. </li></ul><ul><li>Fruitore del servizio (Service Consumer ): la parte che consuma il servizio utilizzandolo per il proprio processo di business </li></ul>
    11. 11. Il concetto di Servizio (2) <ul><li>I servizi diventano quindi le unità “atomiche” per il design e l'implementazione di architetture software distribuite che rispondono all'esigenza di processi di business anche molto complessi nonché potenzialmente decentralizzati ed eterogenei. </li></ul><ul><li>I servizi possono essere composti tra loro </li></ul><ul><ul><li>Nuove applicazioni possono essere “rapidamente” costruite mediante una loro composizione </li></ul></ul><ul><li>Si parla di orchestrazione e coreografia di servizi </li></ul><ul><ul><li>esistono approcci alternativi; fra questi stanno prendendo quota gli eventi , da cui le Event-Driven Architecture </li></ul></ul><ul><li>Le applicazioni composte sono a loro volta un servizio </li></ul>
    12. 12. Interoperabilità e disacoppiamento (loose-coupling) (1) <ul><li>Web Services: la tecnologia dei Web Service è rapidamente diventata la tecnologia abilitante per SOA. </li></ul><ul><li>Web Services (WS), una definizione: </li></ul><ul><ul><li>“ A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” (W3C) </li></ul></ul><ul><li>Grazie alle descrizioni formali e gli standard definiti per i WS, essi sono oggi ampiamente utilizzati, riuscendo a garantire anche l'interoperabilità, il disacoppiamento e indipendenza dalla piattaforma. </li></ul>
    13. 13. Interoperabilità e disacoppiamento (loose-coupling) (2) <ul><li>I web service sono un sistema sincrono </li></ul><ul><li>La comunicazione può essere anche asincrona </li></ul><ul><ul><ul><li>Nessuno dei due schemi è vincente di per sé, la scelta deve essere strettamente legata al contesto in cui il servizio andrà ad operare </li></ul></ul></ul><ul><li>Un approccio asincrono è basato sullo scambio di messaggi, che può avvenire secondo modelli diversi (si parla di Message Exchange Patterns o MEP) </li></ul><ul><li>Uno strumento è fornito da prodotti che implementano la specifica JMS (messaggistica basata su code o su “topic”) </li></ul>
    14. 14. Enterprise Service Bus (ESB) <ul><li>Realizza la comunicazione fra i servizi </li></ul><ul><li>Permette l'invocazione dei servizi su sistemi eterogenei </li></ul><ul><ul><li>supporto allo scambio dei messaggi </li></ul></ul><ul><ul><li>la trasformazione dei dati </li></ul></ul><ul><ul><li>il routing intelligente dei messaggi </li></ul></ul><ul><ul><li>gestione dell'affidabilità e sicurezza </li></ul></ul><ul><ul><li>monitoring e management dei servizi </li></ul></ul><ul><li>Costituisce una “backbone” che tratta le applicazioni come servizi, consentendo la composizione e la comunicazione tra applicazioni con: loose coupling, Messaggi, “Plug & Play” di applicazioni enterprise eterogenee </li></ul>
    15. 15. Enterprise Service Bus (ESB) Applicazioni Enterprise Applicazioni Java .NET, ... Mainframe, Applicazioni legacy BPEL orchestration Data Sources Immagine adattata, si veda il rif. [1] Enterprise Service Bus (ESB) JMS / JavaEE MQ gateway Distributed Query Engine Web Services Adapters Service orchestration Applications ...
    16. 16. Service Orchestration <ul><li>Un'orchestrazione di servizi descrive come essi possono interagire tra di loro a livello di messaggi, includendo la logica di business e l'ordine di esecuzione delle interazioni </li></ul><ul><ul><ul><ul><li>L'intero flusso e la sua esecuzione sono sempre controllati da una delle parti coinvolte nel processo. </li></ul></ul></ul></ul><ul><li>Mediante orchestration quindi è possibile definire un processo di business multi-step, eseguibile, potenzialmente di lunga durata e transazionale </li></ul><ul><ul><ul><ul><li>WS-BPEL il linguaggio più usato </li></ul></ul></ul></ul>
    17. 17. Service Coreography <ul><li>Ogni servizio conosce solo il suo “compito” e come passare ai servizi che lo seguono nella catena il prodotto della loro elaborazione </li></ul><ul><ul><li>è il modello del “passacarte” </li></ul></ul><ul><ul><li>Non c'è una “entità centrale” che ha conoscenza di tutto il processo e lo dirige </li></ul></ul><ul><li>Vantaggi: l'implementazione di un servizio coreografico è concettualmente più semplice </li></ul><ul><li>Svantaggi: </li></ul><ul><ul><li>capire dove un processo si è “incastrato” può diventare complicato </li></ul></ul><ul><ul><li>non ci sono standard e tool consolidati come per BPEL e orchestrazione </li></ul></ul>
    18. 18. API <ul><li>In questo caso si utilizzano i prodotti di un vendor che mette a disposizione una API e dei tool di sviluppo per costruire i servizi </li></ul><ul><li>I servizi e il bus condividono la API </li></ul><ul><li>Vantaggi: lo sviluppatore non deve occuparsi di dettagli di basso livello (p.e.: protocollo di comunicazione, reliability, gestione degli errori...) </li></ul><ul><li>Svantaggi: si è legati al vendor, ai suoi prodotti e alle loro modifiche, al suo servizio di supporto... </li></ul>
    19. 19. Esempi
    20. 20. Architettura di esempio Enterprise Service Bus (ESB) SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (FM) S1 S2
    21. 21. Esempio: flusso non integrato <ul><li>qualcuno inserisce un ticket di fault su TT </li></ul><ul><li>S1 vede il fault, lo prende in carico e allerta S2 </li></ul><ul><li>S2 importa il fault su FM </li></ul><ul><li>FM invia per SMS attraverso GW gli aggiornamenti del ticket </li></ul><ul><li>risolto il problema, S2 chiude il ticket su TT </li></ul><ul><li>FM rileva la chiusura del fault e manda l'ultimo aggiornamento via GW </li></ul>
    22. 22. Coreografia (con messaggi one-way) S1 S2 Enterprise Service Bus (ESB) SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (FM)
    23. 23. Coreografia (ottimizzato) S1 S2 Adapter SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (FM)
    24. 24. Messaggi asincroni S1 S2 FM.OPEN SMS.IN FM.CLOSE TT.FAULT.OPEN SMS gateway (GW) Trouble Ticket (TT) Monitoring (MON) Fault manager (FM)
    25. 25. Un altro approccio: Web Services (1) <ul><li>Tutti i servizi sono realizzati: </li></ul><ul><ul><ul><ul><li>O come Web Service </li></ul></ul></ul></ul><ul><ul><ul><ul><li>O dispongono di un adapter di tipo Web Service </li></ul></ul></ul></ul><ul><li>La gestione dei processi automatici ora avviene mediante una Web Service Orchestration: </li></ul><ul><ul><ul><ul><li>Mediante un processo BPEL, “long-running”, capace di reagire ad eventi (asincroni) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Per esempio alla chiusura del ticket che termina di fatto il processo </li></ul></ul></ul></ul>
    26. 26. Un altro approccio: Web Services (2) S1 S2 Enterprise Service Bus (ESB) SMS gateway WS (GW) Trouble Ticket WS (TT) Monitoring (MON) Fault manager WS (FM) BPEL orchestration SMS close
    27. 27. Riferimenti [1] Michael P. Papazoglou, “Web Services: Principles and Technology” , Pearson Prentice Hall, 2007 [2] Nicolai M. Josuttis, “SOA in Practice – The Art of Distributed System Design”, O'Reilly, 2007 [3] AA.VV. : “SOA Practiotioners' Guide”, part 1, 2, 3. http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html http://www.soablueprint.com/practitioners_guide
    28. 28. Grazie per l'attenzione.

    ×