Sei sulla pagina 1di 93

INGEGNERIA DEL WEB

Anno accademico: 2017/2018


Studente: Federico Candela

Prof.Domenico Rosaci
1
Sommario
INTRODUZIONE.................................................................................................................................................. 4
1.0) Il web ................................................................................................................................................. 4
1.1) Le Applicazioni ................................................................................................................................... 4
1.2) I Web Services ................................................................................................................................... 5
I SISTEMI DISTRIBUITI ........................................................................................................................................ 6
2.0) Lo sviluppo tecnologico e introduzione ai sistemi distribuiti (SD). ................................................... 6
2.1) I sistemi distribuiti ............................................................................................................................. 6
2.2) Tipologie di sistemi distribuiti ........................................................................................................... 9
2.3) Oggetti distribuiti e chiamate ai metodi.......................................................................................... 10
2.4) I processi e i thread ......................................................................................................................... 11
2.5) I sistemi distribuiti e gli stili architetturali ....................................................................................... 13
2.6) Architetture di Sistema.................................................................................................................... 14
2.7) Comunicazione dei Sistemi Distribuiti ............................................................................................. 20
2.8) Modello ISO/OSI e architettura TCP/IP ........................................................................................... 23
2.9) Naming nei sistemi distribuiti .......................................................................................................... 33
CHIAMATE AI METODI E RMI (REMOTE METHOD INVOCATION).................................................................... 40
3.0) Sistemi a Oggetti.............................................................................................................................. 40
3.1) RMI (Remote Method Invocation)................................................................................................... 41
IL WEB E GLI URI .............................................................................................................................................. 49
4.0) Il Web, risorse e introduzione degli identificatori ........................................................................... 49
4.2) Gli URI (UNIFORM RESOURCE IDENTIFIER)...................................................................................... 50
4.3) HTTP (HyperText Transfer Protocol)................................................................................................ 53
LINGUAGGIO XML E XML SCHEMA .................................................................................................................. 61
5.0) XML (eXstensible Markup Language) .............................................................................................. 61
5.1) XML Schema (eXstensible Markup Language)................................................................................. 65
SOA (SERVICE ORIENTED ARCHITECTURE) INTRODUZINE AI WEB SERVICE .................................................... 71
6.0) SOA (SERVICE ORIENTED ARCHITECTURE) ...................................................................................... 71
6.1) I web service .................................................................................................................................... 77
PATTERNS PER L’E-BUISNESS ........................................................................................................................... 80
7.0) I livelli dei patterns .......................................................................................................................... 80
APPROCCIO SOA E PATTERNS .......................................................................................................................... 81
8.0) Descrizione dell’approccio SOA ....................................................................................................... 81
I WEB SERVICE E IL SOAP (SIMPLE OBJECT ACCESS PROTOCOL) ..................................................................... 84
2
9.0) I WS (Web Service) ......................................................................................................................... 84
9.1) Il protocollo SOAP ............................................................................................................................ 87

3
INTRODUZIONE
1.0) Il web

WEB=world Wide Web-insieme delle reti interconnesse. Al mondo d’oggi tramite il web è possibile
usufruire di molteplici servizi e contenuti multimediali o altro (e-commerce, e-learning, e-government, e-
health, Social-Network…).

PAGINA WEB= composizione di testo e/o grafica visualizzate dal browser web.

Tutti i siti web sono indetificati da un URL.

SERVIZI WEB=

• download: la distribuzione di software;

• web mail: la gestione della casella di posta elettronica attraverso il Web;

• streaming: la distribuzione di audio/video in tempo reale;

– web TV: la televisione fruita attraverso il Web;

– web radio: la radio fruita attraverso il Web;

• web chat: la comunicazione testuale in tempo reale tra più utenti di Internet, tramite pagine web;

• playgame: vidiogiochi on-line.

1.1) Le Applicazioni

APPLICAZIONE = Il termine applicazione in informatica individua un programma installato o una serie di


programmi in fase di esecuzione su un computer con lo scopo e il risultato di rendere possibile una o più
funzionalità, servizi o strumenti utili e selezionabili su richiesta dall'utente tramite interfaccia utente.

il risultato a livello utente è dato dalla combinazione di risorse software e rispettive risorse hardware di
processamento per la loro esecuzione. Le applicazioni accessibili attraverso il Web sono molteplici, ed
estremamente disomogenee. Esse sono infatti scritte in differenti linguaggi di programmazione.

Problema: Spesso le applicazioni devono “parlare” tra loro anche se scritte in linguaggi diversi, al fine di
rendere possibile la realizzazione di determinate funzionalità.

Soluzione: Sistemi ed architetture distribuite: consentono di risolvere i problemi di scalabilità, ma


consentono anche apertura, robustezza e miglioramenti delle prestazioni. Linguaggi ontologici: XML, XML
Schema, RDF, OWL, WSDL: consentono di realizzare un’effettiva interoperabilità.

4
1.2) I Web Services

WEB SERVICES= E’ un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori
su di una medesima rete ovvero in un contesto distribuito.

Utilizzano un formato dei dati di tipo testuale, quindi più comprensibile e più facile da utilizzare per gli
sviluppatori (esclusi ovviamente i trasferimenti di dati di tipo binario). Normalmente, essendo basati sul
protocollo HTTP, non richiedono modifiche alle regole di sicurezza utilizzate come filtro dai firewall. Sono
semplici da utilizzare e possono essere combinati l'uno con l'altro (indipendentemente da chi li fornisce e
da dove vengono resi disponibili) per formare servizi "integrati" e complessi.

Vantaggi

➢ Permettono di riutilizzare applicazioni già sviluppate.


➢ Fintanto che l'interfaccia rimane costante, le modifiche effettuate ai servizi rimangono trasparenti.
➢ I servizi web sono in grado di pubblicare le loro funzioni e di scambiare dati con il resto del mondo.
➢ Tutte le informazioni vengono scambiate attraverso protocolli "aperti".

5
I SISTEMI DISTRIBUITI

2.0) Lo sviluppo tecnologico e introduzione ai sistemi distribuiti (SD).


1945-1985: Computer ingombranti e costosi. Ogni computer operava indipendentemente dagli altri. Metà
anni 80: sviluppo di microprocessori potenti a 8, 16, 32, 64 bit: capacità di calcolo di un mainframe ma costi
molto più bassi. Si passa da macchine da 10 milioni di dollari che eseguivano 1 istruzione/sec a macchine da
1000 dollari che eseguono 1 miliardo di istruzioni al secondo.

Questo ha comportato l’Invenzione delle reti di computer ad alta velocità

- Reti Locali (LAN): connettono centinaia di macchine in un edificio con velocità da 100 milioni a 10 miliardi
di bit/sec.

- Reti Geografiche (WAN): milioni di macchine connesse in tutto il mondo, con velocità da 64Kbs a
gigabit/sec.

Vantaggi

Facilità di mettere insieme sistemi di calcolo composti da un gran numero di computer connessi da reti ad
alta velocità

Questi sistemi sono chiamati Sistemi Distribuiti, diversamente dai precedenti Sistemi Centralizzati, che
avevano un singolo processore e alcune periferiche.

2.1) I sistemi distribuiti

SISTEMA DISTRIBUITO(SD)= Collezione di computer indipendenti che appare ai propri utenti come un
singolo sistema coerente.

Le differenze tra i computer, le modalità di comunicazione e l’organizzazione interna del SD sono nascoste
agli utenti. Un SD deve essere facilmente espandibile e scalabile, essendo composto da computer
indipendenti e avendo un’organizzazione trasparente: facilità di sostituire parti o aggiungere nuove
componenti.

Di solito, un SD si configura come un layer di software intermedio tra un soprastante livello delle
applicazioni e un sottostante livello di software di base (Sistemi Operativi, Sistemi di Comunicazione).

6
Vantaggi

Un SD viene costruito in quanto:

• Si vuole che le risorse siano facilmente accessibili (Accessibilità)

Risorse: computer, dati, stampanti, pagine Web, ecc.


A volte si vuole che queste risorse siano condivise (la condivisione è economica).
Internet dimostra che connettere utenti e risorse è una strategia di successo.
Groupware: File Sharing, Editing Collaborativo, Video Conferenza, ecc.
Importanza della Sicurezza quando si è connessi in rete: protezione della privacy, evitare lo spam,
sono tutti ottimi motivi per progettare un SD.

• Si vuole che la distribuzione delle risorse sia nascosta (Trasparenza)

- Trasparenza all’accesso: si vuole nascondere all’utente come i dati sono rappresentati sulle
singole macchine (es. differenti S.O.)

- Trasparenza all’ubicazione: si vuole che gli utenti non possano indicare dove è fisicamente
localizzata una risorsa

- Trasparenza alla migrazione: le risorse possono essere spostate senza interferire sulla loro
modalità d’accesso. Se ciò si può fare addirittura mentre le risorse sono in uso, abbiamo
Trasparenza al riposizionamento.

- Trasparenza alla replica: si nasconde l’esistenza di molte copie di una risorsa, che vengono
automaticamente tenute aggiornate

- Trasparenza alla concorrenza: l’accesso concorrente ad una risorsa condivisa la lascia in uno
stato coerente.

- Trasparenza ai guasti: l’utente non si rende conto che una risorsa ha smesso di funzionare.

Non è detto che una trasparenza assoluta sia desiderabile, per esempio:
Si pensi ad una applicazione che per eseguire una certa operazione per l’utente debba
contattare uno tra tanti server disponibili, e che si voglia nascondere quale server viene
7
contattato. Se il server contattato non risponde, l’utente non ha modo di interrompere il
tentativo per passare ad un altro server.

• Si vuole che il sistema sia aperto (Apertura)

Un SD aperto è un sistema che offre servizi rispettando certe regole standard che descrivono la
sintassi e la semantica dei servizi stessi. In un SD i servizi sono specificati per mezzo di interfacce
scritte in un Interface Definition Language (IDL). Esse spesso specificano la sintassi ma il difficile è
specificare la semantica (“cosa i servizi fanno”). Se le interfacce sono ben specificate i sistemi che le
usano possono implementarle in modo diverso senza problemi ed interagire tra loro
(interoperabilità). Inoltre si possono portare agevolmente da un sistema ad un altro (portabilità)
Anche l’ampliabilità è una caratteristica dell’apertura. I sistemi devono essere estendibili.

• Si vuole che il sistema sia scalabile (Scalabililità)

Aspetto centrale, visto l’aumento esponenziale degli utenti Internet, si ha quindi:

- Scalabilità rispetto alla dimensione: possiamo aggiungere utenti e risorse al sistema.

- Scalabilità geografica: utenti e risorse possono essere anche molto lontani

- Scalabilità rispetto all’amministrazione: il sistema deve rimanere gestibile anche coprendo


molte strutture indipendenti

Problemi di scalabilità:

I limiti maggiori emergono quando i dati, i servizi, o le applicazioni sono centralizzate


In tal caso l’unità centrale diventa un collo di bottiglia: si immagini se il DNS di Internet fosse ancora
implementato come un’unica tabella
La scalabilità rispetto alle dimensioni si affronta mediante approcci decentralizzati.
La scalabilità geografica è difficile da ottenere perché le reti geografiche sono point-to-point. Anche
qui occorrerebbe adottare soluzioni decentralizzate
La scalabilità rispetto all’amministrazione è strettamente legata a problemi di sicurezza. Occorre
fare in modo che passando da un dominio ad un altro più esteso, non si violi la sicurezza di
quest’ultimo (esempio: applet Web)

Soluzioni ai problemi di scalabilità:

Tecniche di scalabilità:

- Comunicazione asincrona: cercare di evitare l’attesa delle risposte alle richieste di


servizi remoti. Per esempio, quando un servizio viene richiesto ad un server, invece di
aspettare passivamente la risposta si può permettere all’applicazione richiedente di
fare altro lavoro utile. Quando arriva una risposta, l’applicazione interrompe quello che
stava facendo e torna a gestire il processo originale (sono utili i thread paralleli).

8
- Ridurre la comunicazione totale, spostando su client parte del lavoro che è fatto dal
server (es. Applet Java)

- Distribuzione: prendere un componente, spezzarlo in più parti e distribuirle nel sistema


(es. DNS)

- Replicazione – Caching: incrementare la disponibilità delle risorse.

2.2) Tipologie di sistemi distribuiti

• Sistemi di Calcolo Distribuiti

– Sistemi di calcolo a cluster: semplici computer collegati da reti ad alta velocità, per
consentire la programmazione parallela (es. Beowulf su Linux)

– Grid Computing: in un cluster, i computer sono tutti uguali. La tecnologia grid presenta
invece componenti eterogenee. Gli appartenenti alla stessa organizzazione virtuale hanno
diritto all’accesso alle stesse risorse (server, data storage, basi di dati)

• Sistemi Informativi Distribuiti

Emergono in contesti aziendali, in cui necessita l’integrazione di diverse applicazioni.


L’integrazione di applicazioni aziendali è oggi un campo in grande sviluppo (Enterprise
Application Integration, EAI)

• Sistemi Distribuiti Pervasivi

nascono con i dispositivi di calcolo mobili ed embedded. Dispositivi piccoli,a batteria, mobili e
wireless. Devono “integrarsi” nel nostro ambiente.

– Sistemi Domestici (integrano in un solo sistema TV, smartphone,PDA, eventualmente


impianti antifurto,videosorveglianza,climatizzazione ecc.)

– Sistemi elettronici per l’assistenza sanitaria (basati su sensori wireless)

– Reti di Sensori: centinaia o migliaia di nodi, ognuno equipaggiato con un sensore (es.
sistemi per il controllo del traffico).

9
2.3) Oggetti distribuiti e chiamate ai metodi

• Oggetti distribuiti

Le risorse di rete sono rappresentate da oggetti distribuiti:


per richiedere un servizio ad una risorsa di rete, un processo invoca uno dei metodi o operazioni
messe a disposizione, passando al metodo i dati come parametri.
Il metodo viene eseguito sull’ host remoto, e la risposta è inviata al processo richiedente come
valore di ritorno.

• Chiamate di metodi

Un processo in esecuzione su un host A chiama un metodo su un oggetto distribuito che risiede su


un host B, passando allo stesso eventuali parametri.
La chiamata del metodo invoca un’azione che il metodo eseguirà sull’ host B. Il valore di ritorno, se
c’è, verrà trasferito dall’ host B all’ host A.
Un processo che fa uso di un oggetto distribuito viene detto processo client di quell’ oggetto, e i
metodi dell’oggetto sono chiamati metodi remoti (contrariamente ai metodi locali, o metodi
appartenenti ad un oggetto locale).

10
2.4) I processi e i thread

• Processo: Programma in esecuzione.

Problematiche classiche di un processo

- Gestione
- Scheduling

Problematiche nei SD

- Multi-threading
- Virtualizzazione
- Processi Client e Processi Server
- Mobilità tra processi

Nel corso della sua attività il S.O. crea una serie di Processori Virtuali, ad ognuno dei quali è assegnato un
processo (programma in esecuzione). Il S.O. ha cura che i singoli processi non si disturbino a vicenda: è reso
trasparente il fatto che i processi utilizzano la stessa CPU.

Prezzo della Trasparenza alla Concorrenza:

- ogni processo deve avere uno spazio degli indirizzi indipendente


- Si devono gestire gli switch da un processo all’altro

• Thread: è una suddivisione di un processo in due o più filoni o sottoprocessi che vengono eseguiti
concorrentemente da un sistema di elaborazione monoprocessore (multithreading) o
multiprocessore o multicore.

A differenza dei processi, non c’è però un alto grado di trasparenza alla concorrenza infatti, un sistema
a thread gestisce solo l’insieme minimo delle informazioni per permettere alla CPU di essere condivisa
da più thread. Il contesto di un thread è composto solo dal contesto della CPU e da qualche altra
informazione sui thread in esecuzione (ad esempio un thread è bloccato e non può essere utilizzato). E’
il programmatore che deve proteggere i dati da accessi scorretti da parte dei thread.

Vantaggio rispetto ai processi:

Prestazioni generalmente migliori, al prezzo di uno sforzo intellettuale da parte del programmatore

• Thread nei sistemi distribuiti:

Vanno considerati due aspetti specifici:

- Client multithread

11
Un obiettivo dei sistemi distribuiti è quello di raggiungere un alto grado di trasparenza alla
distribuzione.
Nelle reti globali, ciò comporta la necessità di nascondere i lunghi tempi di propagazione dei
messaggi tra i processi (ordine delle centinaia di millisec., o addirittura dei secondi). Un
metodo per nascondere la latenza nella comunicazione è avviare la comunicazione stessa e
immediatamente iniziare a fare qualcos’altro.

Esempio: Browser Web: quando si carica una pagina Web, si prelevano dati spesso molto “pesanti”
come immagini o oggetti multimediali. Per nascondere la latenza, il Browser spesso comincia a
visualizzare i dati disponibili mentre ancora la comunicazione è in corso. Non appena il file HTML è
stato prelevato, si possono lanciare più thread indipendenti per prelevare i vari dati. Se un thread si
blocca, gli altri non ne risentono.

Inoltre Se il server è effettivamente replicato su più macchine per gestire flussi elevati di richieste,
un client multi-thread può ottenere performance migliori perché è altamente probabile che i vari
thread verrano eseguiti (in parallelo) da server differenti.

- Server multithread

Semplifica notevolmente la scrittura del codice di un server.Si consideri ad esempio un file server
che occasionalmente deve bloccarsi in attesa. Un file server attende la richiesta di un’operazione su
un file, quindi la soddisfa ed invia la risposta

Organizzazione possibile:

Un thread, il dispacher, legge le richieste in ingresso


Le richieste sono inviate dai client al server ad una porta ben conosciuta. Il server esamina la
richiesta, sceglie un worker thread inattivo e gliela passa. Il worker va avanti eseguendo una lettura
bloccante sul file system locale del server. Il worker può rimanere bloccato in attesa dei dati da
disco. Ma questo non blocca né il dispatcher ne gli altri worker thread.

Nota: senza il multithreading, il server rimarrebbe bloccato sulla singola richiesta, senza poter
servire altre richieste.

Vantaggio:
rendono più semplice la gestione di connessioni logiche multiple.

• Thread in Java:

Vogliamo scrivere il codice di un programma server in Java, dobbiamo introdurre:

- Socket: collegamento bidirezionale tra un programma server ed uno o più programmi client.

Un socket associa al programma server una specifica porta hardware sulla macchina su cui è
eseguito, in modo tale che ogni programma client che sta in qualunque altro luogo nella rete con
un socket associato a quella stessa porta può comunicare col programma server.

12
2.5) I sistemi distribuiti e gli stili architetturali

I sistemi distribuiti si esprimono in termini di:

- Componenti:
Un componente è un’unità modulare con interfacce ben definite e sostituibile nel suo ambiente.

- Connessione dei componenti (Connettori):


Un connettore è un meccanismo che media la comunicazione tra due componenti.

- Dati scambiati tra i componenti.

- Modalità di cofigurazione dei componenti.

Si distinguono in particolar modo quattro principali architetture:

- Architetture a livelli (layered):


I componenti sono organizzati a strati, e ogni componente a livello i può richiamare i componenti
del livello sottostante i-1. Le richieste scendono lungo la gerarchia, mentre le risposte risalgono.
Largamente adottato dalla comunità della Rete (es. Architetture di Rete, ISO-OSI, TCP/IP).

- Architetture basate sugli oggetti:


Ogni componente è un oggetto e gli oggetti sono connessi attraverso un meccanismo di chiamata a
procedura remota. Corrisponde all’architettura client-server. I grandi sistemi software sono
oggigiorno organizzati principalmente a livelli e ad oggetti.

- Architetture centrate sui dati:


Idea di base: i processi comunicano attraverso un repository comune. Sono state sviluppate un gran
numero di applicazioni in rete che si basano su un file system distribuito condiviso, e tutta la
comunicazione ha luogo attraverso dei file. I sistemi distribuiti basati sul Web sono spesso centrati
sui dati.

- Architetture basate sugli eventi:


