Introduzione alle varie tipologie di Sistemi Distribuiti con una piccola introduzione all'architettura a micro servizi.

1. Architetture
distribuite
ENTERPRISE & SOLUTION ARCHITECT

2. Sistemi Distribuiti - Definizione
Alcune definizioni di Sistema Distribuito …
«Un insieme di calcolatori indipendenti che appare agli utenti ed alle applicazioni come un
singolo sistema coerente»
(Tanenbaum & van Steen)
«Un Sistema Distribuito è formato da componenti hw e sw localizzati su computer in rete che
comunicano e coordinano le loro azioni attraverso scambio di messaggi»
(Coulouris & Dollimore)

3. Sistemi Distribuiti - Tipologie
Nei Sistemi Distribuiti vi è la necessità di far comunicare diversi sistemi tra
loro. Ci sono due tipologie di sistemi distribuiti:
 Request / Response («Call & Return» or RPC):
 Orientati alla chiamata di sistema
 Usualmente sono di natura sincrona
 Possiedono parametri in input e output
 Il loro focus è sul definire i parametri, le operazioni e correlare le
risposte con la richiesta
 Non è un loro focus il come i diversi valori vengono raggruppati e
come vengono realizzate le risposte
 Message Passing :
 Orientati a dati
 Usualmente sono asincroni
 Messaggi sono costruiti e spediti ai destinatari
 Il loro focus è costruire i messaggi nel formato corretto, come instradarli
e a chi inviarli
 Non è un loro focus il comportamento dopo l’invio del messaggio e
un’eventuale massaggio di risposta
Request /
Response
OOA
Object
Oriented
ROA
Resource
Oriented
SOA
Services
Oriented
Messag
e
Passing
EDA
Event
Driven
SOA
Service
Oriented
(in alcuni
casi)

4. OOA - Object Oriented Architecture
Architettura orientata ad oggetti ha queste macro caratteristiche:
 La comunicazione avviene verso l’istanza di un oggetto
 Oggetti hanno uno stato, comportamento/azioni e un identità
 L’informazione sullo stato dell’oggetto è totalmente server-side
 La comunicazione è principalmente con stato (stateful) e in modalità sincrona
 Server sono molto complessi per permettere di utilizzare meccanismi intelligenti di gestione
degli oggetti
 Sono disegnati per minimizzare le chiamate su rete attraverso delle chiamate «bulk data»
 Usualmente usano dei protocolli non internet friendly (IIOP, DCOM or RMI)
 Usualmente richiedono passaggio per riferimento
 Marshalling / Unmarshalling degli oggetti generalmente richiede l’uso di diversi tipi di
software lato client e server

5. ROA - Resource Oriented Architecture
Architettura orientata alle risorse ha queste macro caratteristiche:
 La comunicazione avviene richiamando una particolare risorsa (una pagina html o una riga da
un database)
 La risorsa è identificabile attraverso un sottoinsieme di dati (nome pagina web, clausola where
sql)
 I dati sono indipendenti dal server e dal client
 Le risorse hanno uno stato (dato dal valore dei dati) e Identificate dalla URI o query utilizzata
 Il recupero di una risorsa crea uno snapshot dello stato corrente della risorsa sul client
 La copia master del dato rimane sul server. Tale copia non viene propagata automaticamente in
caso di modifica alle copie già presenti sul client. Possono essere tecniche di notifiche in
broadcasting attraverso l’uso di tecniche di publish/subscribe.
 Usualmente utilizzano meccanismi di cache per il riuso del dato
 Aggiornamento dei dati della risorsa può essere parziale o totale

6. ROA – REST
REST (Rapresentational State Transfer) non è un’architettura nè uno standard, ma un
insieme di linee guida per la realizzazione di una “architettura di sistema Resource
Oriented”. Per rendere un servizio secondo l’approccio REST occorre seguire i
seguenti cinque principi:
1. Identificazione delle risorse (URI ben definita)
2. Utilizzo esplicito dei metodi HTTP (GET,POST,PUT,DELETE) per uniformare le
interfacce
3. Risorse autodescrittive all’interno della risposta HTTP (XML,Json,Atom,etc..)
4. Collegamenti tra risorse tramite link ipertestuali
5. Comunicazione senza stato (ciascuna richiesta non ha alcuna relazione con le
richieste precedenti e successive. E’ possibile però trasformare uno stato in una
risorsa rest in modo da ottenere dei stati ad-hoc)

7. SOA - Service Oriented Architecture
Una Service-Oriented Architecture è un modello architetturale
concettuale che non fa riferimento a nessuna particolare
implementazione, ma definisce alcune proprietà, orientate al
riutilizzo e all’integrazione in un ambiente eterogeneo di Sistemi,
focalizzando l’attenzione sul concetto di servizio. Ogni servizio
mette a disposizione una certa funzionalità e può utilizzare
quelle che gli altri servizi hanno reso disponibile, realizzando, in
questo modo, applicazioni di maggiore complessità.
Un sistema costruito seguendo la filosofia SOA è costituito da
applicazioni e chiamate servizi ben definite ed indipendenti l’una
dall’altra, che risiedono su più computer all’interno di una rete.
L’Architettura SOA è un Enterprise Architect poiché si riferisce a
tutti i sistemi e applicazioni di un’organizzazione.
SISTEMA
Applicazione
as SERVIZIO
Applicazione
as SERVIZIO
Applicazione
as SERVIZIO
Hardware Hardware
SISTEMA SISTEMA SISTEMA

