Sistemi distribuiti

SISTEMI DISTRIBUITI (Prof. De Paoli – Unimib)
ARCHITETTURA DEL WEB Web è una architettura software di client-server che comunicano con HTTP. Server
spesso sono chiamati web server o HTTP server. HTTP caratterizza le applicazioni WEB dalle altre: il WEB è
HTTP, non INTERNET. Il client (o user agent) è lo strumento a disposizione dell'utente, gli permette l'accesso e
la navigazione nell'ipertesto del Web. Esso: trasmette all'opportuno server le richieste di reperimento dati
che derivano dalle azioni dell'utente; riceve dal server le informazioni richieste; visualizza il contenuto della
pagina Web richiesta dall'utente gestendo in modo appropriato tutte le tipologie di informazioni in esse
contenute; consente operazioni locali sulle informazioni ricevute. I client usano I browser per navigare.
Browser dunque è una applicazione client che utilizza il protocollo HTTP per inoltrare le richieste dell’utente
ad un web server. Interpreta codice in cui sono espresse le informazioni (pagina web) e lo visualizza in forma
di ipertesto. È caratterizzato dalla capacità di “parlare” con HTTP. Consente la navigazione. Qualsiasi
software che usa HTTP è un browser. In sintesi browser: chiede documenti a un server tramite HTTP +
rendering (resa grafica di tali documenti à motore di rendering: parte del browser che si occupa di
mostarare a video le pagine secondo le specifiche proprie dello strumento – pc, smartphone, ecc). Client
invia domanda a server (HTTP request) componente attivo/server risponde alla domanda del client (HTTP
response) fornisce il servizio al client, è componente passivo perchè risponde alle azioni fatte dal client.
PAGINA WEB è costituita da diversi oggetti (file) è memorizzata su un server ed identificata da un URL
(inidirizzo univoco per la risorsa) quindi 1FILE = 1URL. La maggior parte delle pagine web sono costituite da
un file HTML che definisce struttura e contenuti testuali della pagina + altri oggetti aggiuntivi. HTML (Hyper
Text Markup Language) linguaggio di tipo statico utilizzato per la realizzazione dei contenuti di una pagina
web. Utilizza dei tag per indicare a un browser come deve interpretare e visualizzare l'ipertesto (permette di
definire l’aspetto della pagina, link, ecc). Quindi linguaggio HTML permette di definire la presentazione del
documento nonché dei link ipertestuali verso altri documenti attraverso dei tag di formattazioneIPERTESTO
insieme di testi (o pagine) leggibili tramite interfaccia elettronica in maniera non sequenziale, tramite
hyperlink (o link) che costituiscono I collegamenti tra un testo (o pag) e un altro. LINGUAGGI DEL WEB la
parte testuale dei documenti è espressa con linguaggi standard: 1) HTML (focus su PRESENTAZIONE DEI DATI,
imaginazione): CSS, HTML DINAMICO, ecc. 2) XML (focus su DATI E LORO STRUTTURA): XSL, RDF. 3)
LINGUAGGI DI SCRIPTING (arricchiscono interazione): JAVASCRIPT, VBSCRIPT. INTERNET rete di reti, a livello
mondiale, che interagiscono. Ha struttura parzialmente gerarchica, composta appunto da reti, diverse
(locali, regionali, nazionali, ecc che devono essere collegate e “parlare”). Non c’è grande controllo, in
questo modo ogni rete può crescere e/o evolversi. È composto da segmenti pubblici e intranet private.
BLACKBONE è Il livello gerarchicamente più alto dell’architettura di una rete. E' una linea di connessione ad
alta velocità' che connette le reti di velocità e capacità inferiore tra di loro. Tipicamente canali in fibra
ottica, controllate da provider nazionali/internazionali. STRUTTURA RETE: 1) host end-system: dispositivi (pc,
smartphone, ecc) collegati, eseguono applicazioni di rete (es. broweser) 2) mezzi trasmissivi: rame, fibra
ottica, ecc. 3) router. I protocolli regolano la comunicazione tra sistemi (ex. TCP, IP). STANDARD INTERNET:
RFC request for comments; IETF internet engineering task force. La rete di comunicazione permette di
eseguire applicazioni (www, mail, giochi, ecc). Comunicazione basata sul concetto di protocollo. I
protocolli di rete coivolgono la macchina e governano tutte le comunicazioni in internet (tra macchine).
PROTOCOLLI [*pag.5]: definiscono il formato, l’ordine di invio e di ricezione dei msg tra dispositivi e azioni
prese quando si riceve un msg. 5 LIVELLI DI PROTOCOLLO: per dare una struttura ai protocolli è stata
adottata un’architettura a livelli, ogni protocollo appartiene a uno o più livelli. Ogni livello possiede un
service model: ogni livello usa i servizi del livello immediatamente inferiore per fornire il proprio servizio,
effettuando determinate azioni all’interno del proprio livello. La stratificazione ha come vantaggio il fatto
che fornisce un modo strutturato per trattare I componenti dei sistemi. Come svantaggio potenziale c’è il
fatto che due livelli possono duplicare le funzionalità o, ancora, un livello può richiedere info presenti solo in
un altro livello. Protocol stack è l’insieme dei protocolli dei vari livelli. I livelli sono: 1) di applicazione Sede
delle applicazioni di rete e dei relativi protocolli. Appartengono: HTTP, FTP, SMTP, DNS, POP. 2) di trasporto
Trasferisce i msg a livello di applicazione tra modulo client e server di un’applicazione. Nelle reti sono 2: TCP
(permette un controllo della congestione) e UDP (fornisce un servizio senza connessioni, non controlla
congestione). 3) di rete Trasferisce I pacchetti a livello di rete; generalmente incapsula I msg del livello
precedente in datagrammi dotati di un network layer header. Questo livello possiede un protocollo, detto
IP, che definisce I campi del datagramma + come I sistemi terminali e I router possono agire su tali campi.

(protocolli aggiuntivi in questo livello: protocolli di instradamento). 4) di collegamento Instrada un
datagramma attraverso una serie di commutatori di pacchetto (= router) tra l’origine e la destinazione. A
ogni nodo della rete i datigrammi entrano dal liv inferiore (fisico) salgono a quello di collegamento che li
instrada al nuovo nodo o sistema terminale, passando di nuovo il pacchetto al livello precedente (fisico,
che li spedisce). 5) fisico trasferisce I singoli bit da un nodo a quello successivo e dipende dall’effettivo
mezzo trasmissivo. LIVELLO APPLICATIVO è sede delle applicazioni e dei loro relativi protocolli à applicazioni
sono processi distribuiti in comunicazione, in esecuzione su host remoti; si scambiano msg per eseguire
l’applicazione; es. posta, FTP, www. Un processo è un programma in esecuzione su un host. Sullo stesso host:
comunicano mediante meccanismi definiti dal SO. Processi in comunicazione su host diversi: comunicano
mediante meccanismi definiti dal protocollo dello starto di applicazione (HTTP). User agent è l’interfaccia
tra utente e applicazione di rete. Un programma è una sequenza di istruzioni eseguibili dalle “macchine”
(fisiche o virtuali) e I processi sono entità gestite dal SO e costituiti da: area di memoria ram per effettuare le
operazioni e memorizzare i dati + registro che ricorda la prossima istruzione da eseguire + canali di
comunicazione. Ogni processo comunica tramite I canali: canale gestisce I flussi di dati in ingresso/uscita;
canale: schermo, tastiera, rete, ecc; dall’esterno ogni canale è identificato da un numero intero
detto”porta”. Per il SO tutti I processi sono uguali. Il SO attiva un processo che andrà a lanciare un
programma, ma tutti questi processi per il SO sono identici. Applicazione di rete tipica è divisa in 2 parti:
client e server. Client inizia dialogo col server (speaks first), di solito richiede un servizio; nel caso del web il
client è integrato nel browser. Server fornisce il servizio al client, su richiesta. URL Uniform Resource Locator
servono a “identificare” quello con cui si vuole comunicare (indirizzo della risorsa). IP ADDRESS identifica
l’host su cui l’altro processo è in esecuzione; PORT NUMBER permette all’host ricevente di identificare il
processo locale destinatario del msg (il programma a cui bisogna dare i dati). URL quindi identifica un
oggetto nella rete e specifica il modo per accedere ad esso: protocollo. Ha tre componenti: nome del
protocollo, indirizzo dell’host (IP+PORTA) e percorso nell’host. Protocollo://indirizzo_IP [:porta]/cammino/file.
La porta è opzionale PROTOCOLLO HTTP è un protocollo di livello
applicativo; usa il modello client/server. Client: browser che richiede,
riceve e visualizza oggetti web. Server: web server che invia oggetti
in risposta alle richieste. HTTP request, formato pacchetto e
specifiche: 1) request line method/sp/url/version/cr/lf à request line
identifica una request HTML. A)Metodi (tipo di operazioni che client
richiede al server) GET usato per richiedere una pag web; POST
usato quando utente compila una form – contenuto dei campi è
posto nell’entity body. Comando serve per richiedere una pag web
il cui contenuto dipende da info inviate dal client, nel body. HEAD
come il get ma viene restituito solo l’head della pagina web. B)Carattere spaziale C)URL richiesta
D)Versione HTTP (es. 1.1) E)Carriage return e F)Line Feed sono due caratteri speciali. 2) Header line: righe
testuali free-format che specificano caratteristiche. Sono di molti tipi e possono essere più o meno
numerose. Formato generale è “header name : valore (es. User agent : Mozzila/4.0. 3) + cr/lf e altre
ipotetiche righe di header. Tra header e body c’è sempre una riga vuota (composta da cr/lf) sia nelle HTTP
request che response. 3) Entity body è opzionale, campo contenente dati (es. documento richiesto dal
client). HTTP response, formato pacchetto e specifiche: 1) response line, identifica una HTML response –
protocol/sp/status code/sp/status phrase/cr/lf. A)protocol identifica la versione del protocollo usata
B)codice dello stato (200 OK: Successo, oggetto richiesto più avanti nel messaggio. 301 Moved
Permanently: L’oggetto richiesto è stato spostato. Il nuovo indirizzo è specificato più avanti. 400 Bad
Request: Richiesta incomprensibile al server. 404 Not Found: Il documento non è stato trovato sul server. 505
HTTP Version Not Supported). C)significato del codice di stato. 2) Headers line: insieme di linee facoltative
che permettono di dare delle info supplementari sulla risposta e/o il server. Formato generale è “Header
name: valore”. 3) Body contiene il documento richiesto. // HTTP per funzionare si basa su TCP: il client inizia
una connessione TCP (crea una socket) verso il server (sulla porta 80); il server accetta la connessione TCP
dal client; scambio di msg HTTP tra browser (che è il client HTTP) e il web server (che è il server HTTP);
connessione viene chiusa. HTTP è stateless: server non mantiene informazioni sulle richieste precedenti del
client, ogni richiesta è indipendente da quelle precedenti e si conclude al momento della chiusura della
connessione (I protocolli che mantengono le info sono complessi). Il server web quindi non ha "memoria" di
quanto comunicato precedentemente con un certo client: per questo motivo, per realizzare applicazioni
web complesse, sono stati sviluppati meccanismi a livello superiore come i cookies per costruire "sessioni" e
permettere al server di recuperare informazioni riguardanti un certo client. Es. Utente accede alla url