I processi comunicano attraverso la propagazione di eventi, che facoltativamente trasportano
anche dei dati (Politica PUBLISH/SUBSCRIBE). I processi possono pubblicare degli eventi, dopodichè
il middleware assicura che solo quei processi che si sono iscritti a quei determinati eventi li
ricevano.
Si distinguono:
o Sistemi blandamente accoppiati
o Sistemi disaccoppiati nello spazio, o disaccoppiati referenzialmente (referentially
decoupled)
Le architetture basate sugli eventi possono essere combinate con quelle centrate sui dati,
generando i cosiddetti spazi di dati condivisi.
13
Negli spazi di dati condivisi, i processi sono anche disaccoppiati nel tempo, non è necessario che
siano entrambi attivi quando la comunicazione ha luogo (molti spazi di dati condivisi utilizzano
un’interfaccia tipo SQL per il repository condiviso, rendendo così i dati accessibili attraverso una
descrizione anziché attraverso un riferimento esplicito).

2.6) Architetture di Sistema.

Per architettura informatica di un sistema si intende l'insieme dei criteri in base ai quali è progettato e
realizzato un sistema informatico oppure un dispositivo facente parte di esso.

Tre tipologie:

• Architetture centralizzate (Protocolli con connessione, senza connessione)


Un esempio di architettura centralizzata è il modello client-server.

- Il server: è un processo che implementa uno specifico servizio (es. File System, Base di Dati)

- Il client: è un processo che richiede un servizio a un server attendendone la risposta


(comportamento domanda-risposta)

MODELLO CLIENT SERVER ED APPLICAZIONI.


Livelli Logici del Software:
- Livello dell’interfaccia utente
- Livello applicativo
- Livello dei dati
I due ultimi livelli possono essere posizionati sul client, sul server, o su entrambi. Si noti che i livelli
fisici sono invece solo due: il client ed il server.
Esempio:
1) Client-Server Applicazione ‘
Motore di ricerca web:
Interfaccia (front-end): l’utente digita delle keyword e gli viene ritornata una lista di collegamenti il
livello dei dati (back-end): è costituito da una vasta base di dati di pagine Web prelevate e
indicizzate
14
Il livello applicativo (cuore del sistema ’Application layer’): è un programma che accetta in ingresso
le keywords e genera interrogazioni per la base di dati del back-end

2) Client-Server Applicazione ‘’
Sistema di Supporto alle Decisioni per una mediazione di mercato:
Front-End: Interfaccia Utente
Back-End: Base di Dati con dati finanziari
Livello delle Applicazioni: Programmi di Analisi Finanziaria

MODELLO CLIENT SERVER E DISTRIBUZIONE DEL SOFTWARE.

1) Distribuzione software ‘(Thin Client)


(Front-End): Interfaccia utente sul client
(Back-End & Application layer): Programmi che implementano il livello applicativo e il livello dati sul
server.

Ogni aspetto è quindi gestito dal server, mentre il client è solo uno “stupido” terminale.

2) Distribuzione software ‘’ (Thin Client)


(Front-End): Interfaccia utente solo parzialmente sul client. Sono presenti sul client solo gli aspetti
dipendenti dal terminale.
(Application layer) Le applicazioni che stanno sul server insieme ai Dati (Back-end) hanno il
controllo (remoto) sulla presentazione dei loro dati.

3) Distribuzione software ‘”(Thin Client)


(Front-End) L’interfaccia grafica e parte (Application layer) dell’Applicazione sono posizionate sul
client. Sul server stanno le restanti applicazioni e i (Back-End) dati.

Esempio: l’applicazione fa uso di una form che deve essere compilata prima di essere processata. La
compilazione potrebbe avvenire sul client.

4) Distribuzione software “” (Fat Client)


(Front-End) L’interfaccia grafica e tutte le (Application layer) applicazioni stanno sul client.
Sul server stanno quindi soltanto i (Back-End) dati.

Esempio: la macchina client è un PC connesso con una base di dati remota. E’ il caso delle
applicazioni bancarie, che spesso vengono eseguite sulla macchina dell’utente finale, mentre il
server della banca serve solo da base di dati.

5) Distribuzione software ‘”” (Fat Client)


Tutte le applicazioni (Application-layer) e parte dei (Back-End) dati stanno sul client. Sul server
stanno quindi soltanto la parte restante dei (Back-End) dati.

Esempio: la macchina client è un PC connesso con una base di dati remota. Ad esempio, navigando
sul Web un client può gradatamente costruire una vasta cache sul disco locale delle pagine visitate
più di recente.

TENDEZE ATTUALI DI DISTRIBUZIONE

15
Si cerca di evitare l’uso delle alternative 4 e 5 (Fat Client).

I fat client rende il software lato client più soggetto ad errori e più dipendente dalla piattaforma del
client. Sono invece più usate le alternative 1,2 e 3 (Thin Client).

Si potrebbe pensare che questo significhi che non si vogliano distribuire le risorse. In realtà, non si
vogliano distribuire le risorse sui client, e si preferisce distribuire le risorse su più server. Per far
questo però il server deve poter agire anche da client.

In tal modo si passa da architetture a due livelli fisici ad architetture a tre livelli
fisici(Decentralizzate)

➢ Protocolli senza Connessione:

La comunicazione client-server può essere implementata mediante un protocollo senza


connessione, nel caso di reti affidabili (LAN). In questo caso, il client confeziona un messaggio
identificando il servizio richiesto ed i dati necessari, mentre il server resta in attesa di messaggi, li
processa, e confeziona la risposta per il client.

Vantaggi: efficienza.
Svantaggio: in caso di malfunzionamenti, il client è costretto a rinviare le richieste. Ma se l’originale
risposta si era solo persa, allora il server dovrà effettuare più volte la stessa operazione (es.
trasferire 10000 $ dal proprio conto!)

➢ Protocolli con Connessione:


Quando un client e un server iniziano a comunicare si possono scambiare pacchetti di controllo
prima di spedire i dati reali. Queste procedure dette di handshaking preparano le due componenti
alla comunicazione. Tali procedure sono alla base, ad esempio, del TCP.

(Tuttavia possono anche esserci servizi che inviano direttamente i dati come nel caso dell'UDP).
La maggior parte delle applicazioni, compresi i server proxy tuttavia, hanno bisogno di inviare i dati
in maniera sicura e affidabile per cui l'handshake serve proprio a questo compito. Si comprende
come la connessione con TCP, ad esempio, sia più sicura ma anche più lenta perché scambia non
solo dati relativi al contenuto della comunicazione (o payload), ma anche dati di servizio.

Protocollo affidabile, orientato alla connessione


Vantaggio: i messaggi non si perdono
Svantaggio: Il costo è elevato
Adatto su rete globale, es. TCP/IP su Internet

• Architetture decentralizzate
Le architetture a tre livelli fisici sono un esempio di distribuzione verticale: componenti logicamente
diversi vengono posizionati su macchine diverse. La distribuzione verticale è solo un modo di

16
organizzare le applicazioni client-server. Nelle architetture moderne si è invece più interessati a
come sono distribuiti i client ed i server: distribuzione orizzontale.

Una Importante classe di sistemi che supportano la distribuzione orizzontale:

SISTEMI PEAR-TO-PEAR
Ogni unità agisce sia come client che come server (unità servent).
Problema fondamentale: organizzare i processi in una rete i cui nodi sono i processi stessi e gli archi
sono i canali di comunicazione (reti overlay).

Si distinguono due tipi di reti overlay.


RETE OVERLAY STRUTTURATA (PEAR TO PEAR)
La rete overlay è costruita usando una procedura deterministica:
I processi sono organizzati attraverso una Hash Table Distribuita (DHT).
Ai dati viene assegnata una chiave casuale in uno spazio di identificatori grande (es. 128 bit).
Anche ai nodi della rete è assegnato un numero causale preso dallo stesso spazio di identifcatori.
Un sistema basato su DHT usa un qualche schema efficiente e deterministico per mappare la chiave
di un dato nell’identificatore di un nodo, basandosi su qualche metrica di distanza. Quando si cerca
un dato, il sistema è in grado di restituire l’indirizzo di rete del nodo associato al dato.

17
- Esempio di rete pear to pear strutturato: il sistema CHORD:

Nodi logicamente organizzati in un anello, tale per cui un dato con chiave k è mappato in un nodo
con il più piccolo identificatore id≥k. Questo nodo è chiamato successore di k, succ(k)
Un’applicazione in esecuzione su un nodo arbitrario e che sta cercando il dato k, chiamerà la
funzione lookup(k) che restituirà l’indirizzo di rete del nodo succ(k) in cui risiede il dato k. Questo
nodo sarà poi contattato per ottenere una copia del dato.

ENTRATA DI UN NODO IN UN SISTEMA CHORD

Quando un nodo vuole entrare nel sistema, genera causalmente un identificatore id (la probabilità
di generare un id già esistente è tendente a 0, se lo spazio degli id. è grande). Il nodo fa una ricerca
dell’id, che restituisce succ(id). Viene contattato succ(id), e il nuovo nodo si unisce adesso. Poiché
ogni nodo memorizza inoltre il suo predecessore, viene contattato anche il predecessore di succ(id)
che diventa predecessore del nuovo nodo. Tutti i dati associati al nuovo nodo id sono ora trasferiti
dal vecchio nodo succ(id).

ENTRATA DI UN NODO IN UN SISTEMA CHORD


Il nodo uscente informa della sua dipartita il suo successore e il suo successore.
Tutti i dati del nodo uscente vengono trasferiti al successore.

RETE OVERLAY NON STRUTTURATA (PEAR TO PEAR)


I sistemi p2p non strutturati si basano su algoritmi casuali per la costruzione di reti overlay: ogni
nodo mantiene una lista dei vicini, costruita in maniera più o meno casuale
Anche i dati sono posizionati sui nodi in maniera casuale quindi, quando un nodo ha bisogno di
trovare un dato, non può che inondare la rete con un’interrogazione per la ricerca

18
Ogni nodo mantiene una lista dei vicini, scelta in maniera casuale, chiamata vista parziale.
I vari framework esistenti differiscono per il modo in cui si costruisce la lista parziale.

Esempio di pear-to-pear non strutturato (Jelasity)


In questo framework si suppone che i nodi si scambino periodicamente gli elementi delle loro viste
parziali. Ricordiamo che ogni elemento della vista parziale è un nodo della rete, ed ha un’età
associata che indica da quanto tempo esiste un riferimento a quel nodo, ogni nodo usa due distinti:
thread attivo
thread passivo
Ogni nodo può assumere, in entrambi i thread, due stati distinti:
MODALITA_PUSH: quando decide di costruire un buffer per un altro nodo
MODALITA_PULL: quando ha ricevuto un buffer da un altro nodo

- thread attivo
Seleziona un nodo P dalla vista parziale attuale

Se MODALITA_PUSH
1)miobuffer=[(mioindirizzo,0)]
2)Permuta vista parziale
3)Sposta gli H elementi più vecchi alla fine
4)Appendi i primi C/2 elementi a miobuffer
6)Invia miobuffer a P,altrimenti invia un trigger a P

Se MODALITA_PULL
1)ricevi il buffer di P
2)Costruisci una vista parziale a partire dalla attuale e dal buffer di P
3)Aumenta l’età di ogni elemento nella nuova lista parziale

- thread passivo
Ricevi il buffer da qualunque nodo Q

Se MODALITA_PULL
1)miobuffer=[(mioindirizzo,0)]
2)Permuta vista parziale
3)Sposta gli H elementi più vecchi alla fine
4)Appendi i primi C/2 elementi a miobuffer
6)Invia miobuffer a Q
7)Costruisci una vista parziale a partire dalla attuale e dal buffer di Q
8)Aumenta l’età di ogni elemento nella nuova lista parziale

• Architetture ibride

– In cui la classica soluzione client-server è combinata con un’architettura decentralizzata.

Ad esempio:

– Sistemi P2P con superpeer

– Sistemi edge-server nelle Content Delivery Network

– Sistemi distribuiti collaborativi, ad esempio basati sul protocollo Bit Torrent


19
2.7) Comunicazione dei Sistemi Distribuiti

Esamineremo i modi in cui processi su macchine diverse possono scambiarsi informazione. La


comunicazione si basa sempre sullo scambio di messaggi a basso livello come fornito dalla rete sottostante.
Nelle piattaforme non distribuite si usano invece primitive basate sull’uso della memoria condivisa: più
semplice. I sistemi distribuiti consistono spesso di migliaia o milioni di processi sparsi su macchine diverse,
collegati da una rete inaffidabile come Internet: occorre sostituire le funzionalità di comunicazione a basso
livello con qualcos’altro.

I PROTOCOLLI

Ad ogni livello, su una macchina, esistono delle entità software (processi) che intendono comunicare con
entità software di pari livello su un’altra macchina. Entità di pari livello si chiamano peer. La comunicazione
fra due peer ad un certo livello avviene per mezzo di un insieme di regole e convenzioni chiamate
protocollo del livello.

LE INTERFACCE

Fra ogni coppia di livelli adiacenti c’è un’interfaccia. L’interfaccia definisce quali operazioni, primitive e
servizi il livello sottostante offre al livello superiore, le interfacce devono essere chiare: ogni livello deve
eseguire una collezione di funzioni specifica. Ciò semplifica l’eventuale sostituzione dell’implementazione di
un livello.

MECCANISMO DI COMUNICAZIONE

In realtà, nessun dato viene trasferito dal livello n di una macchina al livello n di un’altra macchina. I dati
vengono inviati, insieme ad opportune informazioni di controllo, dal livello n al livello n-1, e così via
scendendo nella gerarchia dei livelli fino al livello 0 (livello fisico).

ARCHITETTURA DI RETE

Un insieme di livelli e protocolli è chiamata Architettura di Rete. Né i dettagli implementativi né le


specifiche delle interfacce appartengono all’architettura. Le macchine della rete non devono
necessariamente usare le stesse interfacce, purchè usino la stessa gerarchia di protocolli.

I SERVIZI

La funzione di ogni livello è di offrire servizi al livello superiore.

Il livello inferiore è il service provider.

il livello superiore è il service user.

20
Un livello n che usufruisce dei servizi di livello (n-1) può, per mezzo di questi, a sua volta offrire al livello
(n+1) i propri servizi.

I servizi sono disponibili ai SAP (Service Access Point). I SAP del livello n, o n-SAP, sono i punti di accesso nei
quali il livello (n+1) può accedere ai servizi del livello n. Ogni n-SAP ha un indirizzo che lo identifica
univocamente.
n - PDU

Interfacc ia (n-1) - SAP


Entità di liv. n fra i liv. n e (n - 1)
(n -1) - SAP

Interfaccia
fra i liv. n e (n - 1)

(n - 1) - PCI (n - 1) - SDU

Entità di liv. n - 1 (n - 1) - PDU

Interfacc ia (n - 2) - SAP
fra i liv. (n - 1) e (n - 2)

L'informazione passata dal livello n al livello (n-1), attraverso il (n-1)-SAP, si dice PDU (Protocol Data Unit) di
livello n, o n-PDU.

Essa, entrando nel livello (n-1), diventa una SDU (Service Data Unit) di livello (n-1), o (n-1)-SDU.

Entro il livello (n-1) viene aggiunta alla (n-1)-SDU una PCI (Protocol Control Information) di livello (n-1).

Il tutto diventa una (n-1)-PDU, che verrà passata al livello (n-2) attraverso un (n-2)-SAP.

Vengo distinti due tipi di servizi:

• servizi connection-oriented;
un servizio connection-oriented si sviluppa in 3 fasi:
1) Si stabilisce una connessione, cioé si crea con opportuni mezzi un "canale di
comunicazione" fra la sorgente e la destinazione. La relativa attività tipicamente
coinvolge un certo numero di elaboratori nel cammino fra sorgente e destinazione;
2) la connessione, una volta stabilita, agisce come un tubo digitale(Canale di connessione)
lungo il quale scorrono tutti i dati trasmessi, che arrivano nello steso ordine in cui sono
partiti;
3) si rilascia la connessione (attività che coinvolge di nuovo tutti gli elaboratori sul
cammino).

• servizi connectionless.
I servizi connectionless sono modellati secondo il sistema postale:
ogni lettera viaggia indipendentemente dalle altre; arriva quando arriva, e forse non arriva.
Inoltre, due lettere con uguale mittente e destinatario possono viaggiare per strade
diverse.
Analogamente, in un servizio connectionless, i pacchetti (PDU) viaggiano
indipendentemente gli uni dagli altri, possono prendere strade diverse ed arrivare in ordine
diverso da quello di partenza o non arrivare affatto.
La fase è una sola:
invio del pacchetto (corrisponde all'immissione della lettera nella buca).

21
I servizi inoltre possono essere affidabili, o non affidabili.

• SERVIZII AFFIDABILI
Un servizio affidabile non perde mai dati, cioé assicura che tutti i dati spediti verranno
consegnati al destinatario. Ciò generalmente richiede che il ricevente invii un
acknowledgement (conferma) alla sorgente per ogni pacchetto ricevuto. Si introduce
ovviamente overhead, che in certe situazioni può non essere desiderabile.

• SERVIZII NON AFFIDABILI


un servizio non affidabile non offre la certezza che i dati spediti arrivino effettivamente a
destinazione.

Esempi di servizi:

reliable connection oriented: trasferimento di file (non devono mancare pezzi e il file non deve essere
"rimescolato");

non reliable connection oriented: nelle trasmissioni isocrone (quali voce e video) le relazioni temporali fra i
bit del flusso devono essere mantenute. E' meglio qualche disturbo ogni tanto, piuttosto che interruzioni
momentanee, ma avvertibili, del flusso di dati;

non reliable connectionless (detto anche datagram service, da telegram): distribuzione di posta elettronica
pubblicitaria, non importa se qualche messaggio si perde.

reliable connectionless (detto anche acknowledged datagram service): si invia un breve messaggio e si
vuole essere assolutamente sicuri che è arrivato.

PRIMITIVE DI SERVIZI

Un servizio di livello n è formalmente specificato da un insieme di primitive (cioé operazioni) che un'entità
di livello (n+1) può adoperare per accedere al servizio. Esse possono indicare al servizio:

l'azione da compiere (l'informazione viaggia da livello n al livello (n-1));

cosa riportare in merito ad una azione effettuata dalla peer entity di livello n (l'informazione viaggia dal
livello (n-1) al livello n).

22
2.8) Modello ISO/OSI e architettura TCP/IP

Iniziamo ad esaminare due importanti realtà nel mondo delle reti:

1) OSI Reference Model;

2) Internet Protocol Suite (detta anche architettura TCP/IP o, piuttosto impropriamente, TCP/IP reference
model).

Un modello di riferimento: definisce il numero, le relazioni e le caratteristiche funzionali dei livelli, ma non
definisce i protocolli effettivi.

Architettura di rete: definisce, livello per livello, i protocolli effettivi.

MODELLO ISO/OSI

L'OSI (Open Systems Interconnection) Reference Model è il frutto del lavoro della ISO (International
Standard Organization), ed ha lo scopo di:

- fornire uno standard per la connessione di sistemi aperti, cioé in grado di colloquiare gli uni con gli
altri;
- fornire una base comune per lo sviluppo di standard per l'interconnessione di sistemi;
- fornire un modello rispetto a cui confrontare le varie architetture di rete.

Esso non include di per se la definizione di protocolli specifici (che sono stati definiti successivamente, in
documenti separati).

Principi di progetto seguiti durante lo sviluppo del modello OSI:

- ogni livello deve avere un diverso livello di astrazione;


- ogni livello deve avere una funzione ben definita;
- la scelta dei livelli deve:

1) minimizzare il passaggio delle informazioni fra livelli;


2) evitare:

- troppe funzioni in un livello;


- troppi livelli

23
Application protocol
7 Application Application

Presentation protocol
6 Presentation Presentation

Session protocol
5 Session Session

Application protocol
4 Transport Transport

Subnet di comunicazione

3 Network Network Network Network

2 Data Link Data Link Data Link Data Link

1 Fisico Fisico Fisico Fisico

HOST 1 ROUTER ROUTER HOST 2

Protocolli host - router Protocolli router - router Protocolli host - router

Il modello OSI consiste di 7 livelli.

OSI 1 – Il livello fisico

Livello fisico: ha a che fare con la trasmissione di bit "grezzi" su un canale di comunicazione.

