nei sistemi distribuiti salta l'ordine degli eventi, non si ragiona pi in prima o

dopo
le tecnologie pi adatte hai sistemi distribuiti sono quelle ad agenti
coordination-based
si estende su diverse macchine -
offre ad ogni applicazione la stessa interfaccia -
Soluzione tramite separazione -
Un sistema distribuito organizzato come middleware:
Gli strati del middleware permettono a componenti distribuiti autonomi di
interagire significativamente tra loro e nasconde le differenze di tecnologia,
struttura, comportamento...
Cos' un sistema distribuito:
dalla definizione sulle slide:
il concetto di user un po datato
Computazione e interazione, sono le dimensioni della computer science
Quando si lavora su sistemi distribuiti l'importanza dell'interazione diventa pi
evidente
Obbiettivi di un sistema distributo:
Una buona ragione per costruire in sistema distribuito per rendere le risorse
distribuite disponibili come se fossero un sistema unico
-Rendere risorse distribuite , o remote, disponibili per l'uso
Una buona ragione per costruire un sistema distribuito per rendere la
distribuzione fisica irrilevante dal punto di vista dell'utente. E' chiamata
TRASPARENZA.
-Nascondere dove non necessario la distribuzione delle risorse
Essenzialmente la propriet di poter lavorare con numero e tipo dei
componenti non stabilito a priori al tempo del design
-promuovere l'apertura
Un sistema pu scalare quando il numero di utenti o risorse aumenta, la
distribuzione geografica degli utenti e delle risorse si estende, si espande su
diversi domini amministrativa
-promuovere la scalabilit
TRASPARENZA
Trasparenza Descrizione
Accesso(Access) Nasconde la differenza nella rappresentazione dei dati e come sono accedute le risorse
Posizione(Location) Nasconde dove posizionata una risorsa
Migrazione(Migration) Nasconde che una risorsa pu spostarsi
Riposizionamento(Relocation) Nasconde il fatto che una risorsa pu essere spostata in un altro posto mentre la usa
Copia(Replication) Nasconde se la risorsa copiata
Concorrenza(Concurrency) Nasconde che la risorsa condivisa da diversi utente in concorrenza
Malfunzionamento(Failure) Nasconde la rottura e il ripristino di una risorsa
Nascondere la distribuzione pu non essere sempre la
scelta migliore, dipende dal sistema (esempio stampanti
in 2 uffici diversi, non so in quale ufficio ho stampato)
Si possono avere diversi gradi di trasparenza
Problemi per i sistemi aperti
Misura della facilit con cui poter far lavorare diversi componenti e sistemi tra loro basati su
uno stesso standard (WEB)
-Interoperabilit:
Misura quanto un applicazione pu essere spostata da un sistema ad un altro e continuare a
funzionare
-Portabilit:
Misura la facilit con cui si possono aggiungere nuovi componenti o funzionalit ad un
sistema distribuito esistente
-Estendibilit:
I componenti devono essere piccoli e facilmente modificabili, le specifiche interne devono essere
anche loro pulite.
Ci deve essere separazione tra meccanismi e politiche
Anche se un solo server un collo di bottiglia, potrebbe essere necessaria in caso
di problemi di sicurezza
-
Anche se una sola collezione di dati un collo di bottiglia, potrebbe essere
necessaria se la replicazione non sicura
-
A volte il miglior algoritmo da un punto di vista teorico potrebbe essere quello
centralizzato
-
Centralizzazione potrebbe essere necessaria:
Dovrebbe comunque essere evitata.
Scalabilit geografica:
In un singolo dominio, utenti e componenti potrebbero essere affidabili, ma la
fiducia non esce dal confine del dominio
In un sistema distribuito si diffonde spesso in pi domini
Nascondere le latenze di comunicazione ( comunicazioni asincrone) -
Distribuzione -
Replicazione -
Tecniche:
Computer scientist definition:
Un sistema distribuito un insieme di computer indipendenti che appaiono all'utente come un solo
sistema coerente
Computer engineer definition:
Un sistema distribuito un insieme di entit computazionali autonome che sono concepite come un un
unico sistema coerente dal suo ideatore.
Un sistema distribuito composto da un molteplicit di componenti: entit computazionali autonome ,
indipendenti ed eterogenee , senza assunzione sulla loro natura, struttura o comportamento individuale
I maggiori problemi sono la Collaborazione e l'Amalgamazione delle entit: devono lavorare insieme e
sembrare un sistema uniforme
I sistemi aperti sono inprevedibili quindi richiesto che ci
siano oggetti prevedibili, deve esserci qualcosa condiviso
tra il sistema e il potenziale componente. Ad esempio
regole strandard per la sintassi e la semantica.
Per specificare la sintassi si usano le interfacce, che
vengono specificate mediante l'uso di IDL (Interface
Definition Language)
Introduzione
marted 25 febbraio 2014
13:59
Sistemi Distribuiti Pagina 1
A volte il miglior algoritmo da un punto di vista teorico potrebbe essere quello
centralizzato
-
Dovrebbe comunque essere evitata.
I dati dovrebbero confluire da tutta la rete in un solo posto -
La rete sarebbe in sovraccarico -
Un problema di trasmissione pu causare problemi all'intero algoritmo -
Problemi degli algoritmi centralizzati:
la suddivisione di un algoritmo in pezzi, ogni macchina ne fa una certa parte -
Nessuna macchina ha conoscenza completa dello stato del sistema -
Rottura di una macchina non distrugge l'intero algoritmo -
Caratteristiche degli algoritmi decentralizzati:
La centralizzazione sempre un casino
Nascondere le latenze di comunicazione ( comunicazioni asincrone) -
Distribuzione -
Replicazione -
Tecniche:
Comunicazione asincrona:
Mando una richiesta, non aspetto che arrivi la risposta e proseguo con il mio
lavoro, se ricevo la risposta la gestisco
A volte pu non essere fattibile una richiesta asincrona. Per la navigazione
web ,si fa in modo che i browser eseguano il pi possibile tramite javascript
Distribuzione:
Spezzare in parti e spargerle per il sistema.
Replicazioni:
Quando c' un degrado di performance, la replica di un componente pu
incrementare la disponibilit e riducendo la latenza. Si copia da una location ad
un'altra pi vicina.
Una particolare replica il caching che a differenza della replicazione decisa
dal cliente della risorsa.
La replicazione pu portare a problemi di inconsistenza , tecnicamente
inevitabile , il punto quanta inconsistenza intollerabile.
Insidie nei sistemi distribuiti:
La rete affidabile -
La rete sicura -
La rete omogenea -
La topologia non cambia -
La latenza 0 -
La banda infinita -
Il costo di trasporto 0 -
C' un amministratore -
Assunzioni False :
Di solito queste assunzioni producono tutti i problemi dell'ingegneria dei sistemi distribuiti
Affidabilit della rete -
Sicurezza della rete -
Eterogeneit della rete -
Topologia della rete -
Latenza -
Larghezza di banda -
Costo di trasporto -
Domini amministrativi -
Bisogna affrontare queste tematiche:
In un sistema non-distribuito non emergono.
Sistemi di computazione distribuiti -
Sistemi di informazione distribuiti -
Sistemi pervasivi distribuiti -
Tipi di sistemi distribuiti:
Sistemi di Calcolo distribuiti:
La necessit di potenza di calcolo non soddisfatta dalla potenza fornita dai singoli componenti.
Si pensa quindi a mettere insieme pi calcolatori.
A cluster: -
una collezione di macchine simili tra loro, con lo stesso OS, nella stessa zona, interconnesse
da LAN ad alta velocit.
Le motivazioni principali sono che: costava meno mettere insieme pi computer meno
potenti che comprarne uno pi potente; e era robusto, con facile mantenimento e
miglioramento.
L'uso principale la computazione parallela, tipicamente un solo programma a
computazione elevata caricato su tutte le macchine
E' omogeneo
A griglia -
Un sistema a griglia tipicamente eterogeno.
Risorse da differenti organizzazioni sono portate insieme per promuovere la collaborazione
fra individui gruppi e istituzioni, oltrepassando le barriere di organizzazione.
E' costruita mediante organizzazioni virtuali.
Ha a che fare con diversi domini amministrativi.
Esistono diversi strati: Fabric, Connectivity, Resource, Collective, Application
Sono due tipi:
Sistemi di informazione distribuiti: (meglio il suicidio all'inizio)
Svariati server non-interoperanti condivisi da un certo numero di
clienti. (Transaction Processing System):
-
Operazioni sui database sono transazioni, in un database distribuiti
anche la transazione dovrebbe esserlo.
Servono delle primitive.(BEGIN_TRANSCATION,
END_TRANSCATION,ABORT TRANSCATION,READ, WRITE)
Si usano transazioni nested: dovrebbero essere interamente ACID.
Si pu lavorare su una copia e se una subtransazione fallisce tutte
le altre devono essere considerate come tali. Se tutto va a buon
fine si fa il commit
Svariate applicazioni sofisticate devono comunicare tra loro.
(Enterprise Application Integration):
-
Non solo un problema di accesso a database distribuiti, deve
avvenire anche a livello applicativo. Integrazione dei processi oltre
che dei dati
Le applicazioni dovrebbe interagire tra loro significativamente.
Il middleware come facilitatore di comunicazione.
Nasce dai database, pi applicazioni di rete separate da integrare,
problemi strutturali di interoperabilit.
Sistemi distribuiti pervasivi:
(dispositivi mobili con batterie e sporadiche assenze di segnale)
parte di quello che ci circonda.
Generalmente ha poco controllo amministrativo umano.
Devono abbracciare il cambiamento nel contesto(devono essere felici dei cambiamenti nel
contesto)(il contesto la parte del mondo che interessa a me, al mio sistema)
-
Incoraggiare composizioni ad-hoc -
La condivisione base -
Requisiti:
Sistemi casalinghi: dovrebbero essere auto-configuranti e auto-manutenuti, alle persone non sono
richieste competenze di amministrazione di rete o di sistema
Sistemi costruiti attorno alle informazioni personali: un enorme quantitativo di dati eterogenei devono
essere gestiti, provenienti da sorgenti eterogenee fuori e dentro il sistema. (forno che sapendo le ricette
tipiche controlla gli ingredienti nel frigo e ti avverte se manca qualcosa)
Sensori per la salute
Sistemi Distribuiti Pagina 2
Sensori per la salute
Reti di Sensori
Sistemi Distribuiti Pagina 3
Architetture software: sono i modi di organizzare i componenti di un sistema distribuito
Componenti -
Modo di interconnessione dei componenti -
I dati che passano tra i componenti -
Il modo in cui queste cose sono configurate insieme -
Uno stile di architettura formulato in termini di:
Questa definizione permette di suddividere e classificare i sistemi, di compararli e fornisce una guida di design.
Un componente un unit modulare con una interfaccia ben definita, sostituibile nel suo ambiente.
l'interfaccia sia richiesta che fornita, ovvero cosa il componente pu chiedere al sistema, e cosa il sistema pu chiedere
al componente.
Un connettore una qualunque cosa che fornisce meccanismi di interazione tra componenti
A seconda dei componenti e dei connettori possiamo fare una prima divisione di stili
Architettura a layer: un layer pu comunicare solo con i layer vicini. chiamare il livello sotto, e essere chiamati da
quelli sopra.
-
Architettura basata sugli oggetti: il componenti sono oggetti, che comunicano tra loro via RPC. E' il tipico modo in
cui sono costruite le architetture client-server. ( pi diffuso oggi, ma non per i sistemi progettati per il futuro).
-
Architetture centrare sui dati: la comunicazione tra i processi avviene attraverso un repository condiviso, che pu
essere attivo o passivo; dipendono dalla scelta fatta nel repository: come sono rappresentati i dati, come sono
gestiti gli eventi, come risponde alle interazioni, come i processi interagiscono con e mediante la repository.
-
Architettura basata sugli eventi: i processi comunicano tramite l'event bus, attraverso il quale si propagano gli
eventi, non necessitano di conoscersi tra loro, e non devono condividere uno spazio comune per poter comunicare
-
Architettura a data-space condivisoIl problema che a volte l'attesa non pu essere troppo elevata. Si deve
scaricare il carico.: unione di data-centric e event-base. La shared repository sia un data-space persistente che un
bus eventi, dove i dati sono salvati e accessibili insieme agli eventi legati.
-
Esistono principalmente 4 stili architetturali:
Architetture di Sistema:E' come sono sparsi i componenti del sistema effettivamente.
Architetture centralizzate:
Client Server:
Connectionless: ok per le operazioni idempotenti ( eseguibili pi di una volta senza danno) -
Connection oriented: meno efficiente ma assicura affidabilit. -
In un architettura centralizzata il client richiede servizi al server. I due componenti sono divisi ovviamente in client e
server, e un componente pu essere sia client che server.
Application Layering:
User interface level: interfaccia utente -
Processing level: contiene le logiche di controllo, il nucleo dell'applicazione -
Data level: gestice i dati che interessano all'applicazione -
La suddivisione logica nelle architetture client server:
L'organizzazione logica non fisica, client e server potrebbero essere distribuiti come nello stesso computer.
Two-tiered:
Organizzazione in 2 tipi di macchine: client e server che si divino l'applicazione ( vedi cap. 2 slide 30)
Three-tiered:
Architetture software
marted 18 marzo 2014
14:22
Sistemi Distribuiti Pagina 4
Three-tiered:
Organizzazione in 3 tipi: i server suddivisi in sotto server: application server e database server.
Architetture decentralizzate:
Distribuzione verticale: divisione in tear come visto sopra. -
Distribuzione orizzontale: quando la distribuzione fisica dei client e dei server importante. I client
e i server potrebbero essere divisi in parti logicamente equivalenti, ognuna che si occupa di una
sua porzione dei dati(peer to peer)
-
Architetture Ibride:
Possono essere necessarie propriet di entrambi i sistemi, messe insieme sono dette architetture ibride
Collaborativa: (bittorrent)
Il sistema ha problemi a partire, si usa un interazione client-server , una volta instaurato il dialogo si usa
la logica peer-to-peer completamente decentralizzata
Architecture vs. Middleware
Il middleware non neutro, si porta dietro modelli, stili, astrazioni, componenti che influenzano il tipo di
sistema che si pu costruire attorno ad esso.
Sono le applicazioni a doversi adattare al middleware di solito, non il contrario, in quanto molto
pervasivo.
Quando si sceglie il middleware si cerca qualcosa che abbia tutti le astrazioni richieste.
Se il mio middleware comprende svariate volte il pattern interceptor, molto flessibile.
Adapting middleware
Una soluzione fissa pu fallire di fronte a cambiamenti imprevisti.
Creare un sistema adattativo pi facile a dirsi che a farsi.
Separazione delle preoccupazioni:
separazione di funzionale da non-funzionale, queste ultime(comprendenti affidabilit,
performance, sicurezza) vanno gestite separatamente. Aspect-oriented programming.
-
Riflessione computazionale: -
La capacit di controllare se stessi ed eventualmente di auto-adattare il comportamento, cuore
dei moderni linguaggi di programmazione. Il programma osserva lo stato di se stesso, e basandosi
sull'ambiente circostante si pu auto-adattare
Design a componenti:
i comportamenti sono aggiunti "al volo", grazie all'apertura dell'architettura, tramite componenti
-
Tre tecniche base:
Self-managment
Automatic Adaption:
l'imprevedibilit dei cambiamenti rende l'adattamento guidato fallimentare, dovrebbero essere in grado
di rilevare cambi (rilevanti) nell'ambiente e di conseguenza cambiare, adattarsi.
l'adattamento deriva dal un sorta di loop feedback
Sistemi Distribuiti Pagina 5
Un architettura software un astrazione degli elementi di run-time di un sistema software durante alcune fasi delle sue
operazioni. Un sistema pu essere composto da diversi livelli di astrazione e diverse fasi di operazione, ognuna ha una
propria architettura software .
Un architettura software definita dalla configurazione di elementi architetturali (Componenti,connettori,data) ,
vincolati nelle loro relazioni in modo da raggiungere certe propriet architetturali.
Componente: unit astratta di istruzioni software e stato interno, che fornisce una trasformazione di dati
attraverso la sua interfaccia.
-
Connettore: meccanismo astratto che fa da mediatore tra i componenti -
Data: un informazione che trasferita da o a un componente tramite un connettore. -
Uno stile architetturale un set coordinato di vincoli architetturali, che presi insieme mi danno una restrizione su come
gli elementi possono essere organizzati tra loro.
Nel web non c' controllo sulla scalabilit da parte di un singolo
Il cambiamento del web incrementale, disordinato
ReST(Representational State Transfer)
Si inizia dal cosidetto "Null Style", punto di partenza concettuale, senza nessun vincolo. Essi vengono aggiunti
successivamente.
Principio: separazione delle preoccupazioni ( tra interfaccia utente e dati)
Vincolo: un server offre servizi e ascolta per questi, un client che vuole un servizio manda una
richiesta al server tramite un connettore, il server o esaudisce la richiesta e restituisce un risultato
oppure la rifiuta.

Propriet:
migliora la portabilit dell'interfaccia utente tra varie piattaforme,
migliora la scalabilit semplificando il componente server,
permette l'evoluzione indipendente dei componenti

Client Server: -
Vincolo:Ogni richiesta da parte dell'utente deve contenere tutti i dati interessanti per la
compressione della richiesta, non si deve fare affidamento su dati del server.

Properties:
- migliora la visibilit permettendo di determinare la natura della richiesta, senza guardare oltre
- migliora l'affidabilit, facilitando il recupero da fallimenti parziali
- migliora la scalabilit, permettendo ai server di rilasciare velocemente le risorse
- migliora la semplicit perch il server non deve gestire risorse tra le richieste
- peggiora la performance di rete, a causa dell'overhead in caso di richiesta multiple consecutive
- riduce il controllo del server

Stateless: -
Vincoli: i dati in una risposta, possono essere esplicitati o meno come inseribili in cache, se in
cache il client pu riusare la copia salvata in caso di una richiesta uguale futura

Propriet:
migliora efficienza scalabilit e performance percepita, riducendo la latenza
diminuisce l'affidabilit se i dati in cache sono molto diversi da quelli che restituirebbe il server

Cache: -
Vincoli:
Architetture del Web
venerd 21 marzo 2014
15:04
Sistemi Distribuiti Pagina 6
diminuisce l'affidabilit se i dati in cache sono molto diversi da quelli che restituirebbe il server
Principio di generalit
Vincoli: Identificazione delle risorse, un tipo di interazione uniforme, messaggi auto descrittivi,
hypermedia come motore di stato dell'applicazione.

Propriet:
Semplificazione di tutto il sistema,
migliora la visibilit delle interazioni,
incoraggio l'evoluzione indipendente disaccoppiando l'implementazione dal servizio.
degrado di efficienza a causa del trasferimento di informazioni in modo standardizzato (general
purpose ) anziche specifico e personalizzato

Interfaccia Uniforme: -
Vincolo: composizione dell'architettura in modo gerarchico costringendo i componenti a certi
comportamenti (tipo non vedere gli strati sotto di lui)
Migliora la semplicit e promuove l'indipendenza restringendo le conoscenze ad un solo layer,
migliora la scalabilit permettendo load balancing dei servizi agli intermediari,
migliora la sicurezza attraverso policy tra i livelli.
Riduce le performance percepite dall'utente a causa dell'aumento dell'overhead

Sistema a strati: -
Vincolo: Le funzionalit del client possono essere estese scaricando ed eseguendo
codice(Javascript).

Propriet: Semplifica il client riducendo il numero di caratteristiche da pre-implementare,

migliora l'estendibilit.
Riduce la visibilit

Codice on Demand: -
L'architettura Representational State Transfer (ReST) uno stile archietturale, quindi un astrazione degli
elementi archietturali per il web, i dettagli sono tralasciati in quanto astrazione.
Il ruolo dei componenti -
I vincoli sull'interazione dei componenti -
L'interpretazione da parte dei componenti di dati significativi -
Ci concentriamo su:
I componenti ReST comunicano trasferendo una rappresentazione di una risorsa tramite uno standard
evolvente, selezionato dinamicamente basandosi sulle capacit e i desideri del ricevente e la natura delle
risorse. Anche se la rappresentazione comunque nel formato della sorgente, o in un suo derivato,
rimane nascosta dall'interfaccia del componente.
(un documento, un immagine, un oggetto temporale (il meteo di oggi in una citt italiana), una
collezione di risorse, un oggetto non virtuale).
Risorsa:
L'astrazione principale la risorsa, una qualunque informazione che pu essere nominata ed
abbastanza importante da poter essere riferita come una cosa in se
Una risorsa un mapping concettuale ad un insieme di entit, non ad un entit specifica che rappresenta
il mapping in un determinato momento.
Le entit possono essere: resource representations, resource identifiers.
Una risorsa pu essere mappata anche prima che essa esista, un concetto prima della sua realizzazione.
Una risorsa pu essere statica ( quando analizzata in un qualunque momento dopo la sua creazione
sempre la stessa) o dinamica ( altrimenti)
Fornisce generalit comprendendo pi sorgenti di informazioni. -
Permette il late binding del riferimento alla rappresentazione. -
Permette un autore di referenziare il concetto invece che una specifica rappresentazione di esso -
La definizione astratta delle risorse permette alcune delle caratteristiche chiave del web:
Ogni risorsa deve avere un identificatore in forma di URI( nome e indirizzo della risorsa). Le uri
dovrebbero avere una struttura, che dovrebbe variare prevedibilmente. Una risorsa pu avere pi URI,
ma un URI punta sempre ad una sola risorsa. Un URI e la sua risorsa dovrebbero avere una
corrispondenza intuitiva.
Sistemi Distribuiti Pagina 7
Rappresentazione:
Una rappresentazione una sequenza di byte, pi metadati di rappresentazione che descrivono quei
byte. I metadati di rappresentazione in forma di coppie nome-valore, dove il nome corrisponde ad uno
standard che definisce la struttura e la semantica del valore
Media Types:
Il formato dei dati di una rappresentazione. Pu impattare direttamente le performance percepite
dall'utente, ogni dato in pi aggiunge latenza
Connector:
Forniscono una generica interfaccia per l'accesso e la manipolazione al set di valori di una risorsa,
incapsulano le attivit delle risorse di accesso e di trasferimento
(Client Server, Resolver, Tunnel, Cache)
Components:
Origin server, Gateway, proxy, user agent
Sistemi Distribuiti Pagina 8
Comportamento non bloccante
! Una chiamata di sistema bloccante pu essere eseguita senza che si blocchi l'intera
applicazione
-
Sfruttare il parallelismo
! Un unit multi-processore pu essere sfruttata al meglio
-
Sfruttare la comunicazione tramite spazio di dati condiviso in grandi applicazioni
! Un applicazione multi-thread pi veloce a switchare di una multi processo
-
Espressivit della potenza dell'ingegneria del software
! Un applicazione multi-thread modella un applicazione concorrente cooperativa facilmente
-
Threads Benefits:
Tuttavia, i processi nei sistemi distribuiti sono veramente concorrenti, e l'accoppiamento nei sistemi
distribuiti pi complicato.
Virtualizzazione:
Ogni risorsa pu essere condivisa e vista come virtuale.
Questo migliora il porting del software Legacy, il quale cambia pi lentamente dell'hardware su cui
gira; migliora il porting su rete, in quanto piattaforme eterogenee sono interconnesse e fanno girare
applicazioni diverse; un server pu essere replicato dove e quando si vuole
Code Migration:
A volte per ragioni di sicurezza, scalabilit, load balancing non solo i dati devono essere trasferiti,
ma anche il codice.
Solitamente si sposta con tutto il suo contesto, ovvero si muove tutto il processo.
Un processo si divide essenzialmente in 3 segmenti:
Code segment(il set di istruzioni del processo) , resource segment( il set di riferimenti alle risorse
esterne), execution segment(dove viene salvato lo stato di esecuzione del processo(private data,
stack , program counter)
Weak: dove solo il codice, e qualche dato di inizializzazione sono trasferiti; il codice pu quindi
essere eseguito ex-novo ovunque.
-
Strong: il code segment viene trasferito insieme all'execution segment; permettendo di
stoppare, spostare e fare ripartire il processo su un'altra macchina
-
Ci sono quindi diversi tipi di mobilit:
Per quanto riguarda il resource segment il discorso non semplice.
Esso si riferisce alle risorse tramite Id, valore o tipo.
Possiamo differenziare le risorse per il loro grado di mobilit: unattached, fastened, fixed. Le prime
due si possono spostare, ma le fastened (come un database locale) hanno un costo per il
trasferimento, le fixed non si possono spostare invece e di solito sono oggetti fisici.
Stabilire un riferimento a livello di sistema globale -
Spostare la risorsa -
Copiare il valore della risorsa -
Bindare il processo ad una risorsa disponibile localmente -
A seconda della combinazione del grado di mobilit e del metodo di referenziazione si possono
eseguire le seguenti operazioni:
Processi nei Sistemi Distribuiti
venerd 28 marzo 2014
15:42
Sistemi Distribuiti Pagina 9
E' importante vedere i sistemi dal punto di vista dell'interazione e della computazione.
Processi, thread, LWP sono rappresentazioni della parte computazionale.
I componenti di un sistema compongono un sistema solo se interagiscono tra loro.
La comunicazione una forma di interazione dove avviene uno scambio di informazioni. (non
tutte le interazioni sono comunicazioni)
Persistent Comunication: Un messaggio salvato dal middleware di comunicazione finch
non ricevuto. Non richiede la compresenza .
-
Transient communication: Un messaggio salvato dal midlleware finch client e server sono
attivi. Richiede la compresenza.
-
Asynchronous commnunicaton: E' tale se chi emette la comunicazione pu continuare
senza aspettare la risposta.(poco dettaglio) il messaggio dovrebbe essere salvato nel
middleware.
-
Synchronous communication: E' tale se chi emette la comunicazione aspetta una risposta,
o una conferma, o quando l'altro ha finito.
-
Tipi di comunicazioni:
Sono usate varie combinazioni di persistenza e sincronizzazione.
Message oriented transient comunication:
Messaggi inviati tramite un astrazione a canale, che connette due processi, deve esserci
compresenza tra sender e receiver(il tempo misurato in millisecondi).(esempio MPI, Berkley
Sockets)
Message Oriented persistent comunication (Message Oriented Middleware)
MOM fornisce un servizio di salvataggio messaggi, i quali sono messi in coda dal sender e
consegnati alla coda del receiver, il quale pu prendere il messaggio da questa coda , non
necessit di compresenza. (Esempio: IBM's WebSphere)
Uno stream trasmesso inviando sequenze di messaggi inerenti.
In caso di media continui (filmati) il tempo rilevante per comprendere il dati, in caso di media
discreti(immagini fisse) non rilevante.
La trasmissione asincrona usata per un immagine, i dati sono inviati in ordine senza altri vincoli.
La trasmissione sincrona usata per sensori pro-attivi, i dati sono inviati in ordine ma con un delay
massimo fissato.
La trasmissione isosincrona usata per i video, i dati sono inviati in ordine ma con delay minimo e
massimo fissati.
Comunicazione nei sistemi distribuiti
marted 1 aprile 2014
15:40
Sistemi Distribuiti Pagina 10
Il problema del naming:
Dare un nome alle entit computazionale.
Dato un nome trovare l'entit associata detto "name resolving"
C' una porzione del middleware detta naming system che si dedica alla risoluzione dei nomi (dato
un nome dice a cosa si riferisce).
E' un problema che si riscontra in generale nei sistemi computazionali, ma nei sistemi distribuiti pi
problematico.
Openness -
Location -
Mobility ( la relazione con la posizione non duratura o stabile) -
Distribution of the naming sytem -
Tutto ci a causa di:
Nome:
E' qualcosa che si riferisce ad un entit.(stringa, sequenza di simboli)
Definizione dell'insieme dei nomi ammissibili (definizione di una grammatica per i nomi)
(definizione intenzionale)
-
Definizione dell'insieme delle entit nominabili -
Definizione dell'associazione tra nome e entit (possibilmente in maniera formale) -
Definire un naming system consiste nella:
Entit:
Un entit qualcosa con cui puoi operare, accedendo tramite un "access point"
L'access point un entit particolare del sistema distribuito, usata per accedere ad un entit, come il
telefono per accedere a noi
Indirizzo:
Per accedere ad un entit tramite un access point serve un indirizzo, come il numero di telefono,
l'indirizzo dell'access point pu essere considerato per estensione l'indirizzo dell'entit.
Sono nomi di un qualche tipo, ma non vengono usati come nomi perch non semplici da elaborare
all'uomo
Identificatore:
un particolare tipo di nome, che si riferisce al massimo ad una entit, ed ogni entit riferita da
massimo un identificatore. Si riferisce sempre alla stessa entit, non mai risultato
Risoluzione di nomi:
Si possono usare tabelle con coppie (nome, indirizzo)
Flat Naming:
Il nome una sequenza piatta di caratteri/simboli.
Esempio: un messaggio con l'identificatore viene inviato a tutti e solo chi ha quella risorsa risponde,
poco efficiente con l'allargarsi delle risorse
Structured Naming:
Il nome composto da nomi comprensibili facilmente dall'uomo , come i nomi internet.
Name Space: organizzata in modo gerarchico, secondo un grafo, il naming graph. I nodi foglia sono
rappresentativi delle entit nominate, i nodi direttivi hanno un numero di uscite ognuna etichettata
con un identificatore
Naming nei sistemi distribuiti
marted 8 aprile 2014
14:35
Sistemi Distribuiti Pagina 11
Attribute based Naming:
Una collezione di <attributi,valori> associati ad un entit per descriverli. (come funzionano le pagine
gialle)
Sono conosciuti anche come "Directory services". Stanno dentro al middleware.
E' strutturato in moda da rispondere a query.
Sistemi Distribuiti Pagina 12
Adesso qua diverso da adesso l
Il sistema di eventi pu essere al pi parzialmente ordinato. Meglio non considerare l'ordine.
Nei sistemi distribuiti pu non esserci una nozione di tempo globale, bisogna vedere se possibile definirla
Tempo Fisico:
In un sistema centralizzato la nozione di tempo disambigua, in un sistema distribuito non c' una nozione naturale di tempo.
E' possibile crearla?? E' utile crearla??
Prendendo due clock teoricamente uguali essi in verit saranno diversi, dopo un certo tempo perderanno la sincronia, la
differenza di tempo tra i due detta "clock skew"
E' necessario per la sincronizzazione degli algoritmi.
Global absolute time:
fornito dal BHI di parigi, espresso in termini UTC, trasmesso come impulso ad onde corte ogni secondo UTC
ora si usa NTP(Network Time Protocol), il server ha l'absolute global time e le altre macchine devono sincronizzarsi
-
Global relative time:
a volte l'unica cosa necessaria un tempo condiviso, non assoluto, quindi algoritmi basati su server attivi, fanno polling su
altri server per capire il tempo medio
-
Esistono due approcci: global absolute time, global relative time.
Tempo Logico:
Come step successivo, possiamo osservare che spesso semplicemente necessario un clock condiviso, anche non relazionato al
tempo reale, quindi possibile e utile una nozione di tempo logico.
A volte non importante il tempo in cui avvien un azione ma l'ordine con cui vengono eseguite
La sincronizzazione di un clock logico sia ammissibile che utile.
Se a e b sono eventi nello stesso processo e a avviene prima di b allora sono ordinati dal tempo locale
Se un messaggio inviato da un processo con un evento 'a' e ricevuto da un processo con evento 'b', allora un
messaggio ci mette un tempo finito positivo e maggiore di 0 a propagarsi dal mandante al ricevente.

Pu essere osservato questo comportamento in 2 situazioni:

a-->b transitiva: a-->b ,b-->c allora a-->c
Quando a-->b o b-->a non possono essere osservati, allora non si pu dire nulla sul loro ordine, quindi a e b sono
concorrenti.
a --> b si legge : "a precede casualmente b" e significa che tutti i processi sono d'accordo che 'a' avvenga prima di 'b'
Una nozione condivisa di tempo per un evento a: "time value" C(a) tale che ogni processo l'accetti
Il "Time value" dovrebbe essere pensato come il valore di un clock logico su cui tutti i processi sono d'accordo
a-->b implica che C(a)<C(b)
Algoritmo di Lamport:
Ogni processo Pi ha un contatore locale Ci
Prima di eseguire un evento, Pi esegue Ci <--- Ci+1 1.
Quando mando un messaggio 'm' a Pj, Pi setta il time stamp di 'm' ts(m) a Ci (dopo aver eseguito l'aggiornamento) 2.
Alla ricezione di un messaggio 'm', Pj aggiusta il contore locale a Cj = max(Cj,ts(m)) poi procede con lo step 1 3.
I contatori sono aggioranti seguendo i seguenti step:
Multicast totalmente ordinato:
Problema: un database replicato in due banche, un cliente versa 100$ e un impiegato aumenta dell'1% il conto. Nelle due
banche i dati sono diversi, c' inconsistenza a causa di update concorrenti.
Assunzioni: il gruppo di processi in multicast tra di loro; ogni messaggio inviato con il timestamp logico locale del
processo; anche il mittente riceve il messaggio; l'ordine di ricezione dei messaggi da uno stesso mittente uguale a quello
con cui vengono spediti.
Algortimo: Ogni processo mantiene una coda dei messaggi ricevuti ordinati per timestamp;
ogni messaggio confermato con un messaggio multicast con il timestamp secondo l'algoritmo di Lamport;
solo alla ricezione di tutte le conferme il middleware inoltra il messaggio all'applicazione;
Soluzione:
Sincronizzazione nei sistemi distribuiti
marted 8 aprile 2014
15:43
Sistemi Distribuiti Pagina 13
solo alla ricezione di tutte le conferme il middleware inoltra il messaggio all'applicazione;
avendo i processi la stessa coda, i messaggi sono inviati all'applicazione contemporaneamente
Vector Clock:
a-->b implica C(a) < C(b) ma C(a) < C(b) non implica a-->b. Se questi due eventi non sono relazionati il confronto inutile.
Manca la possibilit di dire se 'a' e 'b' sono relazionati. Per farlo devo usare i Vector Clock
Se dato VC(a) per ogni 'b', VC(a) < VC(b) allora 'a' precede casualmente 'b'
Vci[i] il numero di eventi avvenuti in Pi (il clock logico di Pi), ogni nuovo evento viene incrementato -
Vci[j] = k significa che Pi sa che in Pj sono avvenuti k eventi(il clock di Pj per quello che sa Pi), ogni messaggio da Pi
stampato con Vci
-
Ogni processo Pi mantiene un vettore Vci tale che
Prima che ogni evento venga eseguito Vci[i] <= Vci[i] +1 -
In un messaggio da Pi a Pj ts(m) =VC -
Alla ricezione del messaggio m da PJ, per ogni k;VCj[k] <= max(VCj[k]; ts(m)[k] ); poi m inviato all'applicazione -
Algoritmo:
Risultato:
Informazioni sulla catena di eventi sono preservate e condivise tra i processi
ts(m) dice quanti eventi possono precedere casualmente l'invio di m, su cui m pu dipendere casualmente
Sistemi Distribuiti Pagina 14
La replicazione dei dati, aumenta l'affidabilit del sistema, ne migliora le performance e permette di
scalare meglio.
Ma porta due problemi, un costo in termini di risorse computazionali, e di banda, e incosistenza.
Prima di risolvere il problema della consistenza, importante definire un modello di consistenza , un
contratto.
Il concetto ruota attorno ai modelli di consistenza.
Un modello di consistenza un contratto tra i processi e i data store, che assicura la correttezza dei
dati, dato un set di regole che i processi devono seguire
Consistenza Continua. Obbiettivo: imporre limiti alle deviazioni tra le repliche. (numerical
deviations, staleness deviation(freschezza dei dati), ordering deviation)
-
Consistenza: nozione di "Unit di Consistenza", chiamata "conit", ogni datastore suggerisce
esplicitamente o no la sua conit.
-
Consistent Operation Ordering. -
Consistenza Sequenziale: tutte le operazioni vengono visti da ogni processo nello stesso
ordine. Un data store sequenzialmente consistente quando il risultato di ogni esecuzione lo
stesso come se le operazioni di tutti i processi fossero eseguite in un qualche ordine
sequenziale, e le operazioni di ogni programma appaiono nella sequenza specificata dal
programma
-
Consistenza Causale: Un data store causally consistent quando tutti i processi vedono le
operazioni di write in relazione di causa/effetto nello stesso ordine.
-
Modelli Data-Centric:
i primi ad essere distribuiti, storicamente, sono stati i dati. Un modello di consistenza un contratto,
tra i processi e le risorse dove sono i dati, che dato un insieme di regole, che i processi devono
seguire, mi garantisce la correttezza dei dati.
condividere dati nello scenario mobile, il client si connette a differenti repliche nel tempo, e le
differenze devono essere rese trasparenti. Si assicura che quando il client si connette ad una
nuova replica, essa "up to date" in accordo con l'accesso precedente del client dalle altre
repliche.
-
Eventual Consistency (alla fine, prima o poi):grande data store distribuito con quasi nessun
conflitto di update. Pi letture e poche scritture. L'unico conflitto nel caso che non sia
definito correttamente il conic, quando leggo durante una modifica. (Es. DNS).
Problemi: dati non aggiornati potrebbero essere forniti, spesso per un inconsistenza
accettabile, ma alla fine (eventualy) tutti i dati sono consistenti
-
Monotonic Reads: un data store fornisce "Monotonic-read Consistency" se:
un processo legge il valore di un data item X, tutte le successive letture restituiranno lo stesso
valore o uno pi recente.
-
Monotonic Write: un data store fornisce "Monotonic-write Consistency" se:
un operazione di scrittura su un data item X completata prima di ogni successiva scrittura su
x dallo stesso processo.
-
Read your Writes: un data store fornisce "read-your-writes Consistency" se:
L'effetto di una scrittura da parte di un processo su un data item X sar sempre visibile da una
successiva lettura su X dallo stesso processo.
-
Writes follow Reads: un data store fornisce "writes-follow-reads Consistency" se:
Una operazione di scrittura su un data item X a seguito di una lettura garantita avvenire sullo
stesso o pi recente valore di X
-
Modello Client-Centric:
Consistenza e replicazione dei sistemi distribuiti
marted 15 aprile 2014
15:38
Sistemi Distribuiti Pagina 15
stesso o pi recente valore di X
Problemi chiave della replicazione:
Supportare la replicazione vuol dire decidere dove e da chi dovrebbero essere posizionate le repliche
e quali sistemi usare per mantenere la consistenza.
Posizionare i server di replica -
posizionare i contenuti -
2 Problemi:
Replicazione dei servizi:
Replicazione non vuol dire solo replicare i dati, ma anche funzioni
Replicazione dei processi:
Anche i processi possono essere replicati in uno scenario distribuite mobile, potrebbe richiedere la
clonazione o meccanismi di alto livello
Sistemi Distribuiti Pagina 16
Partial Failure:
Una tipica funzionalit di un sistema distribuito la nozione di "Partial Failure". Un componente
potrebbe fallire mentre il resto continua a funzionare.
Ridurre l'impatto del fallimento di un componente sugli altri e sul sistema completo -
Sfruttare il fallimento parziale per recuperare dal fallimento -
Ci sono due obbiettivi possibili:
Availability: Il sistema pronto per un uso immediato -
Relaiability: Il sistema pu continuare a funzionare per lunghi tempi senza failure -
Safety: Se il sistema subisce un fallimento temporaneo, non capita nulla di catastrofico. -
Maintainability: Se il sistema facile da manutenere -
Principali funzioni dei dependable system(sistemi affidabili):
Transient Fault: avvengono una volta poi basta. -
Intermittent Fault: avviene, poi scompare e riappare successivamente, e cos via -
Permanent Fault: continua ad esistere finche non si sostituisce o ripara il componente -
Fallimento: un sistema fallisce se non si comporta come dovrebbe, a causare il problema un errore,
la causa di un errore un guasto.
La tecnica chiave per mascherare i guasti la ridondanza: aggiungere bit, re inviare messaggi o rifare
transazioni
Tolleranza ai guasti nei sistemi distribuiti
marted 29 aprile 2014
15:29
Sistemi Distribuiti Pagina 17
Tradizionalmente il middleware sta in mezzo tra il S.O. e l'applicazione
Applicazioni in cima al Middleware in cima al S.O.
Top Interfaces: Interfacce tra middleware e applicazione
Bottom Interfaces: Interfacce tra middleware e sistema operativo
Il middleware sviluppato una volta per tante applicazioni, pu fornire servizi alle applicazioni, astrae dal sistema operat ivo
Il middleware inter-operativo: pi applicazioni con lo stesso middleware possono inter-operare
Enterprise Application Integration enfatizza la comunicazione orizzontale: application-to-application e middleware-to-middleware.
Il software non nasce dal vuoto, deve far fronte con i sistemi precedenti. Non si comincia dal nulla, la soluzione l'integr azione dei
sistemi, con l'aggiunta di nuove funzioni, cercando di non modificare i sottosistemi gi esistenti.
Conceptual Integrity : La propriet del sistema di essere comprensibile e spiegabile tramite un coerente e limitato gruppo di
concetti.
Le tecnologie di middleware sono tecnologie di integrazione: per fare ci cerca di lanciare un modello su applicazioni eterog enee
Abstract Middleware: un comune modello
Concrete Middleware: una comune infrastrutture
Abstractly, un qualunque middleware che modella un sistema distribuito come collezzione di oggetti raggiungibili via rete:
OMG CORBA, Java RMI, MS DCOM, OSGI Architecture.
-
Concrete implementations, punta all'attuale interoperabilit , quindi devono gestire dettagli pi fini -
Esempio: Distributed Objects
Grandi consorzi per lo standard sono creati, che uniscono diverse aziende -
Le grandi industrie spingono per far diventare le loro tecnologie standard de-facto. -
Sforzi di standardizzazione diventano fondamentali per dare impulso intorno ad un tecnologia di infrastruttura:
Presentazione e analisi del modello sotto il middleware
Presentazione e analisi dell'infrastruttura creata dal propagarsi del middleware
Discussione dei problemi di implementazione nella piattaforma e nel livello applicativo
Il concetto fondamentale della programmazione ad oggetti : La Classe
Una classe un tipo di dato astratto con associato un modulo che lo implementa: Tipo + Modulo = Classe
Il modulo da struttura all'implementazione, il tipo specifica come ogni parte va utilizzata.
Condividono per il concetto di interfaccia: Nel modulo seleziona la parte pubblica, nel tipo descrive le operazioni permesse e le
propriet
L'interfaccia il cuore della classe
Il concetto fondamentale delle OOP distribuita l'interfaccia remota
implicito, le trasmissioni sono implicite e avvengono tramite gli stub. -
OO, esistono solo gli oggetti, invocanti operazioni tra di loro, la struttura Client-Server per ogni chiamata. Ogni chiamata
associata ad un oggetto e il risultato dipende dallo stato dell'oggetto
-
Il modello di comunicazione ad oggetti distribuiti:
Object-Oriented Middleware per i sistemi distribuiti
venerd 2 maggio 2014
14:26
Sistemi Distribuiti Pagina 18
Common ORB Architecture
ORB: Object Request Broker
uno standard non un prodotto
OMA(Object Managment Architecture) era la visione del distributed computing di OMG(Object
Managment Group)
Il Common Object Services funge da librerie CORBA, in bundle con l'infrastruttura ORB
Le Common Facilities sono un framework per sviluppare applicazioni distribuite in vari domini.
Corba permette di scegliere se risolvere a tempo di compilazione o a tempo di esecuzione. nel
mezzo.
CORBA
venerd 2 maggio 2014
15:27
Sistemi Distribuiti Pagina 19
Concorrenza e Parallelismo: molte attivit indipendenti, attive simultaneamente -
Distribuzione: le attivit sono in esecuzione in contesti differenti ed etoregenei -
Interazioni "Sociali": Obbiettivi collettivi che richiedono coordinazione e cooperazione, dipendenze tra attivit -
Interazioni "Ambientali": Interazione con risorse esterne(cosa esterne che interessano al mio sistema), Interazioni
con la trama spazio-temporale
-
Cosa produce complessit nei sistemi distributi:
Astrazione: I problemi dovrebbero essere affrontati e rappresentati al livello di astrazione pi idoneo, dovrebbero
essere espressive abbastanza da catturare i problemi pi rilevanti. Integrit Concettuale
-
Localit ed incapsulamento: le astrazioni di design dovrebbero incorporare le soluzioni corrispondenti alle entit di
dominio che rappresentano.
-
Run-time vs design-time: cambiamenti ed evoluzione incrementali, on-line engineering, self-organising system -
Principi ingegneristici:
Non facciamo ipotesi sulla natura e la struttura dei componenti
Non facciamo ipotesi su posizione e movimento dei componenti
Non facciamo ipotesi sulla vita e il comportamento dei componenti
Computazione (comp) -
Interazione (inter) -
Un componente interattivo un attivit computazionale indipendente con capacit di I/O, ha due dimensioni:
I Componenti contengono una computazione ed espongono un interazione.
Sistema composizionale:
Composizione sequenziale P1;P2
Comp(P1;P2) = Comp(P1) + Comp(P2)
-
Sistema non composizionale:
Composizione interattiva P1|P2
Comp(P1|P2) = Comp(P1) + Comp(P2) + Inter(P1,P2)
-
Composizionalit vs Non Composizionalit
Modello di coordinazione:
la colla che mette insieme tante attivit separate; fornisce una cornice concettuale(framework) in cui l'interazione di
entit indipendenti e attive (gli agenti) pu essere espressa; dovrebbe coprire il problema della creazione e della
distruzione di agenti, della comunicazione tra agenti, della distribuzione spaziale degli agenti, e della sincronizzazione
distribuzione della loro azione nel tempo.
Lo spazio "grigio" dell'interazione lo vogliamo rappresentare come modello medium coordination
Riempie lo spazio di interazione, secondo alcune leggi di coordinazione
Quali sono i component idi un sistema coordinato?
Coordination Entities:(Coordinabili)
Sono entit coordinabili tipiche: processi, thread, oggetti concorrenti
I modelli di coordinazione dovrebbero non preoccuparsi di come funzionano i singoli oggetti
Coordination Media:
Sono tipici Media di coordinazione: monitor e semafori
Coordination Laws:
Regole che regolano il comportamento osservabile dei media di coordinazione e dei coordinabili e la loro interazione
Di fornire un astrazione di alto-livello e potenti meccanismi per l'ingegneria dei sistemi distribuiti -
Di abilitare e promuovere di sistemi distribuiti aperti ed eterogenei -
Di introdurre propriet intrinsecamente indipendentemente dai componenti -
Cosa chiediamo ad un modello di coordinazione?
Esempio: Message Passing, Agent Communication Language, Architetture orientate ai servizi
Enabling interaction vs Governing interaction
Enabling Interaction: abilita comunicazione; abilita interoperazione tra componenti; nessun modello per la
coordinazione dei componenti.
Governing Interaction: regola cosa dovrebbero dire, non dire, fare, non fare i componenti in un dato momento,a
seconda di cosa dicono o fanno gli altri e di cosa succede all'esterno
Control Oriented e Data Oriented Coordination Model
(focus sull'atto di comunicazione) i processi sono visti come scatole chiuse con input e output, eventi e segnali di
stato. Il coordinatore crea processi coordinati e canali di comunicazione, determina e cambia la topologia. Molto
flessibili e controllabili, separano comunicazione/coordinazione da computazione/elaborazione
-
Astrazioni: pattern produttore consumatore, comunicazione punto a punto, coordinatore, coordinazione come -
Control oriented:
Software
Component
Spazio di interazione
Composizionalit vs formalizzabilit:
Una nozione di modello formale
server per poter inziare una
propriet composizionale, ma la
formalizzabilit non richiede
composizionalit
Comportamenti emergenti:
Interazione e Coordinamento nei sistemi distribuiti
marted 6 maggio 2014
14:21
Sistemi Distribuiti Pagina 20
Astrazioni: pattern produttore consumatore, comunicazione punto a punto, coordinatore, coordinazione come
configurazione della topologia
-
Sistemi: a grana fine, a controllo fine, sistemi piccoli e chiusi -
(focus sull'informazione scambiata) ruota attorno alla condivisione di memoria, i processi emettono e ricevono
informazioni, la coordinazione sull'acceso, cambiamento e sincronizzazione di dati. Astrazione di comunicazione
espressiva, possibile separazione spazio temporale. Ingegnerizzazione dello spazio di interazione
-
Data Oriented:
Sistemi Distribuiti Pagina 21
I coordinabili si sincronizzano, cooperano e competono sulla base di tuple disponibili nello spazio delle tuple mediante accesso,
consumazione o creazione di tuple associativi
Coordination media: spazi delle tuple
Linguaggio di comunicazione: tuple
Linguaggio di coordinazione: primitive dello spazio delle tuple
Tuples: Collezzione ordinata di possibili chunk di informazione eterogenee
templates / anti-tuples: specificamento di set / classi di tuple
tuple matching mechanism: meccanismo che fa il match tra tupla e template
Linda:
out(T): mette una tupla nello spazio delle tuple
in(TT): prende una tupla corrispondente ad un certo template dallo spazio delle tuple (la tupla viene poi rimossa dallo spazio),finche una
tupla non matcha rimane in attesa, se ci sono pi tuple matchanti si prende una in modo non deterministico
rd(TT): come sopra ma la tupla rimane nello spazio
inp(TT) : come in(TT) ma se non trova un match fallisce
rdp(TT): come rd(TT) ma se non trova una match fallisce
in_all(TT):come in(TT) ma restituisce pi tuple e se non trova match restituisce null
rd_all(TT):come rd(TT) ma restituisce pi tuple e se non trova match restituisce null
Tuple: Una tupla una collezione ordinata di chunk di conoscenza, possibilmente eterogenei -
generative communication: finche esplicitamente non smentita, le tuple generate da i coordinabili hanno un esistenza indipendente
nello spazio delle tuple; una tupla e egualmente accessibile a tutti i coordinabili,ma non legata a nessuno
-
associative access: le tuple nello spazio delle tuple possono essere accedute attraverso il loro contenuto e la loro struttura, invece che
tramite nome indirizzo o locazione
-
suspensive semantics: le operazioni possono essere sospese sulla base della disponiblit di tuple matchanti, e riprese quando questa
tupla diventa disponbile
-
Main Features:
Generative Communication:
Sia il mittente che il ricevente possono interagire senza essere a conoscenza l'uno dell'altro: non c' bisogno di coesistere nello spazio per
poter interagire, non c' bisogno di simultaneit,non c' bisogno di nomi
Associative Access:
Assenza o presenza di tuple con determinati contenuti o struttura determinano il comportamento dei coordinabili e quindi del sistema;
pattern di coordinazione bastato sulle informazioni disponibili; trasformare eventi in tuple
Suspensive Semantics:
Duplica attesa:
Nei coordination medium: l'operazione prima sospesa, poi esguita: (basata sulla presenza/non presenza di tuple di un certo set)
Nelle coordination entity: l'invocazione potrebbe causare uno stato di wait nell'invocatore: ipotesi sul comportamento interno
Dining Philosophers con Linda:
Rappresentiamo i bastoncini con una tupla chop(i), quello a sinistra del filosofo i. Un filosofo ha bisogno dei bastoncini i e (i+1)mod N.
Quando un filosofo prova a mangiare cerca le tuple chop(i) e chop(i+1 mod N)
quando ricomincia a pensare mette nello spazio delle tuple chop(i) e chop(i+1 mod N)
Qual il problema?
La coordinazione limitata ad una lettura scrittura consumazione o sospensione su un tupla alla volta
Le primitive Bulk non sono una soluzione general purpose
Il carico di coordinazione quindi generalmente a carico delle entit di coordinazione
Soluzione?
Rendere il comportamento del medium di coordinazione "aggiustabile" a seconda del problema di coordinazione
I media di coordinazione posso incapsulare soluzioni a problemi di coordinazione
Serve un modo per definire il comportamento di un medium di coordinazione a seconda di uno specifico problema di coordinazione
Coordinazione Tupled-Based dei sistemi distribuiti
venerd 9 maggio 2014
14:32
Sistemi Distribuiti Pagina 22
Prendere due chop insieme, eseguire l'operazione su due tuple
Un centro di tuple uno spazio di tuple migliorato con una specifica di comportamento, descritti in termini di reaction specification
language e associa ogni evento del centro di tupla ad un insieme di attivit computazionali (reaction)
Accedere e modificare lo stato del centro di tuple corrente(aggiungedo o cavando tuple) -
Accedere all'informazione legata all'evento che completamente osservabile -
Invocare primitive su altri centri di tuple -
Ogni reaction pu:
Quindi la semantica pu essere complicata quanto richiesto dalla specifica applicazione
Quando una primitiva viene chiamata su un centro di tuple, tutte le reaction corrispondenti vengono innescate ed eseguite in ordine
non deterministico
-
Una volta eseguite tutte, si procede alla primitiva come se fosse in linda -
Alla fine dell'esecuzione i reaction corrispondenti vengono innescati ed eseguiti in ordine non deterministico -
Una volta eseguite tutte le reaction il ciclo ricomincia in attesa di una nuova primitiva -
Il ciclo principale di un centro di tuple funziona come ci:
reaction( out(chops(C1,C2)), (operation, completion),( in(chops(C1,C2)), out(chop(C1)), out(chop(C2)) ));
reaction( in(chops(C1,C2)), (operation, invocation),( out(required(C1,C2)) ));
reaction( in(chops(C1,C2)), (operation, completion),( in(required(C1,C2)) ));
reaction( out(chops(C1,C2)), (internal),( in(chops(C1)), in(chop(C2)), out(chop(C1,C2)) ));
reaction( out(chop(C)), (internal), (rd(required(C,C2)), in(chop(C)), in(chop(C2)), out(chops(C,C2)) )).
reaction( out(chop(C)), (internal), (rd(required(C1,C)), in(chop(C1)), in(chop(C)), out(chops(C1,C)) )).
Risultato:
Protocol No deadlock
Protocol Fairness
Protocol trivial philosopher's interaction protocol
tuple centre Risorse condivise gestite propriamente
Starvation ancora possibile
Dining Philosophers in uno scenario distribuito
N filosofi distribuiti lugo la rete, ognuno ha assegnato un posto rappresentato dal centro di tuple seat(i,j)
Ogni chop rapprestata come tupla chop(i) nel centro di tuple table
Ogni filosofo esprime la propria intenzione di mangiare o pensare, con una tupla wanna_eat / wanna_think nel suo centro di tuple seat(i,j)
4 stati rappresentati dalla tupla philosopher(_) : thinking, waiting to eat, eating, waiting to think
Determinato dall'invocazione di out(wanna eat) / out(wanna think)
La tupla chops(i,j) si verifica solo nel centro di tuple seat(i,j)nello stato philosopher(eating)
I cambi di stato avvengono solo quando sono sicuri
<Specification> ::= {<SpecificationTuple>.}
<SpecificationTuple> ::= reaction(<Event> ,[<Guard> ,]<ReactionBody>)
<Guard> ::= <GuardPredicate>|(<GuardPredicate>{ ,<GuardPredicate>})
<ReactionBody> ::= <ReactionGoal> | (<ReactionGoal> {,<ReactionGoal>})
Una <Specification> una specifica di comportamento
Una <SpecificationTuple> contiene un descrittore di evento <Event>, una guardia <Guard> opzionale, e una sequenza <ReactionBody> di
<ReactionGoals>
Un <Event> l'invocazione della primitiva <Predicate>(<Tuple>)
Sistemi Distribuiti Pagina 23
La situazionalit la propriet di un sistema di essere immerso nel suo ambiente, cio di essere in
grado di percepire e produrre cambiamenti nell'ambiente, trattando opportunamente gli eventi
ambientali
I sistemi computazionali sono sempre pi affetti dalla loro natura fisica, non per mancanza di
astrazione, ma a causa dei requisiti sempre pi complessi, che mandato per una sempre crescente
context-awareness.
I sistemi computazionali mobili hanno sempre pi messo in chiaro che la situazionalit richiede
almeno la conoscenza del tessuto spazio-temporale. I sistemi non banali necessitano di sapere dove
e quando sono per poter eseguire le sue funzioni con efficacia
Nel problema dei filosofi nessuno tiene traccia del tempo e la starvation questione di tempo.
Dobbiamo quindi definire delle regole di coordinazione dipendenti dal tempo, serve quindi un
medium di coordinazione consapevole del tempo
La conoscenza dello contesto spaziale spesso essenziale per stabilire quali compiti eseguire, quali
obbiettivi raggiungere e come.
La coordinazione spaziale richiede: situazionalit e consapevolezza spaziali.
Situazionalit:
Un astrazione di coordinazione spazio-consapevole dovrebbe essere in ogni momento associata con
una posizione assoluta, sia fisica che virtuale. Le astrazioni software si muovono in uno spazio
virtuale solitamente discreto (la rete), mentre i dispositivi si muovono in uno spazio fisico
prevalentemente continuo
Consapevolezza:
La posizione del medium di coordinazione dovrebbe essere disponibile alle leggi di coordinazione
che contiene in modo da renderle capaci di ragionare sullo spazio
La situazionalit e la consapevolezza sono tra i pi critici problemi
Coordinazione Tuple-based dei Sistemi Situati
venerd 16 maggio 2014
14:55
Sistemi Distribuiti Pagina 24
I Web Services sono applicazioni Client-Server che comunicano tramite interazione a messaggi
attraverso il protoccollo HTTP del Worl Wide Web
Caratteristiche:
Un WS incapsula un unit di logica in un certo contesto.
Le funzionalit che fornisce sono descritte da un contratto
Autonomo
Accoppiamento lasco
Componibile
Riusabile
Supporto e interoperabilit multi-vendor (tramite standard de iuro e de facto)
Sono lo stack di protocolli di riferimento per la costruzione di sistemi distribuiti interoperabili
Per relazionarsi tra di loro devono essere consapevoli l'uno dell'altro, questa consapevolezza
creato mediante l'uso di descrizioni di servizio.
Nome e indirizzo del WS -
I dati attesi e restituiti dal WS -
Una descrizione di servizio stabilisce almeno:
Queste descrizioni di servizio sono usate in accoppiamento lasco.
Comunicano tramite messaggi. Dopo che un messaggio inviato il mittente perde il controllo su
quello che gli succeder dopo.
C' supporto sia alla comunicazione sincrona che asincrona.
SOA(Service Oriented Architecture)
HTTP(come protocollo sottostante),SOAP(come reale protocollo di trasporto),WSDL(come
descrittore), XML(per formattare il messaggio), WS-*(set di specifiche ad alto livello)
-
ROA(Resource Oriented Architecture)
HTTP(come reale protocollo di trasporto), XML(per formattare il messaggio),WADL( come
descrittore)
-
2 Tipologie:
SOA (Service Oriented Architecture)
SOA pu essere definita con un aperta, agile, estensibile, federata e componibile architettura
comporta da autonomi, QoS capabili, di produttori diversi, interoperabili, scopribili e potenzialmente
riusuabili servizi
SOA un architettura, non sinonimo di Web Service. Questi ultimi possono essere fatti anche
usando altre tecnologie
Un ruolo di servizio: classificazione a runtime dipendente dalla responsabilit nel dato scenario -
Un modello di servizio: classificazione permanente dipendente dal ruolo giocato
nell'applicazione
-
Un web service pu essere associato con:
Un WS destinatario di un messaggio di richiesta classificato come un service provider
Il mittente del messaggi classificato come service requestor
Un messaggio pu essere processato da diversi intermediari prima della sua destinazione finale. Gli
intermediari passivi, passano semplicemente il messaggio, quelli attivi lo processano/alterano anche.
SOAP: Simple Object Access Protocol
E' il protocollo standard per lo scambio di messaggi tra WS, usa HTTP come protocollo di trasporto
sottostante.
Web Service
venerd 23 maggio 2014
15:11
Sistemi Distribuiti Pagina 25
sottostante.
E' estremamente flessibile ed estensibile.
Envelope(busta): il contenitore del messaggio, di tutte le sue parti -
Header(testata): contiene le meta-informazioni -
Body(corpo): il contenuto del messaggio -
Struttura:
Ogni piattaforma ha la sua implementazione della comunicazione SOAP, il programma che trami il
quale il WS, spedisce e riceve i SOAP detto SOAP node
WSDL: Web Service Definition Language
scritto in un linguaggio XML-based e definisce la service description
portType: una vista al alto livello dell'interfaccia
Operation: una specifica azione che pu essere eseguita dal servizio
Message: astrazione usata per definire gli input e gli output di un operazione
Astratta: Stabilisce le caratteristiche dell'interfaccia del Web Service -
Binding: descrive i requisiti per stabilire una connessione fisica
Service: definisce il nome e il set di porte ( i possibili indirizzi per contattarlo)
Port: uno specifico indirizzo al quale pu essere contattato con uno specifico protocollo
Concreta: Stabilisce una connessione (binding) della descrizione astratta al protocollo di
trasporto fisico
-
Un documento WSLD definisce le funzionalit fornite da un servizio, e il suo comportamento
E' composto da un descrizione astratta e una concreta
Message Exchange Pattern (MEPs)
Definizione delle possibile interazioni tra WS
Request-Response (un requestor fa una richiesta che viene risposta dal provider) -
Solicit-Response (il provider sollecit il requestor che risponde) -
OneWay ( come request-response, ma senza response) -
Notification ( come solicit-response ma senza response) -
WSDL 1.1:
In-out -
Out-in -
Only in -
Only out -
In WSLD 2.0 diventano
Robust in-out -
Robust out-in -
In-optional-out -
Out-optional-in -
Si aggiungono poi:
Questi ultimi forniscono opzionali messaggi di in/out o messaggi di risposta d'errore
Universal Description Discovery and Integration (UDDI)
lo standard OASIS che cerca di risolvere il problema della scoperta e composizione dei servizi
I WS registrano il proprio WSDL nel registro UDDI, il requestor cerca le funzionalit con query sul
registro
Per ci sono ancora dei problemi: la semantica non considerata, e si affida solo ad aspetti sintattici,
in fatti richiesto un match completo per un operazione.
Esistono 2 tool principali: Java Metro (Glassfish) e Apache Asix 2
JAX-WS l'insieme delle API per la creazione di Web Services in Java. Plain Old Java Object (POJO)
possono facilmente essere esposti come WS, indipendete da protocollo e trasporto.
Top-Down: partendo dalla creazione del WSDL -
Bottom-Up: partendo dalla definizione dei POJO -
Lato server si possono seguire 2 approcci:
Sistemi Distribuiti Pagina 26
WS-Coordination: fornisce regole per gestire attivi complesse (AtomicTransaction e
BusinessActivities)
sono coinvolti 3 servizi, Activation ( che crea il contesto di coordinazione),
Registration(Registra e tiene traccia dei partecipanti), Coordinator(gestisce la coordinazione di
una attivit in riferimento ad un particolare tipo di coordinazione)
-
WS-Security Framework: un set di specifiche che risolve quasi tutti i problemi di sicurezza dei
WS
Security(permette lo scambio sicuro di messaggi SOAP), Policy(per descrivere i requisiti e
capacit del WS), Trust( permetto lo scambio di messaggi di fiducia),
SecureConversation( permette la conversazione sicura tra due o pi WS; sulla vase di Security
e Trust)
-
WS-BPEL: linguaggio permette di specificare formalmente business processes e protocolli di
interazione
-
E altri... -
Nella seconda generazione di WS sono state introdotte nuove specifiche:
RESTful Web Service:
Resource-Oriented Architecture (ROA):
4 concetti: Risorse, i loro nomi(URIs),le loro rappresentazioni, i collegamenti tra loro
4 propriet: Indirizzabilit (via URI), mancanza di stato, connettivit, un interfaccia uniforme
I RESTful WS sono basati sull'architettura ROA, espongono un set di risorse identificando i target
delle interazioni con i propri clienti. Le URI forniscono uno spazio di indirizzamento per le risorse.
PUT: crea una nuova risorsa -
GET: recupera lo stato di una risorsa in una qualche rappresentazione -
DELETE: cancella una risorsa esistente -
POST: trasferisce un nuovo stato ad una risorsa -
La modifica delle risorse avviene tramite i metodi HTTP:
Le risorse sono disaccoppiate dalla loro rappresentazione
I meta-dati di una risorsa sono usati per il controllo della cache, per riscontrare errori, per la
rappresentazione appropriata in fase di negoziazione, per autenticazione e controllo accessi.
Ogni interazione con una risorsa stateless.
Le interazioni con stato si basano sul concetto di trasferimento esplicito di stato
I client manipolano lo stato di una risorsa server mandando una rappresentazione come parte della
PUT o POST
I server manipolano lo stato di una risorsa client mandando una rappresentazione in risposta ad una
GET
Questo il Representational State Transfer.
JAX-RS la specifica java consigliata implementata anche in glassfish
Vantaggi SOA:
pesato da standard progettetati per promuovere l'interoperabilit
Consigliato in ambito enterprise e in soluzioni B2B, e quando si ha la necessit di integrare e
comporre WS e applicazioni
Vantaggi ROA:
Il vantaggio principale la facilit di implementazione, la velocit di progettazione e l'approccio
leggero
Accessibile anche da dispositivi Mobile
Sistemi Distribuiti Pagina 27
Utilizzando la computazione virtuale, risorse d storage e le tecnologie moderne del web, il cloud
computing fornisce astratte, scalabili, network-centriche infrastrutture, piattaforme e applicazioni
come servizi on-demand. Questi servizi sono fatturati in base all'uso
La definizione non specifica che siano sistemi distribuiti, potrebbe anche essere un solo potente
mainframe.
E' anche importante l'impatto economico, essendo service-oriented e basato su standard web, il
cloud computing scelto in un grande numero di scenari applicativi. Molti approcci e soluzioni IT
potrebbero sfruttare servizi cloud e avere benefici economici
NIST:
Il cloud computing un modello che permette l'accesso di rete ad un insieme condiviso di risorse di
computazione configurabili , in modo ubiquo, conveniente e on-demand, che pu essere rilasciato
con un minimo sforzo di gestione o di interazione con il provider
On-demand Self-Service: servizi forniti senza tramite umano -
Broad Network Access: disponibili nella rete in real-time tramite meccanismi standard -
Resource Pooling: risorse messe insieme per uso condiviso, e aggiustate a seconda dell'attuale
richiesta dell'utente
-
(Rapid) elasticity: la richiesta per risorse extra autogestita, per l'utente come se le risorse
fossero infinite
-
Measured (quality of) service: usano misurazione quantitativa e qualitativa permettendo la
fatturazione basata sull'utilizzo e la validazione della qualit del servizio
-
5 caratteristiche:
Virtualizzazione -
Service-Oriented Architectures (SOA) -
Web Services -
Il cloud dipende da queste fondamentali tecnologie
Virtualizzazione:
Le risorse possono essere staccate dalla loro natura fisica grazie alla virtualizzazione. Si mettono
insieme le risorse fisiche, le si rendono trasparenti e si gestiscono come un tuttuno
Benefici:
Per il provider:
Managment(la gestione pu essere automatizzata), -
Consolidation(riduce il numero dei server fisici), -
Energy Consumption, -
Less Space Required, -
Emergency Planning ( spostare macchine virtuali tra insiemi di risorse) -
Resource usage(load balancing fino massima capacit fisica)
Dynamic Behaviour( pu facilmente soddisfare il pi delle richieste), -
Availability( procedure automatiche di tolleranza guasti), -
Access(l'isolamento permette di dare il controllo all'utente), -
Emancipation( nessuna necessit di contatto umano per acquistare) -
Per il consumatore:
Costo di astrazione: il layer di astrazione richiede risorse -
System Management: la struttura fisica aumenta in complessit -
Inconvenienti:
OS virtualisation: applicazioni dentro contenitori stratificati nel SO host -
Platform virtualisation: SO e applicazioni sono un ambiente virtuale, basato su un VM monitor
o un hypervisor
-
Concetti:
Cloud
sabato 28 giugno 2014
13:49
Sistemi Distribuiti Pagina 28
o un hypervisor
Storage vistualisation: scalabile dinamicamente -
Network virtualisation: Virtual IP e VLAN -
Application virtualisation: modello di vendita software per applicazioni centralizzate e
distribuzione di applicazioni attraverso la rete
-
SOA:
Le SOA sono architetture i cui componenti sono implementati come servizi indipendenti.
Interagiscono via messaggi
Il provider si registra presso il broker, che contiene un elenco di servizi, quando un requestor ha
bisogno di un servizio chiede i riferimenti al brocker e poi comincia la comunicazione
Web Services:
I sistemi di Distributed Cloud Computing integrano risorse eterogenee, e l'imprevedibilit delle
connessioni internet richiedono accoppiamento lasco, asincronia e comunicazione a messaggi
Tecnico: con focus sulle funzionalit delle architetture cloud -
Organizzativo: con focus su come il cloud fornito, i ruoli differenti giocati dai provider e dai
clienti
-
Punti di vista:
Cloud pubblico:
fornito da un provider agli utenti esterni alla sua organizzazione, reso disponibile attraverso un
servizio automatico senza intervento umano. Gli obblighi sono pre-definiti in termini del servizio, e
negoziati automaticamente. Pagamento in base all'uso.
Cloud privato:
Il provider e gli utenti appartengono alla stessa organizzazione. L'obbiettivo principale la sicurezza,
mantenendo il controllo sui dati
Cloud ibrido:
Creati per mettere insieme risorse dei cloud privati e pubblici, in modo da poter sfruttare tecnologie
e strumenti del pubblico e scalare automaticamente quando il privato non abbastanza.
Operazioni normali gestiti all'interno del privato, ma i picchi sono trasferiti al pubblico, con occhio ai
dati e le risorse critiche
Infrastructure as a Service: fornisce una visione astratta sulle risorse fisiche, un interfaccia
utente per gestire le risorse
-
Platform as a Service: fornisce agli sviluppatori tool per il cloud: Programming Environment e
Execution Environment
-
Software as a Service: fornisce il software all'utente tramite il cloud -
Human as a Service: top-level dello stack cloud, anche l'uomo pu essere una risorsa, finche
l'uomo esibisce capacit superiori a quelle di un computer una risorsa utile.
-
Everything as a Service:
Service Level Agreements:
Un accordo tra provider e cliente su livello del servizio, con rispetto sulla sicurezza, propriet,
responsabilit, garanzie e modalit di fatturazione. Specifica in oltre metriche sul
servizio( disponibilit, tempo di risposta,)
Sistemi Distribuiti Pagina 29