www.someSchool.edu/someDepartment/home.index (testo + riferimenti a 10 jpeg) à [PARTE CLIENT 1]
apertura connessione TCP verso il server (processo) http sull’host www.someSchool.edu. Porta standard: 80
[PARTE SERVER 2] Il server http presso l’ host www.someSchool.edu è “in ascolto” sulla porta 80. Accetta la
richiesta di connessione e ne dà conferma al client [PARTE CLIENT 3] client invia una HTTP REQUEST
contenente la url desiderata. [PARTE SERVER 4] server http riceve il messaggio di richiesta, costruisce un
messaggio di rispota (response message) contenente l’oggetto richiesto (someDepartment/ home.index),
invia il messaggio. Chiude connessione. [PARTE CLIENT 5] ricezione msg di risposta contente il file HTML,
visualizzazione pagina. Si accorge che ci sono I riferimenti a 10 immagini: ripete I passi 1-4 per ogni
immagine. HTTP interagisce con server tramite METODI (o comandi): GET (Restituisce una rappresentazione
di unarisorsa; è una operazione safe: può essere ripetuta senza conseguenze; può essere gestita con una
cache) Conditional GET (nell’head di una richiesta si possono inserire condizioni sulla restituzione della
risorsa: If-Modified-Since) Partial GET (usando il campo Range nell’head di un msg ottengo solo una parte
della risorsa; Conditional e partial GET riducono il traffico inutile di rete) HEAD (come la GET ma non deve
includere un body nella risposta) POST (crea una nuova risorsa come figlia di una risorsa esistente, indicata
dalla URI associata; La risposta è 201 e il campo Location indica l’URI della nuova risorsa; NON è in generale
gestibile con una cache) PUT aggiorna una risorsa o crea una risorsa in una particolare destinazione; è
idempotente: se la eseguo più volte ottengo sempre lo stesso risultato) DELETE (Elimina una risorsa, è
idempotente, non è safe) OPTIONS (permette ricevere informazioni - possibilità e requisiti – su una risorsa o
sul server, quindi di “scoprire” come operare. es: le operazioni che si possono eseguire). HEADER: con
header si gestisce accesso ad un url che richiede autenticazione da parte dell’utente. Obiettivo:
controllare l’accesso ai documenti sul server (email, form, ecc). Autenticazione tipicamente viene fatta
tramite log (nick e password). Si introduce nell’header la riga “authorization”. Se utente non si autentica,
server rifiuta connessione. Problema: HTTP è stateless. Utente dovrebbe autenticarsi ogni volta. Si risolve con
COOKIE (stringhe di carattere restituite dal server insieme alle risposte, nell’header del msg HTTP di risposta)
Server invia un cookie al client con la risposta in caso di autenticazione avvenuta con successo. Il server
memorizza le credenziali dell’utente. Ad accessi successivi, client presenta cookie che viene controllato dal
server in cerca di autenticazione precedente + traccia delle preferenze dell’utente. Si usa la GET
condizionale per inviare all’utente solo “dati nuovi” cioè: client comunica data dell’ultimo oggetto che ha
in memoria (If-modified-since: <date>) e server risponde inviando il/i nuovo/i documento/I o risposta vuota
se non ci sono aggiornamenti. Per fare queste operazioni si usano le FORM: [definizione, in relazione a
tecnologie lato server più avanti: I form sono pagine web composte da testo e "campi" che l'utente può
riempire; è un eccellete modo di raccogliere informazioni sulle persone che visitano il sito, permettendogli,
così, di interagire con esso. I Form sono scritti in HTML e, normalmente, processati da tecnologia lato server
ASP JSP PHP CGI ecc.. L'output può essere mandato sotto forma di e-mail, memorizzato on line, stampato,
e/o rimandato all'utente come pagina HTML] si usa uno dei due metodi di invio dati, GET o POST + si usano
caselle di testo di vario tipo (text, password, ecc) per l’autenticazione + si usano checkbox/radio button per
eventuali ulteriori comunicazioni + si usano tasti (es. Submit) per inviare le comunicazioni. LIMITI DI HTTP A
CARATTERI: Utilizzo dell’interfaccia browser (uso di FORM); lentezza: occorre tradurre e ritradurre i dati;
costruzione delle pagine HTML in risposta; essendo stateless ogni richiesta è un messaggio autonomo; per
creare sessioni di lavoro (legare più richieste tra loro) occorre includere informazioni con mezzi espliciti,
campi nascosti e cookie. POSTA ELETTRONICA 3 componenti base: 1) user agent – client di posta che
permette di leggere/ricevere/scrivere email. I msg in ingresso/uscita vengono memorizzati su 2) mail server –
contiene msg e permette traffico delle mail; nello specifico: contiene I msg ricevuti (mail box); coda dei
msg in uscita; 3) protocollo SMTP, che permette al mail server di scambiarsi I msg di posta fin quando non
arrivano al servere di posta finale. USER AGENT MITTENTE à MAIL SERVER1 à(SMPT)à MAIL SERVER 2
à(IMAP/POP3)à USER AGENT RICEVE. User agent mittente, invia il msg al mail server 1 e qui viene messo
nella coda dei msg in uscita. Mail server 1 apre connessione SMTP con mail server 2; se contatto fallisce ci si
riprova (ogni 30 minuti, se fallisce per giorni si manda un msg di notifica a user agent mittente) se contatto
riesce ok. Mail server 2 (ricevente) riceve msg inviato via SMTP e lo mette nella mail box in attesa di lettura.
User agent può accedere tramite protoccolo IMAP o POP3. PROTOCOLLO SMTP utilizza TCP sulla porta 25
pe ril trasferimento affidabile dei msg tra server. Interazione avviene tramite comandi/risposte. 3 fasi: 1)
handshaking: saluto, creacione connessione 2) trasferimento di 1 o più msg. sfruttando connessione 3)
chiusura connessione. Formato usato: comandi = testo ASCII a 7 bit; risposta = testo ASCII a 7 bit (codice di
stato e frase); MSG = testo ASCII a 7 bit (anche se contengono dati multimediali). In sintesi: SMPT usa
connessione TCP persistente; richiede che il msg (header e body) sia in formato ASCII a 7 bit; alcune
sequenze di caratteri non sono consentite nel msg (es. CRLF) questo implica la necessità di codificare il msg.

il server SMTP usa CRLF.CRLF per terminare il msg. CONFRONTO SMTP/HTTP: HTTP è pull, il client chiede I dati
(“tira” la richiesta) SMTP è push, c’è un unico trasferimento, non fa richieste (“spinge” dati). Entrambi usano
msg in ASCII a 7 bit per comandi/risposte. In HTTP ogni oggetto è incapsulato nel msg di risposta, in SMTP si
usa la frammentazione dei msg per inviare un msg con più oggetti. FORMATO MSG SMTP: header (to; from;
subject) + linea vuota + body (msg vero e proprio in ASCII a 7 bit). MIME Multipurpose Internet Mail
Extension: Qualifica dati multimediali e di specifiche applicazioni. Permette quindi il riconoscimento/invio di
file del tipo: Text (plain, html) Image (jpeg, gif) Audio (basic, 32kadpcm) Video (mpeg, quicktime)
Application (dati che devono essere processati da un’applicazione prima di essere “visibili” es. msword,
octet-stream). La maggior parte delle mail è spedita via SMTP in formato MIME. FORMATO MSG MIME: si
aggiungono sigle all’header (quello del msg formato SMPT di prima) per specificare il tipo di contenuto
MIME. HEADER campi standard (from, to, suject) + MIME version (1.0) + MIME transfer-encoding (base 64:
tipo di codifica per traferimento) + Content-type (image/jpg: file da trasmettere). Una volta che il server
mail ha in memoria la mail ci sono diversi protocolli di accesso ai dati: POP3/IMAP (+HTTP, es. Hotmail, Yahoo
mail, ecc) POP3 autenticazione tra utente e server + scaricamento posta. Si può usare in modalità 1)
scarica e elimina: elimina la posta della mailbox dopo averla scaricata; disperde la posta sui diversi host da
cui accede alla mailbox; user agent permette di creare cartelle, sopstare msg, effettuare ricerche nei msg.
2) scarica e conserva: User Agent conserva la posta sulla Mailbox; utente può leggere i messaggi da
macchine diverse; non permette di strutturare i messaggi in directory (è stateless tra sesisoni diverse). IMAP:
permette di gestire cartelle di posta remote come se fossero locali; deve mantenere una gerarchia di
cartelle per ogni utente; permette allo User Agent di scaricare solo parti del messaggio (header,
intestazione MIME, ecc). E’ statefull (mantiene stato tra sessioni) 4 stati possibili: 1)Non-authenticated; utente
deve fornire username e password per la connessione 2)AuthenticatedState; utente deve specificare una
cartella prima di eseguire comandi che influiscono sul messaggio 3) Selected State; utente può dare
comandi che influiscono sul messaggio, es. elimina, salva, sposta 4) LogoutState: sessione terminata. DNS
Domain Name System: Servono per associare indirizzi numerici e indirizzi simbolici (o logici) più facilmente
memorizzabili. Gli indirizzi numerici sono utilizzati da server e client, quelli simbolici dagli utenti finali. Bisogna
che esista un sistema per rendere disponibili tali associazioni. Il DNS è il directory service della rete Internet. I
nomi sono costituiti da un elenco di labels. Poichè i nomi sono tanti bisogna usare un database distribuito
implementato come una gerarchia di server, ramificazioni di DSN (o NAME) SERVER. Comunicano tramite
protocollo applicativo: usato da host, router, server per risolvere I nomi logici in IP. esistono quattro tipi di
name servers: 1)Root name servers; vengono contattati dai server locali per risolvere gli indirizzi (conosce
tutti i TLD servers. Esso: contatta il name server di riferimento se la traduzione non è nota; ottiene la
traduzione; restituisce la traduzione al name server locale) 2)TLD: hanno tutte le info sugli authorative server
(.com, .edu, .org), più uno per ogni dominio 3)authorative: sono gestite dalle organizzazioni che forniscono i
sottodomini. Conoscono hosts e sottodomini 4)local name server: viene contattato dalla macchina che
cerca traduzione. Gestisce ricerca in modo trasparente. DSN dunque è una funzione base della rete
implementata come protocollo applicativo dai name server. Non è un’applicazione con cui gli utenti
interagiscono direttamente; fornisce una funzionalità di base di internet per le applicazioni utente;
Rispecchia la filosofia di concentrare la complessità nelle parti periferiche della rete. È usato da diverse
applicazioni (HTTP, SMTP, FTP, ecc). Http richiede la conoscenza dell’indirizzo IP e del nome simbolico
corrispondente, si interroga quindi un Name server con una richiesta UDP per ottenere l’IP (si usa una cache
per ridurre ritardo) N.b. Distribuzione del carico tra Server replicati; DNS fornisce un gruppo di indirizzi
alternando l’ordine, ciò permette di dirigere un client al server più vicino. Non c’è un DSN centrallizzato
perchè avrebbe: Minore tolleranza ai guasti; Traffico eccessivo; Database centrale troppo distante in molti
casi; Scarsa scalabilità; Autorizzazione ed accesso per registrare nuovo host. Nessun name server contiene
tutte le associazioni nome simbolico/indirizzo IP. Schema ricorsivo (recoursive query): I root name server
potrebbero non conoscere il name server di riferimento ma possono conoscere un server intermedio che
permette di raggiungere quello di riferimento. Si trasferisce il carico della traduzione al name server
contattato. In caso di sovraccarico: richieste ripetute (iterated query): il name server contattato risponde
con l’indirizzo del prossimo name server da contattare, con un msg del tipo “non conosco questo name ma
prova a rivolgerti a quest’altro server”. Quando un name server traduce un nome lo memorizza localmente
(caching). Il processo di caching conferisce ai DNS servers la capacità di fornire informazioni sugli indirizzi di
macchine che non fanno parte del loro stesso dominio e non sono sotto il loro stretto controllo: in altre
parole, un server DNS impara dai suoi "colleghi" e può validamente rispondere ad una richiesta di un client
senza avere l'"autorità formale" per farlo. Queste memorizzazioni sono temporanee, scadono (timeout)
dopo un certo tempo (un paio di giorni). Il mapping è mantenuto nei database sotto forma di resource