Gli aspetti di progetto sono:

volti a garantire che se parte un 1, arrivi effettivamente un 1 e non uno zero; largamente riguardanti le
caratteristiche meccaniche, elettriche e procedurali dell’interfacce di rete (componenti che connettono
l'elaboratore al mezzo fisico) e le caratteristiche del mezzo fisico.

Si caratterizzano, tra gli altri:

- tensioni scelte per rappresentare 0 ed 1;


- durata (in microsecondi) di un bit;
- trasmissione simultanea in due direzioni oppure no;
- forma dei connettori.

OSI 2 – Il livello Data-Link

Scopo: far si che un mezzo fisico trasmissivo appaia, al livello superiore, come una linea di trasmissione
esente da errori di trasmissione non rilevati.

Normalmente funziona così:

- spezzetta i dati provenienti dal livello superiore in frame (da qualche centinaia a qualche migliaia di
byte);
- invia i frame in sequenza;
- aspetta un acknowledgement frame (ack) per ogni frame inviato.

Incombenze:

- aggiunta di delimitatori (framing) all'inizio ed alla fine del frame


24
- gestione di errori di trasmissione causati da errori in ricezione, perdita di frame, duplicazione di
frame (da perdita di ack);
- regolazione del traffico (impedire che il ricevente sia "sommerso" di dati);
- meccanismi per l'invio degli ack

Le reti broadcast hanno un'ulteriore problema: il controllo dell'accesso al canale trasmissivo, che è
condiviso. Per questo hanno uno speciale sottolivello del livello data link, il sottolivello MAC (Medium
Access Control).

OSI 3 – Il livello Network

Scopo: controllare il funzionamento della subnet di comunicazione.

Inizialmente tale livello offriva solamente servizi connection oriented; successivamente fu aggiunta la
modalità connectionless.

Incombenze:

routing, cioé scelta del cammino da utilizzare. Può essere:

- statico (fissato ogni tanto e raramente variabile);


- dinamico (continuamente aggiornato, anche da un pacchetto all'altro);
- gestione della congestione: a volte troppi pacchetti arrivano ad un router (es.: da molte linee in
ingresso ad un’unica linea di uscita);
- accounting: gli operatori della rete possono far pagare l'uso agli utenti sulla base del traffico
generato;
- conversione di dati nel passaggio fra una rete ed un'altra (diversa):

1)indirizzi da rimappare;

2)pacchetti da frammentare;

3)protocolli diversi da gestire.

OSI 4 – Il livello Transport

Scopo: accettare dati dal livello superiore, spezzettarli in pacchetti, passarli al livello network ed assicurarsi
che arrivino alla peer entity che si trova all'altra estremità della connessione. In più, fare ciò
efficientemente, isolando i livelli superiori dai cambiamenti della tecnologia di rete sottostante. Il livello
transport è il primo livello realmente end-to-end, cioé da host sorgente a host destinatario: le peer entity di
questo livello portano avanti una conversazione senza intermediari.

Queste problematiche sono, in ambito end-to-end, le stesse che il livello data link ha nell'ambito di una
singola linea di comunicazione; le soluzioni però sono alquanto diverse per la presenza della subnet

Incombenze:

creazione di connessioni di livello network per ogni connessione di livello transport richiesta:

- normalmente, una connessione network per ciascuna connessione transport;


- per ottenere un alto throughput: molte connessioni network per una singola connessione
transport;
- se è alto il costo di una connessione network: una singola connessione network viene usata per
molte connessioni transport, con meccanismi di multiplexing;

offerta di vari servizi al livello superiore:

25
- canale punto a punto affidabile, che consegna i dati in ordine e senza errori (il servizio più diffuso,
connection oriented);
- invio di messaggi isolati, con o senza garanzia di consegna (connectionless);
- broadcasting di messaggi a molti destinatari (connectionless).

OSI 5 – Il livello Session

Ha a che fare con servizi più raffinati che non quelli del transport layer.

Per esempio:

token management: autorizza le due parti, a turno, alla trasmissione. Come vedremo nel seguito, questo
livello non ha avuto un grande successo.

OSI 6 – Il livello Session

E' interessato alla sintassi ed alla semantica delle informazioni da trasferire. Ad esempio, si occupa di
convertire tipi di dati standard (caratteri, interi) da rappresentazioni specifiche della piattaforma HW di
partenza in una rappresentazione "on the wire" e poi in quella specifica dell'HW di arrivo.

Anche questo livello non ha avuto molto successo.

OSI 7 – il livello Application

Prevede che qui risieda tutta la varietà di protocolli che sono necessari per offrire i vari servizi agli utenti,
quali ad esempio:

- terminale virtuale;
- trasferimento file;
- posta elettronica.

Attraverso l'uso di questi protocolli si possono scrivere applicazioni che offrono i suddetti servizi agli utenti
finali.

ARCHITETTURA TCP/IP

La "madre di tutte le reti" fu Arpanet, originata da un progetto di ricerca finanziato dal DoD (Department of
Defense) americano. Arpanet, attraverso varie evoluzioni, ha dato origine alla attuale Internet.
L'architettura divenne, più tardi, nota coi nomi di Internet Protocol Suite, architettura TCP/IP e TCP/IP
reference model, dal nome dei suoi due protocolli principali. Essa non è un modello nel senso stretto del
termine, in quanto include i protocolli effettivi, che sono specificati per mezzo di documenti detti RFC
(Request For Comments).

26
LIVELLO-0 ACCESSO ALLA RETE

Il livello più basso non è specificato nell'architettura, che prevede di utilizzare quelli disponibili per le varie
piattaforme HW e conformi agli standard.

Tutto ciò che si assume è la capacità dell'host di inviare pacchetti IP sulla rete.

LIVELLO-1 LIVELLO INTERNET

E' il livello che tiene insieme l'intera architettura. Il suo ruolo è permettere ad un host di iniettare pacchetti
in una qualunque rete e fare il possibile per farli viaggiare, indipendentemente gli uni dagli altri e magari
per strade diverse, fino alla destinazione, che può essere situata anche in un'altra rete. Dunque è
connectionless. E' un servizio best-effort datagram. E' definito un formato ufficiale dei pacchetti ed un
protocollo, IP (Internet Protocol).

Incombenze:

- routing;
- controllo congestione.

LIVELLO-2 LIVELLO TCP/IP

E' progettato per consentire la conversazione delle peer entity sugli host sorgente e destinazione (end-to-
end). Sono definiti due protocolli in questo livello:

TCP (Transmission Control Protocol): è un protocollo connesso ed affidabile (ossia tutti i pacchetti arrivano,
e nell'ordine giusto). Frammenta il flusso in arrivo dal livello superiore in messaggi separati che vengono
passati al livello Internet. In arrivo, i pacchetti vengono riassemblati in un flusso di output per il livello
superiore.

UDP (User Datagram Protocol): l'UDP è un protocollo di tipo connectionless non è affidabile, i pacchetti
possono arrivare in ordine diverso o non arrivare affatto. L'UDP è un protocollo stateless, ovvero non tiene
nota dello stato della connessione dunque ha, rispetto al TCP, meno informazioni da memorizzare

27
TIPI DI COMUNICAZIONI

COMUNICAZIONE PERSISTENTE

Esempio: sistema di posta elettronica.

Può essere visto come un supporto middleware per la comunicazione. Ogni host esegue uno user agent che
consente all’utente di comporre, inviare e ricevere messaggi di posta. Lo user agent passa la mail al sistema
di consegna delle mail. Il sistema di consegna recapita l’email allo user agent del destinatario.

Comunicazione persistente:

come nell’esempio precedente, il messaggio immesso viene memorizzato dal middleware per tutto il
tempo necessario alla consegna. Non è necessario che l’applicazione mittente continui l’applicazione dopo
l’invio del messaggio. Non è necessario che l’applicazione destinataria sia in esecuzione quando il
messaggio è inviato.

COMUNICAZIONE TRANSIENTE

Il messaggio è memorizzato dal middleware solo finchè le applicazioni mittente e destinatario sono in
esecuzione. Se la consegna non è possibile, il messaggio viene cancellato. E’ il caso della comunicazione di
rete a livello di trasporto: i router memorizzano ed inoltrano, e se non è possibile inoltrare, cancellano.

COMUNICAZIONE SINCRONA/ASINCRONA

- Sincrona: Una volta sottomesso il messaggio, l’applicazione mittente si blocca finchè l’operazione
non si è completata
- Asincrona: Una volta sottomesso il messaggio, l’applicazione mittente può eseguire altri task: il
messaggio viene memorizzato temporaneamente fino ad avvenuta trasmissione

COMUNICAZIONE DISCRETA ED A STREAMING

- Discreta: ogni messaggio costituisce un’unità di informazione completa, come nel caso dell’e-mail

- Streaming: Comporta l’invio di molti messaggi, in relazione temporale tra loro, che servono a
ricostruire un’informazione completa

CHIAMATE A PROCEDURE:

CHIAMATE A PROCEDURA LOCALE

Esempio di chiamata convenzionale:

Count=read(fd,buf,bytes)

fd = intero che indica un file,

buf =array di byte e

nbytes= indica quanti byte dobbiamo leggere dall’array.

28
Il programma chiamante
inserisce sullo stack i
parametri e l’indirizzo di
ritorno

La procedura read mette


sullo stack il valore di ritorno
e restituisce il valore al
programma chiamante

- Passaggio dei parametri per valore: Un parametro come fd o bytes viene semplicemente copiato
sullo stack. La procedura chiamata può modificarlo, ma ciò non ha ripercussioni sulla variabile
originale.
- passaggio dei parametri per riferimento: Il parametro rappresenta un riferimento ad una variabile,
come nel caso del parametro buf che rappresenta l’indirizzo di un vettore. Ogni modifica fatta dal
programma chiamato è effettuata sulla variabile originale.
- Passaggio dei parametri per copia-ripristino: Come nel passaggio per valore, la variabile originale è
copiata sullo stack. Al termine del programma chiamato, il valore modificato sullo stack è ricopiato
sulla variabile originale. Produce effetti simili al passaggio per riferimento, ma quando nella lista dei
parametri un parametro appare più volte, la semantica di questo passaggio è diversa dal passaggio
per riferimento.

CHIAMATE A PROCEDURE REMOTE (RPC REMOTE PROCEDURE CALL)

Usare le primitive:

send() e reveive() per far comunicare i processi non realizza la trasparenza dei sistemi distribuiti.

La soluzione a questo problema fu proposta nel 1984 (Birrell e Nelson): consentire ai processi di chiamare
procedure posizionate su altre macchine.

Quando un processo sulla macchina A richiama una procedura sulla macchina B, il processo su A viene
sospeso e la procedura chiamata viene eseguita su B. Le informazioni possono passare dal chiamante al
chiamato attraverso dei parametri, ed anche i risultati possono essere veicolati da parametri.

Nessun passaggio di messaggi è visibile al programmatore.

CHIAMATE A PROCEDURE REMOTE-CLIENT STUB.

Idea di base: rendere le chiamate a procedure remote quanto più simili a chiamate locali

Le RPC devono essere trasparenti: la procedura chiamante non deve sapere che la procedura chiamata sta
su una macchina remota

Caso della procedura read mostrata in esempio: in un sistema tradizionale, il programmatore mette nel suo
codice una chiamata a read per ottenere i dati. La routine read è estratta dal linker dalla libreria ed inserita
nel codice oggetto. Quando è eseguita, la procedura read si comporta come descritto in precedenza,
29
esegue una chiamata al sistema operativo locale per ottenere i dati e mette il risultato sullo stack. Quindi il
suo operato è trasparente al programma chiamante, che si è limitato ad invocare la procedura coi
parametri corretti.

Le RPC ottengono la trasparenza in modo analogo: quando la read è in realtà una procedura remota, ne
viene messa in libreria una copia, chiamata client stub.

Anche il client stub esegue una chiamata al sistema operativo locale, ma non per ottenere i dati come nel
caso precedente. In realtà esso esegue una chiamata alla primitiva send, impacchettando i parametri della
read in un messaggio per la macchina remota su cui sta la procedura chiamata. Poi esegue una receive e si
blocca aspettando i risultati.

CHIAMATE A PROCEDURE REMOTE-SERVER STUB.

Quando il messaggio raggiunge la macchina remota, il sistema operativo di quest’ultima lo passa al server
stub. Il server stub è un pezzo di codice che trasforma le richieste provenienti dalla rete in chiamate a
procedura locale. Il server stub spacchetta il messaggio, chiama la procedura read locale nel solito modo
(parametri sullo stack) e quando riprende il controllo a procedura eseguita, impacchetta il risultato e lo
invia al client stub chiamante. Quindi esegue nuovamente una receive e si blocca in attesa della successiva
chiamata.

Quando il messaggio arriva al sistema operativo chiamante, esso viene passato al processo che ha chiamato
la send, ovvero al client stub. Quest’ultimo spacchetta il messaggio, estrae il risultato e lo mette in cima allo
stack della procedura che ha chiamato la read. Quest’ultima è semplicemente informata che il risultato è
ora disponibile sullo stack, e non deve preoccuparsi di come ciò sia stato possibile.

PASSAGGIO DEI PARAMTERI NELLE RPC

La funzione del client stub è di prendere i parametri della procedura, impacchettarli in un messaggio ed
inviarli al server stub. L’operazione di impacchettamento è denominata marshaling dei parametri. Finchè le
macchine mittente e destinataria sono identiche ed i parametri passati sono di tipo scalare (int, char, ecc.)
tutto funziona perfettamente.

Problema:

Se una macchina mainframe IBM, che per i caratteri usa la codifica EBCDIC, comunica con un personal
computer IBM che usa la codifica ASCII, lo schema non funziona. Un altro problema si verifica tra macchine
che usano numerare i byte da destra a sinistra (little endian), come le INTEL, quando comunicano con
macchine che usano numerare i byte da sinistra a destra (big endian), come le SPARC.

30
Soluzione: richiedente e
ricevente devono concordare il formato del messaggio

- Stabilire se la codifica è little endian o big endian


- Stabilire in che formato sono codificati i caratteri (es. ASCII)
- Stabilire in che formato sono codificati gli interi (es. UNICOD) ed i float (es. IEEE 754)
- Definire il servizio di connessione (es. TCP/IP)

Definito il protocollo RPC, gli stub devono essere implementati. Fortunatamente, gli stub per lo stesso
protocollo ma per procedure diverse differiscono solo per le loro interfacce alle applicazioni. Per
semplificare le cose, le interfacce sono realizzabili tramite un linguaggio per la definizione delle interfacce
IDL. Un’interfaccia realizzata in IDL può quindi essere compilata in un client stub ed in un server stub

Problema: passaggio per riferimento

Un riferimento è un indirizzo in memoria, e quindi è valido solo nel contesto in cui è usato. Se il client stub
usa per il parametro buf (l’indirizzo del buffer) il valore 100, non possiamo aspettarci che questo valore
abbia senso per il server stub, dove l’indirizzo 100 indicherà una qualche imprecisata area di memoria.

Soluzione:

La soluzione è semplice: il client stub sa che il parametro buf è l’indirizzo di un vettore, quindi può copiare
il vettore nel messaggio ed inviarlo al server stub. Quest’ultimo effettuerà le operazioni col vettore copia,
usando lo spazio di indirizzi della macchina ricevente. Se eventualmente si dovesse effettuare una modifica
sul vettore copia, questa sarebbe poi riportata dal client stub sul vettore originale.

Si è usato un meccanismo di copia-ripristino.

Ottimizzazione: se il client stub sa che il riferimento è un parametro di input, non serve che venga ricopiato
il suo valore restituito. Se si tratta di un parametro di output, non serve effettuare la copia in partenza.

CHIAMATE A PROCEDURE REMOTE ASINCRONE

In modalità sincrona, una chiamata RPC provoca la messa in attesa del processo chiamante, fintanto che la
chiamata stessa non sia stata eseguita e il risultato sia stato restituito. In diverse situazioni, in cui il
processo chiamato non deve restituire nessun risultato, non è necessario tale blocco del processo
chiamante.

31
Alcuni sistemi RPC forniscono quindi la possibilità di effettuare chiamate RPC asincrone, permettendo al
processo chiamante, una volta effettuata la chiamata e ricevuto un acknowledge dallo stub server
attestante che la chiamata è stata ricevuta ed avviata, di dedicarsi ad altri task.

Se il processo chiamante riprende la sua esecuzione senza aspettare l’acknowledge, l’RPC asincrona si
chiama “a senso unico”.

COMUNICZIONE ORIENTATA AI MESSAGGI

Non sempre le RPC sono adatte a supportare la comunicazione in un sistema distribuito. Non lo sono
soprattutto quando non si può essere certi che l’interlocutore sia collegato in rete. In questi casi, la natura
essenzialmente sincrona delle RPC comporta una perdita di efficacia nella comunicazione. La
comunicazione orientata ai messaggi sostituisce le chiamate a procedure remote con messaggi. Può essere
usata sia con interlocutori online sia con interlocutori offline.

Molti sistemi distribuiti usano il semplice modello di scambio di messaggi fornito dal sistema di
trasporto. L’intrefaccia standard del sistema di trasporto: Socket del TCP.

SOCKET: porta di comunicazione astratta su cui si possono scrivere e da cui si possono leggere dati.
(Indirizzo IP+ numero di porta).

SOCKET: PRIMITIVE LATO SERVER

- Socket: crea una nuova porta di comunicazione


- Bind: associa un indirizzo locale alla porta appena creata (es. un server associerà l’indirizzo IP della
macchina e il numero di porta reale su cui vuole ricevere messaggi)
- Listen: usata solo in comunicazioni orientate alla connessione. Chiamata non bloccante che
annuncia la disponibilità ad accettare connessioni
- Accept: blocca il chiamante finchè non arriva una richiesta di connessione.

SOCKET: PRIMITIVE LATO CLIENT

- Socket: il binding all’indirizzo locale non è necessario in quanto il sistema operativo può allocare
dinamicamente una porta quando la connessione viene stabilita
- Connect: richiede che il chiamante specifichi l’indirizzo a cui va inviata la richiesta di connessione. Il
client è bloccato finchè la connessione non è stabilita

GESTIONE COMUNICAZIONE LATO CLIENT E LATO SERVER

- Send: invia dati sulla connessione


- Receive: riceve dati dalla connessione
- Close: rilascia la connessione (deve essere eseguita da ambo le parti)

Il modello a socket è molto utilizzato per programmare in rete in ambiente UNIX.

COMUNICAZIONE TRANSIENTE ORIENTATA AI MESSAGGI: MPI (Message Passing Interface)


32
MPI sta per Message Passing Interface (interfaccia per lo scambio di messaggi)

E’ un protocollo a livello di astrazione più alto rispetto alle socket. Le socket sono state progettate per
lavorare in ambiente TCP/IP: non sono adatte ad ambienti proprietari sviluppati per reti ad alta velocità,
dove sono richieste funzionalità più avanzate (es. cluster di server ad alte prestazioni)

MPI suppone che la comunicazione abbia luogo tra gruppi di processi conosciuti. Ogni processo è
identificato da un ID di processo e da un ID di gruppo, e una coppia (procID,groupID) è usata come
destinatario o sorgente della comunicazione al posto degli IP.

La comunicazione transiente è qui asincrona. Mediante la primitiva MPI_bsend, il mittente invia anzitutto il
messaggio al sistema runtime di MPI, che lo bufferizza e lo recapita al destinatario quando possibile,
lasciando libero il mittente di fare altro. Quando il destinatario chiamerà la primitiva receive il messaggio
sarà inoltrato.

COMUNICAZIONE PERSISTENTE ORIENTATA AI MESSAGGI: SISTEMI A CODE DI MESSAGGI

Idea base: le applicazioni comunicano inserendo messaggi in apposite code. Di solito ogni applicazione ha la
sua coda (a volte esistono anche code condivise da più applicazioni)

Un mittente ha solo la garanzia che il suo messaggio venga inserito in coda del destinatario: non c’è bisogno
che il destinatario sia online al momento della trasmissione, né che il mittente sia online al momento della
ricezione

Primitive principali:

1) put (per inserire un messaggio nella coda del destinatario)


