Il paradigma SOA non `e legato a nessuna specifica tecnologia implementa- tiva, ma fornisce un insieme di caratteristiche che i servizi che compongono il sistema devono seguire.
CAPITOLO 3. SERVICE ORIENTED ARCHITECTURE 37 • Discoverable and Dynamically Bound: Un servizio deve essere poter essere ricercato in base ad un insieme di criteri conosciuti sola a tempo di esecuzione, ed eseguito senza essere a conoscenza di infor- mazioni riguardo la sua implementazione.
I clients non necessitano di alcuna informazione a compile-time, essi non conoscono nemmeno il formato dei messaggi di richiesta e risposta o la locazione del servizio finch´e non ne hanno effettivamente bisogno. Tutti questi dati vengono forniti dal contratto di servizio al momento della ricerca sul repository ed attraverso questi il client `e in grado di effettuare un collegamento dinamico al servizio.
• Self-described: Ogni servizio deve, cio`e, possedere interfacce ben definite contenenti tutte le informazioni necessarie per essere utilizza- to. Il cliente deve poter capire la funzione di un servizio senza essere a conoscenza dei dettagli di progettazione del servizio stesso.
La comprensibilit`a `e particolarmente importante per i servizi, perch´e ogni utilizzatore pu`o cercare ed usare un servizio in qualsiasi momento. Se il servizio non `e comprensibile dal punto di vista funzionale, il cliente trover`a difficolt`a nel decidere quale servizio utilizzare.
• Interoperability: L’interoperabilit`a `e uno dei concetti alla base del- la Service Oriented Architecture, e consiste nella capacit`a, da parte delle applicazioni realizzate con SOA, di lavorare insieme indipenden- temente dalle piattaforme e dai linguaggi utilizzati per costruirle. Ogni servizio fornisce un’interfaccia, che pu`o essere invocata attraver- so un connettore, grazie alla quale `e possibile definire un protocollo di comunicazione tra le due entit`a che vogliono interagire. L’interfaccia deve essere fornita in un formato dati che ogni potenziale cliente pu`o comprendere, questo si realizza definendo i linguaggi standard utiliz- zabili per lo scopo, in modo che essi abbiano un formato decifrabile da ogni piattaforma (ad esempio formato testo) e che siano conosciuti da tutti gli utilizzatori.
• Loose Coupling: Per accoppiamento si intende il numero di di- pendenze tra servizi e con i clienti. L’architettura service oriented promuove un accoppiamento debole tra fornitori e clients e l’idea di poche e ben note dipendenze tra queste figure. Pi`u il service consu- mer ha bisogno di informazioni per invocare il servizio pi`u aumenta l’accoppiamento.
Il grado di accoppiamento del sistema influenza direttamente la sua modificabilit`a. In sistemi strettamente accoppiati la modifica ad un servizio richieder`a cambiamenti anche agli utilizzatori del servizio stes- so. Le modifiche di un servizio devono avere un basso impatto sugli altri servizi e sulle applicazioni che lo utilizzano. Un’interfaccia che non nasconde sufficientemente bene informazioni implementative crea un effetto domino quando necessita di cambiamenti. Ogni servizio de- ve nascondere le informazioni riguardo la sua progettazione interna, un servizio che espone queste informazioni limiter`a la sua continuit`a modulare.
SOA realizza l’accoppiamento debole attraverso il concetto di con- tratto e collegamento. L’utilizzatore non dipende direttamente dalla realizzazione del servizio ma solamente dal contratto che quest’ultimo supporta.
L’implementazione di pi`u servizi pu`o, comunque, essere stretta- mente accoppiata, ad esempio se questi condividono un database o possiedono informazioni sulle reciproche implementazioni.
• Information hiding : Ogni servizio deve mostrare attraverso la sua interfaccia solamente le informazioni fondamentali all’esecuzione (pre- condizioni, post-condizioni, parametri necessari, ecc.) e nascondere tutte il resto in modo da non creare una dipendenza superflua. • Network-Addressable Interface: Un servizio deve possedere una
interfaccia localizzabile attraverso la rete, utilizzando la quale un client pu`o invocare il servizio. L’abilit`a di un applicazione di assem-
CAPITOLO 3. SERVICE ORIENTED ARCHITECTURE 39 possibile solo se il servizio supporta un’interfaccia sulla rete, questo gli permette anche di essere indipendente dalla locazione fisica. • Coarse-Grained Interfaces: Il concetto di granularit`a e correlata
con il metodo di implementazione di interfacce all’interno di un siste- ma. I progettisti tendono a realizzare servizi in modo che questi siano il pi`u possibile specializzati. Minore `e la logica che il servizio incap- sula e maggiore `e la possibilit`a che questo possa essere riutilizzato. Ogni servizio dovrebbe mappare una funzione distinta all’interno del dominio del problema. Durante l’analisi del problema e la creazione della soluzione il progettista deve creare dei confini ben definiti intor- no ai servizi.
Un servizio deve essere in grado di operare in modo indipendente da altri componenti del sistema di cui fa parte.
• Location Transparency: L’utilizzatore del servizio non conosce l’allocazione del servizio finch´e non ne ha bisogno ed effettua una ri- cerca sul repository. Le operazioni di ricerca e collegamento dinamici permettono al servizio di spostarsi senza che i clients se ne accorgano. La trasparenza di locazione pu`o incrementare le performance del si- stema grazie all’utilizzo di politiche di load balancing. Pi`u richieste di uno stesso servizio possono essere distribuite su pi`u istanze di questo. • Composability: La componibilit`a si riferisce alla produzione di ser- vizi che possono essere liberamente combinati con altri servizi per creare nuovi sistemi. I progettisti dovrebbero creare servizi sufficien- temente indipendenti in modo da poterli riutilizzare in applicazioni diverse da quelle per cui erano originariamente destinati.
La possibilit`a di composizione di un servizio e legata alla sua struttura modulare. Questa permette permette ai servizi di essere assemblati in un’applicazione senza conoscere nulla sulla progettazione del servizio. • Self-Healing: Vista la complessit`a dei sistemi distribuiti moderni la capacit`a di un sistema di recuperare da errori senza l’intervento umano `e diventato molto importante.
La capacit`a di self-healing di un sistema dipende da diversi aspetti. L’hardware deve essere in grado di recuperare da errori, la rete deve fornire la possibilit`a di connessioni dinamiche. Anche l’architettura con cui il sistema `e stato progettato influenza la capacit`a di auto- riparazione, un architettura che supporta collegamenti dinamici ed esecuzioni di componenti a runtime sono pi`u preposti al self-healing. L’architettura orientata ai servizi possiede tutte le caratteristiche ne- cessarie per essere in grado di auto-ripararsi. Ad esempio a seguito di un guasto se un servizio non `e pi`u in grado di eseguire il client pu`o cercare, collegarsi ed eseguire un altro servizio che possiede ca- ratteristiche simili, oppure visto il disaccoppiamento tra interfaccia e
CAPITOLO 3. SERVICE ORIENTED ARCHITECTURE 41 rimanenti senza che il client ne sia a conoscenza.
Un errore durante l’esecuzione di un servizio non deve compromettere il funzionamento dei clienti o di altri servizi o intaccare lo stato dei propri dati interni.
Questi principi devono essere rispettati nella progettazione di applicazioni service oriented, in modo che i servizi possano essere facilmente utilizzati ed aggregati con poche ben note dipendenze.