record (RR); ogni RR mantiene un mapping; i record vengono spediti tra server e all’host richiedente
all’interno di messaggi DNS; Un messaggio può contenere più RR. Formato RR: Name, Value, Type, TTL. Ci
sono 4 possibili type: Type A: Hostname à IP address; name è il nome dell’host; value è l’indirizzo IP. Type NS:
Domain name à Name Server; name è il dominio; value è il nome dell’host del server di competenza di
questo dominio. Type CNAME: Alias à Canonical Name; name è il nome alias di qualche nome “canonico”
(nome vero); value è il nome canonico. Type MX: Alias è mail server canonical name; value è il nome
canonico del server di posta associato a name. Protocollo DNS per domande (query) e messaggi di risposta
(entrambi con lo stesso formato) struttura del pacchetto: Intestazione del messaggio (header) à 1)
Identificazione: numero di 16 bit per la domanda; la risposta alla domanda usa lo stesso numero 2) Flag:
domanda o risposta; richiesta di ricorsione; ricorsione disponibile; risposta di competenza (il server è
competente per il nome richiesto) 3) Numero di: numero di occorrenze di risposta, di RR di risposta, di RR
autorevoli, di RR addizionali. Poi Questions (numero di variabili di questions) Answer (numero di variabili di
record di risorsa) Authority (numero di variabili di record di risorsa) + Additional informations. MODELLI PER
L’INTERAZIONE sono 2: client/server e peer to peer à le entità partecipanti condividono le proprie risorse per
contribuire attivamente alla fornitura del servizio (si contrappone alla tradizionale architettura client/server).
In un sistema peer-to-peer ogni entità (peer) partecipa alla fornitura del servizio (interazione simmetirca). Es:
un'applicazione di file-sharing. Un peer agisce contemporaneamente come client e come server (servant):
come server, fornisce parte delle sue risorse e come client, richiede le risorse degli altri peer. I servizi della
rete si dividono in: 1) ORIENTATI ALLA CONNESSIONE e 2) NON ORIENTATI (CONNECTIONLESS) obiettivo
comune è trasferimento di dati tra host. 1) Connection oriented è la modalità di comunicazione dati tramite
cui i dispositivi terminali usano un protocollo di comunicazione per stabilire una connessione logica o fisica
end-to-end tra gli agenti della comunicazione prima della trasmissione di qualsiasi tipo di dato. Si crea un
canale “virtuale” (preceduto da scambio di info di controllo – handshaking) che permette ai due host di
comunicare, tale canale è uno stato nei due host che indica che sono in comunicazione. TCP è un
protocollo orientato alla connessione (prima di poter trasmettere dati deve stabilire la comunicazione,
negoziando una connessione tra mittente e destinatario, che rimane attiva anche in assenza di scambio di
dati e viene esplicitamente chiusa quando non più necessaria) a pacchetti: scompone il msg in pacchetti e
implementa I meccanismi di avvenuta ricezione e eventuale reinvio dei pacchetti persi/danneggiati.
Fornisce: trasferimento affidabile (reliable) di flussi di byte; in caso di perdita viene conferma con gli ack
(acknowledgement) e avviene ritrasmissione; ordine: numerazione dei pacchetti e scarto dei duplicati.
Controllo di flusso (flow control): il sender rallenta (in caso di congestione della rete) o accelera (in caso di
rete libera e veloce) gli invii al receiver. Controllo della congestione (congestion control): il ritmo (rate) di
trasmissione diminuisce se la rete è congestionata. 2) SERVIZI NON ORIENTATI ALLA CONNESSIONE: lo
scambio di dati a pacchetto tra mittente e destinatario (o destinatari) non richiede l'operazione preliminare
di creazione di un circuito, fisico o virtuale, su cui instradare l'intero flusso dati in modo predeterminato e
ordinato nel tempo (sequenziale). Servizi non preceduti dunque da handshaking. UDP è un protocollo
connectionless: suddivide il flusso di dati in entità in pacchetti che vengono instradati singolarmente in
modo indipendente l'uno dall'altro, senza interazioni di ritorno tra sorgente e destinatari/o (per esempio per
verificare se il destinatario è raggiungibile) e senza controllo sulla corretta sequenza temporale di inoltro.
Fornisce quindi: trasferimento di dati non affidabile; nessun controllo di flusso (velocità di invio fissa) e nessun
controllo della congestione. CONFRONTO TCP/UDP: TCP è un protocollo orientato alla connessione,
pertanto per stabilire, mantenere e chiudere una connessione, è necessario inviare pacchetti di servizio i
quali aumentano l'overhead di comunicazione. UDP invece è senza connessione ed invia solo i
datagrammi richiesti dal livello applicativo. UDP non offre nessuna garanzia sull'affidabilità della
comunicazione ovvero sull'effettivo arrivo dei datagrammi, sul loro ordine in sequenza in arrivo, al contrario il
TCP tramite i meccanismi di acknowledgement e di ritrasmissione su timeout riesce a garantire la consegna
dei dati, anche se al costo di un maggiore overhead (raffrontabile visivamente confrontando la dimensione
delle intestazioni dei due protocolli). L'oggetto della comunicazione di TCP è il flusso di byte mentre quello di
UDP è il singolo datagramma. L'utilizzo del protocollo TCP rispetto a UDP è, in generale, preferito quando è
necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (es. nel caso di
trasferimenti di file). Al contrario UDP viene principalmente usato quando l'interazione tra i due host è
idempotente o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete (es. instant
messaging, streaming audio/video). TCP non offre garanzia di banda e ritardo minimi. Perchè uno, perchè
l’altro: le applicazioni hanno dei requisiti da soddisfare affinchè possano funzionare correttamente. In base
ai tipi di requisiti si sceglie il protocollo di comunicazione più adatto. Requisiti: PERDITA; alcune applicazioni
sono tolleranti (es. streaming audio/video) alla perdita di pacchetti, altre (es. transazioni online) richiedono

affidabilità totale. BANDA alcune apllicazioni (es. quelle multimediali) richiedono una banda minima, altre
(elastiche) usano la banda a disposizione.RITARDO alcune appl (es. telefonia internet) richiedono una
banda minima per funzionare. Alcuni requisiti sono determinati da esigenze percettive umane.
*COMMUTAZIONE DI PACCHETTO/DI CIRCUITO: La commutazione è l’operazione che predispone il percorso
che le informazioni emesse dal mittente devono seguire per raggiungere il destinatario. La commutazione di
circuito (circuit switching) è utilizzata nelle linee telefoniche di natura analogica e prevede una
connessione tra due nodi della sottorete realizzata attraverso un cammino fisico scelto, nodo per nodo, con
assegnate modalità di instradamento. Il messaggio rimane compatto e gli viene assegnato un percorso
riservato unicamente ad esso fino al termine della trasmissione. Il vantaggio è di avere la garanzia che, una
volta stabilita la chiamata, questa godrà per tutta la sua durata delle prestazioni richieste (banda passante,
ritardo costante). L'eventuale frazione di capacità trasmissiva non utilizzata (es. le pause di una
conversazione telefonica) è persa, e questo è uno dei grossi limiti della commutazione di circuito. La
commutazione di pacchetto (packet switching) è una tecnica che si basa sulla suddivisione del messaggio
da trasmettere in più unità autonome, i pacchetti, ciascuna corredata delle opportune informazioni di
controllo, es. gli identificativi del mittente e del destinatario e del numero d’ordine del pacchetto all’interno
dell’intero msg. Questa tecnica è utilizzata in ambito strettamente digitale e deve esistere una capacità di
instradamento autonoma allocata nei singoli organi di commutazione della rete detti nodi. Tipico della
comunicazione di pacchetto è il disordine nell’arrivo dei pacchetti che in genere non crea nessun
problema, anzi viene usato come strumento di controllo per il corretto arrivo dei dati. i pacchetti viaggiano
autonomamente quindi può succedere che pacchetti appartenenti ad uno stesso file seguano percorsi
diversi. Infatti quando un nodo intermedio riceve un pacchetto decide qual è il percorso migliore che il
pacchetto può prendere per raggiungere la sua destinazione. Questa strada può cambiare da pacchetto
a pacchetto dipendentemente dalle condizioni di congestione della rete. i pacchetti, proprio in virtù dei
propri diversi percorsi possono giungere a destinazione in un ordine diverso; vengono poi riassemblati nella
loro forma originale quando arrivano sul computer di destinazione. La commutazione di pacchetto
permette quindi a più utenti di inviare informazioni attraverso la rete in modo efficiente e simultaneo,
risparmiando tempo e costi sulle linee trasmissive. Infatti una rete a commutazione di pacchetto,
permettendo a più comunicazioni la condivisione di uno stesso canale trasmissivo (cavo elettrico, etere,
fibra ottica, ecc.), consente a tutti i computer connessi di condividere la capacità trasmissiva della rete
(utilizza meglio la rete). Mentre in una rete a commutazione di circuito la capacità del canale trasmissivo è
interamente dedicata ad una specifica comunicazione. SOCKET (letteralmente “presa”) rappresentazione
a livello software utilizzata per interfacciare i due terminali (endpoint) in gioco in una connessione tra due
computer. In altre parole, potremmo considerare i socket come delle prese (una per ogni macchina) che
siano interconnesse tra loro attraverso un ipotetico cavo in cui passi il flusso di dati che i computer si
scambiano. Es: pensare ai socket come alle prese telefoniche presenti ai due capi opposti durante una
conversazione al telefono. Le due persone che colloquiano al telefono comunicano attraverso le rispettive
prese. La conversazione, in tal caso, non finirà finché non verrà chiusa la cornetta e fino ad allora la linea
resterà occupata. I protocolli coinvolti nell’implementazione dei Socket sono TCP e UDP. Funzioni per TCP/IP:
1) per stabilire una connessione: socket à crea una nuova socket; connect à Lato client: stabilisce la
connessione con il server indicando indirizzo e porta del processo da connettere; bind à Associa una
socket a una porta; listen à Lato server: rende una socket passive,cioè in grado di ricevere richieste di
connessione; accept à Lato server: Accetta connessioni su socket passive. L’effetto è la creazione di una
nuova socket che verrà usata per la comunicazione. 2) dopo la connessione: write à Per scrivere sequenze
di byte, cioè inviare messaggi; read à Per leggere sequenze di byte, cioè ricevere messaggi; close à
Chiude la comunicazione rilasciando la socket. [queste funzioni sono le API di internet – API: application
Programming Interface. Sono le stesse funzioni usate per gestire i dati]. *STRATIFICAZIONE PROTOCOLLARE Le
reti sono complesse e contengono molti elementi: host, router, link fisici dalle caratteristiche diverse,
applicazioni, protocolli, hardware, software. I sistemi sono complessi: la stratificazione permette una più
facile organizzazione e individuazione delle funzionalità. La modularità facilita la manutenzione e la
modifica dei sistemi. La modifica dell’implementazione dei servizi resi da uno strato è trasparente (non si
modifica l’interfaccia). 5 strati o livelli: 1) application: supporto per le applicazioni di rete (ftp, smtp, http) 2)
transport: trasferimento dati end-to-end (tcp, udp) 3) network: trasferimento di datagrammi da sorgente a
destinazione (ip, routing protocols) 4) link: trasferimento di dati tra elementi di rete adiacenti (ppp, ethernet)
5) physical: bit “sul cavo”. COMUNICAZIONE TRA ELEMENTI IN RETE ogni componente di rete ha delle
componenti che implementano le funzionalità di alcuni o tutti gli starti della rete. Es. Host (computer)
implementano funzionalità di tutti gli strati. COME FUNZIONA LA COMUNICAZIONE ogni strato riceve dati

