Coulouris ha definito i sistemi distribuiti come “sistemi in cui componenti hardware e/o software esistenti in una rete di computer comunicano e coordinano le proprie azioni scambiandosi messaggi”.
Questo concetto è diventato popolare negli ultimi anni a causa di diversi fattori. Il primo fattore che ha promosso lo sviluppo di sistemi distribuiti è stato l'emergere di reti locali ad alta velocità. Un altro fattore importante è stato il progresso tecnologico nelle prestazioni dei personal computer e lo sviluppo di software per supportare le applicazioni distribuite. I sistemi distribuiti sono legati al concetto di Web e Internet. Con l'evoluzione del Web e la comparsa di nuove aree, interazioni, esigenze e applicazioni, appare il concetto di Web 2.0. Questo termine è stato coniato da Tim O'Reilly nel 2004 per indicare una seconda generazione nella storia del Web basata su comunità di utenti e una gamma speciale di servizi, come social network, blog, wiki o folksonomie, che incoraggiano la collaborazione e la rapida scambio di informazioni tra utenti.
Le prime architetture che possono essere considerate orientate ai servizi (SOA) erano basate su CORBA (Common Object Request Broker Architecture), che fungeva da livello di astrazione per interconnettere i diversi elementi dell'architettura e costruire servizi. Altre tecnologie precedenti erano DCOM (Distributed Component Object Model) o RPC (Remote Procedure Protocol). Con la necessità di progettare e implementare in modo efficiente sistemi distribuiti sul Web, sorgono diverse sfide, alcune focalizzate sullo sviluppo stesso (prestazioni, esperienza utente, ecc.) e altre complementari, basate sulla riusabilità e compatibilità dei servizi. Da queste esigenze nascono i Web Services, che forniscono meccanismi standardizzati per interconnettere diversi utenti con i server informativi.
ARCHITETTURE ORIENTATE AI SERVIZI
Secondo SOA (Service Oriented Architecture) sono architetture software che definiscono l'uso di servizi per supportare i requisiti aziendali, il cui obiettivo è ottenere il minor accoppiamento possibile tra agenti software. Un servizio è un'unità di lavoro eseguita da un fornitore di servizi per ottenere un risultato finale desiderato da un consumatore di servizi. Sia il fornitore di servizi che il consumatore di servizi sono ruoli svolti da agenti software, non proprietari di software. In senso generale, un'architettura orientata ai servizi è una soluzione software destinata a consentire a un'azienda di organizzare e utilizzare vari processi. Con SOA, le applicazioni software non sono più enormi blocchi di funzioni e processi. Invece, queste applicazioni sono costituite da servizi modulari assemblati. Ricorda che un servizio è una semplice funzione software (come la cancellazione di un CD). Può essere eseguito su richiesta da qualsiasi sistema, indipendentemente dal sistema operativo, dalla piattaforma, dal linguaggio di programmazione o dalla posizione geografica.
Ciò che è rivoluzionario in SOA non è il concetto in sé, che esiste da molto tempo, ma il fatto che può essere implementato sul WWW (World Wide Web). Allo stesso modo in cui le pagine Web vengono caricate su qualsiasi piattaforma, i servizi Web funzionano in modo simile indipendentemente dalla piattaforma utilizzata
standard universali.
L'idea di SOA nasce direttamente dalla programmazione orientata agli oggetti, che suggerisce una relazione tra i dati e la loro elaborazione. Pertanto, definiscono formalmente i servizi attraverso interfacce indipendenti dalla piattaforma sottostante e dal linguaggio di programmazione. Queste interfacce nascondono le peculiarità della loro implementazione, che le rende indipendenti dal sviluppatore e linguaggio di programmazione. Attraverso queste architetture è possibile progettare e realizzare sistemi altamente scalabili che rispecchiano le logiche di business e allo stesso tempo facilitano l'interazione tra diversi sistemi proprietari o di terze parti. Il motivo per cui vogliamo che qualcun altro faccia il lavoro per noi è perché sono esperti. L'utilizzo di un servizio è generalmente più economico ed efficace rispetto al farlo da soli. Quindi la maggior parte di noi capisce che non possiamo essere esperti in tutto. La stessa regola può essere applicata alla creazione di sistemi software.
Le interfacce sono molto importanti, se non sono ben definite o non funzionano il sistema non funziona. L'integrazione di più interfacce è costosa e aumenta anche il potenziale di errori nelle applicazioni distribuite. Le interfacce remote sono la parte più lenta della maggior parte delle applicazioni distribuite. Con tutto ciò, invece di creare nuove interfacce per ogni applicazione, ha più senso riutilizzare interfacce generiche per tutte le applicazioni.
Quindi, poiché disponiamo solo di poche interfacce generiche, dobbiamo includere nei messaggi la semantica specifica dell'applicazione. Possiamo inviare qualsiasi tipo di messaggio attraverso le nostre interfacce, ma ci sono alcune regole da seguire per dire che un'architettura è orientata ai servizi.
– In primo luogo, i messaggi devono essere descrittivi, non istruttivi, in quanto il fornitore del servizio è responsabile della risoluzione del problema. Ad esempio, sarebbe simile alla situazione di andare al ristorante e dire al cameriere cosa vorresti bere e le tue preferenze, ma non dovremmo spiegare al cuoco come preparare i tuoi piatti, passo dopo passo.
‐ In secondo luogo, i fornitori di servizi non saranno in grado di comprendere la tua richiesta se i loro messaggi non sono scritti in un formato, una struttura e un vocabolario comprensibili a tutti i soggetti coinvolti. Pertanto, limitare il vocabolario e la struttura dei messaggi è a
necessario per una comunicazione efficace. Più il messaggio è ristretto, più è facile da capire.
- In terzo luogo, la possibilità di proroghe è di vitale importanza. Il mondo è un luogo in continua evoluzione, così come l'ambiente in cui vive il software. Queste modifiche richiedono modifiche corrispondenti nel software di sistema, consumatori dei servizi, dei fornitori e dei messaggi che si scambiano. Se i messaggi non sono estensibili, i consumatori ei provider sono bloccati su una versione specifica del servizio. Vincolo ed estensibilità sono profondamente correlati, sono necessari entrambi e aumentare l'uno significa ridurre l'altro. L'ideale è raggiungere un equilibrio corretto.
– In quarto luogo, una SOA deve disporre di un meccanismo che consenta al consumatore di scoprire un fornitore di servizi nel contesto di un servizio richiesto dal consumatore. Il meccanismo dovrebbe essere flessibile e non un registro centralizzato.
- In quinto luogo, servizio stateless: ogni messaggio che un consumatore invia a un provider deve contenere tutte le informazioni necessarie affinché il provider lo elabori. Questa restrizione rende un provider di servizi più scalabile, in quanto il provider non ha bisogno di memorizzare le informazioni sullo stato tra le richieste. Questo può essere definito un "servizio di produzione di massa" in quanto ogni richiesta può essere gestita in modo generico. Questa restrizione fornisce anche maggiore visibilità, poiché qualsiasi software di monitoraggio può ispezionare in modo indipendente una richiesta ed estrarne l'intento. Ciò consente anche un facile ripristino da guasti parziali in quanto non ci sono stati intermedi, rendendo il servizio più affidabile.
- Sesto, richieste idempotenti (non apportare modifiche): le richieste duplicate ricevute da un agente software hanno lo stesso effetto di una singola richiesta. Questo requisito consente a fornitori e consumatori di aumentare l'affidabilità complessiva del servizio, semplicemente ripetendo la richiesta in caso di guasto.
Quindi possiamo dire che SOA non è uno strumento, ma un insieme di standard per costruire nuove applicazioni, più dinamiche e meno dipendenti. SOA facilita l'accesso alla logica aziendale e alle informazioni su più servizi in modo sistematico e può anche orchestrare più servizi remoti per comporne uno solo. la maggior parte le definizioni identificano l'utilizzo dei Web Services, che vedremo nel prossimo capitolo, nell'implementazione di un'architettura orientata ai servizi. Tuttavia, può essere implementato utilizzando qualsiasi altra tecnologia basata sui servizi.