Comprendere l'architettura service oriented

1,721 views

Published on

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

No Downloads
Views
Total views
1,721
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Comprendere l'architettura service oriented

  1. 1. Comprendere l’architettura Service-Oriented
  2. 2. UNA PRIMA INTRODUZIONE TEORICAComprendere l’architettura SOA
  3. 3. Introduzione Sembra probabile che la maggior parte del software possa essere realizzato e consumato sotto forma di servizio I sistemi possono essere spesso disaccoppiati in maniera tale da renderne fruibile le funzionalità da portali, da dispositivi o da qualunque mezzo sia in grado di esporre una interfaccia Il timore concreto, manifestato da architetti e designer, è quello di mantenere una certa prudenza in questo approccio Il pericolo è che tutto il software possa essere pensato e progettato sotto forma di servizio E questo approccio può generare solo confusione Comprendere l’architettura SOA 3
  4. 4. Approccio tecnologico In realtà, tutto quello che può essere realizzato in forma di web service, può essere visto come un servizio E la maturità tecnologica di questo paradigma può spingere facilmente verso questa direzione Ma questo non toglie la necessità di progettare tutto da una prospettiva di servizio solo quando è conveniente Il servizio è la parte principale della progettazione e deve essere utilizzato correttamente in tutti i punti significativi di ogni interfaccia Comprendere l’architettura SOA 4
  5. 5. Influenza nel ciclo di vita del software L’architettura Service-Oriented ci consente di gestire completamente i servizi da realizzare La gestione è intesa sia in termini di design che di rilascio, manutenzione e utilizzo Questo comporta notevoli implicazioni nella modo di gestire il ciclo di vita del software Si può passare direttamente dalla specifica dei requisiti (che possono rappresentare direttamente i servizi da erogare), alla loro progettazione in forma di servizi Inoltre è altamente facilitato l’utilizzo di altri servizi esterni Comprendere l’architettura SOA 5
  6. 6. Evoluzione naturale Nel corso del tempo, il livello di astrazione delle specifiche funzionali, è divenuta progressivamente sempre più alta Il modello si è evoluto, prima dalla forma di moduli, quindi agli oggetti, poi ai componenti, e ora ai servizi Tuttavia, il concetto di SOA, anche se applicato naturalmente alle architetture, può facilmente travalicare questo limite Non è possibile limitare la discussione alla sola architettura, perché il concetto può essere applicato anche ad ambiti diversi Un esempio possono essere il Business Design (disegno della logica di business) e il Delivery Process (fase di rilascio) Comprendere l’architettura SOA 6
  7. 7. Paradigmi e parallelismi La nomenclatura più corretta dovrebbe essere SO (Service- Orientation), applicabile a diversi contesti Ci sono anche diversi paralleli con il paradigma OO (Object- Oriented) e con quello CBD (Component-Based Development) Alla stregua degli oggetti e dei componenti, i servizi sono i mattoni naturali per lo sviluppo delle funzionalità E allo stesso modo ci consentono di realizzare queste funzionalità in maniera tale da consentirne l’uso in un modo a noi familiare Comprendere l’architettura SOA 7
  8. 8. Paradigmi e parallelismi Inoltre, sempre come gli oggetti e i componenti, i servizi ci consentono di:  combinare le informazioni e i comportamenti  proteggere le funzionalità interne dalle intrusioni  presentarsi con interfacce semplici per l’integrazione Laddove gli oggetti usano astrazioni sui dati, i servizi sono in grado di fornire una similitudine con l’utilizzo di un contesto Mentre oggetti e componenti si organizzano con delle classi con comportamenti ereditabili, i servizi possono organizzarsi autonomamente in forma gerarchica o collaborativa Comprendere l’architettura SOA 8
  9. 9. Analogie con i Web Services Spesso le aziende tendono a progettare le architetture basate sui servizi, basandole sull’uso dei web services Sebbene ci siano diversi similitudini, possiamo comunque affermare da subito che i web services non sono strettamente inerenti alle architetture basate su servizi I web services infatti, eseguono meramente delle funzionalità, esponendole attraverso i protocolli web Bisogna stabilire delle linee guida per discernere la necessità di utilizzo dei due paradigmi Comprendere l’architettura SOA 9
  10. 10. Principi e definizioni Oramai il termine SOA è largamente utilizzato, addirittura quasi inflazionato Tuttavia le varie definizioni che troviamo in giro generano un po’ di confusione sul concetto esatto di questo termine L’autorevole W3C (World Wide Web Consortium) identifica il termine SOA con la definizione: Service-Oriented Architecture: “A set of components which can be invoked, and whose interface descriptions can be published and discovered” Comprendere l’architettura SOA 10
  11. 11. Principi e definizioni Quella del W3C è la definizione più comunemente diffusa Il limite (se vogliamo) di questa definizione è che rappresenta l’architettura in maniera esplicitamente tecnica Infatti il termine architettura non si presta soltanto al disegno architetturale nel senso informatico del termine Abbiamo già detto infatti che gli ambiti applicativi possono essere tanti e diversi Comprendere l’architettura SOA 11
  12. 12. Principi e definizioni Un’altra entità importante in questo ambito è la CBDI L’acronimo CBDI sta per Component-Based Development and Integration Si tratta di un organismo autonomo che si occupa principalmente dello studio e nella definizione delle best practices relative all’ambito SOA L’indirizzo del sito è: http://www.cbdiforum.com/ Comprendere l’architettura SOA 12
  13. 13. Principi e definizioni Il CBDI ritiene la definizione del W3C estremamente riduttiva, e quindi utilizza per SOA una definizione “più ampia” E’ utile a questo scopo effettuare dei paragoni tra la definizione del W3C e quella del CBDI Queste differenze ci aiuteranno a capire meglio i limiti e gli ambiti in cui collocare il concetto di servizio Comprendere l’architettura SOA 13
  14. 14. Definizioni – “Service” Service  Un componente capace di eseguire un task. Un servizio WSDL: una collezione di endpoints (W3C)  Un insieme di funzionalità descritte con un WSDL (CBDI) Service Definition  Un sistema utilizzato dal consumer del servizio per accordarsi (implicitamente or esplicitamente) sulle modalità di erogazione del servizio, sulle sue regolamentazioni, sulle funzioni offerte e quant’altro (CBDI) A Service Fulfillment (adempimento del servizio)  Una istanza di esecuzione del servizio e delle sue funzionalità Comprendere l’architettura SOA 14
  15. 15. Definizioni – “Web Service” Web Service  (W3C) • Un sistema software capace di supportare l’interazione tra sistemi • L’interazione avviene normalmente nell’ambito di una rete • E’ fornito di una interfaccia descrittiva delle funzionalità esposte • Tale interfaccia viene normalmente fornita in un formato tale da essere elaborato dai sistemi (WSDL) • Consente l’utilizzo delle funzionalità che espone, attraverso l’uso di messaggi SOAP, l’impiego di serializzazioni XML ed altri meccanismi standard dell’ambito web  (CBDI) • Una interfaccia programmatica verso una funzionalità conforme ai protocolli WS-* Comprendere l’architettura SOA 15
  16. 16. Definizioni – “Web Service” Web Service  La definizione dei Web Services data da CBDI rispetto a quella del W3C indica l’intenzione di non considerare i web service come componenti  Inoltre CBDI suggerisce l’utilizzo di tipo, definizione e adempimento del servizio come parti separate  Ma è nella definizione di SOA che CBDI realmente si distingue dal W3C Comprendere l’architettura SOA 16
  17. 17. Definizioni – “Service-Oriented Architecture” Service-Oriented Architecture  Abbiamo già detto che la definizione del W3C ritiene che l’architettura SOA possa essere intesa come: “un insieme di componenti che possono essere invocati, e che espongono una interfaccia descrittiva dei servizi offerti, che può essere pubblicata e recuperata”  CBDI ritiene non corretta questa definizione in due punti:  i componenti (ovvero le loro implementazioni) spesso non rappresentano un insieme  la definizione data considera sempre e solo componenti sviluppati e rilasciati, piuttosto che considerare la scienza, l’arte o la pratica di disegnare e implementare una architettura Comprendere l’architettura SOA 17
  18. 18. Definizioni – “Service-Oriented Architecture” Service-Oriented Architecture  CBDI definisce SOA come: “The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface” Comprendere l’architettura SOA 18
  19. 19. Definizioni – “Service-Oriented Architecture” Service-Oriented Architecture (definizioni a confronto) (W3C) “A set of components which can be invoked, and whose interface descriptions can be published and discovered” (CBDI) “The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface” Comprendere l’architettura SOA 19
  20. 20. Definizioni – “Service-Oriented Architecture” Service-Oriented Architecture  I punti cardine della definizione del CBDI stabiliscono che l’architettura SOA:  è il risultato dell’impiego di particolari politiche, pratiche e frameworks che consentono il rilascio di servizi in maniera rispondente a specifiche regole  si distingue sulla granularità del servizio, sulla sua indipendenza dalla modalità di implementazione, e del suo rispetto e coerenza per gli standard  viene intravista la possibilità, in determinati casi, di esporre i servizi anche in forma di web services Comprendere l’architettura SOA 20
  21. 21. Le basi di SOA Molto spesso, e in maniera errata, si confonde il concetto di “Service Orientation” con la realizzazione di un web service E’ chiaro tuttavia, che la realizzazione di un web service è il primo passo verso il concetto di software distribuito in forma di servizio Quello che è importante riconoscere è che i servizi Web sono parte di un quadro più ampio, rappresentato da SOA Comprendere l’architettura SOA 21
  22. 22. SOA attraverso i Web Services L’interfaccia esposta da un web service fornisce alcune importanti caratteristiche architettoniche e di prestazioni, e in particolare:  lindipendenza dalla piattaforma  lasco accoppiamento  capacità di autodescrizione  capacità di essere “scoperti” Questo consente di realizzare una importante separazione formale tra il provider dei servizi e i consumatori Comprendere l’architettura SOA 22
  23. 23. SOA vs Web Services L’importante nel confronto tra Service e Web Service è comprendere gli aspetti più rilevanti:  il concetto fondamentale è (e resta) il Service  i Web Services rappresentano un insieme di protocolli tramite i quali i Service possono essere pubblicati, scoperti e usati in una forma standard e tramite una tecnologia neutrale Comprendere l’architettura SOA 23
  24. 24. SOA vs Web Services In realtà i Web Services non sono una componente obbligatoria per SOA, sebbene i Services vengano sempre più spesso realizzati tramite essi SOA è potenzialmente molto più ampio nel suo campo di applicazione Inoltre con SOA diventa più semplice la definizione di attuazione del servizio, e della sua qualità dal punto di vista del fornitore (provider) e del consumatore (consumer) Comprendere l’architettura SOA 24
  25. 25. Tecnologia e Disciplina È possibile tracciare un parallelo con CDB (Component-Based Development) e le tecnologie di sviluppo per componenti Tecnologie come COM con lo sviluppo di componenti, o la modellazioni UML con la rappresentazione dei packages, si preoccupano dei componenti dal punto di vista “tecnologico” CBD, o ancora meglio CBSE (Component-Based Software Engineering), rappresentano invece la “disciplina” con cui si assicura che si stiano costruendo i componenti in maniera coerente e allineata con il business Comprendere l’architettura SOA 25
  26. 26. Un confronto tra servizi Facciamo un confronto molto semplice ed allo stesso tempo esplicativo delle differenze tra i vari servizi Prendiamo come termini di paragone due servizi disponibili, per esempio, sotto forma di web services:  il primo che offra funzionalità di business, e metodi per la consultazione di dati relativi alle attività della compagnia  il secondo che offra un accesso di tipo CRUD (Create, Read, Update, Delete) alla propria base dati Comprendere l’architettura SOA 26
  27. 27. Un confronto tra servizi Nel primo caso le funzionalità sono correttamente implementate (tramite il web service) in maniera tale da essere fruite da diversi tipologie di consumer, quindi secondo il paradigma SOA Nel secondo caso, l’accesso alle entità presenti sul database necessita di una conoscenza della struttura stessa della base dati, oltre che la padronanza dello scenario Il secondo servizio poteva essere normalmente creato con un “semplice” web service che non si basasse su SOA, poichè un impiego di questo tipo non rispecchia il concetto di SOA Comprendere l’architettura SOA 27
  28. 28. Un confronto tra servizi Da un confronto di questo genere, fu dedotta dal CBDI una considerazione che ancora oggi viene ritenuta come una delle migliori definizioni di SOA: “SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed” Comprendere l’architettura SOA 28
  29. 29. Principi della Service Orientation Sorge il problema di stabilire la capacità di aderenza al modello “Service Orientation” Quello di cui abbiamo bisogno insomma, è un insieme di linee guida che ci consenta di stabilire come e quando un servizio è più o meno aderente al modello SOA Si manifesta la necessità di un insieme di Principi della Service Orientation che ci permettano di impostare criteri, parametri e quant’altro Comprendere l’architettura SOA 29
  30. 30. Principi della Service Orientation Possiamo subito distinguere due insiemi di principi:  Interface related principles (Principi di relazione tra le interfacce) che stabiliscono la funzione di neutralità della tecnologia, orientata alla standardizzazione e alla sua usabilità in termini di fruizione del servizio  Design principles (Principi di disegno) che riguardano la qualità dei services, la loro aderenza ai requisiti, e la loro usabilità, intrinseca adattabilità e semplicità d’uso Comprendere l’architettura SOA 30
  31. 31. Principi della Service Orientation Il secondo insieme (Principi di disegno) dovrebbe essere idoneo per l’utilizzo in aziende che hanno architetture SOA già mature Tuttavia, è proprio nelle aziende grandi che si riesce difficilmente a giustificare questo livello di disciplina Infatti, sembra essere più giustificabile progettare e sviluppare componenti per le parti fondamentali del sistema, che siano riusabili e durevoli nel tempo, piuttosto che sostenere qualcosa che viene percepito come un costo immediato anche se prospetta un ritorno di investimento (ROI) a breve termine Comprendere l’architettura SOA 31
  32. 32. Principi della Service Orientation Tuttavia, quando questi principi vengono applicati nella progettazione e sviluppo di servizi, risulta:  una maggiore consapevolezza dei requisiti  una maggiore aderenza a questi stessi requisiti  una maggiore comprensione delle problematiche relative a costi e vantaggi dei sistemi e sottosistemi  una maggiore competenza, da parte delle divisioni IT dell’azienda, sulle parti del sistema progettate per funzioni collaterali ai requisiti Comprendere l’architettura SOA 32
  33. 33. Principi di disegno applicati ai Web Services Neutralità della tecnologia  indipendenza dalla piattaforma Standardizzazione  protocolli standard o basati su standard Fruibilità  capacità di scoperta e utilizzo Comprendere l’architettura SOA 33
  34. 34. Principi di disegno applicati ai Servizi Aggiunge a quanto visto per i web services:  Riusabilità • riutilizzo del servizio  Astrazione • il servizio si astrae dalla implementazione  Pubblicazione • informazioni precise e dettagliate sull’uso ma non sulla implementazione  Formalizzazione • Contratto formale tra il provider e il consumer  Pertinenza • Funzionalità presentate ad una granularità comunque riconoscibile dagli utenti come un servizio significativo Comprendere l’architettura SOA 34
  35. 35. Benefici derivanti dall’applicazione dei principi della SO Applicando i principi della Service Orientation, si possono ottenere diversi vantaggi:  Effettiva sincronia tra le prospettive di business e di implementazione  Un servizio ben formato costituisce una importante unità di gestione che si relazioni al business specificato  Un servizio che si astrae dalla sua implementazione è un servizio in cui sia possibile considerare diverse opzioni per il suo modello di distribuzione e di collaborazione Comprendere l’architettura SOA 35
  36. 36. Benefici derivanti dall’applicazione dei principi della SO Effettiva sincronia tra le prospettive di business e di implementazione:  Per diversi anni, le persone che si occupano del business non hanno realmente capito le loro architetture IT  Con un servizio ben disegnato si può migliorare notevolmente la comunicazione con gli strati di business  Si può andare finalmente considerare la convergenza di business e IT Comprendere l’architettura SOA 36
  37. 37. Benefici derivanti dall’applicazione dei principi della SO Un servizio ben formato costituisce una importante unità di gestione che si relazioni al business specificato:  Separare in maniera netta la prestazione del servizio offre una buona base per la comprensione del ciclo di vita  Vengono ben compresi anche le dinamiche dei costi del servizio e di come vengono questi costi vengano utilizzati nel business Comprendere l’architettura SOA 37
  38. 38. Benefici derivanti dall’applicazione dei principi della SO Un servizio che si astrae dalla sua implementazione è un servizio in cui sia possibile considerare diverse opzioni per il suo modello di distribuzione e di collaborazione:  una delle speranze del modello SO è che sia facilmente componibile anche tramite altri servizi, siano essi interni o esterni al contesto dell’azienda che li realizza  quindi l’idea che in futuro, in un contesto in cui siano presenti architetture Service Oriented, questo possa accadere, non è tanto improbabile Comprendere l’architettura SOA 38
  39. 39. L’importanza del processo Uno degli aspetti principali di SOA è l’implementazione del processo su due fronti Questo implica una creazione di due processi separati, uno per il provider del servizio e uno per il consumer del servizio Il processo per il consumer del servizio non è normalmente sviluppato dallo stesso team che sviluppa il servizio ed il suo provider Questo avviene specialmente nell’ottica in cui il servizio venga usato esternamente all’azienda che lo realizza, ovvero che il servizio non sia realizzato solo per un uso interno Comprendere l’architettura SOA 39
  40. 40. L’importanza del processo Dal punto di vista del consumer, la cosa importante è che il servizio sia organizzato tramite interfacce Il servizio deve fornire delle specifiche formali relative a modalità di utilizzo, tramite dei veri e propri “contratti” Soprattutto non ci deve essere nessun tipo di dipendenza del consumer verso la modalità di implementazione del provider Questo è un vantaggio per entrambi, infatti anche il provider non ha idea del modo con cui il consumer utilizzerà il servizio Comprendere l’architettura SOA 40
  41. 41. L’importanza del processo Le uniche cose che interessa sapere al consumer sono:  dove si trova il servizio  cosa fa il servizio  come si può usare il servizio In questo scenario, le interfacce sono l’unica modalità con cui il consumer può ottenere alcune di queste informazioni Comprendere l’architettura SOA 41
  42. 42. Le parti (o viste) di un processo Come abbiamo visto la suddivisione è importante e deve essere netta, tra la parte del provider e quella del consumer Tuttavia le parti (o anche viste) che compongono il processo sono tre:  Implementazione e rilascio del servizio  Fornitura del servizio  Utilizzo del servizio Comprendere l’architettura SOA 42
  43. 43. Implementazione e rilascio del servizio Questa parte del processo si divide a sua volta in:  Implementazione  Pubblicazione del servizio (normalmente sottoforma di web service e spesso tramite tools automatici) Comprendere l’architettura SOA 43
  44. 44. Fornitura del servizio La suddivisione della fornitura (nel senso della disponibilità) del servizio in questo caso viene fatta in:  Orientamento ala problematica  Vista interna and esterna  Gestione del livello di servizio Comprendere l’architettura SOA 44
  45. 45. Fornitura del servizio Suddividendo il processo in queste tre parti (o viste) si vede che la maggior parte degli aspetti collaborativi del processo sono concentrati in questa parte E su questa parte esercita una notevole influenza la natura del contratto, la quale definisce i requisiti del processo Comprendere l’architettura SOA 45
  46. 46. Utilizzo del servizio In quest’ultima parte possiamo trovare le seguenti :  Business guidato dai processi  Consumer del servizio interni o esterni  Servizi disponibili come librerie, e non come codice  Approccio di sviluppo dichiarativo  Valutazione del servizio ad opera di analisti di business (spesso sottovalutato) Comprendere l’architettura SOA 46
  47. 47. Pattern di collaborazione tra Provider e Consumer Ci sono diversi pattern di disegno che possono essere utilizzati nella collaborazione tra il Provider e il Consumer Di questi un paio sono sicuramente più rilevanti:  Negotiated - Consumer and Provider jointly agree service Negoziato (Provider e Consumer sono in accordo)  Instantiated - This is it. Take it or leave it Istanziato (Nessun accordo, il Consumer usa così com’è il servizio) Comprendere l’architettura SOA 47
  48. 48. Pattern “Negotiated” Negotiated - Consumer and Provider jointly agree service. Negoziato (Provider e Consumer sono in accordo) Quando la parte provider e quella consumer di un servizio vengono sviluppati insieme, c’è la possibilità di convenire come e in che modalità il servizio debba essere realizzato L’occasione si verifica quando più aziende convergono verso la necessità (o l’uso) di servizi da sviluppare ex-novo Altri casi sono i cosiddetti “early adopters” , oppure l’uso interno ad una sola azienda o, ancora, in caso di definizione di nuovi standard Comprendere l’architettura SOA 48
  49. 49. Pattern “Instatiated” Instantiated - This is it. Take it or leave it. Istanziato (Nessun accordo, il Consumer usa così com’è il servizio) In questa situazione il servizio spesso già esiste, quindi si decide semplicemente di usarlo o meno Analogo discorso quando bisogna integrare sistemi già esistenti Un altro caso è quello di una azienda dominante sul mercato che semplicemente decide come sviluppare il servizio Possono esserci ulteriori casi di azienda dominante:  Provider led (Use this service or we cant do business)  Consumer led (Provide this service or we cant do business) Comprendere l’architettura SOA 49
  50. 50. Prospettive architetturali Le parti (o viste) di processo appena analizzate rappresentano la base necessaria per definire le tipologie di architettura più adatte a definire gli interessi, le responsabilità e l’integrità Per SOA esistono tre importanti prospettive architetturali:  Application Architecture  Service Architecture  Component Architecture Comprendere l’architettura SOA 50
  51. 51. Application Architecture In questa architettura, il processo è visto in prospettiva dal solo punto di vista business che si intende realizzare L’archiettura consuma uno o più servizi forniti da providers interni e/o esterni e li integra insieme allo scopo di realizzare il processo di business desiderato Comprendere l’architettura SOA 51
  52. 52. Service Architecture Questa architettura rappresenta un “ponte” tra l’implementazione del servizio e il suo utilizzo (consumo) Viene creata una vista logica dei servizi disponibili per l’uso, invocabili attraverso delle interfacce comuni Comprendere l’architettura SOA 52
  53. 53. Component Architecture Questa architettura descrive i vari ambienti e/o configurazioni che supportano l’applicazione implementata Vengono rappresentati anche gli oggetti che rappresentano la funzionalità di business da realizzare, oltre che la sua logica di implementazione Comprendere l’architettura SOA 53
  54. 54. Vista di insieme delle tre prospettive architetturali Comprendere l’architettura SOA 54
  55. 55. Angolazioni A loro volta, queste tre prospettive architetturali possono essere filtrate in maniera diversa se viste con gli “occhi” del provider o del consumer Cerchiamo di comprendere meglio queste ulteriori “angolazioni” Comprendere l’architettura SOA 55
  56. 56. Angolazioni Possiamo pensare, per esempio che:  il consumer non ha alcun interesse nei dettagli implementativi con cui è stato realizzato il servizio, ma solo nel modo con cui questi può essere utilizzato, e a parità di servizio, potrebbero esistere anche implementazioni diverse  in modo simile, il provider non ha nessun interesse nella tipologia di applicazioni che includeranno (e consumeranno) il servizio esposto, che sono e restano sconosciute Comprendere l’architettura SOA 56
  57. 57. Angolazioni Un’altra “angolazione” è la seguente:  il consumer è focalizzato sull’architettura applicativa, sui servizi usati, e non sui dettagli dei componenti  per esempio, il consumer non è interessato a come sono organizzati o implementati i componenti dell’architettura, o il database utilizzato  in modo simile, il provider è focalizzato sull’architettura dei componenti, del servizio e non sull’architettura applicativa  per esempio, il provider può avere interesse a sapere alcuni particolari utili, ma non tutti i dettagli relativi al consumer Comprendere l’architettura SOA 57
  58. 58. Approfondiamo la Service Architecture Al centro della SOA vi è la principale necessità di gestire i servizi da erogare La corretta gestione di questi servizi costituisce la chiave di volta per la comunicazione tra il provider ed il consumer Abbiamo bisogno di una architettura che non riduca i servizi allo status di interfacce I servizi infatti hanno una identità propria, e possono essere gestiti singolarmente o in gruppi Comprendere l’architettura SOA 58
  59. 59. Business Service Bus (BSB) A questo scopo CBDI ha ideato il concetto di Business Service Bus (BSB) Questi rappresenta una vista logica dei servizi disponibili e/o impiegati in un particolare contesto di business (business domain) Un esempio di business domain può essere per esempio la gestione delle Risorse Umane, oppure la Logistica Comprendere l’architettura SOA 59
  60. 60. Business Service Bus (BSB) Principalmente il BSB ci aiuta a rispondere a domande come:  Di quale servizio ho bisogno?  Quali servizi ho a disposizione?  Quali servizi possono interagire e operare insieme?  Quali servizi sono disponibili in alternativa?  Quali sono le dipendenze tra i servizi nelle varie versioni? Comprendere l’architettura SOA 60
  61. 61. Business Service Bus (BSB) Piuttosto che lasciare gli sviluppatori alla ricerca dei servizi da utilizzare e quindi usarli in un contesto, possiamo considerare l’uso del BSB il Business Service Bus può essere il miglior punto di partenza per guidare gli sviluppatori ad un set di servizi coerente con il loro dominio Lo scopo del BSB insomma, è quello di stabilire le specifiche, le politiche ed altre regole, che vengono stabilite a livello di bus e non a livello di ogni singolo servizio Comprendere l’architettura SOA 61
  62. 62. Business Service Bus (BSB) I servizi su un bus devono seguire gli stessi standard sulla semantica, aderire alle stesse policy di sicurezza, e devono puntare tutti allo stesso modello globale del dominio Questo facilita anche l’implementazione di un certo numero di servizi infrastrutturali di uso comune, che possono essere aggregati sullo stesso bus (per esempio, un servizio di validazione del codice prodotto utilizzabile da tutti) In generale, ogni business domain sviluppa un proprio vocabolario e un proprio modello di business sia per quanto riguarda i processi che gli oggetti Comprendere l’architettura SOA 62
  63. 63. Approfondiamo la Service Architecture Una domanda che a questo punto sorge spontanea è: “ma qual è lo scopo di pubblicare un servizio sul BSB?” In maniera semplicistica si pensa che questo sia solo un livello di astrazione della tematica La risposta a questa domanda, anche se suscettibile di interpretazione, assicurerà comunque che il servizio soddisfi i criteri di business, sia orientato al consumer, sia stato correttamente concordato, e sia significativo per il business Comprendere l’architettura SOA 63
  64. 64. Approfondiamo la Service Architecture Il punto chiave di tutta la questione è la possibilità di aderire ad un processo di aggregazioe e collaborazione Questo processo dovrebbe esistere ed evolvere in maniera separata dagli altri componenti In questo modo, aumenta il livello di flessibilità che consenta ai servizi esposti di essere modificati senza toccare le componenti sottostanti In linea di principio, i livelli di astrazione devono essere sviluppati in modo che i servizi siano sempre ad un livello pertinente e opportuno per il consumer Comprendere l’architettura SOA 64
  65. 65. Livelli di astrazione I livelli di astrazione potrebbero essere uno o tutti tra i seguenti:  Servizi di Business  Servizi orientati ai Consumer  Concordati tra Provider e Consumer  Composizione di servizi a basso livello in qualcosa di significativo per il Business  Servizi generici (a granatura grossa)  Adattabilità all’utilizzo dall’esterno  Conforme alla progettazione pre-esistente Comprendere l’architettura SOA 65
  66. 66. I livelli di astrazioneComprendere l’architettura SOA 66
  67. 67. SOA Platform Il punto cardine della separazione è la definizione di una piattaforma virtuale che sia egualmente rilevante per un certo numero di piattaforme reali L’obiettivo di questa piattaforma virtuale è quello di consentire una separazione dei servizi dalla loro implementazione, più completa possibile Più netta sarà questa separazione, e maggiore sarà la possibilità di consentire a componenti costruiti su diverse piattaforme di offrire i loro servizi senza avere dipendenze legate alla loro implementazione Comprendere l’architettura SOA 67
  68. 68. SOA Platform La piattaforma virtuale SOA rappresenta uno schema che riguarda lo sviluppo finalizzato alla realizzazione di queste piattaforme Si tratta di linee guida, di orientamenti, allo scopo di assicurare che i servizi pubblicati siano conformi allo stesso insieme di principi strutturali Questi principi sono rilevanti sia per la gestione di questi servizi, che per la capacità di comprensione da parte del consumer Comprendere l’architettura SOA 68
  69. 69. SOA Platform Quando un certo numero di applicazioni differenti sono in grado di condividere una stessa struttura, e le relazioni tra le parti di questa struttura sono le stesse, allora abbiamo quello che viene definito come uno “stile architetturale” condiviso Questo stile può essere implementato in vari modi: potrebbe riguardare un insieme di policies, un framework di oggetti, o una pratica comunemente adottata Comprendere l’architettura SOA 69
  70. 70. Enterprise SOA (ESOA) La migliore implementazione per una architettura SOA resta l’architettura basata su componenti (non intesi dal punto di vista tecnologico) Questa tipologia di architettura, vista come insieme di componenti relativi a processi ed entità, può risultare molto stabile e allo stesso tempo flessibile Queste caratteristiche sono dovute alla corrispondenza univoca tra le entità di business e le implementazioni dei componenti Comprendere l’architettura SOA 70
  71. 71. Enterprise SOA (ESOA) Enterprise SOA (ESOA) considera queste due parti, Web services e CBD (ovvero CBSE), e le unisce insieme Questo risultato è inteso come una architettura SOA che aderisce contemporaneamente al modello del web service, disponibile esternamente, e al modello del core business, disponibile invece solo internamente Tuttavia l’approfondimento della ESOA è materia molto complessa, e meriterebbe una ampia trattazione separata Comprendere l’architettura SOA 71
  72. 72. Riepilogo L’obiettivo di SOA è realizzare una maglia di servizi collaborativi, pubblicati e disponibili per l’invocazione su un Service Bus L’adozione del modello SOA è essenziale per realizzare appieno l’agilità del business e la flessibilità dei sistemi IT, tanto promessa dal modello dei web services Questi benefici non devono essere visti dal punto di vista tecnologico, ma da una prospettiva di creazione di un ambiente orientato ai servizi (Service Oriented Environment) Comprendere l’architettura SOA 72
  73. 73. Riepilogo Riassumiamo gli aspetti principali:  Il servizio è il concetto fondamentale, i web services sono solo un insieme di protocolli con cui un servizio può essere pubblicato, ritrovato e utilizzato  SOA non è solo una architettura orientata ai servizi intesa da un punto di vista tecnologico, bensì un insieme di politiche, pratiche e librerie che consentono ai servizi di essere correttamente fruiti Comprendere l’architettura SOA 73
  74. 74. Riepilogo Ulteriori aspetti:  Con SOA è importante implementare i processi in maniera tale da assicurare che questi sia diviso in due parti distinte: il processo per il provider e il processo per il consumer  Piuttosto che lasciare gli sviluppatori alla ricerca dei servizi da utilizzare in un contesto, possiamo considerare l’uso del Business Service Bus come punto di partenza per guidare gli sviluppatori ad un set di servizi coerente con il loro dominio Comprendere l’architettura SOA 74
  75. 75. UN PUNTO DI VISTA PIÙ TECNICOComprendere l’architettura SOA
  76. 76. Applicazioni moderne Le applicazioni che oggi sviluppiamo sono sempre più pensate per collaborare con altri sistemi operativi e altre applicazioni Usiamo sempre più spesso la connessione internet, o in alcuni casi delle connessioni dedicate, assimilabili a quelle internet Le tipiche attività di lavoro possono riguardare diversi dipartimenti di una azienda o diverse aziende al fine di realizzare un prodotto oppure di erogare un servizio all’esterno Questo ovviamente deve considerare le varie tipologie di piattaforme e sistemi operativi (oltre che delle loro versioni) Introduzione all’architettura 76
  77. 77. Applicazioni moderneFornitore AApplicazione 1 Azienda di ProduzioneApplicazione 2 …Applicazione N Applicazione 1 App Server INTERNET Applicazione 2 … Applicazione KFornitore 2Applicazione 1Applicazione 2 …Applicazione M Introduzione all’architettura 77
  78. 78. Infrastrutture di rete miste UFFICIO ACQUISTI ERP GESTIONE MARKETING ORDINI CRM SISTEMA GESTIONE DEL FINANZIARIO SOFTWAREProblema: integrare diverse piattaforme e diversi S.O. Introduzione all’architettura 78
  79. 79. Limiti dei componenti I componenti sono porzioni di codice riusabile, scritti tramite una tecnologia particolare (CORBA, COM/COM+, .NET Remoting, ecc.) Dei componenti, normalmente, è necessario conoscere bene sia l’architettura interna che il funzionamento Vengono installati normalmente una volta sola sul lato della distribuzione, e a volte necessitano dell’installazione anche sul client che li utilizza Introduzione all’architettura 79
  80. 80. Limiti dei componenti Lavorano con dati non di loro competenza (BIZDAL) In caso di aggiornamento devono essere reinstallati ovunque Inoltre i componenti sono molto legati alla stessa tecnologia con la quale sono stati sviluppati Nella quasi totalità dei casi non è possibile far dialogare direttamente componenti sviluppati con tecnologie differenti Nella maggior parte dei casi non sono disponibili per tutte le piattaforme e sistemi operativi Introduzione all’architettura 80
  81. 81. Vantaggi dei servizi Sono utilizzabili dai client senza necessità di deploy In caso di aggiornamento non richiedono operazioni sui client Non condividono oggetti o strutture dati Gestiscono i dati in maniera trasparente per il client Possiamo ignorare sia la loro architettura che il loro funzionamento interno Supportano il versioning e l’esecuzione parallela di versioni differenti Usano una infrastruttura tecnologica supportata da tutte le piattaforme Introduzione all’architettura 81
  82. 82. Le applicazioni moderne L’approccio di SOA deriva da una evoluzione delle applicazioni Le applicazioni “moderne” richiedono:  Integrazione tra piattaforme diverse  Aggregazione di dati differenti (trasparenza dei dati)  Interazione tra strutture dati eterogenee  Utilizzare internet per le comunicazioni  Capacità di adattamento al cambiamento dei requisiti  Apertura verso altre funzionalità disponibili all’esterno Introduzione all’architettura 82
  83. 83. Service Oriented Architecture I servizi sono porzioni indipendenti di software che espongono funzionalità (non metodi!) Sono indipendenti dal protocollo, dalla piattaforma e dall’architettura del contesto in cui vengono collocati Per concetto e per necessità devono essere fortemente disaccoppiati e astratti dalla logica di funzionamento interna Introduzione all’architettura 83
  84. 84. Principi base di SOA In caso di evoluzione del servizio non deve essere richiesto agli utilizzatori nessun aggiornamento (ancora disaccoppiamento) I tipi esposti devono astrarre dalla struttura dati sottostante Ancora, i tipi esposti devono essere estendibili (per esempio per supportare il versioning) Non deve esistere alcun “legame forte” tra i tipi di dati usati dai servizi e quelli usati dai loro utilizzatori Non devono esistere DLL o componenti comuni tra i servizi e i loro utilizzatori Introduzione all’architettura 84
  85. 85. Ragionare in termini di servizi Da A Funzioni Processi / Operazioni Processi di sviluppo lunghi Ciclo di vita incrementale Blocchi monolitici OrchestrationPensato per durare nel tempo Pensato per cambiare Forte accoppiamento Forte disaccoppiamento Object Oriented Message Oriented Implementazioni note Astratto Introduzione all’architettura 85
  86. 86. SOA Tenets Possiamo cercare di approfondire il concetto di Service Orientation anche attraverso le 4 dottrine o postulati (tenets) Questi postulati sono stati elaborati da due architetti di Microsoft, “Don Box” e “Pat Helland” verso il 2004 Su questi postulati sono state aperte, sin da subito, accese discussioni sulla validità o meno delle loro enunciazioni Alcuni sostengono che siano validi, altri ne sostengono la validità parziale o solo di alcuni di questi quattro postulati Introduzione all’architettura 86
  87. 87. SOA Tenets I quattro postulati in questione sono: 1. Boundaries are explicit 2. Services are autonomous 3. Services share schema and contract, not class 4. Compatibility is based upon policy Introduzione all’architettura 87
  88. 88. SOA Tenets Boundaries are explicit  “I confini sono espliciti”, ovvero la comunicazione da e verso un servizio deve essere accessibili all’esterno, ma il confine tra l’esterno e l’interno deve essere ben delineato  Questo vuol dire impostare una separazione forte tra quello che sta “dietro le quinte” (parte tecnica e di linguaggio) e la parte disponibile a chi fruisce del servizio dall’esterno Introduzione all’architettura 88
  89. 89. SOA Tenets Services are autonomous  “I servizi sono autonomi”, ovvero devono poter funzionare presi singolarmente  Ogni servizio deve racchiudere quindi una funzionalità finita  Il servizio, fruito dall’esterno, deve poter vivere senza necessità di coinvolgimenti di terzi (ad esempio altri servizi) Introduzione all’architettura 89
  90. 90. SOA Tenets Services share schema and contract, not class  “I servizi condividono gli schema e i contratti ma non le classi”, ovvero un servizio deve essere fruibile senza dovere accedere al codice o a librerie lato server (ad esempio DLL) del servizio stesso  Il servizio deve condividere solo gli schema e i contratti, ovvero le informazioni accessibili a chiunque per l’utilizzo corretto del servizio Introduzione all’architettura 90
  91. 91. SOA Tenets Compatibility is based upon policy  “La compatibilità è basata su delle regole”, ovvero la definizione delle caratteristiche di compatibilità vanno dettagliati tramite dei linguaggi o dei formati di interoperabilità standardizzati  Il formato di comunicazione e di presentazione deve essere noto (per esempio le WS-* policy) Introduzione all’architettura 91
  92. 92. Message Oriented Design Costruiamo i servizi partendo dalla definizione dei messaggi (ovvero cosa i servizi devono “dirsi”)  Per farlo utilizziamo gli XSD  Gli XSD possono definiti tutti i tipi a livello aziendale  Si può creare addirittura un database aziendale (linguaggio) Descriviamo i servizi in base ai contratti (sequenze di messaggi)  Per farlo utilizziamo i WSDL Implementiamo i messaggi e i contratti in maniera con una qualsiasi piattaforma o linguaggio (che sappia farlo) Introduzione all’architettura 92
  93. 93. Definizione dei messaggi I messaggi rappresentano la comunicazione del servizio Si possono stabilire dei veri e propri standard aziendali:  Sui nomi delle entità coinvolte  Sui namespace (per esempio creando una directory dei namespace a livello aziendale) Bisogna definire i tipi tramite XSD (noti e raggiungibili da tutti) Non mettere nei messaggi le informazioni infrastrutturali quali:  Informazioni sul tipo di autenticazione  Identificativi (sessione, transazione, ecc.)  Altre informazioni sensibili Tenere sempre presente il versioning Introduzione all’architettura 93
  94. 94. Definizione dei contratti I contratti rappresentano le funzionalità del servizio Definiscono le operazioni sempre basandosi su sequenze di messaggi Evitare di crearli in automatico, senza il nostro controllo:  SI  Generare gli asmx dai WSDL  NO  Generare i WSDL dagli asmx Cercare di scomporre le operazioni in diversi WSDL, per poterli facilmente riutilizzare L’approccio di SOA è quello di cambiare le WSDL e non di cambiare i prototipi delle funzioni Introduzione all’architettura 94
  95. 95. Concetto di idempotenza A volte può accadere che dei messaggi richiedano di essere spediti più di una volta:  perché non sono arrivati a destinazione  perché non viene ricevuta la conferma di ricezione  per altri motivi (es. replay attack da parte di un hacker) A parità di input, il sistema deve avere le stesse reazioni e produrre gli stessi output:  per evitare problemi in caso di replay dei messaggi  per garantire univocità e stabilità di comportamento Introduzione all’architettura 95
  96. 96. Gestione dei dati All’interno del servizio:  devono essere specifici per l’applicazione  possono essere più complessi di come si presentano all’esterno  sono fortemente legati all’applicazione All’esterno del servizio:  sono rappresentati dai messaggi (XML)  vengono descritti da schema (XSD)  devono essere estendibili e aggiornabili  sono noti a tutti gli attori Introduzione all’architettura 96
  97. 97. I dati dentro e fuori dal servizio MSG DATA MSG SQLOUTSIDE INSIDE Introduzione all’architettura 97
  98. 98. Come esporre i dati In architettura SOA i nostri servizi non possono essere degli intermediari verso il database A questo proposito, i web services che svolgono funzioni “CRUD” (Create-Read-Update-Delete) non sono adatti allo scopo di SOA Non sono espressamente vietati da SOA, ma semplicemente non sono SOA Introduzione all’architettura 98
  99. 99. Controllo sui dati e concorrenza In architettura SOA i nostri servizi non possono mai fidarsi dei consumer Conviene sempre controllare tutti gli input E’ necessario utilizzare una logica di business solo per il controllo Non bisogna fidarsi dei consumer perché i servizi devono essere autonomi (come suggeriscono i SOA Tenets) Introduzione all’architettura 99
  100. 100. Ruolo della logica di business Ci deve sempre essere in ogni servizio una logica adeguata I servizi rappresentano solo la parte di comunicazione Questi sono dei wrapper sugli oggetti di business: L’implementazione va negli oggetti e non nei servizi Non va mai dimenticato l’aspetto della sicurezza Tale aspetto va introdotto direttamente nella logica di business Introduzione all’architettura 100
  101. 101. Quadro complessivo XML DATA SQL XMLXML INFOSET BIZ SQL LOGIC DATA Introduzione all’architettura 101
  102. 102. Dialoghi e sequenze Alcuni dialoghi sono basati sulla sequenza di messaggi Per gestire i messaggi è consigliabile:  HTTP: evitare di usare i cookie  Applicativi: evitare parametri delle operazioni  Infrastruttura: usare token di sessione nei SOAP header (1) Inserisci Ordine CONSUMER (2) OK – Ordine Inseribile PROVIDER (3) Conferma Inserimento Introduzione all’architettura 102
  103. 103. Transazioni I servizi devono essere autonomi, ma:  le transazioni vincolano le operazioni  allo stesso tempo senza transazioni in molti casi non potremmo utilizzare i servizi Laddove possibile isoliamo i servizi e rendiamoli implicitamente transazionali Se non è possibile isolare la transazione all’interno del servizio, abbiamo bisogno di transazioni distribuite “long-running” , e WS-AtomicTransaction lavora in questo senso Affidare la transazionalità ad “accordi” tra i servizi non ha senso, perché li renderebbe meno autonomi Introduzione all’architettura 103
  104. 104. Sicurezza Nella progettazione dello strato di sicurezza bisogna tenere presente:  Integrità: hashing, digital signature  Riservatezza: XML encryption  Autenticità del mittente/destinatario: token (username e password, kerberos, ecc.) Va sempre realizzata a livello infrastrutturale (SOAP header), tranne rari casi (per esempio, in caso di encryption) Introduzione all’architettura 104
  105. 105. WS-Interoperability http://ws-i.org/ Web Service Interoperability Organization WS-I è un ente che si prefigge i seguenti obiettivi:  ottenere l’interoperabilità tra i web service, tra piattaforme, applicazioni e linguaggi differenti  promuovere l’utilizzo dei web service  facilitare e quindi rendere più rapida la produzione di web service Introduzione all’architettura 105
  106. 106. WS-I Basic Profile 1.1 Stabilisce le regole base per la interoperabilità tra servizi e piattaforme differenti Dal 2004 sostituisce ed evolve la precedente versione 1.0 E’ costituito da un insieme di assertion in merito a:  Messaging (SOAP, HTTP, …)  Service Description (WSDL, SOAP Binding XSD, XML, Namespaces)  Service publication and discovery (UDDI)  Security (HTTPS, BP Security 1.0 aka WS-Security) WS-I mette a disposizione dei tools per la verifica delle assertions (per C#.NET e Java principalmente) Introduzione all’architettura 106
  107. 107. Web Services Architecture (WSA)Applications & Infrastructure Connected Applications Management Business Process ...Foundation Security Reliability Transactions Metadata Messaging XMLTransport HTTP TCP SMTP ... Introduzione all’architettura 107
  108. 108. Messaging Una serie di specifiche e regole nella gestione dei messaggi (con SOAP 1.1/1.2) WS-Inspection  per documentare e descrivere i servizi offerti da un determinato sito WS-Addressing  per gestire gli indirizzamenti/instradamenti dei messaggi SOAP (es. dei “router” costituiti da messaggi SOAP)  per definire le politiche di load-balancing Introduzione all’architettura 108
  109. 109. Security WS-Security  autenticazione  integrità  riservatezza WS-SecurityPolicy  per descrivere le politiche di sicurezza di WS-Security WS-Trust (tramite trust server)  per gestire relazioni di fiducia tra servizi WS-SecureConversation (senza trust server)  per stabilire sessioni sicure di comunicazione temporanee Introduzione all’architettura 109
  110. 110. Reliable Messaging e Transactions WS-ReliableMessaging  Garanzia di consegna tra i nodi, bidirezionale WS-TransmissionControl  per gestire e controllare lo scambio di messaggi WS-AtomicTransaction  per fornire funzionalità di transazionalità ai servizi WS-Coordination  per coordinare le attività distribuite su diversi servizi, anche (e soprattutto) in caso di transazioni Introduzione all’architettura 110
  111. 111. Comunicazione WS-MetadataExchange  per scambiarsi informazioni sui messaggi (XSD, WSDL, WS-Policy, ecc.) WS-Eventing  per la gestione delle notifiche (basate su sottoscrizione) Si può implementare un sistema di “Grid Computing”, per:  scalare le applicazioni su più server e/o servizi  distribuire i carichi di lavoro su più servizi  gestire le notifiche tramite WS-Eventing Introduzione all’architettura 111

×