dallo strato superiore (in invio) o inferiore (in ricezione). Aggiunge (in invio) o toglie (in ricezione) l’header
aggiunto dallo strato corrispondente e passa il datagramma al livello inferiore (in invio) o superiore (in
ricezione). EVOLUZIONE WEB Web 1.0, portali: siti che costituiscono porte di accesso ad un gruppo
consistente di risorse internet di vario tipo, spesso organizzati per canali tematici. Predecessori dei motori di
ricerca, modello finito nel 2000. Possono essere generalisti o verticali, spesso personalizzabili sulla base di
singole esigenze. Web 2.0 slogan che identifica un grande cambiamento nel web. Si iniziano a mettere sul
web delle applicazioni, si creano pagine dinamiche. Grande cambio del web: si inizia ad inserire logica nel
server. Questi vantaggi non sono funzionali perchè che siano pagine statiche o dinamiche, se rispondono
entrambe alle richieste, funzionalmente non ci sono differenze. Requisito funzionale è lo scopo ultimo, ma
oggi la differenza la fa il modo in cui vengono svolte le operazioni per soddisfare i requisiti funzionali. Il
vantaggio sta nella flessibilità di queste nuove pagine, la possibilità di di poter fare di tutto con piccoli
cambiamenti. Caratteristiche Web 2.0: piattaforme che consentono una forte interazione tra utenti; utenti
usufruiscono di servizi innovativi mediante potenti interfacce grafiche. Gli utenti forniscono il valore aggiunto
con l’autoproduzione di contenuti e la condivisione della conoscenza. Si sfrutta e si valorizza l’intelligenza
collettiva, vero motore del Web 2.0 (autoproduzione di contenuto + condivisone della conoscenza). I servizi
offerti vengono aggiornati di continuo, in modo da correggere rapidamente gli errori e aggiungere nuove
funzionalità non appena disponibili. Caratteristica fondamentale quindi: centralità + protagonismo
dell'utente che da fruitore diviene sempre più un controllore dei propri dati e dei contenuti che naviga,
facendosi stesso produttore di info e, contemporaneamente, principale giudice di quanto prodotti da altri.
Si passa dalla comunicazione "da uno a molti" a quella "da molti a molti": il web 2.0 ribalta i paradigmi di
comunicazione classica. Nel web 1.0 gli editori pubblicano i contenuti, modello di comunicazione adottato:
“pochi a molti” (portale). Nel Web 2.0 si forma il concetto di comunità online tra utenti, distinte in base al
modello di comunicazione adottato: “uno a uno”(e-mail istant messaging) “uno a molti” (blog) “molti a
molti” (wiki e blog). Elemento tecnologico innovativo di rilievo è l’assemblaggio (Innovation in Assembly) di
tecnologie e servizi preesistenti, i mash-up, che hanno il vantaggio di essere semplici da realizzare e di non
aver bisogno di conoscenze informatiche approfondite. Combinazione di vecchie tecnologie e standard
(come HTML, CSS, XML, JavaScript, DOM) per realizzarne di nuove (come AJAX), che consentono lo
sviluppo di applicazioni Web di nuovo tipo, le RIA. Un es. di mashup è dato dall’unione di Google Maps e
Flickr che consente di visualizzare su una mappa le foto relative alla zona selezionata. In sintesi, web 1.0:
contenuti generati da pochi; Taxonomy; Navigazione: menu; Interazione utente/sito; Online quando serve;
Pesantezza (browser con plug-in, computazione fatta dal client); Banda stretta; Servizi “chiusi”
non si integrano; E-commerce (si paga); Release successive // web 2.0: User generated content;
Folksonomy (categorizzazione dell’info proposta dagli utenti); Navigazione: ricerca e consigli peer; Social
network; Sempre online; Leggerezza (funzioni server side); Banda larga; Servizi aperti, integrazione (mashup);
Freemium (non si paga); “Perpetual beta”. Il prossimo passo è il web sematico: l’idea chiave è quella di
associare opportuni metadati ai contenuti del web in modo da ottenere classificazione rigorosa + possibilità
di ottenere info certe (certificate). APPLICAZIONI WEB BASED: Il web è basato su Internet, quindi
l’ambiente è standard (TCP/IP); ha una larga diffusione ed è indipendente dalla piattaforma. Ha
un’interfaccia grafica (browsers) che definisce modi di interazione standard, è quindi semplice da usare. Ha
un’infrastruttura completa: supporta sistemi aperti (si possono aggiungere/togliere componenti senza
alterare la struttura del sistema) e sono disponibili strumenti sempre più potenti per elaborazioni complesse
lato server e lato client (evoluzioni di HTML, CGI, JavaScript, Java, ecc). Le applicazioni web based
comunicano via HTTP non via TCP (livello applicativo); girano su client e su server. 1) vantaggi applicazione
web: Nessun software da installare nel proprio PC; Utilizzabile da qualsiasi punto della rete dalla quale sia
accessibile il server; Sempre aggiornata (tutti gli utenti condividono la stessa installazione, questa è sempre
l’ultima versione per tutti); Possibilità di integrazione: uso più applicazioni per ottenere un risultato; Possibilità
di collaborazione (web 2.0, es. wikipedia) e 2) svantaggi: Impossibilità di utilizzare l'applicazione se la rete è
fuori servizio; Transito in rete di dati sensibili/personali. Un’applicazione web fornisce all’utente, per mezzo
dell’infrastruttura web: servizi (ricerca, home banking, commercio elettronico, ecc) e info dinamiche
attraverso pagine costruite in base all’interazione con l’utente stesso. Problema: L’infrastruttura web si basa
sul protocollo HTTP, che non prevede lo sviluppo di applicazioni che coinvolgano una fase di elaborazione
oltre che di passaggio di dati. Occorre costruire una architettura più complessa di quella client/server
basato su HTTP: per realizzare un’applicazione, oltre a client/server serve un’application server a supporto
del Web Server. Un’Application server è caratterizzato dal protocollo di interazione con il Web Server e
l’interazione con il client è sempre HTTP. Web e application server seguono quindi un modello logico, sono
entrambi programmi, servono entrambi richieste. La computazione, che avviene lato server, può avvenire

tramite PROGRAMMI COMPILATI: il web server invoca, su richiesta del client, un eseguibile, che può essere
scritto in un qualsiasi linguaggio che supporti l’interazione con il web server, es. Java, C#, C++. O tramite
SCRIPT INTERPRETATI: il web server ha un motore in grado di interpretare il linguaggio di scripting usato (PHP,
Pyton e Perl). Questo implica: velocità di esecuzione ridotta (compilazione durante l’esecuzione) ma facilità
di scrittura programmi e portabilità (possono essere eseguiti su macchine diverse, basta che sia presente un
motore di scripting). CGI Common Gateway Interface: È un’Application Server molto elementare, definisce
le caratteristiche dei programmi lato server e le modalità con cui i dati vengono trasferiti tra Web Servers e
programmi. Un’applicazione CGI è un programma che legge una REQUEST ed elabora una RESPONSE, I
msg sono in formato HTTP. Vantaggi: scrittura applicazioni web in modo efficiente ed ottimizzato; si può
utilizzare qualsiasi linguaggio di programmazione. Svantaggi: è poco flessibile, se si cambiano i dati in
quantità e tipo occorre riscrivere sia la parte di elaborazione che l'interfaccia col web server; richiede la
realizzazione di tutti gli aspetti dell’applicazione (un Application Server vero e proprio fornisce maggior
supporto). ARCHITETTURA CGI: 1) nel caso di un eseguibile il web server lancia lo specifico processo che
esegue l’applicazione richiesta. 2) nel caso di applicazioni interpretate (simile alle macchine virtuali) viene
usato un interpreteper lo scripting (in PHP, Pyton e Perl) web server lo lancia all’interprete che si occuperà di
eseguire lo specifico programma. Quindi: web browser richiede script, nel web server viene individuato lo
script, analizzato e tramite il parser del linguaggio viene generata la pagina HTML da fornire al browser che
l’ha richiesta. MODELLO SERVLET/JSP [pag.9] JavaServer Pages è una tecnologia di programmazione web in
Java per lo sviluppo di applicazioni web che forniscono contenuti dinamici in formato HTML o XML. La
scrittura di apllicazioni JSP richiede la definizione di pagine HTML contentente istruzioni in Java; Le pagine
vengono tradotte in Servlet (programmi Java con una struttura speciale); supporto all’esecuzione di JSP
fornito da application server (come Tomcat). REQUEST e RESPONSE HTTP vengono tradotte in strutture dati in
Java (classi pre-esistenti. HTTPServletRequest e
HTTPServletResponse) che vengono manipolate. à
APPLICAZIONI WEB (a e c) suddividono così il carico
di lavoro perchè il bilanciamento dell’esecuzione fra
client e server migliora le prestazioni e permette la
personalizzazione delle applicazioni. Prestazioni:
Alleggerire il server da computazioni elementari (es.
controllo ortografico); Ridurre traffico di rete.
Personalizzazione: scelta dell’organizzazione dei dati
sulla pagina (es. scelta dei colori, dei dati visualizzati,
ecc); Carico incrementale dei dati (no necessario
caricare un’intera pagina ma solo dati che servono ad
aggiornare una parte dei dati). AJAX Asynchronous
Javascript and XML: è una tecnica (estensione di
javascript) di sviluppo software per la realizzazione di
applicazioni web interattive (RIA). Tecnologia (ma
anche una metodologia e un modello
d’implementazione) composta da una serie di
strumenti già esistenti, che uniti insieme danno vita ad
un potente modello di iterazione. Come metodologia
richiama le funzioni RIA, portando piccole parti di dati
piuttosto che ricaricare l’intera pagina, dal punto di
vista implementativo riguarda più da vicino
l’interfaccia utente UI e il rapporto sistema/utilizzatore.
Tecnologie Ajax comprendono: HTML, usato x
costruire le pagine web e identificare i campi per il
successivo uso nel resto dell'applicazione. Un display
dinamico di iterazione DOM (Document Object
Model). DOM è utilizzato (tramite Javascript) per
manipolare sia la struttura della pagina HTML sia le
risposte XML restituite dal server DHTML o Dynamic
HTML che aiuta a caricare i form in modo dinamico
(aggiornamento dinamico delle pagine) con
comandi come div, span e altri elementi HTML. JavaScript, cuore del codice tramite cui funzionano le
Architetture multilivello
!  Alternative per applicazioni client-server (a) – (e)
!  Le applicazioni Web sono di tipo (a) – (c)
50
1-29
Modello Ajax
54