2) get (per prelevare un messaggio dalla coda)

2.9) Naming nei sistemi distribuiti

I nomi sono usati per condividere le risorse, identificare univocamente le entità e far riferimento alla loro
posizione. Per risolvere i nomi è necessario implementare un sistema di naming, il naming nei SD si
differenzia da quello per sistemi non distribuiti per l’implementazione.

- Un nome: è una stringa di bit o caratteri utilizzati per riferirsi a un’entità


- Un’entità: è una qualsiasi risorsa, un host, una stampante, un file, un oggetto…
Un’entità può avere più punti di accesso, quindi più indirizzi.
Un’entità può cambiare indirizzo nel tempo.

Importante: un’entità che cambia punto di accesso nel tempo, come viene identificata?
Esistono entità (ad esempio servizi Web) che sono associate a punti di accesso variabili nel tempo
(ad esempio cambia la locazione della macchina server che li ospita). I nomi di queste entità
dovrebbero essere indipendenti dagli indirizzi (variabili) dei punti di accesso di volta in volta
associati.

Per operare su un’entità in genere occorre accedervi attraverso un access point. Il nome del punto
d’accesso di un’entità è chiamato indirizzo dell’entità.

- Identificatori:
Sono nomi aventi particolari caratteristiche:

33
un identificatore si riferisce al massimo ad una entità. Ogni entità è referenziata al massimo da un
identificatore. Un identificatore si riferisce sempre alla stessa entità (cioè non è mai riusato)

- Indirizzi:
Poiché un indirizzo può essere assegnato a più entità, non è un nome adatto per fungere da
identificatore. Alcuni nomi sono particolarmente adatti per essere ricordati, e quindi usati
facilmente, dalle persone: nomi human-friendly.
Questi nomi sono in genere rappresentati da stringhe di caratteri (es. nomi DNS).

LEGAME IDENTIFICATORE-INDIRIZZI

Un sistema di naming mantiene un collegamento nome-indirizzo per le entità. Una tabella di coppie
(nome,indirizzo) non è però adatta a realizzare il naming dei sistemi distribuiti, che spesso si espandono in
grandi reti di calcolatori.

Ciò che succede è che invece un nome viene scomposto in molte parti, come ftp.cs.vu.nl

Un client che ha bisogno di conoscere l’indirizzo del punto di accesso di ftp.cs.vu.nl risolverà prima nl per
trovare il server NS(nl) responsabile dei nomi relativi a nl, quindi passerà il resto del nome a NS(nl).
Quest’ultimo risolverà il nome vu identificando il server NS(vu.nl) responsabile dei nomi che terminano con
vu.nl, e passerà il resto del nome a NS(vu.nl).

E’ possibile identificare tre tipi di naming:

- Naming Semplice
- Naming Gerarchico
- Naming basato sugli attributi

NAMING SEMPLICE

In questi sistemi i nomi sono stringhe di bit casuali, non strutturati.

Distinguiamo:

• Soluzioni semplici
Valido per localizzare un’entità su reti locali. In tale ambito, un messaggio contenente
l’identificatore del mittente è messo in rete, ed è richiesto ad ogni macchina di controllare se
possiede l’identificatore.

Principio usato nel protocollo di risoluzione degli indirizzi ARP per trovare l’indirizzo a livello data-
link di una macchina dato il solo indirizzo IP. In ARP, una macchina mette in rete un messaggio
chiedendo chi sia il proprietario di un certo indirizzo IP. Il destinatario risponde col suo indirizzo
data-link (l’indirizzo Ethernet). Il broadcasting diventa inefficiente man mano che la rete cresce.

Alternativa: Multicasting. Solo un numero ristretto di macchine riceve il messaggio

34
Es: un impiegato di un’azienda, quando entra in rete, riceve oltre all’IP un’assegnazione ad un
gruppo multicast. Se qualcuno lo cerca, manda la richiesta al gruppo multicast, specificando l’IP.

Un’altra soluzione semplice sono i puntatori forwarding:


Quando un’entità si sposta da A a B, lascia su A un forward alla sua nuova posizione su B
Quindi un client può rintracciare l’entità seguendo la catena di puntatori forwarding.

Problema:
Le catene possono diventare molto lunghe
Ogni punto intermedio deve mantenere le informazioni di forwarding
Sistema vulnerabile all’interruzione della catena

• Hash Table Distribuite


Le illustriamo tramite il sistema Chord. Chord usa uno spazio degli identificatori a m bit per
assegnare identificatori casuali ai nodi e chiavi a specifiche entità. Il numero di bit è di solito 128 o
160, a seconda di quale funzione di hash viene usata. Un’entità con chiave k cade sotto la
giurisdizione del nodo con il più piccolo identificatore id maggiore o uguale a k
Questo nodo è chiamato succ(k)

Questione fondamentale: come risolvere la chiave k nell’indirizzo di succ(k)?

Approccio ovvio (e non scalabile): ogni nodo p tiene traccia del suo predecessore pred(p) e del suo
successore succ(p+1). In questo caso, quando un nodo p riceve una richiesta con chiave k, vede se
pred(p)<k<=p. In caso positivo, restituisce il suo stesso indirizzo come risposta alla richiesta. In caso
negativo, inoltra la richiesta al suo predecessore o al suo successore, a seconda del valore di k
La complessità di questa ricerca è lineare.

Chord non usa l’approccio lineare, ma un approccio finger-table. Ogni nodo di Chord mantiene una
tabella (finger table) di al massimo m elementi. Nella finger table Fp del nodo p ci sono memorizzati
gli indirizzi di alcuni nodi successivi a p, dove la distanza tra i nodi cresce esponenzialmente:
Fp[i]=succ(p+2i-1), i=1,2,….
Quindi l’i-esimo elemento punta al nodo successivo a p di almeno 2i-1 posizioni.
Per individuare una chiave k, il nodo p stabilisce se è lui stesso a gestire k, altrimenti vede se k
ricade tra p e Fp[1] e in tal caso gira la richiesta a Fp[1], altrimenti inoltra una richiesta al nodo q.
q=Fp[j-1]<k<=Fp[j]

La ricerca in Chord richiede solo log(N) passi, dove N è il numero di nodi nel sistema.

In un grande sistema distribuito i nodi generalmente entrano ed escono dal sistema continuamente
L’entrata di un nodo in Chord è semplice. Quando p vuole unirsi al sistema, esso contatta un nodo
arbitrario nel sistema e chiede la ricerca di succ(p+1). Una volta che questo nodo è stato
identificato, p si inserisce nell’anello. Anche l’uscita ha analoga semplicità.
La complessità sta nel tenere aggiornate le finger table.

• Approcci home-based

35
E’ usato come meccanismo di riserva per localizzare i servizi quando sono impiegati i puntatori
forwarding, come discusso in precedenza. Un altro esempio in cui è utilizzato un approccio home-
based è Mobile IP. Ogni host mobile usa un indirizzo IP fisso. Tutta questa comunicazione verso
questo indirizzo IP viene inizialmente diretta all’home agent dell’host mobile. L’home agent è
posizionato nella rete locale corrispondente all’indirizzo di rete contenuto nell’indirizzo IP dell’host
mobile.

NAMING STRUTTURATO (GERARCHICO)

I nomi semplici si adattano bene alle macchine, ma non all’uomo che deve usarli con facilità e quindi
memorizzarli. Nel naming strutturato, i nomi sono organizzati nel cosiddetto spazio dei nomi

Lo spazio dei nomi può essere rappresentato con un grafo orientato e etichettato con due tipi di nodi

- Nodi foglia
Un nodo foglia rappresenta una data entità e non ha archi in uscita. In genere contiene
informazioni sull’entità (ad esempio il suo indirizzo) da fornire ai client. Può contenere anche lo
stato dell’entità, come nel caso dei file system dove i nodi foglia contengono i file veri e propri

- Nodi directory
Un nodo directory ha vari archi in uscita, ognuno etichettato con un nome.
Ogni nodo directory contiene quindi una directory table, in cui ogni elemento rappresenta il nodo
finale di un arco in uscita e l’etichetta dell’arco. Un nodo che ha solo archi in uscita e nessuno in
entrata è chiamato nodo root.

I PERCORSI NEL NAMING

Ogni percorso N in un grafo dei nomi può essere chiamato con la sequenza delle etichette degli archi
corrispondenti al percorso:

N: <label-1,label-2,..,label-n>

Il nodo N è il primo nodo del percorso

36
Percorso assoluto: Se il primo nodo in un pathname è il nodo root il percorso è detto altrimenti è detto
percorso relativo.

Molti spazi dei nomi sono organizzati come un albero, con un unico nodo radice e ammettendo un solo
arco in entrata per ogni nodo. In questi spazi, ogni nodo ha un unico pathname assoluto. In altri spazi, è
consentito che un nodo abbia più archi in entrata, ma non vengono ammessi cicli (grafi orientati aciclici).

RISOLUZIONE DEI NOMI NEL NAMING

Dato un pathname

N: <label-1,label-2,..,label-n>

Si inizia dal nodo N del grafo dei nodi, dove si cerca nella directory table l’etichetta label-1 e che restituisce
l’identificatore del nodo n1 a cui si riferisce label-1. La risoluzione quindi continua col nodo n1, cercando
nella table di n1 l’etichetta label-2 e restituendo il nodo associato.

MECCANISMO DI CHIUSURA

Un meccanismo di chiusura specifica come e dove iniziare la risoluzione di un nome.

Esempio:

la risoluzione di un nome nel file system di UNIX fa uso del fatto che la posizione del nodo root nel disco
logico che rappresenta il file system è implicitamente conosciuta.

NAMING SERVICE

Lo spazio dei nomi costituisce il cuore di un naming service. Un naming service è un servizio che consente
agli utenti di aggiungere, eliminare e cercare nomi. Un naming service è implementato attraverso uno o più
name server. Se la rete è locale, basta un solo name server. Se il servizio è per reti geografiche, occorre
distribuirlo su più name server.

DISTRIBUZIONE DELLO SPAZIO DEI NOMI

E’ opportuno suddividere lo spazio dei nomi in livelli logici:

Il livello globale è costituito dal nodo root e dai nodi immediatamente vicini alla root, caratterizzati da un
alto livello di stabilità della directory table. Tali nodi rappresentano in genere istituzioni, aziende o gruppi di
aziende. Visto che le directory table del livello globale non cambiano spesso, i client possono memorizzare
in memorie cache i risultati delle ricerche. I name server possono quindi non rispondere in tempi molto
veloci alle richieste. E’ invece necessario avere un alto throughput a livello globale, disponibilità e
prestazioni possono essere ottenute combinando meccanismi di caching con politiche di replicazione dei
server (entrano qui in gioco problematiche di consistenza dei dati).
Il livello amministrativo è costituito dai nodi che rappresentano singole entità (es. dipartimenti) che
appartengono alla stessa unità amministrativa.
Il livello gestionale è costituito dai nodi che cambiano più frequentemente, ad es. associati agli host di una
rete locale.

37
IMPLEMENTAZIONE PER LA RISOLUZIONE DEI NOMI

Supponiamo per semplicità che non vi sia replicazione dei name server né uso di caching lato client
Ogni client ha accesso ad un name resolver locale, responsabile di avviare il processo di risoluzione.

Esempio di path da risolvere:


Root:<nl,vu,cs,ftp,pub,globe,index.html>
URL corrispondente: ftp://ftp.cs.vu.nl/pub/globe/index.html

Due meccanismi di risoluzione possibili:

- Risoluzione iterativa
Il name resolver passa al root name server (di cui conosce l’indirizzo) il nome completo
Nel nostro esempio, il root name server risolve l’indirizzo del nome nl e restituisce questo indirizzo
al name resolver. Il name resolver passa il resto del pathname, cioè:
nl:<vu,cs,ftp,pub,globe,index.html> a quel name server nl.
nl può risolvere solo l’indirizzo di vu, e restituisce al name resolver il nome del name server di vu
Il name resover contatterà il name server di vu, che risolverà sia l’etichetta cs sia successivamente
quella ftp, e quindi restituirà l’indirizzo del name server ftp.
A questo punto il name resolver contatterà il name server ftp, che risolverà le etichette pub,globe e
index.html, e restituendo al name resolver l’indirizzo della risorsa (un file html) che potrà venire
trasferita dal client mediante protocollo FTP.

- Risoluzione ricorsiva
Invece di restituire ogni risultato intermedio al name resolver del client, il name server contattato
restituisce il risultato direttamente al name server successivo. L’inconveniente di questa risoluzione
è che viene richiesto a ciascun name server un grado di prestazioni superiore. Di solito questo
carico è pesante, ed a livello globale i name server supportano solo la risoluzione iterativa.

Vantaggi:

Ogni name server può gradualmente imparare, e salvare nella sua cache, gli indirizzi dei name
server di livello più basso. A livello globale e a livello amministrativo gli indirizzi cambiano poco
spesso, quindi il caching è molto efficace. Inoltre la comunicazione con la risoluzione ricorsiva è in
genere più veloce, perché il name server contattato non deve restituire il risultato al name resolver.

38
DNS (DOMAIN NAME SYSTEM)
E’ usato per ricercare gli indirizzi IP degli host e dei mail server.E’ organizzato gerarchicamente come un
albero con radice. Un’etichetta è una stringa case insensitive, alfanumerica, della lunghezza massima di 63
caratteri. La lunghezza di un pathname completo è limitata a 255 caratteri. La rappresentazione in forma di
stringa di un nome è costituita dall’elenco delle sue stringhe, da sinistra verso destra. La root è
rappresentata da un punto:

Es:flits.cs.vu.nl. (il punto per semplicità si omette)

Dato che un nodo ha esattamente un arco in entrata, l’etichetta di questo arco viene usata come nome del
nodo.Un sottoalbero è chiamato dominio. Il path del nodo radice del sottoalbero è chiamato nome del
dominio. Il contenuto di un nodo è costituito da un insieme di resouce record.

Il DNS è suddiviso solo in livello globale e livello amministrativo. Il livello gestionale è costituito dai file
system locali e quindi non fa parte del DNS. Ogni zona è gestita da un name server primario, di solito
replicato, che gestisce gli aggiornamenti, modificando la base di dati locale al DNS primario. I name server
secondari di una zona non possono accedere alla base di dati, ma chiedono il trasferimento del contenuto
al name server primario (trasferimento di zona). Una base di dati del name server è implementata come un
insieme di file, il più importante dei quali contiene i resource records di tutti i nodi della zona.

39
CHIAMATE AI METODI E RMI (REMOTE METHOD INVOCATION)
3.0) Sistemi a Oggetti

OGGETTI

Oggetti Locali: sono oggetti i cui metodi possono essere invocati solo da un processo locale, cioè da un
processo in esecuzione sulla stessa macchina su cui risiede l’oggetto.

Oggetti Distribuiti (remoti): Oggetti i cui metodi possono essere invocati da un processo remoto, cioè un
processo in esecuzione su una macchina connessa attraverso una rete alla macchina su cui risiede l’oggetto.

RISORSE DI RETE

Le risorse di rete sono rappresentate da oggetti distribuiti:

Per richiedere un servizio ad una risorsa di rete, un processo invoca uno dei metodi o operazioni messe a
disposizione, passando al metodo i dati come parametri. Il metodo viene eseguito sull’ host remoto, e la
risposta è inviata al processo richiedente come valore di ritorno.

Un processo in esecuzione su un host A chiama un metodo su un oggetto distribuito che risiede su un host
B, passando allo stesso eventuali parametri. La chiamata del metodo invoca un’azione che il metodo
eseguirà sull’ host B. Il valore di ritorno, se c’è, verrà trasferito dall’ host B all’ host A.

Un processo che fa uso di un oggetto distribuito viene detto processo client di quell’ oggetto, e i metodi
dell’oggetto sono chiamati metodi remoti (contrariamente ai metodi locali, o metodi appartenenti ad un
oggetto locale).

• Sistema ad oggetti distribuiti ‘

Un oggetto distribuito è esposto (messo a disposizione) attraverso un processo chiamato oggetto


server.

40
Un oggetto detto registry deve essere presente nell’architettura per sistemi distribuiti affinché gli
oggetti distribuiti vengano registrati.
Un riferimento permette ad un oggetto remoto di essere localizzato, cioè di localizzare la macchina
su cui l’oggetto risiede.

Per poter accedere ad un oggetto distribuito, un processo – cioè un oggetto client – si serve del
registry per ottenere un riferimento all’oggetto.
Questo riferimento è usato dall’oggetto client per chiamare i metodi sull’oggetto remoto.

• Sistema ad oggetti distribuiti “

Logicamente, l’oggetto client fa una chiamata direttamente al metodo remoto.


Realmente, la chiamata è gestita da un componente software, chiamato client proxy, il quale
interagisce con il software sul client host che fornisce il supporto a runtime per il sistema di oggetti
distribuiti.
Il supporto a runtime si fa carico delle chiamate inoltrate dal proxy verso l’oggetto remoto,
includendo il marshalling dei parametri che verranno trasmessi all’ oggetto remoto.

• Sistema ad oggetti distribuiti “’

Un’architettura simile è richiesta anche sul lato server, dove il supporto a runtime per il sistema ad
oggetti distribuiti gestisce la ricezione dei messaggi e l’unmarshalling dei dati, e inoltra la chiamata
ad un componente software chiamato server proxy. Il server proxy comunica con l’oggetto
distribuito ed invoca il metodo chiamato, passandogli come argomenti i dati unmarshalled.
L’esecuzione del metodo sull’host remoto, include il marshalling del valore di ritorno, il quale è
inoltrato dal server proxy al client proxy, attraverso il supporto runtime e il supporto di rete.

Framework basati sul paradigma ad oggetti distribuiti:

o Java Remote Method Invocation (RMI)


o Common Object Request Broker Architecture (CORBA)
o Distributed Component Object Model (DCOM)
o Meccanismi che supportano Simple Object Access Protocol (SOAP)

3.1) RMI (Remote Method Invocation)

Remote Method Invocation ha origine da un modello chiamato Remote Procedure Call (RPC).Nel modello
RPC, una “procedure call” viene inoltrata da un processo ad un altro, con i dati passati come argomenti.

Alla ricezione della chiamata, le azioni previste nella procedura vengono eseguite, al chiamante viene
notificato l’avvenuto completamento della chiamata, ed un valore di ritorno, se esiste, viene trasmesso dal
processo remoto al processo chiamante.

41
RMI è un’implementazione object-oriented del modello Remote Procedure Call; è un API per soli
programmi Java.

Usando RMI, un oggetto server esporta un oggetto remoto registrandolo (pubblicandolo) in una directory
service. L’oggetto fornisce i metodi remoti, i quali possono essere invocati nei programmi client.
Sintatticamente:

- Un oggetto remoto è dichiarato con una interfaccia remota


- L’interfaccia remota è implementata dall’ oggetto remoto
- Un oggetto client accede all’oggetto remoto invocando i metodi remoti associati all’oggetto stesso

Le API RMI permettono di usare diversi tipi di directory service per registrare un oggetto distribuito.

Noi useremo un semplice directory service chiamato RMIregistry, il quale è fornito direttamente con Java
Software Development Kit (SDK)

L’ RMIregistry è un servizio, che se attivo, deve essere in esecuzione sulla macchina host su cui risiede
l’oggetto server (oggetto che pubblica l’oggetto remoto), e per default riceve sulla porta 1099.
Un’alternativa ad RmiRegistry è Java Naming and Directory Interface (JNDI), il quale è più generale di RMI
registry, nel senso che può essere utilizzato da applicazioni che non usano RMI.

42
LE API JAVA RMI

• Software server-side

L’Interfaccia Remota

Un’Interfaccia Remota è un’interfaccia che estende l’interfaccia java.rmi.Remote


Tale interfaccia non contiene alcun metodo ma serve solo come “marcatore”, cioè attesta
che la classe è utilizzabile per accedere ad un oggetto remoto (cioè invocarne i metodi) e
protegge l’applicazione da anomalie derivanti dall’utilizzo di risorse remote.
Oltre che estendere l’interfaccia Remote, ogni metodo dell’interfaccia remota deve poter
generare una Remote Exception, ma la sintassi dell’interfaccia remota è la stessa di una
interfaccia Java locale.