8. SOA - Service Oriented Architecture
Un Servizio dovrà essere:
 Ricercabile e recuperabile dinamicamente
 Autocontenuto e modulare, ossia indipendente dal contesto o dallo stato di altri servizi rendendolo di fatto facilmente
distribuibile e scalabile
 Definito da un Interfaccia e indipendente dalla sua implementazione
 Debolmente accoppiato con altri servizi in modo da renderlo facilmente flessibile e facilmente modificabile
 Pubblicamente accessibile attraverso la pubblicazione della sua interfaccia (in un Service Directory o Service Registry) ed
accessibile in modo trasparente rispetto alla sua allocazione  è ben definita la location
 Riutilizzabile in altri servizi creando servizi più complessi (Service Orchestration) attraverso lo scambio di messaggi adoperando
un formato standard ampiamente riconosciuto (Platform Neutral). Per ottenere questo obiettivo, i servizi dovrebbero fornire
delle interfacce a grana grossa (coarse-grained) ossia con poche funzionalità basilari.
 Senza stato
Ad oggi, l’Architettura SOA viene implementata attraverso la Web Service Architecture.

9. Web Services – Che cos’è?
Nel 1998 seguendo la strada tracciata da XML prende forma il concetto di Web
Services. Ma cosa è un web service?
Un Web Service è un servizio (applicazione modulare) ben descritto, pubblicato,
individuato ed utilizzato attraverso il web. Esso realizza delle funzioni, che
spaziano da una semplice richiesta di informazioni ad un complicato processo
commerciale.
Il loro scopo è quello di avere un approccio che realizza completamente ciò a cui
aspira la distributed computing: un modo flessibile ed economicamente
vantaggioso di sfruttare tutte le capacità e le risorse della distributed computing,
sia internamente sia esternamente e nella maniera più efficiente possibile – senza
preoccupazioni per il tipo di applicazioni o sistemi operativi coinvolti.

10. SOA - Web Service Architecture
E’ assolutamente essenziale che gli standard nell’area dei Web Services
siano ovunque gli stessi. Senza l’accordo dell’industria di tutto il mondo
sugli standard della tecnologia sottostante ai Web Services, la
promessa della neutralità delle piattaforme e della compatibilità
universale di sistemi eterogenei non può semplicemente essere
mantenuta. Per questo la Web Service Architecture ha definito le
tecnologie da utilizzare:
 SOAP per l’accesso e fruizione dei servizi remoti e distribuiti (RPC)
 WSDL per la descrizione dei servizi
 XML per definire il formato dei dati
 HTTP come protocollo di comunicazione
 UDDI per il catalogo dei servizi
Ciò non vuol dire che non si possano utilizzare altri standard di
riferimento a supporto o in sostituzione.
Web Services
WSDL
SOAP
XML
HTTP

11. Eda - Event-driven Architecture
Un‘Architettura Event-Driven si basa sul comportamento attorno
alla produzione, la rilevazione e il consumo di eventi.
Un evento è una qualsiasi occorrenza identificabile che ha un
significato per l'hardware o per il software.
L’Architettura si basa su due attori principali che utilizzano un BUS
comune di comunicazione chiamato Event Bus:
 Event Producer, è il creatore dell'evento, sa che si è verificato
l'evento
 Event Consumer sono entità che hanno bisogno di conoscere
quando accade un’evento; essi possono essere coinvolti
nell'elaborazione dell'evento o possono semplicemente
essere colpiti dall'evento stesso.
A volte, per semplificare la comunicazione tra i due attori viene
utilizzato l’Event Manager. Esso riceve la notifica di un evento da
un Event Producer ed inoltra l'evento a tutti i consumatori
collegati.
Event
Producer
Event
Producer
Event
Producer
Event
Consumer
Event
Consumer
Event
Consumer
Event BUS

12. Architettura a Micro servizi
E’ bene osservare che i micro servizi sono ancora un argomento in rapido
movimento, ma possiamo darne una definizione preliminare :
«Architettura a micro servizi è uno stile architetturale per lo sviluppo di una
singola applicazione come un insieme di micro servizi. I micro servizi sono dei
servizi piccoli e autonomi, eseguiti come processi distinti, che lavorano insieme
comunicando mediante meccanismi leggeri»
L’Architettura a Micro servizi è un Application Architecture, poiché si riferisce alla
singola applicazione (a differenza della SOA).

13. Architettura a Micro servizi
Basandoci sul fatto che ogni applicativo è composto da moduli, componenti o librerie in
maniera monolitica, l’Architettura a micro servizi si pone come obiettivo quello di trasformarli
in micro servizi dipendenti tra loro attraverso lo scambio di messaggi in maniera semplice e
veloce.
MAIN
LIB A LIB B
Main
Micro Service
A
Micro Service
B
Applicativo Monolitico Applicativo Micro Servizi
DB A+B DB A DB B

14. Architettura a Micro servizi
La scomposizione dei vari componenti in micro servizi porta diversi vantaggi:
 Riusabilità: le componenti trasformate in micro servizi possono essere utilizzate da diversi
applicativi
 Scalabilità: vengono replicati e bilanciati i soli micro servizi che necessitano
 Deployment: può essere realizzato sia su una stessa macchina che su macchine differenti
 Cloud : I microservizi sono il modo nuovo e ideale per affrontare lo sviluppo di applicativi
orientati nativamente al cloud computing

15. Contact – Giampiero Cerroni
giampiero19
gcerroni@gmail.com
linkedin.com/in/giampierocerroni
+ 39 3332250803