applicazioni Ajax ed è di supporto per la comunicazione con le applicazioni server. CONFRONTO CON
ARCHITETTURE WEB APPLICATION STANDARD termine ASINCRONO significa che si ottiene la risposta da parte
del server quando disponibile, senza aspettare l’apertura di una nuova pagina. Il modello di una classica
applicazione web fa in modo che le azioni dell’utente diano il via ad una richiesta, veicolata dal protocollo
HTTP verso il server. Questo elabora i dati e restituisce i risultati al cliente, con una pagina HTML. Così
l’esperienza dell’utente è completamente ai margini. Utente non dovrebbe bloccare le proprie azioni ogni
volta che l’applicazione richieda info al server, ne dovrebbe percepire la richiesta stessa. Un’applicazione
Ajax elimina la tradizionale natura d’iterazione INIZIO-FINE/INIZIO-FINE, creando la figura di un mediatore tra
l’utente e il server: intermediario è il motore Ajax, che viene caricato dal browser al principio della sessione
di lavoro e si sostituisce ad una classica pagina web. Il motore, che consiste di funzioni JavaScript e non
richiede alcun plug-in o installazione da parte dell’utente, è responsabile della comunicazione tra utente e
server e si occupa sia di ciò che deve apparire sull’interfaccia utente, sia di trasmettere le richieste al server
con linguaggio XML. Grazie a questo sistema, l’iterazione ha luogo asincronicamente, cioè in modo
indipendente dall’attività del server. L’utente non si troverà di fronte a pagine bianche e non percepirà il
lavoro svolto dalla trasmissione per mezzo dei protocolli. Se nelle tradizionali applicazioni web, le azioni
dell’utente generano una richiesta HTTP, con le applicazioni Ajax l’evento è una chiamata da parte di
JavaScript al motore Ajax. Questo passo intermedio permette di evitare il rinvio al server se la richiesta di
dati può essere fornita dal motore stesso. In caso contrario il motore comunicherà “asincronicamente” con
il server. PRO E CONTRO AJAX le applicazioni AJAX devono essere testate su più browser per verificarne la
compatibilità + è richiesto che nel client sia attivato Javascript. Il vantaggio di usare AJAX è la grande
velocità alla quale un'applicazione risponde agli input dell'utente. Un problema è che, senza l'adozione di
adeguate contromisure, le applicazioni AJAX possono rendere non utilizzabile il tasto "indietro" del browser:
con questo tipo di applicazioni non si naviga da una pagina all'altra, ma si aggiorna di volta in volta una
singola parte del medesimo documento. Proprio per questo i browser, che sono programmi orientati alla
pagina, non hanno possibilità di risalire ad alcuna di tali versioni "intermedie". JAVASCRIPT è un linguaggio
di scripting orientato agli oggetti. È interpretato dal browser, lato client (= codice non viene compilato, ma
interpretato: l'interprete è incluso nel browser che si sta utilizzando). In JavaScript lato client, il codice viene
eseguito direttamente sul client e non sul server. Il vantaggio di questo approccio è che, anche con la
presenza di script particolarmente complessi, il web server non viene sovraccaricato a causa delle richieste
dei clients. Di contro, nel caso di script che presentino un codice sorgente particolarmente grande, il tempo
per lo scaricamento può diventare abbastanza lungo. Può definire un oggetto capace di effettuare
richieste in HTTP al server, in maniera trasparente all'utente. Originariamente tale oggetto era stato pensato
per ottenere documenti XML. Una volta ottenuti dei dati XML (da un’applicazione Web), è possibile
cambiare certe parti della pagina già caricata utilizzando le capacità di Javascript di modificare gli
elementi del DOM. Javascript più richiedere anche dati come testo semplice e HTML. DOM Document
Object Model: modello a oggetti del documento, è una forma di rappresentazione dei documenti
strutturati come modello orientato agli oggetti. PARADIGMA A OGGETTI: oggetto = struttura composta da dati +
operazioni che possono essere fatti su quei dati. I dati sono le informazioni che caratterizzano un oggetto (definiscono
un modello dell’oggetto) i metodi descrivono le operazioni che si possono applicare all’oggetto stesso (e quindi ai suoi
dati). I metodi definiscono l’interfaccia di un oggetto. Un metodo è definito da un nome e dai parametri (i dati usati dal
metodo per eseguire l’operazione desiderata). Una classe implementa una interfaccia associando ai metodi i
programmi che realizzano le operazioni. Un oggetto è un’istanza (una realizzazione concreta) di una classe (che ne è
quindi la sua descrizione). Ogni oggetto può: usare un altro oggetto, lo ingloba come un proprio dato e può accedervi
tramite I suoi metodi; ereditare da un altro oggetto le sue proprietà (relazioni tra oggetti). JAVA SERVLET
applicazioni lato server dotate di una interfaccia standard, il che le rende limitate (non posso fare ciò che
voglio) ma semplici (basta realizzare le parti mancanti). Sono residenti in memoria, cioè mantengono uno
stato (posso realizzare delle sessioni) e consentono interfaccia con altre servlet. Vantaggi: più efficienti e
potenti delle CGI in quanto utilizzano un linguaggio e un ambiente completo (Java); consentono di
integrare sistemi e applicazioni dando accesso via web. Una servlet è un componente gestito in modo
automatico da un container (engine). L’interfaccia definisce un set di operazioni predichiarate e
(ri)definibili di volta in volta. Container controlla le servlet (attiva/disattiva) in base alle richieste dei client (le
chiama in modo intelligente). Ogni servlet implementa l’interfaccia javax.servlet.Servlet con 5 metodi: 1)
init: Inizializza la servlet 2) destroy: chiamata quando la servlet termina (es. per chiudere un file o una
connessione con un database) 3) getServletConfig: Restituisce i parametri di inizializzazione e il
ServletContext che da accesso all’ambiente 4) getServletInfo: restituisce informazioni tipo autore e versione
5) service: invocato per gestire le richieste dei client. L’interfaccia è solo la dichiarazione dei metodi che,
per essere utilizzabili, devono essere implementati in una classe (implementare = associare il codice, cioé le

istruzioni, che definiscono il compito assegnato al metodo). Sono presenti 2 CLASSI ASTRATTE:
javax.servlet.GenericServlet e javax.servlet.http.HTTPServlet permettono di creare servlet implementando
solo I metodi che di fatto servono, facilitando di molto la scrittura vera e propria delle servlet. HTTPServlet
implementa il metodo service in modo da legare le invocazioni al protocollo HTTP (ai tipi GET, POST, ecc),
cioè: doGet, processa le richieste GET e doPost processa le richieste POST. Anche i paramentri
(HTTPServletRequest e HTTPServletResponse) sono stati adattati al protocollo HTTP, cioè consentono di
costruire dei msg HTTP specificando i dati da inserire nell’head e nel body. HTTPServletRequest: viene
passato un oggetto da service; Contiene la richiesta del client; Estende ServletRequest.
HTTPServletResponse: Viene passato un oggetto da service; Contiene la risposta per il client; Estende
ServletResponse. Una servlet viene creata dal container quando viene effettuata la prima chiamata. Viene
invocato il metodo init()per inizializzazioni specifiche. Una servlet viene distrutta, invocando il metodo
destroy() quando non ci sono servizi in esecuzione e quando è scaduto un time out predefinito. Server può
anche restituire cookie (stringhe di carattere che permettono di gestire la sessione) insieme alle risposte,
inserendole nell’header. HTTPsession: gestito direttamente dal container, sopperisce alla non persistenza di
HTTP. *JSP/SERVLET Nella servlet la logica per la generazione del documento HTML è implementata
completamente in Java: il processo di generazione delle pagine è lungo e passibile di errori, è scomodo
aggiornare la struttura delle pag quando necessario. Le JSP nascono per facilitare l’aggiornamento delle
pagine: è possibile produrre pagine senza la necessità di conoscere i dettagli della logica server side, la
generazione di codice dinamico è implementata sfruttando un linguaggio di scripting. Di default si utilizza
Java, il codice delle JSP viene compilato in Servlet. Vantaggi di JSP: contenuti sono separati dalla logica di
presentazione; lo sviluppo delle applicazioni è semplificata rispetto alla programmazione tramite servlet;
manutenzione delle JSP è automatica. Le JSP vengono ricompilate “automaticamente” quando sono
apportate modifiche alla pagina; l’authoring delle pagine è particolarmente semplice; essendo compilate
in servlet anche le JSP sono portabili. Limiti Servlet: le servlet forniscono un adeguato supporto per la
generazione di pagine dinamiche ma hanno svantaggi: per generare le pagine (anche gli elementi statici)
bisogna scrivere del codice; ogni modifica alla pagina richiede la ricompilazione e l’installazione della
nuova release della servlet; la compilazione e l’installazione può essere tediosa. Dunque, le JSP non
rendono inutili le servlet: le servlet forniscono agli sviluppatori delle web application un completo controllo
dell’applicazione. Se si vogliono fornire contenuti differenziati a seconda di diversi parametri (quali l’identità
dell’utente, ecc) può essere conveniente lavorare con le servlet. Le JSP rendono invece molto semplice
presentare documenti HTML o XML all’utente. Servlet e JSP sono perciò usate congiuntamente in
applicazioni strutturate in accordo al modello Model-View-Controller (MVC*). Nel contesto della
piattaforma Java, la tecnologia JSP è correlata con quella delle servlet: all'atto della prima invocazione, le
pagine JSP vengono infatti tradotte automaticamente da un compilatore JSP in servlet. Una pagina JSP
può essere vista come una rappresentazione ad alto livello di una servlet. Per via di questa dipendenza
concettuale, anche l'uso della tecnologia JSP richiede la presenza, sul Web server, di un servlet container, oltre che di
un server specifico JSP, il motore JSP (che include il compilatore JSP); in genere, servlet container e motore JSP
sono integrati in un unico prodotto (es. Tomcat svolge entrambe le funzioni). JSP è una tecnologia
alternativa rispetto a numerosi altri approcci alla generazione di pagine Web dinamiche, per esempio PHP,
o ASP o la più tradizionale CGI. Differisce da queste tecnologie non tanto per il tipo di contenuti dinamici
che si possono produrre, quanto per l'architettura interna del software che costituisce l'applicazione Web.
JSP Tecnologia per la creazione di applicazioni web, specifica l’interazione tra un contenitore/server ed un
insieme di “pagine” che presentano informazioni all’utente. Queste pagine sono costituite da tag
tradizionali (HTML, XML, WML) e da tag applicativi che controllano la generazione del contenuto. Rispetto ai
servlet, facilitano la separazione tra logica applicativa e presentazione. Analogo alla tecnologia Microsoft
Active Server Page (ASP) ma, mentre una Java Server Page chiama un programma Java eseguito sul Web
server, una ASP contiene uno script VBScript o Jscript. Un file JSP viene prima compilato e la versione
compilata viene tenuta in memoria per rendere più veloce una successiva richiesta della pagina. Gli
elementi di una JSP sono: 1) Template text: le parti statiche della pagina. I contenuti statici sono porzioni
della pagina JSP che devono essere mantenute integralmente nella pagina Web generata
dinamicamente, senza alcuna elaborazione. Devono pertanto essere scritte nel linguaggio di tag di cui il
client può usufruire direttamente, per esempio HTML (se il client è un browser) WML (se il client è un cellulare
che accede alla pagina in WAP) o XML (vari tipi di client). 2) Commenti <%-- commento --> 3) Direttive
<%@direttiva%> Le direttive JSP si possono interpretare come comandi rivolti al motore JSP. Questi comandi
vengono eseguiti in una fase di preprocessing, prima che siano elaborate le porzioni della pagina
contenenti script. Sono: a) page liste di attributi/valore, valgono per la pagina in cui sono inseriti, es <%@