Esempio:

package esempioRMI;

import java.rmi.*;

import java.rmi.server.*;

public class MiaInterfacciaImplementata extends UnicastRemoteObject

implements MiaInterfaccia {

public MiaInterfacciaImplementata() throws RemoteException {

super( );

public String mioMetodo( ) throws RemoteException {

return "ciao dal mio metodo";

}
43
}

Generare la classe Stub:

In RMI, ogni oggetto distribuito richiede un proxy sia per l’oggetto server che per l’oggetto
client. Questo proxy è generato a partire dall’ implementazione dell’interfaccia remota
usando un tool fornito con la JDK: RMI compiler rmic.
rmic –v1.2 esempioRMI.MiaInterfacciaImplementata
Come risultato della compilazione, verrà generato la classe proxy, il cui nome avrà come
prefisso il nome della classe che implementa il servizio:
MiaInterfacciaImplementata_Stub.class

Generare Oggetto Server:

L’oggetto server crea un’istanza dell’oggetto che implementa l’interfaccia remota ed


esporta lo stesso sul Registry

Esempio:

import java.rmi.*;
public class MioServer {
public static void main(String args[]) {
try{
MiaInterfacciaImplementata exportedObj =
new MiaInterfacciaImplementata();
Naming.rebind(“Mia”, exportedObj);
System.out.println(“Mio Server ready.");
}
catch(Exception e){
e.printStackTrace();
}
}
}
Naming: fornisce metodi per memorizzare e ottenere riferimenti ad oggetti remoti dal
registro
Rebind: (String name, Remote obj): associa un nome (servizio) ad un oggetto remoto,

RMI Registry:

L’RMI Registry (per motivi di sicurezza) deve essere eseguito sull’host dove risiede il server
che esporta (pubblica) l’oggetto remoto. Esso può essere attivato usando l’utility
rmiregistry fornita con la JDK, nel seguente modo:

rmiregistry <port number>


dove <port number> rappresenta il numero di porta
Se non viene specificato nessun numero di porta, allora rmiregistry userà la porta di default
1099.

44
Quando un oggetto server viene eseguito, la pubblicazione dell’oggetto distribuito fa si che
l’oggetto server inizi ad essere in ascolto su una porta (accept) aspettando connessioni da
parte dei clients che richiedono l’esecuzione dei metodi. Un oggetto remoto deve
supportare accessi concorrenti perché più clients potrebbero usarla contemporaneamente
(Bisogna usare metodi/blocchi synchronized dove serve).

• Il Software Client-side.

La programmazione della classe client è simile alla programmazione di una normale classe
Java:

Sintassi necessaria per la richiesta RMI:


- localizzazione dell’RMI Registry nel server host
- Eseguire il looking up del riferimento all’oggetto remoto
- Si esegue il casting del riferimento rispetto all’interfaccia remota. Su di essa può
allora essere invocato il metodo remoto

Esempio:

INVOCARE UN METODO REMOTO

La sintassi per l’invocazione di metodi remoti è la stessa dei metodi locali.

Un errore comune è il casting dell’oggetto prelevato dal registry alla classe dell’oggetto che implementa
l’interfaccia o dell’oggetto server. Si deve castizzare rispetto all’ interfaccia.

STUB DELL’OGGETTO REMOTO

Il file Stub dell’oggetto remoto, così come il file dell’interfaccia remota, deve essere condiviso con l’oggetto
client. La copia di questi file deve essere fornita all’oggetto client (anche manualmente). In alternativa, Java
RMI ha una caratteristica chiamata stub downloading il quale permetta ad un file Stub di essere ottenuto
dal client dinamicamente.

RMI: PASSAGGIO DEI PARAMETRI

- Tipi primitivi
o passati per valore;
- Oggetti remoti
o passati per riferimento;
- Oggetti non remoti
45
o passati per valore;
o si usa la Java Object Serialization (Serializzazione).

RMI E SOCKETS

Remote Method Invocation può essere usato in luogo dei Socket in una applicazione di rete

Alcune differenze tra le RMI e i Socket:

- La comunicazione esplicita tra socket è più efficiente, ma richiede più tempo per la
programmazione (classi proxy)
- RMI garantisce un livello di astrazione maggiore con una conseguente aumento di leggibilità.
Quando la complessità dell’applicazione aumenta può divenire indispensabile
- Con RMI tutti i componenti di una applicazione distribuita devono essere necessariamente scritti in
Java

FIREWALL

Ogni operazioni di rete, che opera fuori da quelli che sono i confini di una rete locale, incontra
evitabilmente i cosiddetti firewall.

Tipicamente i firewall bloccano tutto il traffico di rete, eccetto quello Destinato ad alcune porte
generalmente aperte

Problema:

RMI apre solitamente connessioni socket dinamiche tra client e server, il traffico è tipicamente bloccato dai
firewall.

Soluzione:

Per oltrepassare i firewall, RMI si avvale del tunneling HTTP, incapsulando la chiamata RMI all’interno del
body di una richiesta http post.

46
L’RMI transport layer è in ascolto con un server socket che è capace di decodificare e capire la chiamata
RMI che si trova all’interno della richesta HTTP POST. Le risposte del server sono inviate indietro come
pacchetti HTTP REPLY verso la porta client originaria, dove vengono estratte le informazioni e inviate verso
lo stub RMI appropriato.

DISTRIBUTE GARBAGE COLLECTOR (JAVA)

47
RMI SOCKET FACTORY

48
IL WEB E GLI URI

4.0) Il Web, risorse e introduzione degli identificatori

Identificazione: Il WWW è uno spazio informativo (per umani e applicazioni) in cui ogni elemento di
interesse è chiamato risorsa ed è identificato da un identificatore globale chiamato URI.

Interazione: Un protocollo di comunicazione chiamato HTTP permette di scambiare messaggi su una rete
informatica (nel nostro caso TCP/IP)

Formato: la disponibilità di apposite applicazioni sul computer ricevente e la corretta identificazione del
formato dati con cui la risorsa è stata comunicata permette di accedere al suo contenuto in maniera chiara
e non ambigua. I formati sono molti, tra cui (HTML, PNG, RDF, ecc.)

RISORSA

Il concetto di risorsa è indipendente dal meccanismo di memorizzazione effettiva o dal tipo di contenuto.

“Una risorsa è qualunque struttura che sia oggetto di scambio tra applicazioni all’interno del World Wide
Web”.

Anche se molti identificatori fanno riferimento a file memorizzati in un file system gerarchico, questo tipo di
risorsa non è né necessario né frequente:

- Potrebbe essere in un file system relazionale (VM di IBM)


- Potrebbe essere in un database, e l’URI essere la chiave di ricerca
- Potrebbe essere il risultato dell’elaborazione di un’applicazione, e l’URI essere i parametri di
elaborazione.
- Potrebbe essere una risorsa non elettronica (un libro, una persona, un pezzo di produzione
industriale), e l'URI essere il suo nome Uniforme
- Potrebbe essere un concetto astratto (la grammatica di un linguaggio)

Per questo si usa il termine Risorsa, invece che File, e si fornisce una sintassi indipendente dal sistema
effettivo di memorizzazione. Mai assumere che si stia lavorando con un file system!

IDENTIFICATORI

Gli URI sono stati verosimilmente il fattore determinante per il successo del WWW. Attraverso gli URI, il
WWW è stato in grado di identificare risorse accessibili tramite il proprio protocollo, HTTP, e tramite tutti
gli altri protocolli esistenti (FTP, Telnet, Gopher, WAIS, ecc.).

Il punto principale a cui gli altri sistemi non erano arrivati era una sintassi universale, indipendente dal
protocollo e facilmente memorizzabile o scambiabile con cui identificare le risorse di rete.

Il WWW utilizza gli identificatori in una varietà di modi:

Immagini ed altri oggetti inclusi nei documenti HTML.

- Link ipertestuali posti nei documenti ipertestuali: è importante che l'applicazione sia in grado di
accedere ad una risorsa che è tipicamente nello stesso spazio di nomi della risorsa base

49
- Identificatori di namespace per documenti XML (i.e., un vocabolario di termini a cui fare
riferimento): può essere in uno spazio di nomi diverso

- Identificatori di risorsa su cui esprimere affermazioni: interessa solo identificarla, non accedervi;
tipicamente è in uno spazio di nomi diverso dalla risorsa base.

- identificatori di risorse di cui fornire firme crittografiche o valori hash.

4.2) Gli URI (UNIFORM RESOURCE IDENTIFIER)

Gli URI (Uniform Resource Identifier) sono una sintassi usata in WWW per definire i nomi e gli indirizzi di
oggetti (risorse) su Internet. Gli URI si orientano a risolvere il problema di creare un meccanismo ed una
sintassi di accesso unificata alle risorse di dati disponibili via rete.

Gli Uniform Resource Identifier (URI) sono, per definizione:

• Uniform Resource Locator (URL): una sintassi che contiene informazioni immediatamente
utilizzabili per accedere alla risorsa (ad esempio, il suo indirizzo di rete)

• Uniform Resource Names (URN): una sintassi che permetta una etichettatura permanente e non
ripudiabile della risorsa, indipendentemente dal riportare informazioni sull'accesso.

URI
URL URN

URL (USER RESOURCE LOCATOR)

Gli URL sono un indirizzo della risorsa che possa essere immediatamente utilizzato da un programma per
accedere alla risorsa.

Gli URL contengono tutte le informazioni necessarie per accedere all’informazione, ma sono fragili e
soggetti a modifiche non sostanziali del meccanismo di accesso (es. cambio del nome di una directory).

URN (USER RESOURCE INDICATOR)

Gli URN sono un nome stabile e definitivo di una risorsa, che possa fornire un’informazione certa ed
affidabile sulla sua esistenza ed accessibilità.

Gli URN debbono essere trasformati da un apposito servizio, negli URL attualmente associati alla risorsa.
Inoltre la mappa deve essere aggiornata ogni volta che la risorsa viene spostata.

50
Nella visione classica, i due insiemi erano disgiunti: un URI era o un URL, che riportava informazioni sul
protocollo, sul nome dell'host e sul nome locale della risorsa, oppure era un URN, che non riportava queste
informazioni perché non persistenti.

Nella visione moderna, la distinzione tra URL e URN è secondaria rispetto al concetto di schemi: ogni URI
appartiene ad uno schema (la parte della stringa che precede i due punti).

Alcuni schemi sono per natura persistenti, e possono essere usati per identificare in maniera non
ripudiabile delle risorse; altri per natura contengono informazioni dirette per l'accesso, e allora possono
essere considerati dei locatori. Ma le cose non si escludono, e in ogni caso dipendono dalla natura dello
schema.

CRITERI DI DESIGN DEGLI URI

Trascrivibili: gli URI sono sequenze di caratteri tratti da un set molto limitato (lettere, numeri, alcuni - pochi
- caratteri speciali), per permettere la trascrizione degli URI su canali anche non elettronici (un pezzo di
carta, un cartellone, ecc.).

Fornire identificazione, non interazione: le operazioni eseguibili sulle risorse ed i protocolli per eseguirli non
sono indicati nell’URI, ma nell’interpretazione che degli URI si fa all’interno dello specifico schema.

Fornire spazi di nomi organizzati gerarchicamente: i caratteri “:”, “/”, “?” e “#” separano ambiti diversi
all’interno degli URI.

Un URI è diviso nelle parti seguenti:

