L’Orientamento al Servizio
L’orientamento al servizio è un paradigma di design inteso per la creazione di unità logiche di soluzione che siano individualmente modellate in modo da poter essere collettivamente e ripetitivamente utilizzate a supporto della realizzazione di specifici obiettivi strategici e benefici associati con il computing service-oriented.
La logica risolutiva progettata in accordo con l’orientamento al servizio può essere qualificata con “Service-oriented”, e unità di logica risolutiva service-oriented sono riferite come “servizi”. Come paradigma di design per il calcolo distribuito l’orientamento al servizio può essere comparato con il paradigma object-oriented nella programmazione, dal quale discende. Il paradigma di design di orientamento al servizio può essere riassunto negli otto principi di design seguenti.
Contratto di servizio standardizzato. Servizi appartenenti allo stesso gruppo sono conformi con gli stessi standard contrattuali.
Service Loose Coupling. Il principio del legame debole promuove il design e l’evoluzione indipendente di una logica di servizio rispetto alle altre e l’implementazione che garantisca l’interoperabilità con il consumatore. L’obiettivo insito in questo principio è ridurre le dipendenze tra l’ambiente interno del servizio e l’esterno, costituito dal contratto di servizio, dalla sua implementazione, e dai suoi utilizzatori finali.
Astrazione del servizio. I contratti di servizio contengono solo informazioni essenziali e informazioni riguardanti i servizi sono limitate a ciò che è pubblicato nei contratti di servizio.
Riusabilità del servizio. I servizi contengono ed esprimono una logica “agnostica” e possono essere posizionati come risorse aziendali riutilizzabili.
Autonomia del servizio. I servizi esercitano un alto livello di controllo lungo il loro ambiente di esecuzione sottostante.
Assenza di stato nei servizi. I servizi minimizzano il consumo di risorse deferendo la gestione delle informazioni di stato quando necessario.
Accertabilità del servizio. A supporto del servizio vengono forniti dei metadati informativi tramite i quali il servizio può essere studiato e interpretato.
Componibilità del servizio. I servizi devono essere assemblabili a prescindere da dimensioni e complessità della loro composizione.
Logica Orientata al servizio. Fonte: SOA Governance: Governing Shared Services On-Premise and in the Cloud
Service Oriented Architecture
SOA è un insieme flessibile di principi di progettazione che guidano il processo di sviluppo e integrazione dei sistemi software. L’impiego di tale metodologia comporta la realizzazione e l’esternazione di funzionalità attraverso un insieme di servizi interoperabili eventualmente residenti in diversi sistemi e/o domini amministrativi. Il servizio è da intendersi come un componente software che incapsula la logica operativa necessaria per offrire una determinata funzionalità di business.
In un tipico scenario il service provider responsabile dell’implementazione del servizio definisce un service description pubblicandolo (publish) su un ulteriore attore denominato service discovery agency, concretamente realizzato attraverso un registro o un repository come UDDI (Universal Description Discovery and Integration). Tale componente consente la reperibilità del servizio. Il service client interroga il service discovery agency per reperire il service description di interesse al fine di riferire (bind) l’implementazione del servizio. Il concetto di legame debole (loose coupling) è di fondamentale importanza nel contesto SOA in quanto ne individua una caratteristica fondante. In una generica situazione di connessione debole gli elementi reagiscono gli uni agli altri, ma si mantengono separati ed identificabili; il legame che li unisce può essere saltuario, circoscritto, poco importante e/o con scarsi effetti reciproci. L’adesione a tale principio impedisce che la comunicazione avvenga per riferimento diretto, ma piuttosto suggerisce una logica a scambio di messaggi tramite la definizione di opportuni protocolli, garantendo quindi l’autonomia dei servizi coinvolti.
L’utilizzo di SOA consente in definitiva di sviluppare sistemi software distribuiti di dimensione variabile assemblando servizi dinamicamente. In uno scenario dinamico di modifica continua dei confini organizzativi e dei processi di business delle imprese la flessibilità garantita da SOA comporta particolari vantaggi, permettendo di adattarsi velocemente alle necessità. Il riuso dei servizi in diversi contesti applicativi consente di sviluppare sistemi software piu agili, mentre i principi di autonomia e di legame debole limitano le ingerenze tra componenti riducendo i costi di manutenzione e la complessità globale del sistema. SOA definisce un’architettura che astrae dalle scelte specifiche in termini di protocolli e tecnologie. WSDL –Web Service Definition Language– per la definizione dei service descriptions e SOAP–Simple Object Access Protocol– per il trasporto dei messaggi costituiscono alcuni degli esempi piu significativi (non vincolanti) di protocolli utilizzabili. E’ importante sottolineare la diversità sostanziale che sussiste tra i concetti di SOA e di Web Service. Il web service costituisce un’implementazione concreta di un generico modello architetturale orientato ai servizi, di cui il SOA ne rappresenta una particolare istanza. Ne consegue la possibile esistenza di web services che non aderiscono pienamente ai principi propri dell’architettura SOA.
Da un punto di vista strettamente architetturale, il cloud computing condivide col SOA la centralità per quanto concerne l’orientamento ai servizi. Una chiara definizione del confine esistente tra i due modelli può essere tuttavia evidenziata enunciando le varie differenze. SOA individua l’idea di servizio come principio di design del sistema. Il Cloud Computing colloca il concetto di servizio ad un livello di generalità e astrazione maggiore, in particolare lo identifica nel rapporto tra l’utilizzatore e la generica risorsa computazionale di interesse assumendo quindi una connotazione di tipo economico. In tale contesto quindi il software costituisce soltanto un sottoinsieme del dominio complessivo.
Esempio Pattern Design SOA. Fonte: SOA Governance: Governing Shared Services On-Premise and in the Cloud by Thomas Erl.
Il principio di service-oriented-computing evolve quindi verso l’idea di “computing-as-a-service”: applicazioni, piattaforme, funzionalità di rete, dispositivi di calcolo e di memorizzazione vengono offerti come servizi. La diversa natura delle due entità consente di concettualizzare il Cloud Computing come la piattaforma in cui è possibile ma non indispensabile sviluppare sistemi software aderendo ai principi dell’architettura SOA. A tal proposito i web services costituiscono una possibile proposta. Il disaccoppiamento nell’applicazione dei due concetti si evidenzia assumendo ad esempio la possibilità di sviluppare applicazioni in ambito cloud computing (SaaS) con un design di tipo monolitico, così come è possibile ingegnerizzare un sistema software in un’ottica service-oriented in un contesto estraneo al cloud.
Cloud Computing e SOA costituiscono quindi due concezioni complementari, utilizzabili indipendentemente o concordemente. L’integrazione dei servizi costituisce tuttavia un fattore critico in ambito cloud, coinvolgendo sia le infrastrutture e applicazioni interne che il rapporto con le risorse esterne. SOA consente di fronteggiare efficacemente tali problematiche attraverso la definizione di principi di design per i sistemi, come la composizione, il riuso, la consistenza e la definizione di standard per le interfacce dei componenti.
Architettura SOA
Fonti utilizzate per la redazione di questa pagina:
1) SOA Governance: Governing Shared Services On-Premise and in the Cloud. Thomas Erl, Stephen G. Bennett, Benjamin Carlyle, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Moores, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable, Filippos Santas.
2) Cloud Computing modelli, piattaforme e sviluppo di un caso applicativo. Tesi di laurea triennale di Yuri Ricci.
3) Il sito web http://www.soaprinciples.com
Leave A Comment