page import="java.util.*" buffer="16k" %> <%@ page import=“java.math.*, java.util.*” %> b) include include in
compilazione pagine HTML o JSP <%@ include file="copyright.html" %> c) taglib dichiara tag definiti
dall’utente implementando opportune classi d) forward determina l’invio della richiesta corrente,
eventualmente aggiornata con ulteriori parametri, all’URL indicata, es. <jsp:forward page=“login.jsp” %> e)
include: invia dinamicamente la richiesta ad una data URL e ne include il risultato, es. <jsp:include
page=“login.jsp” %> f) useBean: localizza e distanzia (se necessario) un javaBean nel contesto specificato. Il
contesto può essere la pagina, la richiesta, la sessione, l’applicazione. Es. <jsp:useBean id=“cart”
scope=“session” class=“ShoppingCart” />. 4) Azioni: in XML <tag attributes>body</tag> 5) Elementi di
scripting: istruzioni nel linguaggio specificato nelle direttive. Sono: a) Declaration <%! declaration
[declaration] ...%> Variabili (che valgono per la durata della servlet) o metodi usati nella pagina, essi
andranno a far parte della classe "servlet" generata dal compilatore JSP, la loro posizione all'interno del
testo della pagina JSP è irrilevante. b) Expression <%= expression %> Una espressione nel linguaggio di
scripting che viene valutata e sostituita con il risultato (il risultato viene convertito in stringa, e la stringa
immersa nel codice HTML/XML nel punto corrispondente a quello dove compariva l'espressione stessa). c)
Scriptlet <% codice %> Frammenti di codice che controllano la generazione della pagina, valutati alla
richiesta. Le variabili valgono per la singola esecuzione, ciò che viene scritto sullo stream di output
sostituisce lo scriptlet. Si può immaginare che durante la costruzione della pagina Web dinamica, il motore
JSP includa senza elaborazioni i contenuti statici, procedendo dall'alto verso il basso nel documento, ed
esegua immediatamente eventuali scriptlet incontrati durante l'operazione. Tecnicamente, questi scriptlet
vengono inclusi nei metodi del servlet generato dalla pagina JSP, all'interno dei metodi che producono la
risposta a una richiesta HTTP. Linguaggio di script ha lo scopo di interagire con oggetti java e gestire le
eccezioni java. Gli oggetti impliciti sono gli elementi delle servlet (sono9, es. request, response, out, page).
Tali oggetti possono essere creati: 1) implicitamente usando le direttive JSP 2) esplicitamente con le azioni 3)
direttamente usando uno script (raro). Gli oggetti hanno un attributo che ne definisce la visibilità: scope.
Visibilità crescente da page a request a session e a application. Sessione: da la possibilità di gestire
efficientemente i cookie (come per le servlet), esiste un oggetto session implicito che può essere utilizzato
per la sessione: utilizza lo stesso sistema delle servlet; sessione server side;
la sessione scade dopo un determinato time-out. Tutte le JSP che
partecipano alla gestione della sessione di interazione con un utente
possono memorizzare informazioni nell’oggetto implicito session.
Attenzione alla memoria richiesta per la gestione della sessione degli
utenti ed al tempo in cui questa è mantenuta. FUNZIONAMENTO JSP Il client richiede via HTTP un file .JSP. Il
file .JSP viene interpretato e accede a componenti lato-server (Java Beans, Servlet) che generano
contenuti dinamici. il risultato viene spedito al client sotto forma di pagine HTML. La richiesta viene inviata
ad un Java Servlet che genera i dati dinamici richiesti dall’utente. Il Servlet richiama un file .jsp, che si
occupa di formattare in HTML i risultati e inviarli all’utente. JAVABEAN sono classi scritte in Java secondo una
particolare convenzione. Sono utilizzate per incapsulare più oggetti in un oggetto singolo (il bean), cosicché
tali oggetti possano essere passati come un singolo oggetto bean invece che come multipli oggetti
individuali. Al fine di funzionare come una classe JavaBean, una classe di un oggetto deve obbedire a
certe convenzioni in merito ai nomi, alla costruzione e al comportamento dei metodi. Queste convenzioni
rendono possibile avere tool che possono usare, riusare, sostituire e connettere JavaBean. Le convenzioni
sono: la classe deve avere un costruttore senza argomenti; le sue proprietà devono essere accessibili
usando get, set, is e altri metodi (metodi accessori) seguendo una convenzione standard per i nomi; la
classe dovrebbe essere serializzabile (capace di salvare e ripristinare il suo stato in modo persistente); non
dovrebbe contenere alcun metodo richiesto per la gestione degli eventi. Lo scope determina la vita del
bean: page è lo scope di default (viene messo in pageContext ed acceduto con getAttrubute) request
(viene messo in ServletRequest ed acceduto con getAttrubute) session e application: se non esiste un bean
con lo stesso id, ne viene creato uno nuovo. Il type permette di assegnargli una superclasse (al posto della
classe si puo’ usare il nome del bean. beanName="nome" nome è la classe o un file serializzato). È
raccomandabile usare MVC con le pagine JSP in modo da dividere il livello di presentazione da quello
dell'elaborazione della request e dalla memorizzazione dei dati. Le normali servlet o pagine JSP dedicate
vengono utilizzate per processare i dati. Dopo che l'eleborazione è terminata, il controllo passa ad una
pagina JSP che serve solo a visualizzare l'output. Quest'ultima pagina JSP dovrebbe contenere solo HTML,
XML e action e tag JSP; la pagina dovrebbe far uso dei JavaBeans per ottenere i dati. Quindi, nello sviluppo
di un'applicazione web la convenzione vuole che nelle JSP ci sia meno codice Java possibile e quello
presente vada a richiamare codice Java nativo (oggetti e metodi) implementato in classi separate

apposite dette appunto JavaBeans. Questa separazione consente infatti un facile riuso di codice dei Java
beans una volta richiamato in un qualsiasi punto richiesto dell'applicazione web. MVC: è un pattern
architetturale molto diffuso nello sviluppo di sistemi software, soprattutto nella programmazione orientata
agli oggetti, in grado di separare la logica di presentazione dei dati dalla logica di business. Il pattern è
basato sulla separazione dei compiti fra i componenti software che interpretano 3 ruoli principali: 1) il model
fornisce i metodi per accedere ai dati utili all'applicazione (è JAVABEAN) 2) il view visualizza i dati contenuti
nel model e si occupa dell'interazione con utenti e agenti (è JSP) 3) il controller riceve i comandi dell'utente
(in genere attraverso il view) e li attua modificando lo stato degli altri 2 componenti (è la SERVLET). SOA E
WEB SERVICE Un servizio è un componente software che esegue task (compiti) predefiniti ed è dotato di
contratti/interfacce pubblici. Può essere visto semplicemente come la caratterizzazione astratta e
l'incapsulamento in un'interfaccia di uno specifico contenuto o risorsa o capacità di elaborazione. Es.
capacità di spostare file, creare processi, fornire informazioni, ecc. Altra def: procedura, metodo o oggetto
con una interfaccia pubblica e stabile che può essere invocato da un client. Sia la richiesta sia l’esecuzione
del servizio impongono che vi sia un programma che ne “chiama” un altro. L'interfaccia di un servizio è: il
protocollo (come interagire con il servizio) da usare per interagire con esso; il formato dei dati scambiati
(come sono strutturati i dati scambiati) e il comportamento atteso a seguito dei diversi scambi di messaggi
(che cosa il servizio fa). Caratteristiche: utilizzatore li vede come black-box; sono indipendenti da
piattaforma; hanno un’alta interoperabilità (possono agevolmente scambiarsi informazioni da usare
ognuno nella propria elaborazione). Le azioni svolte da un servizio creano un insieme coerente dal punto di
vista sia dell’utilizzatore sia del fornitore. SERVICE ORIENTATION indica l’integrazione di differenti applicazioni
presentate come servizi. SOA service oriented architecture: particolare architettura che sfrutta i principi
della service orientation. Filosofia di progetto: i processi di business sono sempre più estesi nel mercato
globale e coinvolgono numerose e svariate parti di una o più imprese. Si devono poter cambiare
rapidamente e a basso prezzo le modalità del business (quello che si fa, gli strumenti usati) e le persone
coinvolte. Composite application: insieme di servizi collegati e integrati a supporto di un processo di
business (ciò che produce un output che crea profitto). Attori: offerente; colui che offre il servizio a terzi. Sa
dell’esistenza di un terzo quando questo gli richiede il servizio. Richiedente: colui che necessita/richiede un
servizio per raggiungere un obiettivo prefissato. Non ha conoscenza dei fornitori (solitamente), deve scoprire
l’esistenza di un servizio e contattare il fornitore. Componenti: servizio e descrizione dei servizi. Ruoli: service
providers, discovery agencies, service requestors. Operazioni: pubblicare, trovare, interagire. Es: io (service
requestor) guardo sulle pagine bianche (discovery agency) alla ricerca di una pizzeria a domicilio (service
provider). Una volta trovata quella che mi interessa, copio il numero e per avere il servizio ci interagisco
cioè chiamo. Principi dell’architettura SOA: minimizzazione della dipendenza (tra servizi); presenza di
contratti (relativi a come I servizi devono comunicare); astrazione (servizio come black box, non si sa come
lavora); riutilizzabilità (logica è divisa in più servizi per poter essere riusata); compatibilità (I servizi possono
essere composti in servizi più complessi); I servizi possono essere scoperti tramite meccasismi noti. SOA ≠ WEB
SERVICE: soa è un modello architetturale, I web services sono le migliori tecnologie che implementano I
principi della SOA. Web services perchè: per far comunicare 2 applicazioni tramite internet; per costruire
programmi tramite composizione di altri programmi; per usare un metodo di comunicazione standardizzato;
perchè possono far cambiare radicalmente metodi di sviluppo/funzione delle applicazioni. I punti di forza
dei web services sono: 1) interoperabilità dinamica di business: possibilità di costruire dinamicamente nuove
partnership in quanto I WS garantiscono iteroperabilità tra sistemi 2) accessibilità: servizi di business sono
decentralizzati, distribuiti in rete e possono essere usati da una grande quantità di devices (servizio di
business è una delle fasi che compongono un processo di business) 3) specifiche universali: note e
accettate, riguardano lo scambio di dati, la scoperta di servizi, descrizione dell’interfaccia, ecc 4) Legacy
integration: maggior integrazione coi sistemi legacy, questo garantisce più flessibilità (un sistema legacy è
un'applicazione o un componente obsoleto, che continua ad essere usato poiché l'utente - tipicamente
un'organizzazione - non intende o non può rimpiazzarlo). Inoltre, un Web service è self-describing (se si
pubblica un Web service, si dovrebbe pubblicare anche la sua interfaccia pubblica. L’interfaccia pubblica,
scritta in XML, viene utilizzata per identificare tutti i metodi pubblici, gli argomenti dei metodi e i valori di
ritorno) ed è discoverable (se si crea un Web service, esiste un meccanismo relativamente semplice che
permette la sua pubblicazione. Similmente, esiste un meccanismo semplice che permette, alle parti
interessate, di cercare un servizio e localizzare la sua interfaccia pubblica). Web service è un’interfaccia di
rete accessibile alle funzionalità di un’applicazione, costruito usando tecnologie standard di Internet. Sono
identificati da URI. Definizione (creazione) descrizione e scoperta fatte con XML. Sono una tecnologia che
permette alle applicazioni di comunicare tra loro in modo indipendente da piattaforma e linguaggio di

programmazione. Essendo basati su
XML per la rappresentazione dei dati
per tutti i protocolli e le tecnologie dei
Web services, possono raggiungere la
più completa indipendenza dal
linguaggio di programmazione e dalla
piattaforma utilizzata. Sono strutturati a
livello, ogni livello ha le sue finalità.
Nomi/protocolli/linguaggi per
regolamentare/implement varie
funzioni. 1)Architettura in base ai ruoli:
Service provider è il fornitore del servizio; implementa il servizio e lo rende disponibile su Internet. Da una
prospettiva business rappresenta il proprietario del servizio, dal punto di vista architetturale è la piattaforma
che ospita l’accesso al servizio. Service requestor è il responsabile dell’invocazione del servizio. Il service
requestor localizza il Web service usando il service broker, invoca il servizio richiesto che viene eseguito dal
service provider. Da una prospettiva business è il cliente richiedente la soddisfazione di determinate funzioni,
da prospettiva architetturale questa è l’applicazione che effettua la ricerca e invoca o inizializza
un’interazione con il servizio. Service registry è l’elenco logicamente centralizzato dei servizi. Il registry
fornisce un punto centrale dove gli sviluppatori possono pubblicare nuovi servizi e trovarne uno già
esistente. Il registry si comporta da intermediario (broker) per le società ed i loro servizi 2)Architettura in base
a stack dei protocolli: La pila, ancora in fase di evoluzione, possiede 5 strati principali: Network i web
services devono essere accessibili tramite rete per essere invocati da un service requestor. I Web services
che sono disponibili comunemente su Internet utilizzano a questo strato HTTP (altri protocolli cmq sono
supportati) XML-Based Messaging rappresenta l’uso di XML come protocollo per lo scambio dei messaggi. Il
protocollo scelto per lo scambio di messaggi XML è SOAP (standard document-centric utilizzato per
‘avvolgere’ i msg e le chiamate di procedura remota usando XML. Il msg SOAP viene spedito come
richiesta HTTP di tipo POST) Service Description strato responsabile della descrizione dell’interfaccia pubblica
di un Web service. WSDL è lo standard de facto, basato su XML, per la descrizione di un servizio. Oltre a
garantire l’interoperabilità, definisce l’interfaccia e il modo in cui si interagisce con il servizio. Service
Publication e Service Discovery rappresenta lo strato responsabile della centralizzazione dei servizi fornendo
le funzionalità di pubblicazione e ricerca di un servizio. Attualmente, lo standard utilizzato, basato su XML è
UDDI. Service Flow descrive come comunicazioni service-to-service, collaborazioni e flussi sono eseguiti.
XML è un linguaggio di markup, permette di: definire tag e loro grammatica (come devono essere
strutturati) indipendentemente da sistema usato e dal fornitore. Rispetto all'HTML, l'XML ha uno scopo
diverso: il primo definisce una grammatica per la descrizione e la formattazione di pagine web e, in
generale, di ipertesti, il secondo è un metalinguaggio utilizzato per creare nuovi linguaggi atti a descrivere
documenti strutturati. HTML ha un insieme ben definito e ristretto di tag, con l'XML è possibile definirne di
propri a seconda delle esigenze. A supporto di XML ci sono I linguaggi
schema (permettono di creare nuovi linguaggi XML): DTD (Document
Type Definition) è un documento attraverso cui si specificano le
caratteristiche strutturali di un documento XML attraverso una serie di
"regole grammaticali". In particolare definisce l'insieme degli elementi
del documento XML, le relazioni gerarchiche tra gli elementi, l'ordine
di apparizione nel documento XML e quali elementi e quali attributi
sono opzionali o meno. XSD (XML Schema) come la DTD, serve a
definire la struttura di un documento XML. Tecnica più recente ed
avanzata della DTD. XML SCHEMA definisce la struttura che deve
avere il documento; definisce gli attributi e gli attributi che possono
apparire in un documento, definisce quali elementi sono “figli” e il loro
numero; definisce se l'elemento è vuoto o può includere testo;
definisce i tipi di dati per gli elementi e gli attributi e definisce valori di
default e fissi per elementi e attributi. Migliore di DTD in quanto: XML
schema sono estendibili a future aggiunte; sono più ricchi e più utili di
DTD; sono scritti in XML; supportano data types e namespace. XML è
portable (trasportabile) in quanto un XSD associato ad un documento
permette al ricevente di validare (vedere se è strutturato bene) il