URI = schema : [// authority] path [? query] [# fragment] authority = [userinfo @] host [: port]

Lo schema (negli URL è il protocollo) é identificato da una stringa arbitraria (ma registrata presso IANA,
l’Internet Assigned Numbers Authority) usata come prefisso.

La presenza esplicita di un’authority individua un’organizzazione gerarchica dello spazio dei nomi a cui
sono delegati i nomi (che possono essere ulteriormente delegati).

La parte userinfo non deve essere presente se lo schema non prevede identificazione personale. La parte
host è o un nome di dominio o un indirizzo IP. La port può essere omessa se ci si riferisce ad una well-
known port (per http è la porta 80).

La parte path è la parte identificativa della risorsa all’interno dello spazio di nomi identificato dallo schema
e (se esistente) dalla authority. Poiché la presenza di una parte authority evidenzia uno spazio di nomi
gerarchico sotto la gestione dell’authority, in questi casi la parte path è divisa in blocchi separati da slash
“/”, ciascuno dei quali è un componente del path organizzato in gerarchia. In questo caso diventano
significativi gli pseudo componenti “.” e “..”.

La parte query individua un’ulteriore specificazione della risorsa all’interno dello spazio di nomi identificato
dallo schema e dall’URI precedente. Di solito questi sono parametri passati all’URI (un processo) per
specificare un risultato dinamico (es. l’output di una query su un motore di ricerca). La parte query è tutto
51
quello che sta dopo il punto interrogativo e prima del carattere hash. Tipicamente ha la forma
nome1=valore1&nome2=valore+in+molte+parole

La parte fragment individua una risorsa secondaria (una risorsa associata, dipendente o in molti casi un
frammento) della risorsa primaria. E’ tutta la parte che sta dopo al carattere di hash “#”.

ORGANIZZAZZIONE GERARCHICA DEGLI URI

Gli URI sono decisi da una autorità, che li assegna alle risorse in modo da permettere l’identificazione,
garantire la non ambiguità dell’assegnazione, e (a volte) fornire i meccanismi di risoluzione (cioè di accesso
alla risorsa indicata dall’URI stesso).

Gli URI vengono assegnati con una varietà di tecniche che includono:

- Delegazione gerarchica dell’autorità: l’autorità somma delega a sottoautorità il compito di


assegnare i nomi, garantendo non ambiguità tra sottoautorità e richiedendo ad esse il compito di
garantire la non ambiguità all’interno dei loro sottonomi. Es.: http e ftp.

- Numeri random: l’improbabilità di ottenere lo stesso numero random riduce il rischio di ambiguità
ad un valore calcolabile (es. uuid, un identificativo standard usato nelle infrastrutture software).

- Checksum: l’uso di valori hash per il contenuto della risorsa diminuisce analogamente la probabilità
di ambiguità. E’ il caso di MD5 (algoritmo grittografico di hashing).

Misto: una combinazione di approcci usata per esempio da mid e cid.

CARATTERI RISERVATI NEGLI URI

- % Il carattere “%” é il codice di escape, e serve per l’utilizzo di caratteri particolari nell’URI,
precedendone il codice esadecimale. Ad esempio, per utilizzare un carattere “%” nel’URI bisogna
usare la stringa “%25”
- / Il carattere “/” é utilizzato unicamente per l’identificazione di sottoparti di uno schema
gerarchico, e non può essere usato per altri scopi.
- . Il punto singolo “.” o il punto punto “..” hanno anch’essi un significato gerarchico riservato,
per indicare ovviamente risorse allo stesso livello o al livello superiore.
- # Il carattere di hash “#” serve per delimitare l’URI di un oggetto da un identificatore di un
frammento interno alla risorsa considerata. Questo permette ad un URI di far riferimento non
soltanto ad una risorsa (oggetto di interesse del server), ma anche a frammenti interni alla risorsa
(che verranno identificati dal client).
- ? Il punto interrogativo “?” serve per separare l’URI di un oggetto su cui é possibile fare una
query (un database, per esempio), dalla stringa usata per specificare la query.
- + All’interno della query, il segno più “+” é usato al posto dello spazio (che non é mai usato
per nessuna ragione).

- * L’asterisco “*” ha un significato speciale all’interno di schemi specifici.

- ! Analogamente il punto esclamativo “!” ha un significato all’interno di uno schema.

- %XX Caratteri speciali o riservati o in generale non sicuri (es. quelli superiori al codice ASCII 127)
possono essere specificati tramite codifica esadecimale introdotta dal carattere di escape.
52
URI ASSOLUTI E RELATIVI

URI assoluto: contiene tutte le parti predefinite dal suo schema, esplicitamente precisate. Un URI
gerarchico può però anche essere relativo, ed in questo caso riportare solo una parte dell'URI assoluto
corrispondente. Sicuramente manca la parte schema.

URI relativo: Un URI relativo fa sempre riferimento ad un URI di base (ad esempio, l'URI assoluto del
documento ospitante l'URI relativo) rispetto al quale fornire elementi di differenza.

4.3) HTTP (HyperText Transfer Protocol)

HTTP é un protocollo client-server generico (HTTP è indipendente dal formato dati con cui vengono
trasmesse le risorse) e stateless (Il server non è tenuto a mantenere informazioni che persistano tra una
connessione e la successiva sulla natura, identità e precedenti richieste di un client. Il client è tenuto a
ricreare da zero il contesto necessario al server per rispondere) utilizzato non solo per lo scambio di
documenti ipertestuali, ma per una moltitudine di applicazioni, incluso name server e sistemi object-
oriented distribuiti.

Caratteristiche di HTTP sono:

- la negoziazione del formato di dati, per l’indipendenza del sistema dal formato di rappresentazione
dei dati.

- Specifiche di politiche di caching sofisticate a seconda del tipo di connessione.

- Specifiche di autenticazione dell'utente di varia sofisticazione.

RUOLI DELLE APPLICAZIONI HTTP

User agent: Quel particolare client che inizia una richiesta HTTP (tipicamente un browser, ma può anche
essere un bot).

Un bot (abbreviazione di robot) è un'applicazione automatica che richiede e scarica pagine HTML e siti web
per scopi vari: indicizzazione, catalogazione, verifica di correttezza sintattica, etc. E' uno user agent anche
se non vi sono utenti che serve.

Origin server: il server che possiede fisicamente la risorsa richiesta (è l’ultimo della catena).

Proxy: Un’applicazione intermediaria che agisce sia da client che da server. Le richieste sono soddisfatte
autonomamente, o passandole ad altri server, con possibile trasformazione, controllo, verifica.

Gateway: un’applicazione che agisce da intermediario per qualche altro server. A differenza del proxy, il
gateway riceve le richieste come fosse l’origin server: il client può non essere al corrente che si tratta del
gateway.

Tunnel: un programma intermediario che agisce da trasmettitore passivo di una richiesta HTTP. Il tunnel
non fa parte della comunicazione HTTP, anche se può essere stato attivato da una connessione HTTP.

In più è importante ricordare:

53
Cache: memoria locale di un'applicazione e il sistema che controlla i meccanismi della sua gestione ed
aggiornamento. Qualunque client o server può utilizzare una cache, ma non un tunnel.

TIPI DI PROXY HTTP

In generale un proxy si pone come intermediario tra client e server e decide se e come rispondere al client.
I proxy sono trasparenti (non cambiano la risposta) o non trasparenti (possono cambiare la risposta)

• Proxy trasparenti

Proxy di cache: Richieste multiple agli stessi URL possono essere salvate in una locazione intermedia per
una maggiore efficienza nella gestione delle risposte

Proxy di filtro: Esigenze di sicurezza o di controllo degli abusi di una rete possono richiedere l'effettiva
esecuzione della richiesta solo in certi casi, e altrimenti la risposta con un generico messaggio di mancata
autorizzazione.

• Proxy non trasparenti

Il motivo principale per utilizzare non trasparente (o proxy manuale) è che il browser Web e altre
applicazioni client sappiano che viene utilizzato un proxy e che quindi possono agire di conseguenza. La
configurazione iniziale di un proxy non trasparente potrebbe essere più complicata, ma in definitiva
fornisce un servizio di proxy molto più potente e flessibile.

LA CONNESSIONE HTTP

La connessione HTTP è composta da una serie di richieste ed una serie corrispondente di risposte.

La differenza principale tra HTTP 1.0 e 1.1 è stata la possibilità di specificare coppie multiple di richiesta e
risposta nella stessa connessione (connessione persistente).

Le richieste possono essere messe in pipeline, ma le risposte debbono essere date nello stesso ordine delle
richieste, poiché non è specificato un metodo esplicito di associazione.

54
• Le connessioni persistenti hanno diversi vantaggi:
- Richiedono meno connessioni TCP, con vantaggio per le CPU e per la rete
- Permettono di ridurre l'attesa della visualizzazione
- Permettono di gestire in maniera migliore gli errori
• Il pipelining è la trasmissione di più richieste senza attendere l'arrivo della risposta alle richieste
precedenti
- Riduce ulteriormente i tempi di latenza, ottimizzando il traffico di rete, soprattutto per richieste che
riguardano risorse molto diverse per dimensioni o tempi di elaborazione.
- E' fondamentale che le risposte vengano date nello stessso ordine in cui sono state fatte le richieste
(HTTP non fornisce un meccanismo di riordinamento esplicito).

LA RICHIESTA CON HTTP


La richiesta semplice (HTTP 0.9) è:

GET URI CrLf

La richiesta completa (HTTP 1.0 e segg.):

Method URI Version CrLf


[Header]*
CrLf
Body

- Method indica l’azione del server richiesta dal client.


- URI è un identificativo di risorsa locale al server.
- Version è “HTTP/1.0” o “HTTP/1.1”.
- Header sono linee RFC822, classificabili come header generali, header di entità, ed header di
richiesta.
- Body è un messaggio MIME.

I METODI DELLA RICHIESTA


Noi ci occupiamo dei metodi seguenti:
- GET
- HEAD
- POST
- PUT
Ma non di
- OPTIONS
- DELETE
- TRACE
- CONNECT
Un metodo HTTP può essere:
Sicuro: non genera cambiamenti allo stato interno del server
Idempotente: l’effetto sul server di più richieste identiche è lo stesso di quello di una sola richiesta.

55
• METODO GET
Il più importante (ed unico in v. 0.9) metodo di HTTP è GET, che richiede una risorsa ad un server.
Questo è il metodo più frequente, ed è quello che viene attivato facendo click su un link
ipertestuale di un documento HTML, o specificando un URL nell’apposito campo di un browser.

GET è sicuro ed idempotente, e può essere:


- assoluto (normalmente, cioè quando la risorsa viene richiesta senza altre specificazioni),

- condizionale (se la risorsa fa match con un criterio indicato negli header If-match, If-modified-since,
If-range, etc.)

- parziale (se la risorsa richiesta è una sottoparte di una risorsa)

• METODO HEAD
Nel metodo HEAD il server deve rispondere soltanto con gli header relativi, senza il corpo.
viene usato per verificare:

- la validità di un URI: la risorsa esiste e non è di lunghezza zero,


- l’accessibilità di un URI: la risorsa è accessibile presso il server, e non sono richieste procedure di
autenticazione del documento.
- la coerenza di cache di un URI: la risorsa non è stata modificata nel frattempo, non ha cambiato
lunghezza, valore hash o data di modifica.

• METODO POST

Il metodo POST serve per trasmettere delle informazioni dal client al server, ma senza la creazione
di una nuova risorsa.
POST non è sicuro né idempotente, e viene usato per esempio per sottomettere i dati di una form
HTML ad un’applicazione CGI sul server. Il server può rispondere positivamente in tre modi:

- 200 Ok: dati ricevuti e sottomessi alla risorsa specificata. E’ stata data risposta
- 201 Created: dati ricevuti, la risorsa non esisteva ed è stata creata
- 204 No content: dati ricevuti e sottomossi alla risorsa specificata. Non è stata data risposta.

• METODO PUT

Il metodo PUT serve per trasmettere delle informazioni dal client al server, creando o sostituendo
la risorsa specificata. In generale, l’argomento del metodo PUT è la risorsa che ci si aspetta di
ottenere facendo un GET in seguito con lo stesso nome.
L’argomento del metodo POST, invece, è una risorsa esistente a cui si aggiunge (es. come input)
informazione.

GLI HEADER
Gli header sono righe RFC822 che specificano caratteristiche generali della trasmissione:

- dell’entità trasmessa,
- della richiesta effettuata
- della risposta generata

56
• HEADER DELL’ENTITA’

Gli header dell’entità danno informazioni sul body del messaggio, o, se non vi è body, sulla risorsa
specificata.

Content-Type: il tipo MIME dell’entità acclusa. Questo header è obbligatorio in ogni messaggio che
abbia un body.

Content-Length: la lunghezza in byte del body. Obbligatorio, soprattutto se la connessione è


persistente.

Content-Encoding, Content-Language, Content-Location, Content-MD5, Content-Range: la


codifica, il linguaggio, l’URL della risorsa specifica, il valore di digest MD5 e il range richiesto della
risorsa.

Expires: una data dopo la quale la risorsa è considerata non più valida (e quindi va richiesta o
cancellata dalla cache).

Last-Modified: Obbligatorio se possibile. La data e l’ora dell’ultima modifica. Serve per decidere se
la copia posseduta (es. in cache) è ancora valida o no.

• HEADER DELLA RICHIESTA

Gli header della richiesta sono posti dal client per specificare informazioni sulla richiesta e su se
stesso al server.
User-Agent: una stringa che descrive il client che origina la richiesta; tipo, versione e sistema
operativo del client, tipicamente.

Referer: l’URL della pagina mostrata all’utente mentre richiede il nuovo URL (Se l’URL è richiesto
con altri metodi che non l’attraversamento di un link es. digitando l'URL o selezionandolo dai
bookmark, Referer deve essere assente).

Host: Header obbligatorio in HTTP 1.1.


Contiene il nome di dominio e la porta a cui viene fatta la connessione.

From: l’indirizzo di e-mail del richiedente. Si richiede che l’utente dia la sua approvazione prima di
inserire questo header nella richiesta.

Range: il range della richiesta. Poco usato.

Accept, Accept-Charset, Accept-Encoding, Accept-Language: Implementazione della negoziazione


del formato, per quel che riguarda tipo MIME, codice caratteri, codifica MIME, linguaggio umano.
Il client specifica cosa è in grado di accettare, e il server propone il match migliore.

If-Modified-Since, If-Unmodified-Since: richieste condizionali (per esempio, per aggiornare una


cache) che vanno portate a termine solo se la condizione è vera.
Se la pre-condizione è valida, viene ritornato un 304 (not modified), altrimenti si procede come per
un GET normale.

57
Authorization, Proxy-Authorization: una stringa di autorizzazione per l’accesso alla risorsa
richiesta. Ne parliamo oltre.

LA RISPOSTA

GET /index.html HTTP/1.1


Host: www.ing.unirc.it:80
HTTP/1.1 200 OK
Date: Fri, 26 Nov 1999 11:46:53 GMT
Server: Apache/1.3.3 (Unix)
Last-Modified: Mon, 12 Jul 1999 12:55:37 GMT
Accept-Ranges: bytes
Content-Length: 3357
Content-Type: text/html
<HTML> …. </HTML>

STATUS CODE

Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta, e le altre due la
risposta specifica. Esistono le seguenti classi:

- 1xx: Informational. Una risposta temporanea alla richiesta, durante il suo svolgimento.

- 2xx: Successful. Il server ha ricevuto, capito e accettato la richiesta.

- 3xx: Redirection. Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte
del client per portare a termine la richiesta.

- 4xx: Client error. La richiesta del client non può essere soddisfatta per un errore da parte del client
(errore sintattico o richiesta non autorizzata).

- 5xx: Server error. La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la
richiesta per un problema interno (suo o di applicazioni CGI).

Esempio:
100 Continue (se il client non ha ancora mandato il body)
200 Ok (GET con successo)
201 Created (PUT con successo)
301 Moved permanently (URL non valida, il server conosce la nuova posizione
400 Bad request (errore sintattico nella richiesta)
401 Unauthorized (manca l’autorizzazione)
403 Forbidden (richiesta non autorizzabile)
404 Not found (URL errato)
500 Internal server error (tipicamente un CGI mal fatto)
501 Not implemented (metodo)

58
HEADER DELLA RISPOSTA

Gli header della risposta sono posti dal server per specificare informazioni sulla risposta e su se
stesso al client
- Server: una stringa che descrive il server: tipo, sistema operativo e versione.
WWW-Authenticate:
l’header di WWW-Authenticate include una challenge (codice di partenza) con cui il meccanismo di
autenticazione deve fare match in caso di una risposta 401, (unauthorized). Il client genererà con
questo valore un valore di autorizzazione posto nell’header Authorization della prossima richiesta.
- Accept-ranges: specifica che tipo di range può accettare (valori previsti: byte e none).

AUTENTICAZIONE

Quando si vuole accedere ad una risorsa su cui esistono restrizioni di accesso, il server richiede
l'autenticazione dell'utente.
HTTP ha due metodi di autenticazione:

- Basic authentication (introdotto in HTTP 1.0)


L'header della prima risposta WWW-Authenticate contiene il contesto di sicurezza (realm)
dell'autenticazione. Il client richiede le informazioni di autorizzazione all'utente e
Il client crea una nuova richiesta GET e fornisce le informazioni di autorizzazione codificate in
Base64. Il client continua a mandare lo stesso header per tutte le pagine dello stesso realm.
Problema: La password passa dunque in chiaro sulla rete.

- Digest access authentication (introdotto in HTTP 1.1)


Introdotto da HTTP 1.1, descritto in RFC 2069 e RFC 2617.
Non manda la password in chiaro, ma una fingerprint della password, ovvero la password
crittografata con il metodo MD5 (RFC 1321).
Per evitare l'abuso della password, anche se crittografata, insieme alla fingerprint vengono
codificate anche informazioni come lo username, il realm, l'URI richiesto, una time stamp, ecc.).

CACHING

Può essere client-side, server-side o intermedia (su un proxy). La cache server-side riduce i tempi di
computazione di una risposta, ma non ha effetti sul carico di rete. Le altre riducono il carico di rete.

Server-specified expiration
Il server indica una scadenza della risorsa con l'header Expires o con la direttiva max-age in Cache-
Control. Se la data di scadenza è già passata, la richiesta deve essere rivalidata. Se la richiesta
accetta anche risposte scadute, o se l'origin server non può essere raggiunto, la cache può
rispondere con la risorsa scaduta ma con il codice 110 (Response is stale).

Se Cache-Control specifica la direttiva must-revalidate, la risposta scaduta non può mai essere
rispedita. In questo caso la cache deve riprendere la risorsa dall'origin server. Se questo non
risponde, la cache manderà un codice 504 (Gateway time-out). Se Cache-Control specifica la
direttiva no-cache, la richiesta deve essere fatta sempre all'origin server.

59
Heuristic expiration
Poiché molte pagine non conterranno valori espliciti di scadenza, la cache stabilisce valori euristici
di durata delle risorse, dopo le quali assume che sia scaduta.
Queste assunzioni possono a volte essere ottimistiche, e risultare in risposte scorrette. Se non
valida con sicurezza una risposta assunta fresca, allora deve fornire un codice 113 (heuristic
expiration) alla risposta.

MODELLI DI SICUREZZA PER LA TRASMISSIONE


Ci sono due modi per fornire un trasporto sicuro (cioè non intercettabile da orecchie maliziose
durante la trasmissione):

- Usare un'infrastruttura di trasporto sicura.


Il protocollo non cambia, ma ogni pacchetto trasmesso nello scambio di informazioni viene gestito
in maniera sicura dal protocollo di trasporto.

- Usare un protocollo sicuro a livello applicazione.

- Si usa un protocollo anche diverso, che si occupa di gestire la trasmissione delle informazioni.

60
LINGUAGGIO XML E XML SCHEMA

5.0) XML (eXstensible Markup Language)

In informatica XML (sigla di eXtensible Markup Language) è un metalinguaggio per la definizione di


linguaggi di markup, ovvero un linguaggio marcatore basato su un meccanismo sintattico che consente di
definire e controllare il significato degli elementi contenuti in un documento o in un testo.

XML prevede una sintassi semplificata rispetto a SGML, e definisce contemporaneamente una serie
piuttosto lunga di linguaggi associati: uno per i link, uno per i nomi di tag, uno per i fogli di stile, uno per la
descrizione di meta-informazioni, ecc.

XML si propone di integrare, arricchire e, nel lungo periodo, sostituire HTML come linguaggio di markup
standard per il World Wide Web.

APPLICAZIONI E VANTAGGI DI XML

- Data Interchange

Ogni volta che più programmi si debbono scambiare dati, ci sono problemi di compatibilità. Ogni
programma ha le proprie assunzioni in termini di caratteri, separatori, ripetibilità di elementi, differenza tra
elementi vuoti e assenti, ecc.

XML si propone come la sintassi intermedia più semplice per esprimere dati anche complessi in forma
indipendente dall’applicazione che li ha creati.

- Document publishing

XML è ideale come linguaggio per esprimere documenti strutturati o semi strutturati, e per esprimerli in
maniera indipendente dalla loro destinazione finale. Lo stesso documento XML può essere preso e
trasformato per la stampa, il Web, il telefonino, l’autoradio.

- Platform-independence

XML è uno standard aperto, e chiunque può realizzare strumenti che lo usino come formato di dati.

- Documenti auto-descrittivi

La scelta dei nomi degli elementi può essere fatta per facilitare la comprensione del ruolo strutturale
dell’elemento.

Inoltre, l’uso di un DTD può esplicitare le regole di composizione ed i rapporti possibili tra le varie parti dei
documenti.

- Facile convertibilità a formati Web

La totale interdipendenza tra XML, SGML, HTML etc. fa sì che la conversione tra formati interni e formati
per il Web sia facile.

61
- Sintassi universale, minimale e rigorosa

XML definisce una sintassi di scrittura (per dati, metadati, categorie, etc.) utile per qualunque applicazione,
vocabolario, linguaggio umano, sistema operativo. La totale mancanza di eccezioni e l’equivalenza tra
struttura dati e rappresentazione linearizzata favoriscono l'adozione in ambienti estremamente eterogenei.

- Content model misti

XML trova un punto di equilibrio tra i formati dati per l'interscambio di dati e i formati per la strutturazione
di documenti di testo. I content model misti (elementi che possono contenere sia altri elementi sia testo)
infatti permettono di inserire caratterizzazioni semantiche non solo per interi elementi, ma anche
all'interno di elementi di testo contenitori (ad esempio, i paragrafi).

- Ripetibilità degli elementi

XML permette di definire formalmente elementi ripetibili. Questo permette strutture più flessibili e
complesse di altri formati di dati

- Strutturazione gerarchica degli elementi

Esistono molti formati di dati generici per l'interscambio di dati, ma sono tutti organizzati linearmente. XML
permette strutture ad albero.

- Struttura navigabile dei documenti

La sintassi rigorosa, la gerarchia garantita, la genericità delle strutture permettono la definizione di modelli
di programmazione sui nodi dell’albero (in particolare, DOM, document object model) che risultano
particolarmente e potenti perché permettono di organizzare i dati in maniera molto sofisticata senza
perdere nulla in programmabilità.

XML è in realtà una famiglia di linguaggi:

- XML 1.0: un meta-linguaggio di markup


- DTD: specifica di vincoli di correttezza su documenti XML
- XSLT: trasformazione di documenti XML
- XML-Schema:specifica di vincoli sofisticati di correttezza su documenti XML
- RDF: specifica di meta-informazioni machine-processable
- DOM, SAX: modelli e strutture dati per la programmazione
- SOAP, WSDL, UDDI: linearizzazione di strutture dati e loro dichiarazione per di dati di interscambio
tra applicazioni.
- Migliaia di proposte di vocabolari con lo scopo di standardizzare linguaggi, processi e servizi in
ambiti specializzati: TEI, RSS, News-ML, Math-ML, CML, ebXML, cXML, etc.

PERCHE’ XML?

- Produzione di documenti automatici


Integra e sostituisce le tecnologie server-side di accesso ai dati: ASP, PHP, server-side Javascript,
ecc.

- Gestione indipendente di produzione e uso di dati

62
XML è strutturato, auto-esplicativo, enfatizza la descrizione del dato più che del suo scopo nella
elaborazione. E’ quindi ideale per le situazioni in cui l’elaborazione non è nota in anticipo.

- Elaborazione di dati con aspetti strutturali complessi


I database utilizzano le relazioni per ogni tipo di esigenza: dalla descrizione di connessioni logiche
tra entità concettualmente diverse, alla gestione di dati strutturati in maniera complessa.
XML prevede strutture con blocchi ripetuti, alternativi, facoltativi. La descrizione di queste strutture
in XML è molto più naturale che con DB relazionali.

- Elaborazione di dati strutturati in contenitori semi-strutturati


XML permette di inserire all’interno di strutture documentarie (pensate per la visualizzazione) tag
di natura descrittiva utilizzabili per elaborazioni sofisticate.

XML NEWS
XMLNews definisce il contenuto testuale e le meta-informazioni di notizie da agenzia stampa. è
composto di due parti:

- XMLNews-Story
E’ un DTD XML per descrivere in maniera variamente arricchita il testo delle notizie.
E’ possibile in qualunque momento aggiungere informazioni inline.
Questo permette di arricchire la storia con molte informazioni e in maniera semi-automatica:
– Nella ricerca: è possibile cercare tutto quello che è successo in Colombia, o cosa è successo
in una certa data.
– Nella presentazione: un provider potrebbe fornire semi-automaticamente dei link o delle
cartine della Colombia.
– Nell’organizzazione delle news: è possibile cercare tutti i terremoti effettivi, e non le
notizie che ne usano la parola, magari figurativamente.

- XMLNews-Meta
Assieme ad ogni notizia, vengono scritte delle informazioni sulla notizia, che possono avere una
distribuzione separata.

- Informazioni sul contenuto della notizia (titolo, lingua, formato, ecc.)


- Informazioni sulle date della notizia: creazione, pubblicazione, scadenza, ecc.
- Informazioni sulla provenienza ed attendibilità della notizia
- Informazioni sui possessori dei diritti di distribuzione e copyright
- Informazioni di classificazione ed organizzazione
- Link a documenti connessi: versioni precedenti, seguenti, ed altre notizie connesse.

63
DOCUMENTI XML

Ben formati:

Un documento XML si dice ben formato se:

- Tutti i tag di apertura e chiusura corrispondono e sono ben annidati


- Esiste un elemento radice che contiene tutti gli altri
- Gli elementi vuoti (senza contenuto) utilizzano un simbolo speciale di fine tag: <vuoto/>
- Tutti gli attributi sono sempre racchiusi tra virgolette
- Tutte le entità sono definite.

Validi:

Il cuore di un’applicazione XML è il parser, ovvero quel modulo che legge il documento XML e ne crea una
rappresentazione interna utile per successive elaborazioni (come la visualizzazione).

Un parser validante, in presenza di un DTD, è in grado di verificare la validità del documento, o di segnalare
gli errori di markup presenti.

Un parser non validante invece, anche in presenza di un DTD è solo in grado di verificare la buona forma del
documento. Un parser non validante è molto più semplice e veloce da scrivere, ma è in grado di fare meno
controlli. In alcune applicazioni, però, non è necessario validare i documenti, solo verificare la loro buona
forma.

XML IN BREVE

Concretamente, un documento XML è un file di testo che contiene una serie di tag, attributi e testo
secondo regole sintattiche ben definite.

Analizziamo ora XML dal punto di vista logico e sintattico e i documenti che con esso si possono creare
dando uno sguardo alla struttura logica. Introduciamo alcuni concetti fondamentali per la corretta
comprensione di questo meta-linguaggio.

Un documento XML è intrinsecamente caratterizzato da una struttura gerarchica. Esso è composto da


componenti denominati elementi. Ciascun elemento rappresenta un componente logico del documento e
può contenere altri elementi (sottoelementi) o del testo. Gli elementi possono avere associate altre
64
informazioni che ne descrivono le proprietà. Queste informazioni sono chiamate attributi. L'organizzazione
degli elementi segue un ordine gerarchico o arboreo che prevede un elemento principale, chiamato root
element o semplicemente root o radice. La radice contiene l'insieme degli altri elementi del documento.
Possiamo rappresentare graficamente la struttura di un documento XML tramite un albero, generalmente
noto come document tree.

5.1) XML Schema (eXstensible Markup Language)

Inizialmente si pensava che XML servisse solo per i documenti. Nasce poi l’idea che XML possa servire per
qualcosa di più: XML è (anche) un linguaggio di markup per trasferire dati: un meccanismo per convertire
dati dal formato interno dell’applicazione ad un formato di trasporto, facile da convertire in altri formati
interni. Per esprimere documenti di testo, i DTD (Document Type Definition) probabilmente bastano, ma
per esprimere blocchi di dati strutturati, è necessario un meccanismo di verifica più raffinato. XML Schema
è stato pensato per fornire quel supporto di validazione che i DTD permettono solo parzialmente, in
particolare sul contenuto degli elementi e degli attributi dei documenti XML.