documento; in quanto XSD è leggibile/riscrivibile dall’uomo. WSDL Web Service Description Language:
linguaggio di definizione dei WS. Basato su XML, fornisce il meccanismo con cui le definizioni dei WS sono
rese pubbliche. Non solo descrizione delle procedure d’impiego di un servizio ma definisce anche il
protocollo di trasporto. WSDL consente ai Service Providers di fornire il modo in cui le richieste, da inoltrare ai
Web services, dovranno essere definite. In un documento WSDL si specificano la locazione fisica e le
operazioni disponibili per il servizio descritto. Si ha una descrizione astratta che comprende i tipi, i messaggi
e le operazioni e una descrizione concreta che dipende dal binding e dalla posizione in cui si trova il
servizio. Svolge in sintesi 3 funzioni fondamentali: WHAT (descrive I msg e I tipi di dati coinvolti durante
interazione con WS) HOW (descrive come accedere al WS attraverso il livello ditrasporto – es. con TCP)
WHERE (descrive locazione per accedere al WS). I principali tag XML che compongono una descrizione
WSDL sono: <types> all'interno sono definiti i tipi di dato complessi utilizzati dal Web service, servendosi della
stessa sintassi degli XSD. <message> indica quali sono le parti di cui è composto un msg, che dati verranno
comunicati. Un msg può essere composto da 1 o più parti (dati). <portType> raggruppa le operations
disponibili per il Web service, elencando per ognuna quali messages ne fanno parte (libreria). Types,
message e portType sono il WHAT. <binding> raggruppa un insieme di operazioni e gli assegna un tipo di
binding (che indica un portType). È l’HOW. <service> collezione di endpoint; raccoglie tutte le ports del
Web service. <port> rappresenta una singola implementazione del Web service: contiene un binding e un
indirizzo di rete (al quale le richieste verranno inviate). Service e binding sono il WHERE. WSDL 2.0,
cambiamenti: aggiunta di semantiche al linguaggio di descrizione; rimozione dei costrutti dei msg;
portTypes rinominate Interfacce; port rinominate endpoint. Problema dei ws: come scoprire partner di
business con soluzioni WS compatibili, come far conoscere ai partners I WS di cui dispongo? I web services
sono una gran cosa ma il processo di scoperta è difficile. Problema risolto da UDDI. UDDI (Universal
Description Discovery and Integration) è un directory service, dove le aziende possono registrare i propri
Web services e cercarne altri. Un registro UDDI contiene informazioni riguardanti un insieme di Web services,
tra le quali anche la loro descrizione WSDL, e i dati in esso contenuti sono accessibili tramite SOAP. UDDI è
stato proposto per fornire uno standard che mettesse in comunicazione le aziende con i clienti e i partners
fornendo informazioni riguardanti i propri prodotti e servizi. (È dunque uno degli standard alla base del
funzionamento dei Web Service: è stato progettato per essere interrogato da messaggi in SOAP e per
fornire il collegamento ai documenti WSDL che descrivono i vincoli protocollari e i formati dei messaggi
necessari per l'interazione con i Web Service elencati nella propria directory). Il registro UDDi fornisce tre tipi
di servizi: le pagine bianche, comprendono le informazioni di base sui contatti dell'azienda (ragione sociale,
indirizzo, codice DUNS) le pagine gialle, comprendono le informazioni sui servizi Web in base alle loro
categorie, per consentire, a chi esegue ricerche, di localizzare un certo tipo di servizio (ad esempio
produttori di automobili); le pagine verdi comprendono info tecniche sulle funzioni supportate dal servizio
Web ospitato dall'azienda (riferimento alle descrizioni dei Web services, localizzazione). Un registro UDDI può
essere pubblico o privato. MODELLO UDDI Le specifiche UDDI definiscono 1) l’interfacce Web del servizio:
publish API e inquiry API e 2) strutture dati utilizzate: a) Business entity: descrizione di un’azienda o altra
organizzazione che fornisce il servizio b) Business service: descrive una collezione di WS collegati offerta da
un organizzazione descritta da una Business entity (L’elemento businessService rappresenta un servizio
logico di business che pu`o essere erogato in modi diversi. c) Binding template (modello vincolante):
descrive info tecniche necessarie per l’uso di un WS (L’elemento bindingTemplate contiene le informazioni
tecniche per l’accesso al servizio. Uno stesso servizio logico pu`o essere associato a piu` binding template)
d) tModel: e un tipo di dato che permette la definizione di etichette utili alla classificazione delle
informazioni caratterizzate da una chiave unica.
Attraverso un tModel è possibile definire:
technical fingerprints per Web services;
namespaces utili per identitificare business entities
o per classificare business entities, business
service, e tModels. La realtà è che UDDi non è
così diffuso anche se ha il supporto di compagnia
quali IBM e Microsoft. È molto usato in piccoli
ambienti, ma a tale scopo è troppo complesso e
fornisce troppi tipi di dato. Microsoft, IBM, ecc
hanno spento I loro nodi UDDI pubblici nel 2006.
SOAP Simple Object Access Protocol: è un
protocollo (per SOA) leggero che permette lo

scambio di messaggi tra componenti software/applicazioni (in ambienti distribuiti) usando protocolli
standard di internet. Progettato per essere il più semplice possibile in modo da essere compreso/adottato
con semplicità, ma al tempo stesso abbastanza completo da poter trasmettere dati complessi. È basato su
XML, gestisce info strutturata e tipata; non definisce alcuna semantica per applicazioni o scambio
messaggi, ma fornisce un mezzo per definirla. STRUTTURA un msg SOAP è composto da: 1)Envelope:
elemento radice, obbligatorio, che identifica il documento XML come un msg SOAP 2)Header: opzionale.
Trasporta info non facenti parte del msg, destinate agli “attori” (varie parti che il msg attraverserà per
arrivare al destinatario finale) 3)Body, obbligatorio. Contiene il msg vero e proprio msg che deve essere
processato/recapitato + info su chiamate/risposte. Le regole principali che un messaggio SOAP deve
seguire sono: deve essere codificato in XML valido; deve far uso del SOAP Envelope Namespace; deve far
uso del SOAP Encoding Namespace; non deve contenere riferimenti ad un DTD ne istruzioni di XML
processing. DATA ENCODING: il concetto di encoding riguarda le info applicative contenute nel tag Body:
defisce come i dati vengono rappresentati in XML. I dati possono essere semplici (scalari) o composti (fatti
da più parti, ognuna è un dato semplice). TERMINOLOGIA: <accessor>value</accessor> accessor è chi
può accedere al valore; value è il valore del dato e/o combinazione di dati. I tipi strutturati sono una
combinazione di uno o più tipi semplici raggruppati come figli in un singolo accessor. Una struttura dati
SOAP è codificata tramite un elemento che contiene altri elementi nidificati. Ogni elemento è identificato
da un nome. SOAP CONTAINER accetta richieste in arrivo e le invia al servizio adeguato; traduce da SOAP
al linguaggio del servizio (es. Java). I clienti devono così conoscere solo l’indirizzo del servizio, non il
linguaggio, la piattaforma o la posizione. SOAP usa HTTP come protocollo di trasporto: si usa la modalità
POST per i msg (il blocco di dati è costituito dal msg SOAP vero e proprio). PROCESSI DI BUSINESS sono una
serie di attività (servizi) logicamente correlate che permettono di avere un outcome ben definito che crea
profitto. Peculiarità: possono richiedere interazioni più o meno formali tra i partecipanti; la durata è molto
variabile, attività possono essere manuali/automatiche; a lungo termine. WORKFLOW è la sequenza di passi
durante cui info/oggetti fisici vengono passati da uno step produttivo all’altro. Caratterizzato da presenza di
regole, punti di decisione, ruoli. PROCESSI WEB sono la prossima generazione di tecnologie per definire i
workflow. Sono creati tramite la composizione dei web services scoperti. WEB SERVICE COMPOSTI I service
provider offrono funzionalità che il workflow specifica che devono essere fornite da un business partner al
fine di creare un processo di business. Cioè, un service provider è un business partner che offre un servizio
indicato nel workflow, per eseguire un processo di business. Tale servizio è presentato tramite un’interfaccia
pubblica nella forma di documento WDSL. Composizione di WS: WS interconnessi che possono essere usati
come un nuovo servizio in altre composizioni. Mediante la composizione si crea un nuovo servizio a valore
aggiunto. Per farlo è necessaria la compatibilità fra le operazioni fatte dai WS. BPEL Business Process
Execution Language: linguaggio di programmazione testuale basato su XML costruito per la specifica
formale di processi di business e per I protocolli che definiscono le modalità di interazione fra processi di
business (in modo da permettere una suddivisione dei compiti tra attori diversi). ll linguaggio BPEL permette
di descrivere un business process mediante un insieme di attività, semplici o composte. BPEL fornisce molte
funzionalità per facilitare modellazione/esecuzione di processi di business basati sull’uso di WS, come:
modellazione del controllo dell’esecuzione dei processi di business; rappresentazione dei ruoli dei
partecipanti e dei loro rapporti, ecc. STRUTTURA: BPEL usa WSDL per specificare le attività che dovrebbero
prendere parte in un processo di business. Documento BPEL influenza (estende) WSDL in 3 modi: 1) un
processo BPEL espresso come WS usa WSDL: questo descrive entry pubbliche e endpoint del processo 2) I
tipi di dati WSDL usati in un processo BPEL descrivono le info scambiate tramite richieste 3) WSDL può essere
usato per referenziare servizi esterni richiesti da un processo di business. BPEL permette di considerare un
Web Service come un processo di collaborazione composto da altri Web Service, definendone una natura
di tipo ricorsivo e questo “processo di processi” così definito avrà una sua propria interfaccia WSDL. Un
processo definito mediante BPEL è composto da attività che rappresentano sia richieste di tipo client, sia
risposte al client medesimo; il processo si basa su una serie di Web Service che vengono chiamati partner
invocati attraverso l’attività di “invoke” che può essere di tipo sincrono o asincrono. BPEL “ORGANIZZA”
WSDL: wsdl insieme disordinato di operazioni (scambio di msg), BPEL fornisce: regole di ordinamento;
supporto per sequenzialità/concorrenza delle operazioni. Lo fa con 2 metodi: ORCHESTARTION; gestita da
BPEL. Un processo (eseguibile) di business descrive un flusso sotto il controllo di un endpoint vedendolo dalla
prospettiva di questo (= come un processo di business è visto da un endpoint). CHOREOGRAPHY (gestita da
WSDL) Il pubblico scambio (osservabile) di msg, le regole di interazione e di accordi tra due o più endpoint
di un processo di business. ATTIVITA’ BPEL – semplici: <invoke> Attività utilizzata per invocare una
determinata operazione di un Partner Link. <receive> esegue una wait bloccante aspettando che arrivi un

messaggio (una richiesta); è l'attività delegata ad istanziare il processo business. <reply> viene utilizzata per
rispondere al Partner Link che ha inviato il messaggio di richiesta, a conclusione del processo business. La
combinazione delle attività: <receive> e <reply> forma un’operazione di richiesta/risposta in WSDL. <assign>
aggiorna il valore di una variabile. <throw> genera un’eccezione (Un processo BPEL può fallire per vari
motivi: può esplicitamente lanciare un'eccezione; l'invocazione di un servizio esterno può non andare a
buon fine; possono verificarsi problemi a livello di ambiente d'esecuzione. Come in Java, possiamo sollevare
esplicitamente un'eccezione con il costrutto <throw>). <wait> mette in attesa per un tempo specificato.
<empty> operazione “no-op” utile per sincronizzare attività concorrenti. – strutturate: <sequence> Consente
l'esecuzione sequenziale di attivita. <flow> consente esecuzione parallela di attività. <switch> scelta tra
attvità. <scope> permette la creazione di “pacchetti” di attività. Ogni <scope> ha un'attività primaria,
solitamente <sequence> o <flow> + ogni <scope> ne può contenere altri annidati. RESTful web service
Representational State Transfer: fu introdotto come uno STILE ARCHITETTURALE per costruire sistemi distribuiti
su larga scala. Stile architetturale soggetto a questi vincoli: 1) risorse identificate tramite URI 2) interfacce
uniformi per tutte le risorse 3) msg autodescrittivi (uso di metadati) 4) interazione stateful. 1) cosa
identificano gli URI? Qualsiasi cosa debba essere identificata specialmente tutte le risorse ad alto livello che
le applicazioni web forniscono (oggetti individuali o collezzione di oggetti, risultati di computazioni, ecc). Un
processo o un passo di un processo, la richiesta per un preventivo, ecc. Queste “cose” identificate, in
cambio, possono portare alla creazione di entità più persistente rispetto ad un approccio tipico. 2)
l’interfaccia uniforme per tutte le risorse permette di avere 4 possibili azioni per tutte le risorse: PUT inizializza
lo stato di una specifica risorsa ad un URI definita; GET riceve lo stato corrente di una risorsa puntata con un
URI; POST modifica lo stato di una specifica risorsa; DELETE cancella una risorsa. Dopo questa operazione
l’URI che la identifica non sarà più valida. 3) Msg autodescrittivi tramite metadati: L'approccio adottato da
HTTP è quello di consentire una separazione tra quello che concerne la manipolazione dei dati e quel che
riguarda l’invocazione di operazioni. Ogni msg (HTTP) include abbastanza info per descrivere come
processare il msg a seconda se quetso serva a modificare dati o a invocare operazioni. 4) Interazione
stateful attraverso hyperlink (à quello che rende il web ciò che è): il serve fornisce una serie di link a dei
client; ciò consente al client di “muovere” un’applicazione da uno stato ad un altro (seguendo I link). Rest
ha il compito di trasformare lo stato in uno stato della risorsa e tenerlo lui o salvare questo stato Della risorsa
sul client. Così il server può salvare parte dei dati sui client, non deve necessariamente farsi carico di
memorizzare tutte le info sullo stato. à Rest dunque ha una diversa struttura rispetto ai WS classici. WS SOAP
(WSS) vs WS REST (WSR) Protocollo di trasporto: WSR HTTP, WSS molti protocolli (HTTP, TCP, SMTP, ecc).
Formato dei msg: WSR molti formati (XML-SOAP, RSS, JSON) WSS formato dei msg definito da XML-SOAP
(Envelope, Header, Body). Identificatore dei servizi: WSR URI, WSS URI e indirizzamento WS. Descrizione dei
servizi: WSR documentazione testuale o WADL (Web Application Description Language) WSS WSDL (Web
Service Description Language). Composizione servizi: WSR mashup WSS BPEL. Scoperta servizi: WSR nessuno
standard WSS UDDI. Approfondendo: Anche se l’obiettivo dei due approcci è pressocchè identico
(adozione del Web come piattaforma di elaborazione) la loro visione e la soluzione suggerita sono
differenti. La prima evidente differenza è la visione del Web proposta come piattaforma di elaborazione:
REST propone una visione del Web incentrata sul concetto di risorsa mentre SOAP su concetto di servizio. Un
ws RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del
protocollo HTTP. Un ws SOAP espone un insieme di metodi richiamabili da remoto da parte di un client. Il
protocollo SOAP definisce una struttura dati per lo scambio di messaggi tra applicazioni, riproponendo in un
certo senso parte di quello che il protocollo HTTP faceva già. A differenza di HTTP, però le specifiche di SOAP
non affrontano argomenti come la sicurezza o l’indirizzamento, quindi non sfrutta a pieno il protocollo HTTP,
lo usa come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di
livello applicativo, e ne utilizza a pieno le potenzialità. È evidente che l’approccio adottato dai ws basati su
SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web. Questo approccio può
essere visto come una sorta di adattamento di queste tecnologie al Web. L’approccio REST invece tende a
conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere
una piattaforma per l’elaborazione distribuita. Quindi non è necessario aggiungere nulla a quanto è già
esistente sul Web per consentire ad applicazioni remote di interagire. Inoltre i ws basati su SOAP prevedono
lo standard WSDL per definire l’interfaccia di un servizio. Questa è un’ulteriore evidenza del tentativo di
adattare al Web l’approccio di interoperabilità basato su chiamate remote. Da un lato l’esistenza di WSDL
favorisce l’uso di tool per creare automaticamente client in un determinato linguaggio di programmazione,
ma allo stesso tempo crea una forte dipendenza tra client e server. REST non prevede esplicitamente
nessuna modalità per descrivere come interagire con una risorsa, le operazioni sono implicite nel protocollo

HTTP. Qualcosa di analogo a WSDL è WADL, un’applicazione XML per definire risorse, operazioni ed
eccezioni previsti da un Web Service di tipo REST. In conclusione, i ws basati su SOAP costruiscono
un’infrastruttura prolissa e complessa al di sopra del Web per fare cose che il Web è già in grado di fare. Il
vantaggio di questo tipo di servizi è che in realtà definisce uno standard indipendente dal Web e
l’infrastruttura può essere basata anche su protocolli diversi. REST invece intende ripristinare il Web ad
architettura per la programmazione distribuita senza aggiungere sovrastrutture non necessarie. WS
SEMANTICI prima di tutto, concetto di ontologia: descrizione esplicita di un dominio. Riguarda: concetti
(del dominio), proprietà e attributi del concetto, vincoli su proprietà/attributi. Ontologie definiscono:
vocabolario comune + modalità condivisa di comprensione del vocabolario. Ontology engineering:
consiste nella definizione dei termini del dominio e la relazione che sussiste tra essi. Quindi comprende:
definizione dei concetti del dominio (classi); organizzazione gerarchica dei concetti (in superclassi,
sottocalssi), definisce che attributi e proprietà una classe può avere e I vincoli sui loro valori. Sviluppare
ontologie per: condividere la comprensione della struttura dell’info tra persone e tra agenti software;
riutilizzare conoscenze relative a un dominio (per evitare di rifare cose già fatte e per introdurre standard
che permettono l’interoperabilità). Nb. I metodi standard per descrivere I WS pongono il focus sul garantire
l’interoperabilità su diverse piattaforme ma non forniscono buoni strumenti per scoprire/integrare WS
differenti. WS semantici permettono sviluppo autonomo di processi che rappresentano complesse
interazioni tra organizzazioni. Ad oggi no standard condiviso/accettato per gestire WSS ma 2 approcci
promettenti: 1) WSMO Web Service Modeling Ontology: fornisce un modello concettuale per descrivere i
vari aspetti dei Web Services semantici. È un ontologia, basato su WSML (web services modeling language).
I web service sono descritti in WSMO secondo tre differenti punti di vista: proprietà non funzionali,
funzionalità e comportamento. Quindi un web service e definito dalle proprietà non funzionali, le ontologie
importate, i mediatori utilizzati e le sue interfacce. Un web service può essere descritto da interfacce
multiple, ma ha una ed una sola funzionalità. La funzionalità di un web service incapsula le sue funzionalità
e l'interfaccia di un web service descriver il comportamento del web service da due prospettive:
comunicazione e collaborazione. WSMO è composto da quattro elementi: 1) ontologia, che fornisce la
terminologia usata dagli altri elementi WSMO. Un’ontologia è composta da proprietà non funzionali
(l’insieme esistente di proprietà core predefinite), le ontologie importate, e la definizione dei concetti,
relazioni, assiomi, funzioni e istanze dell’ontologia. In aggiunta, questo meta-livello definisce gli ooMediator
che sono utilizzati per importare tutte le ontologie per le quali i problemi di allineamento, fusione e
trasformazione devono essere risolti durante l’importazione. 2) descrizione del Web service, che descrive gli
aspetti funzionali e comportamentali del Web service. 3)goal, obiettivi che formalizzano i desideri
dell’utente; 4)mediatori, che hanno lo scopo di gestire automaticamente i problemi d’interoperabilità tra
differenti elementi WSMO. I Mediators hanno l’obiettivo di risolvere i problemi di eterogeneità. I mediatori in
WSMO sono elementi speciali utilizzati per collegare componenti eterogenee coinvolte nella modellazione
di un Web service. WSMO enfatizza il ruolo dei mediatori per superare i problemi d’interoperabilità. Essi
definiscono tutti i mapping, le trasformazioni o le riduzioni necessarie tra gli elementi collegati. Ci sono
quattro differenti tipologie di mediatori: a) ggMediators, questi collegano tra loro due goal, ed esprimono la
riduzione da un goal sorgente ad un goal target. Possono utilizzare gli ooMediator per superare le differenze
nella terminologia utilizzate per riferirsi a questi goal. In aggiunta, WSMO permette il linking non solo dei goal,
ma anche dei goal dei ggMediator, permettendo di conseguenza il riuso di più goal per la definizione di
nuovi goal b) ooMediators, questi importano le ontologie e risolvono possibili incongruenze di
rappresentazione tra loro, come ad esempio per i linguaggi di rappresentazione differenti o
concettualizzazioni differenti dello stesso dominio c) wgMediators, essi collegano un Web service ad un
goal. Questi collegamenti rappresentano il raggiungimento (totale o parziale) del goal da parte del Web
service. I wgMediator possono utilizzare gli ooMediator per risolvere problemi di eterogeneità tra i Web
service e i goal d) wwMediators, questi collegano due Web service, che contengono gli ooMediator
necessari per superare i problemi di eterogeneità che possono sorgere nelle situazioni in cui i servizi utilizzano
vocabolari differenti. 2) OWL-S Il Web semantico dovrebbe consentire un ottimo accesso non soltanto ai
contenuti ma anche ai servizi presenti nel Web. Utenti ed agenti software dovrebbero essere in grado di
ritrovare, invocare, comporre e monitorare le risorse del Web oltre che farlo con un grado di automazione
scelto a priori. OWL-S è una ontologia di servizi che rende queste funzionalità possibili. OWL-S nasce con
l’obiettivo di rispondere alle seguenti domande: Cosa fornisce il servizio ad eventuali client? Come è
utilizzato? Come si interagisce? Per fornire risposta a queste domande sono necessari tre tipi essenziali di
conoscenza riguardo un servizio. La struttura di OWL-S fornisce essenzialmente un modello di
rappresentazione astratta del servizio. E’ un’ontologia di alto livello la cui radice è rappresentata dalla

Sistemi distribuiti

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Sistemi distribuiti

Similar a Sistemi distribuiti (20)

Más de Valeria Gennari

Más de Valeria Gennari (16)

Sistemi distribuiti