XML E DTD (Document Type Definition)

• Modularità:
I DTD offrono le entità parametriche per tutto: content model ripetuti, frammenti di DTD riusabili,
modularizzazione delle specifiche.

XML Schema offre:


- Un meccanismo di inclusioni di file(differenziato e sofisticato)
- Un sistema di tipi gerarchico e complesso
- Un sistema di specifica di frammenti riutilizzabili di content model e attributi.

• Gestione dei namespace


- I DTD ignorano i namespace. E' molto complesso far convivere DTD e qualifica degli elementi.
- XML Schema permette esplicitamente di qualificare gli elementi e gli attributi, e fornisce molte
funzionalità di estensione o limitazione dei vincoli sugli elementi a seconda del loro namespace.

65
• Vincoli su elementi e attributi
- I DTD permettono un ragionevole controllo degli elementi strutturati, ma poca flessibilità sui
content model misti.
- Inoltre non permettono vincoli sugli elementi di testo (#PCDATA e CDATA) a parte le liste di valori
negli attributi
- XML Schema amplia il set di vincoli per gli elementi strutturati, ed è molto più flessibile negli
elementi con CM misto.
- Inoltre permette di definire tipi semplici, ovvero di esprimere vincoli su dati di tipo stringa, in
maniera completa e sofisticata.

• Documentazione esplicita
- Allegare documentazione per esseri umani in un DTD significa inserire commenti XML dentro al
DTD. Questo è limitante e fragile (i parser eliminano i commenti).
- XML Schema permette di inserire annotazioni in maniera esplicita e controllata, in maniera che
sopravviva al parser.

• Sintassi XML
- I DTD usano una sintassi propria e particolare, che richiede parser appositi e strumenti di
generazione e verifica appositi.
- XML Schema usa XML come sintassi. Tutti gli strumenti che si usano per XML sono immediatamente
utili: parser, visualizzatori, verificatori, ecc.
- Per contro, XML Schema è estremamente più verboso, tre o quattro volte più lungo del
corrispondente DTD, e molto spesso meno chiaro da leggere.

Sintassi di un documento:

Un documento di XML Schema è racchiuso in un elemento <schema>, e può contenere, in varia


forma ed ordine, i seguenti elementi:
– <import> ed <include> per inserire, in varia forma, altri frammenti di schema da altri
documenti
– <simpleType> e <complexType> per la definizione di tipi denominati usabili in seguito
– <element> ed <attribute> per la definizione di elementi ed attributi globali del documento.
– <attributeGroup> e <group> per definire serie di attributi e gruppi di content model
complessi e denominati.
– <notation> per definire notazioni non XML all’interno di un documento XML
– <annotation> per esprimere commenti per esseri umani o per applicazioni diverse dal
parser di XML Schema.

I TIPI DI XML
XML Schema usa i tipi per esprimere vincoli sul contenuto di elementi ed attributi.
– Un tipo semplice è un tipo di dati che non può contenere markup e non può avere attributi.
In pratica è una sequenza di caratteri. E' una specificazione (e restrizione) di CDATA o
#PCDATA.
– Un tipo complesso è un tipo di dati che può contenere markup e avere attributi. E'
l'equivalente di un tipo strutturato o misto.

66
TIPI SEMPLICI

Gli elementi e gli attributi sono istanze di un tipo. I tipi semplici sono tipi stringa non ulteriormente
strutturati, e possono essere usati per entrambi.
XML Schema non fa nessuna distinzione tra attributi ed elementi con content model testo.

E' possibile derivare i tipi semplici per:


- Restrizione:
Si parte da un tipo già definito e ne si restringe il set di valori leciti attraverso l'uso di
facet(delle caratteristiche indipendenti tra di loro che specificano aspetti del tipo:
length, minLength, maxLength: numero richiesto, minimo e massimo di caratteri
minExclusive, minInclusive, maxExclusive, maxInclusive: valore massimo e minimo,inclusivo
ed esclusivo,
precision, scale: numero di cifre significative e di decimali significativi
pattern: espressione regolare che il valore deve soddisfare
enumeration: lista all’interno dei quali scegliere il valore (simile alla lista di valori leciti degli
attributi nei DTD).
period, duration, encoding, ecc.)

- Unione:
L'insieme dei valori leciti è data dall'unione dei valori leciti di due tipi semplici.

- lista:
Sono valori leciti una lista separata da virgole di valori del tipo semplice specificato.

In XML Schema i tipi possono essere predefiniti (solo x tipi semplici), denominati (con una
definizione esplicita, come nei casi precedenti) o anonimi (interni alla definizione di un elemento).

TIPI COMPLESSI
Sono tipi complessi:
• Content model ANY ed EMPTY
Esempio:
<xsd:element name="anything" type="xsd:anyType"/>

<xsd:element name="empty">
<xsd:complexType/>
</xsd:element>

• Content model strutturati


Nei DTD si usano virgole e barre per specificare obblighi e scelte tra gli elementi di un
content model complesso. In XML schema si usano <choice>, <sequence> e <all>. Questi
sostituiscono anche le parentesi:
Esmpio:
La scelta (A | B | C) diventa
<xsd:choice>
<xsd:element name=”A” type="xsd:string"/>
<xsd:element name=”B” type="xsd:string"/>

67
<xsd:element name=”C” type="xsd:string"/>
</xsd:choice>

XML Schema riprende l'operatore & di SGML

Esempio Il raggruppamento non ha bisogno di parentesi: (A, ( B | C)) diventa


<xsd:sequence>
<xsd:element name=”A” type="xsd:string"/>
<xsd:choice>
<xsd:element name=”B” type="xsd:string"/>
<xsd:element name=”C” type="xsd:string"/>
</xsd:choice>
</xsd:sequence>

Si usano anche gli attributi minOccurs e maxOccurs. XML Schema permette non solo i valori
0, 1 e infinito, ma qualunque numero intero. Infinito è "unbounded", e può essere usato
solo per maxOccurs.
Per default entrambi valgono 1. Inoltre, minOccurs ≤ maxOccurs.Posso specificare questi
attributi non solo per gli elementi, ma anche per le strutture (choice, sequence, all).

Esempio (A,B,C)* diventa:


<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name=”A” type="xsd:string"/>
<xsd:element name=”B” type="xsd:string"/>
<xsd:element name=”C” type="xsd:string"/>
</xsd:sequence>

• Content model misti


Il content model misto aggiunge semplicemente l’attributo mixed con valore “true”.
Qualunque espressione di elementi viene rispettata, ma il PCDATA può comparire ovunque,
prima o dopo questi elementi.

Esempio:
<!ELEMENT para (#PCDATA | em | strong)*>

<xsd:complexType name="paraContent" mixed="true">


<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="em" type="paraContent"/>
<xsd:element name="strong" type="paraContent"/>
</xsd:choice>
</xsd:complexType>
<xsd:element name="para" type="paraContent"

• Content model di qualunque tipo ma con attributi


Nei tipi complessi, gli attributi vengono sempre posti alla fine del content model, in una
lista aperta di elementi <attribute>.

Esempio:

68
<xsd:element name=“Z” type=“Tz”/>
<xsd:complexType name=“Tz”>
<xsd:sequence>
.
.
.
</xsd:sequence>
<xsd:attribute name=“y” type=“xsd:string”/>
</xsd:complexType>

Non esistono tipi complessi predefiniti (o quasi).


La derivazione può avvenire per restrizione o estensione.

DERIVATZIONE DEI TIPI COMPLESSI PER RESTRIZIONE

si limitano ulteriormente i vincoli espressi: modificando minOccurs e maxOccurs, fissando dei valori
per certi elementi o attributi, o imponendo ad un elemento un sottotipo del tipo originario.

DERIVAZIONE TIPI COMPLESSI PER ESTENZIONE

aggiungendo al content model nuovi elementi o nuovi attributi.

Attenzione: i nuovi elementi sono posti necessariamente alla fine degli altri.

In generale:

Per definire gli elementi e gli attributi si usano Si usano gli elementi <element> e <attribute>.

DEFINIZIONI GLOBALI O LOCALI :

Una definizione si dice globale se è posta all'interno del tag <schema>. In questo caso l'elemento o
l'attributo è definito in maniera assoluta. L'elemento può essere un elemento radice del documento.

Una definizione si dice locale se è inserita all'interno di un tag <complexType>. In questo caso l'elemento o
l'attributo esiste solo se esiste un'istanza di quel tipo, e l'elemento non può essere un elemento radice del
documento.( Gli attributi elementFormDefault e attributeFormDefault controllano se gli elementi e gli
attributi locali siano per default qualificati o non qualificati)

I NAMESPACE:

La dichiarazione di targetNamespace definisce il namespace del documento da validare.

Esempio:

<schema xmlns="http://www.w3.org/2000/08/XMLSchema"

xmlns:po="http://www.example.com/PO1"

targetNamespace="http://www.example.com/PO1"

69
elementFormDefault="unqualified"

attributeFormDefault="unqualified">

etc… </schema>

Per gestire più namespace è necessario separare la gestione dei namespace in più xsd:schema, ciascuno
con il proprio targetNamespace.

INCLUSIONI ED IMPORTAZIONI

• In XML Schema, esistono meccanismi per dividere lo schema in più file, o per importare definizioni
appartenenti ad altri namespace

– Include: Le nuove definizioni appartengono allo stesso namespace, ed è come se venissero


inserite direttamente nel documento.

– Redefine: come include, le definizioni appartengono allo stesso namespace, ma possono


venire ridefiniti tipi, elementi, gruppi, ecc.

– Import: le nuove definizioni appartengono ad un altro namespace, ed è l'unico modo per


fare schemi che riguardino namespace multipli.

UNICITA’ E CHIAVI

In XML Schema, è possibile richiedere che certi valori siano unici, o che certi valori siano chiavi di riferimenti

Tramite per esempio

<xsd:unique name="code"> “unico”

Oppure

<xsd:key name="code"> “chiave”

Accorgimento generale:

(Con l’attributo schemaLocation dentro all’istanza del documento XML diamo un suggerimento sulla
posizione dello schema al validatore)

70
SOA (SERVICE ORIENTED ARCHITECTURE) INTRODUZINE AI WEB SERVICE

6.0) SOA (SERVICE ORIENTED ARCHITECTURE)

INTRODUZIONE

Obiettivo 1: Tagliare i costi e massimizzare l’uso delle tecnologie esistenti

Obiettivo 2: Servire meglio gli utenti, essere più competitivi, e più reattivi verso le strategie di business

Punti essenziali: Eterogeneità e Cambiamento

ETEROGENEITA’

Le aziende utilizzano al giorno d’oggi prodotti informatici eterogenei, provenienti da differenti vendor,
difficili da integrare. Se l’integrazione è difficile, essa è anche strettamente necessaria. Impossibile utilizzare
prodotti provenienti da un unico vendor.

CAMBIAMENTO

La tecnologia disponibile si evolve velocemente, in un mercato globalizzato e estremamente competitivo.


Le esigenze degli utenti cambiano altrettanto rapidamente. I sistemi aziendali devono consentire il
costante adeguamento a tale evoluzione, per continuare a catturare l’utenza.

Come rendere il mio ambiente IT più flessibile e reattivo ai requisiti del business, che cambiano
continuamente?

Come posso far comunicare il più efficacemente possibile applicazioni e sistemi eterogenei?

Le risposte dell’IT si sono evolute in parallelo con l’evoluzione della business organization.

INTRODUZIONE SOA (ARCHITETTURA SERVICE ORIENTED)

Deve fornire una piattaforma per costruire servizi applicativi aventi le seguenti caratteristiche:

- Loosely coupled
- Location transparent
- Protocol independent

L’utente di un servizio non deve preoccuparsi di scegliere con quali servizi comunicare: la scelta deve farla
l’infrastruttura, usando un Service Bus. L’infrastruttura deve nascondere al richiedente del servizio quanti
più dettagli tecnici possibili, relativi a tecnologie tra loro differenti come J2EE o .NET. Deve essere possibile
aggiornare in qualunque momento le implementazioni.

71
SVILUPPO TECNOLOGICO

• Analisi e design object-oriented

Si considera un problema e le sue soluzioni logiche usando oggetti (concetti, entità). Gli oggetti
sono caratterizzati da un certo numero di operazioni e da uno stato. Nell’analisi object oriented, gli
oggetti sono descritti nel dominio del problema. Nel design object oriented essi sono considerati
come componenti software da implementarsi in un linguaggio di programmazione object oriented

• Design component based

Gli oggetti sono a un livello di granularità troppo “fine” per consentire un facile riuso del software.
Le componenti sono “pezzi” di software a grana grossa, riusabili per realizzare software packages.

• Design service-oriented

Servizio: unità eseguibile di codice che fornisce l’incapsulamento di servizi correlati. L’accesso ai
servizi è possibile solo attraverso un’interfaccia pubblica consistente. Un componente del servizio
deve essere in grado di potersi connettere ad altri componenti (tramite un’interfaccia di
comunicazione). Un servizio è generalmente implementato come un componente software,
pubblicamente accessibile, a grana grossa, che esiste come singola istanza e interagisce con
applicazioni e con altri servizi.

- Servizi: entità logiche, i cui contratti sono definiti da una o più interfacce
- Service provider: entità software che implementa le specifiche di un servizio
- Service customer (o requestor): entità software che richiede il servizio, agendo come client
- Service locator: agisce come un “registry” e consente di individuare i servizi
- Service broker: entità software che può trasferire una richiesta ad un certo numero di
servizi

• Design interface based

- Interaccia: insieme di metodi pubblici, logicamente ragruppati ma che non forniscono


implementazione. Definisce un “contratto” tra il requestor e il provider del servizio. Ogni
implementazione di un’interfaccia deve implementarne tutti I metodi.

72
- Interfaccia pubblicata: Interfaccia univocamente identificata e resa disponibile tramite un registro
per i clients.
- Interfacce “duali”: frequentemente le interfacce sono sviluppate come coppie in modo che
un’interfaccia dipenda dalla sua duale. Es: un client deve implementare un’interfaccia per chiamare
un requestor perchè l’interfaccia client fornisce dei meccanismi di callback.

AccountManagement e ContentManagement sono interfacce pubblicate, mentre


SystemsManagement è un’interfaccia pubblica. SystemsManagement e ManagementService
formano un’interfaccia duale.

Un CRM service può implementare un numero qualunque di istanze di tali interfacce

• Architetture layered application

L’approccio “object oriented” è il modo migliore per implementare componenti, e l’approccio “component
based” è un’ottima soluzione per implementare servizi.Tuttavia un software puramente “component
based” non è necessariamente la scelta migliore per realizzare un service oriented system.

Occorre introdurre un addizionale “application layer che consenta un’efficace esposizione del servizio verso
il customer”.

73
STRUTTURA SOA (SERVICE ORIENTED ARCHITECHTURE)

Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented Architecture (SOA) si indica


generalmente un'architettura software adatta a supportare l'uso di servizi Web per garantire
l'interoperabilità tra diversi sistemi così da consentire l'utilizzo delle singole applicazioni come componenti
del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente.

Una SOA comprende due categorie di elementi:

- Funzionali
- Quality of service

ELEMENTI FUNZIONALI

Transport è il meccanismo usato per muovere le richieste di servizio dal service consumer al service
provider, e le risposte di servizio dal provider al consumer.

Service Communication Protocol è un meccanismo prestabilito che il consumer ed il provider usano per
comunicarsi cosa si sta chiedendo e cosa viene ritornato.

Service Description è uno schema prestabilito per descrivere cos’è il servizio, come deve essere invocato. E
quali dati sono richiesti per invocare il servizio con successo.

Service descrive un effettivo servizio disponibile per l’uso.

Business Process è una collezione di servizi, invocati in una particolare sequenza con un particolare insieme
di regole, per conseguire un particolare requisito di business.

Service Registry è un repository di servizi e di data descriptions che possono essere usate dai service
providers per pubblicare I loro servizi, e dai consumers per trovare servizi disponibili.

74
QUALITA’ DI SERVIZIO

Policy è un insieme di condizioni sotto le quali un provider rende disponibile il servizio ai consumers. Ci
sono aspetti della policy che sono funzionali, e aspetti relativi alla QoS, quindi abbiamo funzioni di policy sia
nelle aree funzionali e QoS.

Sicurezza è l’insieme delle regole che possono applicarsi all’identificazione, autorizzazione e controllo
dell’accesso dei consumers che invocano il servizio.

Transactions è l’insieme degli attributi che possono applicarsi a un gruppo di servizi per fornire un risultato
consistente.

Management è l’insieme degli attributi che devono essere applicati per gestire I servizi forniti o consumati.

RUOLI SOA

Service consumer: applicazione, modulo software o servizio che richiede un servizio. Inizia la ricerca del
servizio nel registry, si collega al servizio attraverso il trasporto ed esegue (invoca) la service function, in
accordo con l’interface contract.

Service provider: entità indirizzabile in rete, che accetta ed esegue richieste provenienti dal consumer.
Pubblica i servizi e le interface contract nel registry.

Service registry: Contiene il repository dei servizi, permette la ricerca e fornisce ai consumer le interface
contract dei provider.

Ogni entità SOA può assumere uno dei ruoli di cui sopra

Il consumer opera ricerche di servizi interrogando il service registry per servizi che soddisfano determinati
criteri. Se i servizi esistono, il registry fornisce al consumer l’interface contract e gli endpoint access dei
servizi.

75
OPERAZIONI SOA

Publish: perché un servizio sia disponibile, una service description deve essere pubblicata nel registry dal
provider

Find: un service requestor può cercare servizi che soddisfano determinati criteri nel registry

Bind and invoke: dopo aver trovato il servizio, questo può essere individuato e invocato usando le
informazioni fornite dal registry.

CARATTERISTICHE DEI SERVIZI SOAP

- I servizi sono modulari e self contained


- I servizi supportano l’interoperabilità
- I servizi sono debolmente accoppiati
- I servizi sono trasparenti rispetto alla locazione
- I servizi sono composti da moduli, compresi i componenti

Alcune implementazioni

Vantaggi soa:

• Valorizzazione delle risorse esistenti, grazie al livello di astrazione prodotto che consente di
continuare a sviluppare nuove soluzioni riusando materiale preesistente

• Facilità di integrazione: il punto di integrazione in SOA è al livello delle specifiche di servizio, così
garantendo massima trasparenza rispetto all’implementazione

• Alta reattività ai cambiamenti di mercato

• Costi ridotti grazie al riuso

76
SERVIZIO E COMPONENTE

Un servizio è un software coarse grained che consuma e produce insiemi di oggetti passati per valore. E’
differente da un oggetto nella OOP(Programmazione orientata agli oggetti). Consiste invece di una
collezione di componenti che lavorano insieme per fornire la business function che il servizio rappresenta.

I componenti sono entità a grana fine, che mappano le business entities e le business rules della business
function che il servizio rappresenta.

Esempio: approccio a componenti

APPROCCIO SERVICE ORIENTED

Nell’approccio a componenti, ogni componente corrisponde con una business entity (es. Customer,
Purchase Order, Item ecc.) ed incapsula il behaviour che ci si aspetta da quella componente.

In un approccio service oriented, un servizio non è creato in corrispondenza di una business entity.
Piuttosto, esso può essere visto come un manager di informazioni, capace di rispondere ad ogni richiesta
che riguarda le informazioni relative al servizio. In genere il servizio opera su un insieme di componenti che
è trasparente all’utente.

6.1) I web service

“Un Web service è un’applicazione software identificata da un’URI, le cui interfacce e collegamenti sono
passibili di essere definite, descritte e scoperte come documenti XML. Un Web service supporta interazioni
dirette con altri software agents usando messaggi XML-based scambiati attraverso protocolli Internet-
based.”

- Combinano i vantaggi di un linguaggio standard per la rappresentazione dei dati (XML) e di un


protocollo di trasporto supportato dalla maggior parte dei browsers e dei Web server (HTTP)
- Sono self contained
- Lato client, non è necessario nessun software addizionale. Basta un linguaggio di programmazione
che supporta XML e HTTP. Lato server, basta un Web server ed una servlet engine
- Sono self describing

77
Le tecnologie alla base dei Web services sono tutte “open standards”, quali:

– eXtensible Markup Language (XML)


– Simple Object Access Protocol (SOAP)
– Universal Description, Discovery and Integration (UDDI)
– Web Services Description Language (WSDL)

Né il client né il server devono preoccuparsi di nulla eccetto il formato e il contenuto dei messaggi di
richiesta e di risposta. La definizione del formato del messaggio viaggia con il messaggio stesso.
L’interazione tra un service requester ed un service provider è completamente indipendente da linguaggio
e piattaforma.

ESB (ENTERPRISE SERVICE BUS)

L’ESB è un'infrastruttura software che fornisce servizi di supporto a service-oriented architecture


complesse.I Web services sono ormai largamente diffusi in ambiente aziendale: diventa importante trovare
dei modi per disegnare business systems basati su Web services

L’ESB è un modello che consente di applicare la tecnologia dei WS alle applicazioni aziendali

I WS di base, che sfruttano SOAP e HTTP, forniscono un solido supporto all’implementazione di architetture
SOA. Tuttavia ci sono diverse problematiche da affrontare quando l’applicazione è su scala d’impresa.

Obiettivi:

Fornire una virtualizzazione delle risorse aziendali, permettendo che la business logic aziendale possa
svilupparsi indipendentemente dall’infrastruttura software e dalla rete.

Implementare un ESB richiede un insieme di servizi middleware. I servizi middleware in ESB devono fornire:

Middleware di comunicazione che supporti una varietà di paradigmi di comunicazione (synchronous,


asynchronous, request/reply, one-way,call-back), di qualità del servizio (security, guaranteed delivery,
performance, transactional),

Un meccanismo per introdurre elaborazione intelligente delle richieste di servizio “in-flight” Standard-
based tools per consentire l’integrazione rapida dei servizi.

Un Management system per applicazioni loosely-coupled e per consentire la loro interazione.

78
IBM

L'International Business Machines Corporation, che è comunemente nota e commercializza i propri


prodotti come IBM, e soprannominata "Big Blue"[2], è un'azienda statunitense, tra le maggiori al mondo[3]
nel settore informatico IBM produce e commercializza hardware e software.

79
PATTERNS PER L’E-BUISNESS
7.0) I livelli dei patterns

Soluzioni aziendali già esistenti, strutturate a layer. Consentono il riuso di software concepito per risolvere
una data tipologia di problemi.

Ogni livello di dettaglio è costruito sul livello precedente

Per esempio, la collezione di Pattern IBM comprende sette livelli:

1.0) Business patterns: identificano le interazioni tra utenti, business e dati.

2.0) Integration patterns: collegano più Business patterns


3.0) Composite patterns: rappresentano combinazioni di Business ed Integration patterns di usale
ricorrenza
4.0) Application patterns: Forniscono un layer concettuale che descrive come interagiscono le
componenti applicative e I dati in un Business o Integration pattern
5.0) Runtime patterns: definiscono la struttura logica middleware che supporta un Application pattern.
6.0) Product mappings: identifica implementazioni software provate e testate per ogni Runtime pattern.
7.0) Best-practice guidelines: guidano nello sviluppo.

80
APPROCCIO SOA E PATTERNS

8.0) Descrizione dell’approccio SOA

L’importanza di SOA non è solo a livelli tecnologico. Essa fornisce un ponte tra tecnologia e business. L’IT
fornisce interfacce ai business service e li combina in applicazioni che supportano i rapidi cambiamenti del
business stesso. Identificare l’insieme di servizi che un business richiede al proprio IT non è semplice. E’
necessaria un’attività specifica (Service Identification) che determini i servizi e le loro interdipendenze, così
come i componenti a “grana grossa” che li supportano.

• Il Self-Service business pattern permette agli utenti di interagire con i business services.

• Il Collaboration pattern permette le collaborazioni tra business partners che in parte coinvolgono
l’integrazione di servizi e in parte coinvolgono persone e workflow

• L’Extended Enterprise business pattern permette ad un business di interagire con altri business
services.

• Questi Business patterns sono combinati al front-end usando Access Integration pattern e al back-
end usando Application Integration pattern.

PASSI DELL’APPROCCIO SOAP

Metodo:

- per scoprire servizi (top down)


- per sfruttare servizi esistenti (bottom up)

Sette step principali:

81
Il processo inizia quando il business problem suggerisce l’uso di un approccio service oriented. Tipici
candidati sono i business problem che necessitano l’esposizione di un back office verso l’esterno
dell’azienda. L’aspetto top down si evidenzia col prendere in considerazioni le prospettive di business
aziendale: le business functions, i processi ed i sottoprocessi sono elaborati per delineare le componenti
software

DOMAIN DECOMPOSITION

Il dominio è suddiviso in

- Value chain
- Business processes
- Sub processes
- Use cases

Il dominio consiste di una serie di aree funzionali, lungo le dimensioni chiamate value-net o value-chain. Noi
possiamo usare gli use cases per decomporre ulteriormente il dominio.

Gli use cases identificati sono buoni candidati ad essere servizi che dovranno essere “esposti” come Web
services su componenti aziendali.

APPLICAZIONI DEI PATTERN

Ad ogni passo dell’approccio SOA, è possibile sfruttare assets provenienti da esistenti Patterns per e
Business

• Si inizia con i Business Patterns, per definire i partecipanti al business e le loro relazioni, usando le
aree funzionali e gli use cases identificati nella domain decomposition

• Possiamo anche usare l’Application Integration pattern per integrare i service consumers ed i
service providers nella supply value chain

• Inoltre possiamo usare l’Extended Business Pattern per i service consumers ed i service providers ai
“confini” aziendali

Annotazione:

• (Per l’interazione tra i servizi interni all’organizzazione, è utilizzato il Direct Connection runtime
pattern. I connettori forniscono la connettività tra due componenti

• L’Exposed Direct Connection runtime pattern fornisce la connettività per i servizi esterni.

SUB-SYSTEM ANALYSIS

Dopo aver completato i due step precedenti, abbiamo un’idea delle aree funzionali di cui si compone il
nostro business domain. Adesso vogliamo muoverci verso decisioni di “design” e architetturali. La sub
system analysis raffina i business use cases in system use cases che supportano un dato processo di
business

Durante questa analisi i componenti “business” e tecnici sono identificati come segue:

82
• Si analizza il flusso di processo del sottosistema (spesso una sequenza di use case) per
scoprire/identificare dei componenti business “candidati”

• Si utilizzano requisiti non funzionali per identificare componenti tecniche

• Si identificano le funzionalità richieste per ogni componente business, cioè gli use cases a livello di
sistema che il componente deve supportare

SERVICE ALLOCATION

Dopo aver identificato i servizi tramite una combinazione di domain decomposition e goal-service
modeling, adesso vogliamo assicurarci che ogni servizio abbia un corretto “posizionamento”

COMPONENT SPECIFICATION

Con la component specification per ogni componente occorre specificare le proprietà e le regole che
devono soddisfare

83
I WEB SERVICE E IL SOAP (SIMPLE OBJECT ACCESS PROTOCOL)

9.0) I WS (Web Service)

• Un WS è un’interfaccia accessibile in rete per funzionalità applicative, costruita utilizzando


tecnologie Internet standard

• In altre parole, se un’applicazione è tale che si può accedere ad essa tramite una combinazione di
protocolli Internet standard come HTTP, XML, SMTP, allora quell’applicazione è un Web Service

• La forma più comune di WS è quella di chiamare procedure in esecuzione su un server, tramite


messaggi del tipo “chiama questa procedura con questi argomenti” oppure “questo è il risultato
della chiamata della procedura”

• Il Service Listener è in grado di comprendere i protocolli (HTTP, SOAP, Jabber, etc.) e sta in ascolto
dei messaggi di richiesta

• Il Service Proxy può elaborare una risposta per il Service Listener (ma può anche non esserci)

• I WS non richiedono il tradizionale modello Client Server per le applicazioni, né richiedono un


modello architetturale n-tier.

Annotazioni:

Buisness vs Programmazzione:

Il Business richiede efficacia, sicurezza, affidabilità, mentre la programmazione ha come obiettivo


l’efficienza, la semplicità e la robustezza.

INTEGRAZIONE JUST-IN-TIME

• L’integrazione JIT consente di innestare il modello di distribuzione delle applicazioni Internet sul
modello chiamato “Architettura WS”

• Il service provider pubblica una descrizione dei servizi che offre attraverso il service registry

• Il service consumer cerca nel service registry i servizi che soddisfano le sue necessità

• Il consumer può essere una persona o un programma

• Il binding (In informatica il binding è il processo tramite cui viene effettuato il collegamento fra una
entità di un software ed il suo corrispettivo valore. Nei termini della programmazione a oggetti, la
decisione circa l'attributo o il metodo da richiamare in un dato momento dell'esecuzione del

84
programma viene effettuata grazie al binding) fa riferimento a un consumer che sta realmente
utilizzando un servizio offerto da un provider.

• La chiave per l’integrazione JIT è che essa può avvenire in qualunque momento, anche a runtime,
come nell’early binding della OOP.

• Il client potrebbe cioè non conoscere quali procedure chiamerà fino a quando non viene eseguita la
ricerca del servizio e si trova il candidato adatto

ARCHITETTURA DI UN WEB SERVICE

I layer addizionali packaging, description e discovery sono essenziali per fornire l’integrazione JIT. I layer
dello stack WS non ricoprono tutte le problematiche possibili. Per esempio, non danno soluzione ai
problemi di sicurezza, privacy, trust, workflow e molti altri

• Intervengono quindi altri standard quali:

– XML (alternativa a SOAP)

– XKMS (sicurezza)

– SAML (sicurezza)

– XML Dsig (firma digitale)

– XML Enc (crypting)

– XSD (ontologie)

– P3P (privacy)

– WSFL (workflow)

– Jabber (Peer to peer)

85
LAYER 1 DISCOVERY

• Il layer Discovery fornisce i meccanismi che permettono al client di scoprire le descrizioni dei servizi
dei provider

• Uno degli standard più largamente diffusi in questo contesto è l’Universal Description Discovery
and Integration (UDDI)

LAYER 2 DESCRIPTION

• Quando un WS è implementato, occorre prendere delle decisioni su come supporterà i protocolli di


network, transport e packaging

• Una descrizione del servizio rappresenta queste decisioni

• Il Web Service Description Language (WSDL) è lo standard de facto in questo contesto

LAYER 3 PACKAGING

• Affinchè i dati delle applicazioni possono muoversi attraverso la rete mediante il livello di trasporto,
essi devono essere “impacchettati” in un formato comprensibile da ognuno degli attori coinvolti

SOAP è un formato di packaging molto comune, costruito su XML.

LAYER 4 TRASPORT

• Il livello di trasporto include le varie tecnologie che permettono la comunicazione application-to-


application

• Alcuni protocolli utilizzati sono TCP, HTTP, SMTP e Jabber

La scelta del protocollo di trasporto da utilizzare dipende dalle esigenze specifiche. HTTP ad esempio
include il servizio firewall più ubiquo, ma non supporta la comunicazione asincrona.

LAYER 5 NETWORK

• Il livello Network è lo stesso che nel modello TCP/IP

• Fornisce le principali funzionalità per l’addressing ed il routing su rete

Annotazioni:

Il Modello Peer Services:

Rappresenta una visione alternativa dei WS, La principale differenza è che nei sistemi P2P il ruolo di
consumer e provider è molto interscambiabile, mentre nei WS la differenza è solitamente netta.

86
9.1) Il protocollo SOAP

E’ un protocollo standard di packaging per i messaggi che si scambiano le applicazioni. La specifica


definisce niente più che una semplice busta basata su XML per le informazioni(un messaggio può
essere qualunque cosa, un catalogo, richiesta di acquisto etc….) che vengono trasferite, ed un
insieme di regole per la traduzione dei tipi di dati delle applicazioni in rappresentazioni XML

SOAP ha due applicazioni possibili: RPC e EDI

• Remote Procedure Call (RPC) è un meccanismo che permette a metodi che girano su macchine
diverse di “chiamarsi” a vicenda scambiandosi dei parametri

• Electronic Document Interchange (EDI) definisce un formato standard per documenti e messaggi
finanziari e commerciali

• Si può usare un “document style” SOAP basato su EDI, con XML che rappresenterà ordini, tabelle
fiscali e documenti simili. Oppure usare un “RPC style” SOAP basato su RPC dove XML
rappresenterà argomenti per metodi o valori di ritorno

LA CODIFICA NEL PROTOCOLLO SOAP

Oltre a dire che stiamo usando XML, dobbiamo definire:

– Il tipo di informazione che stiamo scambiando

– Come l’informazione viene espressa in XML

– Come inviare realmente l’informazione

Senza tali informazioni, le applicazioni non saprebbero decodificare i messaggi, anche sapendo che essi
sono codificati in XML. SOAP fornisce questo tipo di informazioni

MESSAGGI SOAP

Un messaggio SOAP consiste di una busta contenente un header (opzionale) e un body (richiesto)

• L’header contiene blocchi di informazione che indicano come il messaggio deve essere processato
(settaggi sul routing e sulla delivery, asserzioni di autenticazione e autorizzazione, e contesti di
transazione)

• Il body contiene il messaggio vero e proprio. Qualunque cosa possa essere espressa in XML può
andare nel body di un messaggio.

Ogni messaggio possiede l’elemento “contenitore” s:envelope, l’elemento opzionale s:Header e l’elemento
obbligatorio “s:Body”. Ogni envelope può contenere esattamente un elemento Body. Il contenuto
dell’elemento Body, che può essere composto da un qualunque numero di sottoelementi, rappresenta il
messaggio vero e proprio. Ogni envelope può contenere al massimo un Header, che se esiste deve apparire
come il primo “figlio” di envelope

Il proposito di un header è quello di comunicare informazioni contestuali utili per processare un messaggio
(ad esempio, credenziali di autenticazione).

87
WEB SERVICE E IMPLEMENTAZIONE CON PROTOCOLLO SOAP

Esempi di implementazioni WS:

Apache SOAP per Java

SOAP::Lite per Perl

Microsoft .NET

Ricordiamo che un WS si compone di:

- Un listener che resta in attesa di messaggi


- Un proxy che prende il messaggio e lo traduce in qualcosa da fare (ad esempio invocare un metodo
su un oggetto Java)
- Un application code

Cerchiamo di fare in modo che l’application code non sia a conoscenza dell’esistenza del listener e del
proxy, anzi che non sia affatto a conoscenza di essere invocato dall’interfaccia di un WS (non sempre è
possibile).

GESTIRE I MESSAGGI SOAP

L’integrazione di SOAP con i vari toolkit varia con il livello di trasporto

Alcuni implementano i loro server HTTP

In altri casi, il “demone” HTTP passa il messaggio al proxy, che si prende cura di invocare l’application code.

• Il proxy deve effettuare tre azioni:

– Se necessario, “deserializzare” il messaggio, da XML a qualche formato nativo adatto per


consentire l’invocazione del codice
88
– Serializzare la risposta in XML e passarla al listener che si occuperà di trasmetterla al
richiedente

– A prescindere dalle varie implementazioni, tutti i toolkit SOAP prevedono per il proxy questi
semplici passi

• Deploying un WS significa dire al componente proxy quale tipo di codice deve essere invocato
quando viene ricevuto un particolare tipo di messaggio

89
WSDL (WEB SERVICE DESCRIPTION LENGUAGE)
10.0) WSDL

• I Web Services Description Language è il formato utilizzato per descrivere le interfacce dei web
service.

• Rappresentano un modo di descrivere servizi e come questi sono limitati a specifici indirizzi di rete.

• WSDL ha tre parti fondamentali:

1. Definizioni…

– generalmente espressi in XML includono sia le definizioni dei data type, che quelle dei
messaggi.

2. Operazioni…

– descrivono le azioni per i messaggi supportati dai web service.

– Ci sono quattro tipi di operazioni:

• 2.1) One-way -> i messaggi vengono inviati senza una risposta di ritorno.

• 2.2) Request/response -> il sender invia un messaggio e quando lo riceve invia un


risposta.

• 2.3) Solicit response -> si richiede una risposta.

• 2.4) Notification -> i messaggi inviati a più receiver.

– Le operazioni sono raggruppate in port type, ovvero un insieme di operazioni supportate


dai web service.

3. Legami tra i servizi…

– consente la connessione tra port type e port.

Binding

Operation

Data Type

90
- La descrizione WSDL deve essere disponibile a entrambi gli attori (chi richiede il servizio e chi lo
fornisce) di una transizione WS.
- Il binding consente di associare a messaggi o operazioni uno o più meccanismi di trasporto.

WSDL è progettato come una piattaforma XML estensibile per gestire diversi tipi di dato, operazioni,
protocolli di trasporto e definizione di messaggi.

Annotazioni:

WSDL non è legato a nessun protocollo di trasporto particolare, ma può essere utilizzato con protocolli
differenti

WSDL privilegia SOAP, indicando, in una delle sue specifiche (estensioni) le modalità di collegamento a
questo standard. L’utilizzo di WSDL con altri protocolli richiede la definizione di un’estensione WSDL
specifica adatta e la conseguente costruzione di documenti WSDL conformi a tali specifiche.

ELEMENTI PRINCIPALI DI WSDL

• Un documento WSDL utilizza i seguenti elementi per descrivere un servizio (solo 5 figli di
definitions):

– types: rappresenta la sezione dove definire i tipi di dati attraverso un linguaggio come
XMLSchema. WSDL non si occupa di definire i tipi.

– message: contiene la dichiarazione dei messaggi (e i relativi tipi) che possono essere
utilizzati nelle operazioni.

– operation: rappresenta la descrizione astratta di un’azione supportata dal WS.

– portType: rappresenta un insieme di operazioni supportate dal WS.

– binding: definisce un protocollo da utilizzare per un particolare port type.

– port: definisce un singolo endpoint attraverso l’associazione di un binding e di un indirizzo


di rete.

– service: un insieme di endpoint correlati.

UDDI
UDDI (acronimo di Universal Description Discovery and Integration) è un registry (ovvero una base
dati ordinata e indicizzata), basato su XML e indipendente dalla piattaforma hardware, che permette
alle aziende la pubblicazione dei propri dati e dei servizi offerti su internet.

91
APPLICAZIONI WEB
11.0) I livelli di una applicazione web

Un’applicazione Web si sviluppa su tre livelli logici:

– Presentazione: Il livello di presentazione costituisce l’interfaccia utente dell’applicazione


Web e corrisponde al client.

– Intermedio:Il livello intermedio di un’applicazione Web corrisponde alla componente


elaborativa dell’applicazione

– dati: Il livello di presentazione costituisce l’interfaccia utente dell’applicazione Web e


corrisponde al client.

Non sempre i livelli logici di un’applicazione Web corrispondono a locazioni fisiche sulla rete

TIPI DI TECNOLOGIE

92
I SOCIAL NETWORK

12.0) I social network

Una social network è una descrizione di una struttura sociale fra attori, principalmente individui o
organizzazioni. Essa specifica il modo in cui gli attori sono connessi attraverso viarie relazioni sociali,
che vanno da conoscenze causali fino a rapporti parentali.

RETE SOCIALE

Si definisce una “rete sociale” come un gruppo di persone connesse da legami sociali
(principalmente conoscenze, lavoro e famiglia)

Fondato nel 2004 da Mark Zuckerberg, Facebook era originariamente utilizzato e limitato nell’ambito del
campus universitario di Harvard come rete sociale

Aperto a tutti nel 2006 (>13 anni)

E’ oggi il primo social network del mondo per numero di accessi.

SOCIAL NETWORK ANALYSIS

La Social network analysis [SNA] consiste nel mappare e misurare relazioni e flussi tra persone, gruppi,
organizzazioni, computers ed altre entità informative

I nodi della rete sono le persone ed I gruppi mentre gli archi mostrano relazioni o flussi tra I nodi.

I metodi di misura dei social network hanno lo scopo di studiare diverse proprietà:

Centralità, coesione …

Coefficienti di clustering ('cliquishness‘) …

Coefficienti strutturali …

93