Il documento offre una panoramica dei sistemi distribuiti e dell'architettura del web, sottolineando l'importanza del protocollo HTTP e le interazioni tra client e server. Descrive i vari livelli di protocollo, evidenziando la stratificazione e le funzioni di ciascun livello, dal livello applicativo a quello fisico. Viene anche discusso l'uso di URL, indirizzi IP e metodi HTTP, inclusi meccanismi di autenticazione e gestione delle sessioni tramite cookie.

1. 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.

2. (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

3. 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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 <%@

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. classe Service, che corrisponde al servizio reale che viene descritto semanticamente (ciascun servizio
descritto è mappato come istanza di questo concetto). La classe Service è associata con tre altre classi:
ServiceProfile, ServiceModel e ServiceGrounding. Quindi Un servizio, in OWL-S si compone principalmente di
tre parti: 1) ServiceProfile cosa fa un servizio 2) ServiceGrounding come accedere al servizio 3) ServiceModel
come funziona il servizio. 1) Il Service Profile fornisce un modo per descrivere il servizio offerto da chi fornisce
servizi, e inversamente i servizi richiesti da un compratore che richiede servizi. Un profilo OWL-S descrive un
servizio in funzione di 3 tipi base di informazione: quale organizzazione fornisce il servizio, che funzione
computa il servizio, e un'insieme di caratteristiche che definiscono il servizio. L'informazione sul provider (il
fornitore del servizio) consiste in informazioni sul contatto che si riferisce all'entità associata al fornitore. La
descrizione funzionale del servizio è espressa in termini di trasformazioni prodotte dal servizio. Per ultimo,
permette la descrizione di un insieme di proprietà usate per descrivere le caratteristiche del servizio. OWL-S
profile include anche una lista di proprietà (espandibile) non funzionali espresse come parametri per il
servizio. 2) Per illustrare come un client puo interagire con un servizio e possibile definire un servizio come un
processo. Abbiamo due possibili distinzioni: o un servizio e un processo atomico, ovvero riceve in ingresso un
messaggio (anche complesso) e ne restituire un altro (anch'esso possibilmente complesso), oppure e un
processo composito, in cui si possono identificare i vari stadi e i messaggi passano da uno stadio all'altro. Un
processo può avere due possibili scopi. Può generare e restituire nuova informazione a partire dallo stato
del mondo e da ciò che e stato fornito. La produzione di informazione è descritta dagli input e dagli output
del processo. Oppure, può produrre un cambiamento nel mondo. Questa transazione è descritta dalle
precondizioni e dagli effetti del processo. Quando viene eseguito, produce vari effetti. 3) Il grounding di un
servizio specifica i dettagli su come accedere al servizio, in particolare gestisce protocollo e formato di
messaggi, serializzazione, trasporto, indirizzamento. Il grounding può essere pensato come un'associazione
tra una specifica astratta e gli elementi concreti che sono necessari per interagire con il servizio. In OWL-S
sia ServiceProfice che ServiceModel sono rappresentazioni astratte, solo ServiceGrounding si occupa del
livello concreto. Il concetto di grounding è simile a quello di binding di WSDL. Infatti, utilizzando elementi
estendibili già forniti da WSDL, diventa relativamente facile effettuare un collegamento a servizi concreti.
MASHUP miscuglio, poltiglia. Sono applicazioni web che integrano dinamicamente contenuti o servizi
provenienti da più fonti esterne, in genere con API, Feed (RSS o Atom) o Javascript. Rappresentano un
genere davvero innovativo di appl web interattive che riutilizzano dati disponibili presso fonti esterne per
creare servizi completamente nuovi. Sono il marchio distintivo della 2’ generazione di applicazioni web
(web 2.0). Nascita: è una pratica recente. Le prime appl sviluppate con questa tecinca nel 2005, durante
evento “Mashup camp” a Mountain View. Solo nel 2007 prime releases uffciali dei servizi per lo sviluppo di
mashup come Yahoo! Pipes, Google Mashup Editor ecc. nel 2009 calo dei servizi disponibili, alcuni
abbandonati o integrati con altri progetti. Interessano perchè ad oggi si è sempre più interessati al riutilizzo
di quello che già c’è. Popolarità mashup deriva da: capacità di fornire interattività a utente e a
applicazioni + capacità di aggragare e reinventare gli insiemi di dati prodotti da terzi. Un sito web basato su
utilizzo di mashup è in grado di ricevere contenuti provenienti da fonti esterne: correlazione di contenuti
provenienti da fonti non correlate + allargamento e contestualizzazione dell’info (es. realtà aumentata).
Caratteristiche mashup: manipolazione dei dati = selezione e filtraggio dati + combinazione/aggragazione
dati + normalizzazione e traduzione dati + visualizzazione dati. Pro: “Lightweight” application; volume di
codice ridotto, basso costo di sviluppo dell’applicazione. Facilità di sviluppo dell’appl; disponibilità di tools
che non richiedono grandi competenze. Disponibilità di vast basi dati. Bassi (o nulli) costi di acquisizione e
aggiornamento dati. Set-up dell’applicazione rapido, possibilità di quick prototyping. Contro: forte
dipendenza dalla sorgente dei dati in termini di qualità, prestazioni, disponibilità, continuità del servizio,
cambiamento di politiche di serv. Necessita di API:soggette all’avvento di nuovi standard/versioni, il che le
rend edinamiche. Proprità intellettuale e copyright dei dati. Privacy: incorciare e filtrare dati può generare
problemi non esistenti nei dati originali. Logica di presentazione: Mashup può corrispondere a precise
metafore di presentazione e quindi di navigazione/interazione: 1)metafora spaziale (elementi sono
aggregati e presentati in base a loro collocazione spaziale, es. Google Maps) 2)metafora temporale (elem
sono aggregati e presentati in base a loro collocazione temporale, es. Simile-Timeline) 3)metafora
documenti/attività (elem sono i documenti che vengono aggregati in base a appartenenza a
processi/attività). Tramite le API si ha accesso diretto ai dati. WEB SCRAPING è una tecnica per estrarre
informazioni da un sito web per mezzo di programmi software. Obiettivo: trasformare unstructured web
content (in html) in dati strutturati che possono essere salvati in database locali. È considerato una soluzione
poco elegante: a differenza delle API non c’è uno standard contrattuale che lega chi fornisce il contenuto
e chi lo utilizza; contenuto dei siti web è definito mediante strutture eterogee inoltre ha la tendenza ad

19. essere aggiornato di frequente. VIRTUALIZZAZIONE Cenni storici: tardi anni ’60 mainframe grossi e costosi;
necessità di smistare risorse scarse tra tante applicazioni; partizione di un hardware in tante macchine
virtuali con il virtual machine monitor (VMM). Anni ’80 ’90: abbattimento costi hardware; avvento
minicomputer e pc; sistemi operativi multitaking; VMM scompaiono fino a quando non vengono creati
componenti hardware abbastanza potenti per implementarle in modo efficiente. Nell’architettura
tradizionale: hardware = applicazione, sistema operativo, storage. Ci sono server dedicati a finalità diverse
(es. App server, DB server, email server…) se si rompe un server si perde in toto la funzionalità svolta da quel
server. Pro architettura tradizionale: facile da concettualizzare; deployment abbastanza semplice; backup
semplice. Contro: hardware dispendioso da comprare e mantenere; scalabilità ridotta; difficoltà di
replicazione; ridondanza difficile da implementare (server ridondanti: che replicano quello originale). Tardi
anni ’90: macchine a massiccio processing parallelo sono difficili da programmare e necessitano di sistemi
operativi ad hoc; macchine virtuali possono venire utili per rendere queste macchine abbastanza simili alle
piattaforme esistenti. Oggi: caduta del costo dell’hardware ha fatto proliferare le macchine; queste
macchine spesso sono quasi virtualizzate; le maggiori funzionalità dei SO li hanno resi sia più potenti che più
fragili e vulnerabili: ad oggi la virtualizzazione è più una soluzione per la sicurezza/affidabilità che per il
multitasking. Virtualizzaizone è un metodo per dividere le risorse di un PC in più ambienti di esecuzione
applicando uno o più concetti o tecnologie (come partizionamento hardware e sofrtware; time sharing =
utilizzo delle risorse a rotazione; simulazione/emulazione parziale/totale di macchine). Permette di usare più
sistemi operativi in contemporanea su un singolo PC. Questo metodo permette di intordurre nuove funzionalità
senza aggiungere complessità agli hardware/softqare già esistenti. I crescenti sviluppi nel campo della
virtualizzazione possono essere applicati a diverse aree di ricerca.
Virtualizzare perchè: l’hardware cambia velocemente, i software
di alto livello cambiano lentamente. Virtualizzazione permette di far
girare i software presenti sulle nuove piattaforme e di incapsulare
un’applicazione nella sua macchina virtuale. Questa modalità
incentiva/semplifica la portabilità: un’applicazione o un server può
girare su piattaforme eterogenee fin quando c’è un’interfaccia
comune come un VMM. La macchina virtuale “lavora” su 4 tipi di
interfacce 1)Unprivileged machine
instructions: un’interfaccia per la
parte di hardware disponibile ad
ogni programma 2)Privileged
instructions: forniscono
un’interfaccia dell’hardware per
il SO 3)System calls forniscono un’interfaccia del SO per le
applicazioni 4)API interfaccia del SO attraverso le system calls
(usate spesso per nascondere l’interfaccia fornita dalle system
calls) (2 e 3 a livello di SO). Ci sono 2 tipi di virtualizzazione:
1)Process virtual machine: virtualizzazione con
interpretazione/emulazione; fatta per un solo processo; fornisce un
instruction set per una macchina astratta. I programmi sono
compilati nel codice della macchina virtuale che può essere
interpretato o emulato. 2)Virtual machine monitor: fornisce una
macchina virtuale a diversi programmi in esecuzione simultanea. Funziona come se molte CPU girassero su
una singola piattaforma. Molto importante per sistemi distribuiti perchè le applicazioni rimangono isolate e
gli errori sono relativi ad una sola macchina virtuale. SERVER VIRTUALE può essere identificato in base alle
funzioni che svolge. Se l’ambiente è costruito correttamente i server virtuali non possono soffrire per la
mancanza di host. Gli host possono essere rimossi/introdotti praticamente a piacimento. Facile da scalare.
Server virtuali possono migrare da un host all’altro. Virtualizzazione del server permette: cambiare livello di
astrazione; multiplazione/demultiplazione risorse; traduzione tra specifiche equivalenti. I pro di questo
metodo sono: alta ridondanza e disponibilità; pool di risorse (fisiche); rapido deployment di nuovi server;
possibilità di riconfigurare mentre i servizi sono in esecuzione. DISACCOPPIAMENTO HARDWARE/SOFTWARE:
Obiettivo della virtualizzaizone è disaccoppiare il comportamento delle risorse hardware e software di un
sistema di elaborazione, così come viste dall’utente, dalla loro realizzazione fisica. VMM ha un controllo
completo su come i SO guest usano l’hardware. Un VMM fornisce una vista uniforme dell’hardware
sottostante, permettendo a macchine di produttori diversi con diversi I/O di risultare uguali. Quindi una

20. macchina virtuale può girare su ogni computer presente. L’hardware diventa un pool di risorse che può
eseguire arbitrariamente servizi su richiesta. Per completare l’incapsulamento di un software in una virtual
machine il VMM può mappare e rimappare a volontà le macchine virtuali alle risorse hardware disponibili
ed eventualmente far migrare le macchine virtuali tra le varie macchine fisiche. Il bilanciamento del carico
così diventa molto semplice; modelli robusti per gestire i guasti hardware e per scalare i sistemi; forte
isolamento tra macchine virtuali; abbassamento costi hardware e requisiti di spazio; aumento
dell’affidabilità e della sicurezza. Obiettivi VMM: Compatibilità (chiaramente importante, l’obiettivo primario
dei VMM è quello di far girare software legacy) Performance (il VMM deve far girare il software alla stessa
velocità cui girerebbe su una macchina reale) Semplicità (è particolarmente importante perché se un
VMM crasha può causare il fallimento di tutte le macchine virtuali in esecuzione su pc. In particolare, fornire
un isolamento sicuro richiede che il VMM sia privo di bug che gli aggressori potrebbero usare per sovvertire il
sistema). 3 TECNICHE DI IMPLEMENTAZIONE: 1)Virtualizzazione CPU (processore) una cpu è virtualizzabile se
supporta la tecnica del VMM della “direct execution”, cioè esecuzione di una macchina virtuale facendo
in modo che il VMM abbia il pieno e diretto controllo della cpu. Per fare ciò il VMM (che è a “un livello più
basso”) deve essere eseguito con “privileged mode” (kernel mode) e la macchina virtuale (che sta ”a un
livello più alto”) in “unprivileged mode” (user mode). Ciò è possbile implementando modi che permettano
al VMM di usare la cpu in modo diretto, sicuro e trasparente nell’eseguire la macchina virtuale. Questi
meccanismi sono semantiche e permettono al VMM di dare l’illusione al software eseguito sulla macchina
virtuale di essere eseguito su una macchina fisica. Non tutte le macchine hanno la cpu virtualizzabile al
100%, esistono anche tecniche per implementare VMM su CPU che non possono essere virtualizzati:
a)PARAVIRTUALIZZAZIONE, se ne occupa il VMM builder: definisce l’interfaccia della macchina virtuale
rimpiazzando parte dell’infrastructure set originale, non virtualizzabile, con altre facilmente virtualizzabili. I SO
devono essere adattati, le applicazioni possono così girare senza doverle modificare. b)ALTRA TECNICA:
esecuzione diretta combinata con traduzione binaria veloce (la macchina virtuale ritraduce velocemente
le istruzioni). Garantisce: macchine virtuali ad alte prestazioni che mantengono la piena compatibilità
software; alto controllo sul codice tradotto. Es. VMware. 2)Virtualizzaizone della memoria tecnica tradizionale:
VMM che mantiene l’ombra della memoria della macchina virtuale/gestisce le strutture dati (la shadow
page table, copia parallela di quella fisica). Questa struttura permette al VMM di controllare con precisione
quali pagine di memoria sono disponibile alla macchina virtuale. Problema: VMM ha informazioni peggiori
rispetto al SO guest su che pagine sono “buoni candidati” per essere scartate (meccanismo carica/scarica
è molto delicato). VMM può fare uso delle tecniche di paginazione. Occorre un meccanismo efficiente
che consenta al VMM di reclamare ed ottenere in caso di necessità dalle diverse macchine virtuali porzioni
di memoria meno utilizzate. Soluzione: su ogni macchina virtuale è in esecuzione un processo (balloon process)
che comunica con il VMM. La richiesta del balloon process provoca da parte del SOguest il trasferimento su
disco delle pagine meno utilizzate dalla macchina virtuale e la loro comunicazione al balloon process e
quindi al VMM. L’effettiva gestione della memoria è ancora un problema. 3)Virtualizzazione I/O moderni
ambienti supportano un enorme numero di periferiche imput/output, perciò è complesso e difficile scrivere
un VMM che sia in grado di comunicarci, specialmente se questi devices richiedono alte performance (il
lavoro di scrittura di uno livello di VMM che parla a questi vari dispositivi diventa uno sforzo enorme. Inoltre,
alcuni dispositivi hanno requisiti dalle elevate prestazioni). La soluzione VMware è quella di sfruttare le
caratteristiche degli host so. I vantaggi sono: VMM semplice da installare; VMM può usare tutti servizi
dell’host SO; l’I/O è a carico dell’host SO. Svantaggi: può generare sovraccarico; lentezza delle operazioni
I/O. RIASSUMENDO caratteristiche virtualizzazione: separazione/isolamento tra hardware/software;
virtualizzazione processi (PVM: esegue il processo sotto il controllo del livello di software); virtualizzazione
sistemi (VMM: esegue il sistema sotto il controllo del livello di software). FORMATO DEI DATI SCAMBIATI –
JSON JavaScriptObjectNotation: è un formato adatto per lo scambio dei dati in applicazioni client-server. È
basato sul linguaggio JavaScript, di fatto un sottoinsieme della sintassi Javascript ma ne è indipendente. La
maggior parte dei linguaggi di programmazione possiede un typesystem molto simile a quello definito da
JSON per cui sono nati molti progetti che permettono l'utilizzo di JSON con altri linguaggi quali: C, C++, C#,
Java, JavaScript, Perl, PHP. Può rappresentare dati complessi o semplici. Tutti i tipi di dati sono intuitivi e simili
agli altri linguaggi di programmazione. La semplicità di JSON ne ha decretato un rapido utilizzo
specialmente nella programmazione in AJAX. Il suo uso tramite JavaScript è particolarmente semplice,
infatti l'interprete è in grado di eseguirne il parsing tramite una semplice chiamata alla funzione eval(). I tipi
di dati supportati da questo formato sono: booleani (true/false); Numeri (interi, reali, virgola mobile); stringhe
racchiuse da doppi apici ("); array (sequenze ordinate di valori, separati da virgole e racchiusi in parentesi
quadre); Oggetto (raccolta di “chiavi” separato da virgola: coppie di valori racchiusi tra parentesi graffe).

21. Proprietà: è allo stesso tempo un formato leggibile dall’uomo e dalla macchina. Ha un supporto per
unicode, che permette a quasi tutte le info in linguaggio umano di comunicare. Formato di
autodocumentazione decrive struttura e nome del settore come valori specifici. Precisa sintassi e analisi dei
requisiti che permettono all’analisi degli algoritmi di rimanere semplice, efficiente e coerente. Ha l’abilità di
rappresentare le più generali strutture di dati della computer science. JSON in AJAX JSON viene usato in
AJAX come alternativa a XML/XSLT. Può essere incluso direttamente nell’html. Usato come
XMLHttpRequeste può essere convertito in una struttua Javascript. Può sostituire XML, ne usa gli stessi dati.
Estendibilità ridotta di XML rispetto JSON. Problemi di sicurezza: supporto javascript può accedere al
contenuto di una pagina web solo se sia codice javascript che pagina web provengono dallo stesso
dominio. Siti malintenzionati potrebbero servirsi di Javascript per impossessarsi di info sensibili dagli altri siti
usando credenziali del client. Anche se codice javascript maligno non può modificare direttamente
contenuto, si può visualizzare esecuzione del Javascript e memorizzare risultati restituiti. Problema è
aggravato con Json (array di Json sono oggetti di javascript e qualche malintenzionato può vederli
direttamente). RSS (RDF Site Summary ed anche di Really Simple Syndication) è uno dei più popolari formati
per la distribuzione di contenuti Web; è basato su XML, da cui ha ereditato la semplicità, l'estensibilità e la
flessibilità. RSS definisce una struttura predefinita adatta a contenere un insieme di notizie, ciascuna delle
quali sarà composta da vari campi (nome autore, titolo, testo, riassunto...) Quando si pubblicano delle
notizie in formato RSS, la struttura viene aggiornata con i nuovi dati; visto che il formato è predefinito, un
qualunque lettore RSS potrà presentare in una maniera omogenea notizie provenienti dalle fonti più diverse.
COME VENGONO USATI Un'applicazione in grado di interpretare un documento RSS ne effettua il parsing,
ovvero una scansione del documento che individua i tag e isola i diversi elementi, per poi convertire i
contenuti decodificati nel formato utile all'obiettivo. Es. un feed reader può estrarre i titoli di tutti gli elementi
item per visualizzare la lista degli articoli di un giornale online, mentre un aggregatore Web può estrarre i
contenuti del feed per convertirli in linguaggio HTML e incorporarli all'interno delle proprie pagine. XML è un
metalinguaggio, cioè un linguaggio sulla cui base vengono creati nuovi linguaggi. XML definisce le regole
di base per la creazione di linguaggi markup, cioè linguaggi il cui contenuto (testuale) è strutturato tramite
particolari delimitatori detti tag; permette di creare facilmente linguaggi ad-hoc per contenere
informazione strutturata; è completamente text-based, quindi leggibile anche dagli esseri umani e
facilmente editabile anche a mano. Le strutture definite con XML sono utili anche per creare strutture dati
indipendenti dalla piattaforma ed auto-descrittive (RDF). Elaborazione automatica (da parte di un pc) di un
linguaggio XML è particolarmente semplice ed efficiente. Elementi XML regole di base: Ogni documento
XML deve avere un unico elemento “radice”, in cui tutti gli altri sono nidificati (per gli RSS è il tag <rss>). Ai
tag possono essere associati attributi con il relativo valore, un elemento è un frammento di dati, limitato ed
indentificato tramite un nome da un tag (<nomeTag>). Il contenuto di un elemento è tutto ciò che appare
tra il suo tag di apertura e il suo tag di chiusura. Gli elementi possono essere nidificati, cioè possono far parte
del contenuto di un elemento più esterno. Ogni elemento deve essere chiuso, cioè il suo tag di chiusura
deve apparire prima della fine del documento. Nel caso di elementi nidificati, i tag di chiusura devono
apparire in ordine inverso a quello di apertura, cioè i contenuti degli elementi non si possono “accavallare”.
Gli elementi possono avere attributi (version) associati con il relativo valore (2.0). Sintassi RSS: livello più alto
di un documento RSS è costituito da un elemento <rss> con un attributo obbligatorio chiamato version, che
specifica la versione RSS con la quale il file risulta conforme. Per essere conforme a queste specifiche
attributo version deve avere valore 2.0. Subordinato a elem <rss> è l’elemento <channel> che contiene info
relative al canale e il suo contenuto. Elementi obbligatori per l’elemento <channel> sono: <title> <link>
<description>. Elementi opzionali: <language> <pubdate> <lastBuildDate> <generator>. Un channel può
contenere un qualsiasi numero di <item>. Item rappresenta una info, come ad es una notizia su un giornale
(in questo caso la sua descrizione è una sintesi della notizia e il collegamento indirizza alla notizia completa)
<item> può contenere anche info sufficienti per essere autonomo (in questo caso la descrizione contiene il
testo HTML e i tag <link> e <title> possono essere omessi). Gli elementi di un <item> possono essere opzionali,
ma deve esserci almeno un <title> o una <description>. INTEROPERABILITA’ SEMANTICA: L’integrazione è un
problema che si presenta ogni qualvolta si decide di realizzare un sistema a partire da una serie di
componenti sviluppate in modo autonomo. L’interoperabilità è una possibile soluzione: capacità di
comunicare, eseguire programmi o trasferire dati tra varie unità funzionali in modo da richiedere poca o
nessuna conoscenza caratteristiche proprie di tali unità. Tipi di Interoperabilità: Semantica; strutturale;
sintattica. Il concetto di SOA abilita flessibilità e dinamismo tramite una descrizione ricca del servizio e un
meccanismo di pubblicazione/scoperta di tali descrizioni che permette a richiedenti occasionali di
interagire con il servizio senza (o con limitate) conoscenze a priori. Una discovery agency può essere

22. realizzata in diversi modi. Registro: i service provider richiedono al registro di rendere disponibili sul mercato i
proprio servizi. Indice: i service provider rendono disponibile la descrizione per una indicizzazione esterna (es.
Google). Nessun accordo esplicito tra provider e indice. P2P: Service provider e service requester hanno
anche il ruolo di discovery agency. Tramite UDDI: un registro UDDI (v 3.0) contiene: Pagine Bianche (Nome
del service provider, identificativo, indirizzo e altre informazioni per contattare la società) Pagine Gialle
(Sistemi di classificazione di service provider e servizi su base geografica, tipo di industri, etc) Pagine Verdi
(Descrizione tecnica delle interfacce del servizio e del punto di accesso utilizzando opportuni “tModel”)
tModel (Definizione tecnica di un tipo di servizio tipicamente emessa da enti di standardizzazione di specifici
domini per essere utilizzata dai service provider). Oggetti nel repository (gli oggetti descritti sopra sono
immagazzinati come metadati nel registro UDDI, che prevede API per scrivere e cercare nel repository).
Nell’implementazione di una SOA usando i WS, dove sta la semantica dell’informazione scambiata? In
parte è codificata nella descrizione del servizio (WSD), ma quella che abilita l’interazione resta nella testa
delle persone. l Semantic ws stanno rendendo disponibili meccanismi per rendere la semantica elaborabile: la
semantica può essere resa elaborabile dalle macchine tramite le ontologie perchè abilitano la
comprensione dei simboli da parte delle persone e allo stesso tempo la loro elaborabilità. Web sematico no
separato, ma un’estensione del web attuale in cui le informazioni sono strutturate con un senso compiuto, migliorando
il lavoro tra le persone e i computer. Nella pratica il web semantico è una sezione di lavoro del W3C che si
occupa di produrre documenti, soluzioni ed esperienze per consentire al web prossimo futuro di acquisire un
senso più compiuto, contribuendo a fornire alle persone uno strumento più completo, efficace, utile. Nel
Web 1.0 uomo comprende quello che la macchina rende leggibile, nel Web semantico uomo e macchina
parlano lo stesso linguaggio. RDF (Resource Description Framework) è modello per rappresentazione dati sul
web. Principi base Triple: unità base di organizzazione sul web, Grafi orientati: insieme di triple, URI:
identificazione univoca sul web di oggetti rappresentati. RDF linguaggio generico per rappresentare info nel
web. Sintassi XML + Statements (istruzioni) <subject> <predicate> <object> + URI per identificare ogni cosa di
cui si parla (resource) + ogni cosa può essere una risorsa (un pezzo di info, un documento, il concetto di una
particolare ontologia, sogg, predicato, ogg). URI (Uniform Resource Identifier) Identifica univocamente un
contenuto su Internet, sia esso un file di testo, un immagine, un video, un programma o quanto altro. Un URI
generalmente descrive il meccanismo da usare per accedere alla risorsa + specifica in quale computer la
risorsa può essere trovata + specifica il percorso all'interno del computer e il nome della risorsa. A sua volta
composto da URL (specifico per identificare chi è locators primario) e URN (serve come persistente
identicatore delle resource indipendentemente dalla locazione e non implica disponibilità a identificarsi).
Caratteristiche: indipendenza (dal momento che predicati sono risorse, qualsiasi organizzazione
indipendente può inventarli) intercambiabilità (dal momento che proprietà RDF possono essere convertite
in XML, è facile usarlo in modo interscambiabile) scalabilità (proprietà RDF sono 3: sogg, predicato, ogg:
facile maneggiarle) le proprietà sono risorse (ciò significa che essi possono avere le loro proprietà e possono
essere trovati e manipolati come qualsiasi altra risorsa) soggetti e oggetti possono essere risorse (quindi
anche questi godono di proprietà). RIA Rich Internet Application: applicazioni web che possiedono le
caratteristiche e le funzionalità delle applicazioni desktop, senza però necessitare dell'installazione sul disco fisso. Le RIA
si caratterizzano per la dimensione interattiva, la multimedialità e per la velocità d'esecuzione. Infatti la parte
dell'applicazione che elabora i dati è trasferita a livello client e fornisce una pronta risposta all'interfaccia utente,
mentre la gran parte dei dati e dell'applicazione rimane sul server remoto, con notevole alleggerimento per il computer
utente. Le RIA si fondano perciò su un'architettura di tipo distribuito. Anche l'interazione con una RIA avviene in remoto,
tramite un comune web browser. RIA rappresentano una generazione di applicazioni che permette un'interazione
totalmente rinnovata, fondata sugli aspetti migliori delle caratteristiche funzionali e progettuali che finora erano
prerogativa alternata del web o delle applicazioni desktop. Inoltre le RIA, x interattività che offrono, rappresentano uno
dei canali migliori attraverso il quale si va imponendo il paradigma del Cloud, nuova modalità di fruizione del software
tramite architetture distribuite. SERVIZIO, ASTRATTO/CONCRETO, BASE/COMPOSTO, SEGMENTO DI UTENZA, PROP
FUNZIONALI/NON, QUALITA’ Un servizio consiste in un’attività o serie di attività, di natura più o meno
intangibile, che hanno luogo in uno scambio tra un fornitore e un cliente, dove l’oggetto della transazione
è un bene intangibile; lo scambio dura nel tempo, e durante lo scambio fornitore e cliente sono
coproduttori di valore. Servizi astratti: quando si considerano I servizi indipendentemente dalla loro concreta
realizzazione. Servizi concreti: quando si considerano i servizi realizzati, a un servizio astratto possono
corrispondere diversi servizi concreti mentre ad un servizio concreto corrisponde un solo servizio astratto. Il
servizio concreto rappresenta l’implementazione disponibile di un servizio astratto ad esso associato; viene
quindi descritto oltre che dall’associato servizio astratto, dall’insieme delle caratteristiche non funzionali e di
qualità che lo contraddistinguono rispetto ad altri servizi concreti associati allo stesso servizio astratto.
Servizio base descrive un servizio non ulteriormente scomponibile (o che non si ha interesse a scomporre) in

23. altri servizi e la cui specifica funzionale viene espressa in termini di un ins. di attività opportunamente
organizzate. Servizio composto, la cui specifica funzionale viene espressa in termini di altri servizi di tipo base
e/o composto. Un segmento di utenza è un gruppo di individui e/o di imprese che rispetto alla necessità di
invocare il servizio e/o la propensione a spendere per fruire del servizio sono simili riguardo a specifiche
caratteristiche come l’età, il sesso, gli interessi, le abitudini di spesa. Un servizio astratto è caratterizzato da 3
tipi di proprietà: Metadati; Proprieta’ funzionali; Proprietà non funzionali definite da una norma. Un servizio
concreto è caratterizzato da 4 tipi di proprietà: Metadati; Proprietà funzionali; Proprietà non funzionali;
Qualità percepite dagli utenti del servizio. Proprietà funzionali: A un servizio possono essere associate n
proprietà funzionali (n>=1). Le proprietà funzionali di un servizio s possono essere espresse con un insieme di
funzioni fs1, fs2, ..., fsn, ciascuna delle quali esprime COSA il servizio fa per l’utente. Le proprietà non
funzionali di un servizio specificano COME il servizio esegue le funzionalità connesse alle proprietà funzionali.
La qualità dei servizi può essere espressa secondo 2 modalità complementari: La qualità soggettiva è
valutata chiedendo percezione della qualità. Es: Emissione passaporto, si può chiedere a utente di
esprimere percezione sulla rapidità con cui passaporto è stato emesso. La qualità oggettiva è espressa
attraverso un certo num di caratteristiche (o dimensioni) associabili al servizio, a cui è possibile associare
delle metriche, che ne forniscono una quantificazione in un dominio numerico, e dei metodi di misurazione,
che permettono di organizzare una sessione di misura il cui esito è la associazione di una misura alla
metrica. Es: passaporto, possiamo misurare il tempo medio intercorso tra le richieste di un insieme di utenti,
considerati a campione, e l’erogazione passap. VALORE D’USO/DI SCAMBIO COME SI CALCOLANO,
ASSESMENT DEL VALORE DEI SERVIZI/D’USO/DI SCAMBIO Valore d’uso: per l’utente (che richiede il servizio) i
benefici che ha l’utente, commisurati ai sacrifici che deve compiere per fruire del servizio. Valore di
scambio: per il provider (che fornisce il servizio) i ricavi che ha il provider commisurati ai costi che deve
sopportare per offrire il servizio. Come si misurano il valore d’uso e il valore di scambio? Specifica del servizio:
caso più semplice, consideriamo un singolo servizio s specificato mediante una descrizione d(s)=[M ,F ,NF ,Q
] dove: M è un insieme di metadati (es: utenza potenziale) associati ad s; Fs è l’insieme delle funzionalità
offerte di s; NFs è l’insieme delle proprietà non-funzionali di s; Qs è l’insieme delle qualità percepite di s.
Calcolo del valore d’uso: Il valore d’uso per uno specifico servizio s e per uno specifico utente u, viene quantificato
mettendo in relazione i benefici e i sacrifici derivanti dalla sua fruizione. vu(s,u)=fb,s(benefici(s,u),sacrifici(s,u)).
benefici(s,u)= fben(Fs,NFs,Qs,WFs,WNFs,WQs) dove: WFs è l’insieme dei pesi nell’intervallo [0..1] dei benefici
percepiti da u e relativi a Fs. WNFs è l’insieme dei pesi nell’intervallo [0..1] dei benefici percepiti da u e relativi
a NFs. WQs è l’insieme dei pesi nell’intervallo [0..1] dei benefici percepiti da u e relativi a Qs. La somma di WFs
,WNFs eWQs deve essere 1. sacrifici(s,u)=fsac(prs,effs,wpr,weff) dove: prs è il prezzo a cui è venduto il servizio s.
effs è lo sforzo dell’utente per invocare ed ottenere s. Può essere misurato, ad esempio, in termini di tempo.
wpr è il peso nell’intervallo [0..1] dei sacrifici percepiti da u e relativi a prs . weff è il peso nell’intervallo [0..1]
dei sacrifici percepiti da u e relativi a effs. La somma di wprs, e weff deve essere 1. Calcolo dei pesi: I pesi
WFs,WNFs,WQs relativi ai benefici vengono determinati mediante l’analisi di un insieme di fonti di conoscenza, es.:
Questionario erogato all’utente u; Knowledge base di CRM (Customer Relationship Management); Analisi
delle interazioni fra l’utente e il provider. Ciascun peso viene distribuito sull’insieme a cui si riferisce, sempre
mediante l’analisi delle sorgenti informative disponibili. Normalmente il valore d’uso non viene calcolato per
uno specifico utente ma a livello di segmentodi utenza. In tal caso, la formula del valore d’uso non cambia.
I pesi vengono determinati anche in questo caso dall’analisi delle fonti di conoscenza disponibili. Calcolo
del valore di scambio: Il valore di scambio quantifica, per uno specifico provider p ed in un intervallo di
tempo t, i ricavi che ha il provider commisurati ai costi che deve sopportare per offrire il servizio s. vs(s,p,t) = ricavi –
costi. dove: ricavi= risultati delle vendite di s da parte di p nel periodo t. = prezzo(s,p)*#acquisti di s da parte
degli utenti. = prezzo (s,p) * prob. che un utente invochi s * # di acquisti per utente * # utenti. costi= costi di
produzione ed erogazione di s per p nel periodo t. = costi fissi di produzione del servizio s + #serviziprodotti * costo
di produzione di un servizio + #servizi venduti * costo di erogazione di un servizio. L’Assessment del valore dei servizi
ha l’obiettivo di: Misurare il valore (d’uso) che i diversi gruppi di utenti percepiscono dall’utilizzo dei servizi
attuali; Misurare il valore (di scambio) che i provider stimano dalla produzione ed erogazione dei loro servizi.
INPUT: Descrizioni dei servizi da valutare + Segmenti di utenza associati a ciascun servizio. OUTPUT: Matrice
che associa valore d’uso e valore di scambio a ciascuna coppia <servizio, segmento utenza>. Metodologia
per il calcolo del valore d’uso in fase di assessment: 1) Formulare un questionario con lo scopo di:
Determinare il peso che gli utenti attribuiscono alle proprietà funzionali, non-funzionali e qualità del servizio.
Determinare i pesi che gli utenti attribuiscono a ciascuna proprietà funzionale, non-funzionale e qualità.
Determinare valori ottimali e accettabili che gli utenti attribuiscono a ciascuna proprietà non-funzionale.
Valutare la qualità percepita dagli utenti nell’utilizzo del servizio attuale. 2) Selezionare un campione utente

24. per ciascuno dei segmenti utenti associati al serv. Per ottenere un campione significativo si estraggono un
numero di utenti in proporzione alla cardinalità del segmento. 3) Erogare il questionario ai campioni utente
selezionati. 4) Analizzare i risultati al fine di: Determinare il peso che gli utenti attribuiscono alle proprietà
funzionali, non-funzionali e qualità del servizio. Determinare i pesi che gli utenti attribuiscono a ciascuna
proprietà funzionale, non-funzionale e qualità. Determinare valori ottimali e accettabili che gli utenti
attribuiscono a ciascuna proprietà non-funzionale. Valutare la qualità percepita dagli utenti nell’utilizzo del
serv attuale. 5) Esplicitare formula fbs per il calcolo del valore d’uso. Specifica di pesi e applicazione delle
formule locali. L’Assessment del valore di scambio: Metodologia per il calcolo del valore di scambio 1)
Estrazione dalla descrizione del servizio dei seguenti metadati: Utenza potenziale; Probabilità di utilizzo. 2)
Utilizzando i metadati disponibili e informazioni sui processi di produzione determinare i ricavi in un periodo di
tempo t. 3) Stimare i costi di produzione ed erogazione del serv. 4) Calcolo del valore di scambio del serv
attraverso la formula: vs(s,p,t)= ricavi – costi. WEB SERVICE CONTRACTS Con (SOC) WS OrientedComputing si
intende un modello di computazione che propone servizi come costrutti di base per lo sviluppo di
applicazioni rapide, a basso costo e facile da comporre. L’elaborazione è generalmente intesa come
distribuita sia in termini fisici che organizzativi. Tecnologia web service: consente l'attuazione del paradigma
SOC; fornisce linguaggi e protocolli standard; supporto per lo sviluppo e l'esecuzione di processi aziendali
importanti per la scoperta e la composizione di servizi distribuiti su Internet. Un processo di analisi dei dati di
acquisto può essere automatizzato attraverso la scoperta e la composizione dei seguenti servizi: Richiesta di
servizio (RS) invia una richiesta di acquisto; Purchase Processing Service (PPS), gestisce il processo standard
di e-commerce; Validation Service Merchant (MVS) verifica e fornisce i dati su un shopping merchant;
Pagamento del servizio di verifica (PS) convalida i dati relativi al pagamento; Freight Transportation Service
(FTS) offre il trasporto delle merci; convalida acquisto del servizio (PVS) analizza i dati e convalida l'acquisto.
Web service discovery individua mediante macchina descrizione di un ws che soddisfa determinati criteri
funzionali // Web service composition combina la funzionalità dei vari ws scoperti per definire un ws
composito. La chiave per costruire processi di business di valore si basa sull’efficienza della scoperta di
adeguati ws e della loro composizione. WSDL descrive le interfacce pubbliche di servizi web: la semantica
delle info scambiate è codificata in WSDL solo parzialmente. C’è la necessità di un accordo per definire in
modo esplicito il significato delle informazioni scambiate. La soluzione sono descrizioni semanticamente
arricchite: ontologie per formalizzare l'accordo; metadati per consentire alla macchina di elaborare.
Problema: la pura scoperta funzionale e la composizione di WS sono inadeguati a sviluppare i processi di
valore. La crescente disponibilità di ws che offrono funzionalità simili aumenta la necessità di una più
sofisticata attività di discovery e composition per abbinare le richieste degli utenti. La soluzione è valorizzare
la scoperta/composizione di ws con la valutazione delle proprietà non funzionali (PNF). Le PNF sono definite
nella comprensione della transazione commerciale tra un provider e un consumatore. La comprensione è
tipicamente costituita da specifiche politiche, accordi sul livello di servizio e licenze. Una politica (Policy)
fornisce i mezzi per specificare e modulare il comportamento di una funzionalità per allineare le proprie
capacità con le esigenze degli utenti. Una politica stabilisce le relazioni tra le parti, specificando: obblighi,
insieme di attività che un oggetto deve o non deve eseguire su oggetti di destinazione; autorizzazioni,
insieme di attività che a un oggetto è consentito o vietato eseguire su oggetti di destinazione. Un Service
Level Agreement (SLA) è una dichiarazione bilaterale firmata da un provider di servizi ed un consumatore,
specificando le caratteristiche operative previste da misurare, monitorare e gestire. Uno SLA descrive: i
criteri minimi di efficienza che un provider promette di soddisfare offrendo allo stesso tempo un servizio;
azioni correttive e sanzioni nel caso in cui le prestazioni scendano al di sotto dello standard promesso. Una
licenza include tutte le operazioni tra il licenziante (es. provider di servizi) e il licenziatario (es. consumatore
servizi), in cui il licenziante stabilisce i diritti concessi al licenziatario quando si usano alcuni servizi specifici a
condizioni predefinite. Una licenza descrive: la misura in cui il servizio può essere usato (permessi, condizioni
commerciali d'uso, garanzie e indennità); la limitazione di responsabilità del concedente in caso di guasto
di servizio. Anche se ci sono alcune differenze tra le politiche, gli SLA e le licenze, “ombrello" del termine
Contratto di Servizio è usato per identificarli. Oltre alla descrizione delle funzionalità del servizio, un contratto
di servizio è composto da uno o più clausole contrattuali che potenzialmente si riferiscono a: le proprietà
dei criteri specificati nel WS-Policy, i termini delle SLA specificati nel WSLA, le clausole delle licenze
specificate nell’ODRL-S. Di base, un service contarct è definito dalle proprietà non funzionali che descrivono
le caratteristiche del servizio non direttamente collegate alla funzionalità fornita. È composto da varie
sezioni, es: titolo; descrizione/scopo; parti in causa; termini/durata del contratto ecc. Ogni sezione è ricca di
termini contrattuali definiti come istanza di specifiche proprietà non funzionali (es. data d'inizio; durata
temporale, periodo di riferimento; prezzo assoluto, ecc). STRUTTURA esiste una relazione di "appartenenza"

25. tra PNF e sezioni del contratto di servizio: ogni PNF appartiene almeno ad una sezione del contratto. Questa
strutturazione serve per non lasciare spazio ad ambiguità; dare struttura e chiarezza al contratto stesso
(renderlo più comprensibile). Esitono comunque dei problemi: non abbiamo un linguaggio universalmente
riconosciuto per la specifica dei contratti (la struttura di cui sopra è solo una proposta) si crea quindi
eterogeneità a causa dell’assenza di uno standard. È difficile confrontare i contratti. Con quale criterio
comparare due contratti in modo da dare ad ognuno un “punteggio” (che dipende da metro usato
dall’utente, cioè dalle sue necessità). Se stipulo più contratti ognuno per produrre una parte di un software,
come posso sapere se dati prodotti da ogni parte sono effettivamente usabili/usati in modo corretto dalle
altre parti. Come specifico il contratto del servizio globale. Come controllare automaticamente la
compatibilità tra i servizi selezionati; come definire automaticamente un contratto per il servizio composito,
ecc. Emergono le seguenti sfide di ricerca: specificazione del contratto di servizio, selezione del cs,
composizione del cs. WS contract specification Problema 1) mancanza di lingue per descrivere pienamente
PFN; mancanza di linguaggi standard per la descrizione del contratto di servizio (eterogeneità nelle
specifiche del contratto di servizio). Soluzione: definizione del Metamodel Policy-Centered (PCM), un meta-
modello per la descrizione delle PNF da inserire nei contratti di servizio; la definizione di tecniche di
mappatura per eseguire il mapping di specifiche eterogenee con descrizioni PCM-based; progettazione
del Wrapper PCM, uno strumento che supporta le tecniche di mappatura. Il PCM supporta 1)descrizioni
sofisticate: ampio uso di operatori di vincolo per la specifica di gamma (disuguaglianze) e impostrazione di
valori correlati; 2)la definizione dei valori ponderati per le PFN richieste 3)offerta di clustering: l'introduzione di
politiche di offerte congiunte di PNF; 4)la definizione delle condizioni di polizza. Il PCM presenta un buon
compromesso tra espressività (cioè la capacità di descrivere i diversi aspetti legati alle PNF) e complessità. Il
PCM consente la definizione dei contratti riutilizzabili (es. le licenze creative commons) che sono
indipendenti dalla tecnologia specifica. Le descrizioni di contratto possono essere così classificate:
Descrizioni semantiche (rappresentare contratti definiti sulla base di modelli semantici – es. OWL-S, WSMO,
MicroWSMO, WSOL - e in base a più ontologie. Descrizioni basate su XML (rappresentano contratti definiti
mediante clausole < attribute, valore > dove attributo identifica la PNF coinvolta e valore specifica il valore
della PNF offerta. Descrizioni basato su modello (rappresentare contratto definito in base a un modello
predefinito. I termini contrattuali sono testi semplici in lingua naturale). Descrizioni di testo libero
(rappresentare i contratti non strutturati definiti come testi in chiaro in linguaggio naturale. In sostanza, essi
consistono in documenti testuali con qualsiasi riferimento al loro contenuto). Devono essere definite
Tecniche di mappatura per ciascun tipo di linguaggio. Se voglio confrontare i contract sevrice devo
basarmi su 4 caratteristiche 1)Macchina d’interpretabilità: rappresenta la possibilità per una macchina di
concepire il significato di un contratto. 2)Interoperabilità: definisce la possibilità di interpretare
automaticamente il contratto significativamente e con precisione in diversi contesti e domini. 3)Espressività:
rappresenta la capacità di definire i termini contrattuali articolati a sostegno della specificazione delle
interdipendenze tecnologiche e di business. 4)Ragionamento: è la capacità di una macchina di formare
automaticamente inferenze dai termini specificati in un contratto. Le tecniche di mapping sono tecniche
per estrarre i termini contrattuali dalla semantica disponibile, sono basate su XML, basate su modelli e
descrizioni di contratto a testo libero. WS contract selection Problema 2: la valorizzazione della funzionalità
basata su ws discovery con una fase basata su valutazione delle PNF definite in contratti di servizio.
Soluzione: definizione di un approccio ibrido per la selezione del ws discovery che combina tecniche
basate sulle tecniche di logica e algoritmi, progettazione e attuazione della Polimar, un framework che
supporta l'approccio ibrido. L'approccio ibrido offre alti livelli di: espressività; generalità, consentendo la
mediazione su base semantica tra le descrizioni in base a più ontologie; flessibilità. L’approccio ibrido è un
processo in 4 fasi sulla base di: un contratto di servizio PCM-based (vale a dire, la politica richiesta)
indicando una serie di PNF richieste. Contratti di servizio PCM-based (es. le politiche), indicando una serie di
PNF offerte. WS contract composition Problema 3: gli strumenti esistenti di composizione di ws non
supportano la valutazione di compatibilità di ws contract quando si combinano diversi servizi di provider
diversi. Soluzione: definizione di un approccio basato su regole di valutazione e composizione di ws
contract; progettazione e attuazione del Framework di compatibilità del ws contract (SeCO2) che supporta
l'approccio basato sulle regole. L'approccio basato su regole supporta: la valutazione di compatibilitàdel
ws contract; raccomandazione di contratto per i servizi compositi. L'approccio basato su regole considera:
un ricco insieme di proprietà di contratto (es. QoS, Affari, Licenza e termini contesto); entrambi i flussi di dati
e di controllo; schemi di composizione, un’ontologia di riferimento estendibile, un ricco set di valutazione di
compatibilità + regole di composizione. IBM SCIENZA DEI SERVIZI Economie globali sono passate
progressivamente da industria a servizi. Era dei servizi: economia dei servizi. Comunque si guardi e si studi un

26. servizio, esso richiede un approccio multidisciplinare. È un sistema caratterizzato da una pluralità di attori
che collaborano tra loro; è un meccanismo che non deve incepparsi per l’atto finale; è l’insieme delle
persone e delle tecnologie; la risultante di un sitema. Scienza dei servizi è un’applicazione interdisciplinare
nuova di scienza, ingegnereria e gestione allo scopo di migliorare i servizi. Essa contribuisce anche
all’innovazione sistematica e al miglioramento della produttività, è la forza guida per migliorare I servizi
attraverso una migliore prevedibilità nella produzione, qualità, performance, conformità, sviluppo, riuso
della conoscenza e innovazione operativa dei servizi (IBM). Scienza dei servizi difficile per
multidisciplinarietà: servizi dipendono dalle persone, dalle organizzazioni e dalla cocreazione di valore; le
persone lavorano insieme, con la tecnologia e con le organizzazioni x fornire valore ai clienti; l’info condivisa
permette di coordinare le attività, le leggi, le misure e I modelli, sistema di serv complesso sistema socio-
tecno economico; la crescita richiede innovazione che combini persone, tecnologia, organizzazione, valori,
info condivise, clienti; un sistema di servizi è una configurazione e coproduzione di valore di persone,
tecnologia, serv interni e esterni collegati da proposizioni di valore e info condivisa; I sistemi di serv sono sia
disegnati sia modellati dalle forze naturali. In sostanza, c’è bisogno di scienza dei sevrizi per capire
l’architettura, l’evoluzione, le proprietà emergenti di un sistema di servizi; la scienza dei servizi si propone di
ricercare I servizi nello stesso modo scientifico che ha stimolato il successo nel settore della produzione e di
facilitare l’aumento Della produttività con un approccio scientifico alla modellazione. Al tempo stesso, si
propone di rendere più semplici per client/provider effetti e rischi nell’introduzione di servizi. PROFESSIONISTA
DEI SERVIZI Figura indispensabile nel sistemi di servizi è il SYSTEM THINKER (integratore) colui che pensa ed
agisce per sistemi, li fa evolvere, figura sempre più richiesta in azienda per dominare la complessità della
realtà. Integratore in quanto deve integrare, con una formazione a T (versatile; parte verticale Della T è il
background personale, la parte orizzontale vari settori da far cooperare) indicazioni dai vari settori,
coniugandole col suo backgraound. Un professionista dei servizi lavora in team collaborativi di scienziati,
manager, ingegneri ecc. La loro formazione deve essere interdisciplinare. T-shaped in modo ampio: grandi
competenze comunicative e esperienze pratiche supportate da profonda conoscenza nell’area del
managemnet, ingegneria o architettura dei servizi; profonde competenze nel problem solving, deve
“pensare avanti” per modellare la realtà; deve avere un vocabolario e esperienze di laboratorio. Un
professionista T-shape assicura che l’implementazione di nuovi servizi o di adattamento a ambiente
esistente prendano in considerazione sia le alternativi IT che I fattori culturali/umani. È in grado di analizzare
e modellare sistemi di servzio di grandi dimensioni e/o complessi in diversi settori dell’economia dei servizi.
Dimostra capacità di interazione con I clienti. Efficacia attraverso una continua scoperta, analisi e
implementazione di sevrizi emergenti e modelli, strumenti d’innovazione. Le sue abilità devono riguardare:
progettazione e gestione dei servizi; modellazione dei sistemi dei servizi; cicli di vita e qualità dei servizi;
gestione della fornitura/richiesta di servizi; acume di business; comunicazione; collaborazione; capacità da
leader, collante; lavoro di squadra; pensare per sistemi; sviluppo organizzativo. Deve dunque, nello
specifico: Sviluppare la progettazione dei servizi = avere una conoscenza sulle fondamentali caratteristiche
dell’innovazione del servizio, essere in grado di descriverne la struttura e gli elementi manageriali, conoscere
I passi per lo sviluppo di un nuovo servizio ecc. Applicare la gestione del servzio = conoscere sia la gestione
del servizio che la gestione IT del servizio. Eseguire la modellazione del sistema di servizi = comprendere gli
approcci per usare metodi di modellazione di business, strumenti e software per sviluppare modelli finanziari
e di simulazione di sistemi di servizio a valore netto, di impresa o di reparto. Capire metodi qualitativi per fare
analisi dettagliate sulle dimensioni culturali e sociali delle pratiche di lavoro nel sistema dei servizi per ruoli
specifici. Implementare la strategia dei servizi = conoscenza approfondita dei conceti di servizio. Analizzare
il ciclo di vita del servizio per garantire la qualità. Eseguire la fornitura del servizio e la gestione della
domanda = ad esempio segmentare la base dei clienti, offrire incentivi di prezzo, offrire servizi
complementari. Sviluppare l’offerta di nuovi servizi = agire come fonte primaria per rappresentare la voce
del cliente riconoscere e sfruttare opportunità per creare nuove offerte e soluzioni per far crescere il
business. Sviluppare un pensiero di sistema di servizio = analizzare situaioni critiche per decidere cosa fare,
rendendo tutto logico, competente attraverso decisioni tempestive, buon senso e tenendo in cosiderazione
tutti gli aspetti e le info. Applicare le conoscenze di gestione del prgetto di business. Applicare le migliori
pratiche di comunicazione di business. Applicare costantemente capacità di leader, di collaborazione, fare
da collante, lavorare in team. Applicare conoscenze di marketing e di vendita. INGEGNERIA DEI SISTEMI DI
SERVIZI Approccio multidisciplinare per consentire la realizzazione di sistemi di successo. Si concentra su:
definizione delle esigenze dei clienti; funzionalità richieste nelle prime fasi del ciclio di sviluppo;
documentare requisiti; progettazione di architettura e di convalida del sistema, sempre tenendo in
considerazione la totalità del problema. Integra tutte le discipline e le specialità di diversi gruppi di lavoro

27. formando un processo strutturato di sviluppo che procede dall’ideazione a realizzazione fino alla messa in
esercizio del sistema. Prende in considerazione sia il business che le esigenze tecniche di tutti clienti con
l’obiettivo di fornire un prodotto di qualità che soddisfi le esigenze degli utenti. Campo multidisciplinare che
serve ad applicare teoria/conoscenza al servizio della scienza, fornisce servizi di qualità e crea valore nel
suo ciclo di vita. Comprende: metodologia e modellazione dell’architettura dei servizi; tecniche (semantica
del servizio, gestione della conoscenza, ecc); strumenti di supporto, piattaforme e ambienti. Metodologia
del sistema di servizio per sviluppare sistemi di servizi con un approccio sistemico e ingegneristico volto a
garantire soddisfazione cliente. Comprende: Modellazione dei “business services”; Modellazione di “sistema
di erogazione di servizi”; Costruzione di “sistema di erogazione di servizi”; Valutazione del sistema di servizi e
delle relative erogazioni. Si modella il business e il sistema, così facendo è possibile comprendere e valutare
il sistema, quindi successivamente automatizzare. Fattori che portano alla modellazione: componenti; info
scambiate; linguaggio; ambiente in cui è calato il sistema; requisiti; aspettative del cliente; output;
continuità del servizio. È necessario quindi modellare questo ecosistema perchè si giunga all’erogazione del
servizio. Per modellare: Component business model = rappresenta il business dei servizi come una matrice in
cui in verticale ci sono I processi fondamentali, in orizzontale la distribuzione del controllo (operativo,
tattico…) dall’incrocio dei processi verticali con quelli orizzontali scaturiscono le componenti di business à
sottosistema che ha un imput, un obiettivo definito, un insieme di capacità e risorse. CBM idividua
opportunità per cambiamento, innovazione, trasformazione. L'evoluzione nei sistemi informativi: anni 60,
architettura monolitica mainframe based. Oggi, grid/cloud computing e semantic web services: più
dinamica. SOA Alla base: Servizi di sviluppo; IT service management (serve alla gestione dei servizi e risorse);
Servizi di infrastruttura (il server con i suoi servizi: banalmente l'hosting, storage e protezione); Servizi di
interazione; Servizi di raccolta dati; information services; servizi di automazione ecc. sono tutti colllegati
dall'ESP = Enterprise Service Bus. Oltre a questi ci sono anche i partner business, access services (da non
confondersi con l'interazione, constano dell'accesso logico ai dati) business application services. Service
oriented Modeling Nell'Object Oriented andava modellato il sistema a seconda delle funzionalità, costruire
oggetti con proprietà e metodi, qui è simile: va modellato il servizio. Per farlo ci serviamo del SOMA, che
passa i servizi business all'automazione. L'approccio SOMA è step by step, è ponte dal business alla SOA. È
fatto in maniera ciclica: identifica i servizi; specifica delle componenti dei flussi; decide come realizzarlo
(sviluppare exnovo un ws o comprarne uno nel mercato). Quindi: Component business model Strategy
(divide il business in componenti); SOMA Modeling (definisce un modello del servizio); Realizzazione SOA
(implementa il service model). Computer Based Programming Il modello computer based programming
tratta della modellazione del software a livello di programmazione SCA = Service-Component Architecture;
SDO = Service Data Objects. La modellazione è continua. Principi di sviluppo SOA Granularità: è lo stato di
ricchezza funzionale per un servizio. Deve essere scopribile: il requester deve poter trovare il servizio. Il servizio
deve avere una sola istanza. Chiara separazione dei limiti del servizio e delle sue caratteristiche. Asincronia.
Stateless. Service Oriented Development Lifecycle Tutto questo sistema è a spirale con 4 fasi ricorsive: 1)
Modellazione: racimolare i requisiti 2) Assemblazione: si assemblano le componenti software 3) Deploy:
mettere in funzione 4) Gestire. Soa Governance posso prendere servizi da qualsiasi provider. La governance
regola che il servizio sia usato in modo consono, che se ne faccia un uso adeguato e non distorto. In altre
parole definisce cosa fare, come farlo, come dovrebbe essere misurato per ciascuna delle aree di
interesse. Non devo sviluppare software a caso, vanno sempre calati nel contesto in cui è richiesta
l'automazione. Ciò solleva questioni di sicurezza. I dati vengono utilizzati e scambiati tra servizi. Un'altra
questione è il riuso del servizio. Per tutte queste questioni è necessaria una governance. Anche la
governance ha un suo ciclo di vita a 4 fasi: Define; Enable; Measure; Plan. IT SERVICES E IT VALUE servizi di
informatica + valore che viene prodotto da questi servizi. Alla base c'è la stratificazione a 4 layer: Servizi di
business; Processi di business; Servizi IT; Processi IT. In questa struttura c'è una ricorsività: ogni servizio include
in sé dei processi. I servizi it comprendono processi, tecnologie e info. IT SERVICE:Un servizio produce un
valore per il cliente, è misurabile e produce business con il proprio cliente. Si ottiene attraverso una
sequenza di attività di un dato processo. Servizi it in outsourcing: operational services, delivery support
services, management and control services. IT service description descrive un servizio it. Dentro ci sono
l'output e i vantaggi per il cliente. All'interno ci sono anche gli indicatori di prestazione con cui si può
valutare il servizio. Infine anche i processi su cui esso si basa. La strategia dei servizi it: bisogna dotarsi di una
strategia per creare business. Senza una strategia non si va da nessuna parte. La strategia si deve porre tre
problemi: dove deve supportare l'azienda, come la può supportare (attraverso quali servizi) e quando. Tre
ruoli in azienda sono interessati alla definizione della strategia, CIO&provider officer (risponde alle domande:
quali servizi offro? Quali sono gli indicatori di performance? E siamo competitivi, anche internamente?) un

28. altro ruolo è il manager di unità di business. Si pone le seguenti domande: Qual'è la qualità dei servizi? E
quanto costa? Infine gli end users: sono interessati a quali servizi possono chiedere e quando possono usarli.
I focus sono su quali servizi offriamo e come facciamo a sapere che sono di buon valore per i clienti. La
strategia IT è contestuale e varia da settore a settore. I servizi interni sono solitamente quelli core, che si
identificano con la conoscenza e l'esperienza dell'azienda. Il contesto della strategia si divide in: Business
Drivers; Bisogni e desideri del cliente (Visione di IT) Financial Model (Funding; pricing; cost). I primi due
definiscono il profitto. Road map di sviluppo di una strategia di servizi IT: Sviluppo della startegia del
contesto; Definizione del portfolio di servizi IT (permette di centralizzare le info sui servizi erogati e fare un
confronto con I servizi erogati in passato e la loro evoluzione); Defizione del catalogo di servizi IT (contiene
tutti I servizi offerti ai clienti, quindi possono capire come personalizzare le loro necessità. È un servizio
orientato al cliente, di fondamentale utilità per il comparto vendite); Sviluppo della strategia IT service;
definizione e pianificazione delle iniziative. Nel portfolio ci sono tutti i servizi che azienda è in grado di
erogare e varia anch'esso da azienda ad azienda. Esiste da circa 10 anni la necessità di regole e linee
guida che diano indicazioni su come realizzare una strategia di servizi It e su come definire i servizi IT e i
processi alla base di essi. Una di queste linee guide è quella voluta dal ministero UK dei commerci. L'ITIL
attualmente è alla versione 3. Da delle indicazioni per strutturare al meglio i servizi di informatica aziendale.
Non è prescrittiva, ma è una documentazione di riferimento da cui trarre una visione. Viene definita la
modalità con cui definire il ciclo di vita del servizio. Dalla fase di progetto (pipeline) alla dismissione (retired)
passando per la fase di catalogo in cui il servizio è operativo. Il catalogo è quindi un sottoinsieme del
portfolio. Gli status del servizio sono fondamentali: il servizio può essere definito, analizzato, approvato,
progettato, sviluppato, testato, rilasciato, operativo e dismesso. Ci sono 5 manuali per gestire e progettare a
livello ingenieristico il servizio. La strategia è divisa in 4 principali attività: definire il mercato, sviluppare
l'offerta, sviluppare gli assets strategici, preparare l'esecuzione. La governance dei service IT un punto critico
è la mancanza di norme che si è iniziato a impostare solo ora. Un altro problema chiave è la mancanza di
chiarezza e trsparenza. Le cattive decisioni (cioé fraudolente) sono state scoperte solo quando era troppo
tardi e chi aveva preso tali decisioni non ne ha subite le conseguenze in quanto non si sapeva chi aveva la
responsabilità. Cosa significa fare governo dell'IT? Gli aspetti fondamentali della governance sono: definire
gli strati fondamentali dell'azienda, chi dirige (CIO), chi controlla (il consiglio di amministrazione) e chi
esegue (il resto della struttura). Rispondono a quesiti quali: come vengono prese le decisioni; quali
informazioni sono richieste; che meccanismi per la decisione sono richieste; come vengono gestite le
eccezioni; com'è possibile migliorare il governo, come lo si rivede e come viene implementato. Il valore
dell'it è dato dalla relazione tra la soddisfazione del cliente e le risorse usate per raggiungerla. Connessione
tra soddisfazione del cliente e costi. Valore in senso generale del servizio. È legato al Know-how, esperienza
e conoscenza, ma anche a azienda-ecosistema, ma anche la ricchezza e stakeholder value. Ad esso si
collega anche il result value e il back-end value (da chi vi lavora dietro). In azienda viene però considerato
in termini di performance (necessità di business, qualità, immagine, benefici) e risorse (tempo, costi di
design, capitale, utilizzo). Da un lato abbiamo le prestazioni fatte di qualità, vantaggi e fatturato, e dall'altra
parte abbiamo costi di capitale, di uso e progettazione, ma anche gestione e tempo. Sono tutti aspetti
quantitativi. Il valore è sempre in bilico tra performance e risorse. E per chi deve gestire questa situazione la
sfida è tenere in equilibrio la bilancia in accordo con la percezione del cliente. Tentare di migliorare i servizi
a parità di risorse, ad esempio. O stesse prestazioni con minori risorse. Sfida tipica di un T-Shape. Anche qui
c'è una metodologia di gestione del valore. È uno schema ciclico. CLOUD COMPUTING definizioni,
caratteristiche principali, concetti fondamentali/tecnologie infrastrutturali abilitanti e benefici, modelli di
servizio e di distribuzione Il cloud computing è un modello per abilitare, tramite la rete, l’accesso diffuso,
agevole e a richiesta, ad un insieme condiviso e configurabile di risorse di elaborazione (es. reti, server,
memoria, applicazioni e servizi) che possono essere acquisite e rilasciate rapidamente e con minimo sforzo
di gestione o di interazione con il fornitore di servizi. Modello cloud è composto da 5 caratteristiche
essenziali, 3 modalità di servizio (+ 4’ IBM) e 4 modelli di distribuzione. Definizione di wikipedia: con il termine
cloud computing si indica un insieme di tecnologie che permettono, tipicamente sotto forma di un servizio
offerto da un provider al cliente, di memorizzare/archiviare e/o elaborare dati (tramite CPU o software)
grazie all'utilizzo di risorse hardware/software distribuite e virtualizzate in Rete in un'architettura tipica client-
server. 5 Caratteristiche: Self-service su richiesta Un consumatore può acquisire unilateralmente e
automaticamente le necessarie capacità di calcolo, come tempo macchina e memoria, senza richiedere
interazione umana con i fornitori di servizi. Ampio accesso in rete Le capacità sono disponibili in rete e
accessibili attraverso meccanismi standard che promuovono l'uso attraverso piattaforme eterogenee
come client leggeri o pesanti (es. telefoni mobili, tablet, laptops e workstations). Condivisione risorse Le

29. risorse di calcolo del fornitore sono messe in comune per servire molteplici consumatori utilizzando un
modello condiviso (multi-tenant), con le diverse risorse fisiche e virtuali assegnate e riassegnate
dinamicamente in base alla domanda. Dato il senso di indipendenza dalla locazione fisica, l’utente
generalmente non ha controllo o conoscenza dell’esatta ubicazione delle risorse fornite, ma può essere in
grado di specificare la posizione ad un livello superiore di astrazione (es. paese, stato o data center).
Elasticità rapida Le risorse possono essere acquisite e rilasciate elasticamente, in alcuni casi anche
automaticamente, per scalare rapidamente verso l’esterno e l’interno in relazione alla domanda. Al
consumatore, le risorse disponibili spesso appaiono illimitate e disponibili in qualsiasi quantità, in qualsiasi
momento. Servizio misurato I sistemi cloud controllano automaticamente e ottimizzano l'uso delle risorse,
facendo leva sulla capacità di misurazione ad un livello di astrazione appropriato per il tipo di servizio (es.
memoria, elaborazione, larghezza di banda, utenti attivi). L’utilizzo delle risorse può essere monitorato,
controllato e segnalato, fornendo trasparenza sia per il fornitore che per l’utilizzatore del servizio. 3 CONCETTI
ALLA BASE: standardizzazione (infrastruttura tecnologica, chiave per il successo del cloud) virtualizzazione
(non più risorse fisiche ma virtuali) automatizzazione (elasticità in funzione delle richieste tramite
l’automazione) à 5 Tecnologie infrastrutturali abilitanti e benefici: Virtualizzazione avanzata = le risorse IT
possono essere condivise tra diverse applicazioni; le applicazioni possono funzionare praticamente
ovunque. Fornitura automatizzata = le risorse vengono utlizzate rapidamente su richiesta. Scalatura elastica
= ottimizzazione delle risorse e flessibilità. Possibilità di ordinare da un catalogo i servizi = possibilità di servizi
aggiuntivi personalizzati. Monitoraggio e quantificazione dell’uso del servizio flessibile (sulla base
dell’effettivo utilizzo) = trasparenza costi, offerta molto flessibile. Accesso internet = sistemi cloud sono
accessibili da internet e quindi da tutti I dispositivi, ovunque e in ogni momento. Modelli di servizio: Software
come Servizio (SaaS Software as a Service). La facoltà fornita al consumatore è quella di utilizzare le
applicazioni del fornitore funzionanti su un’infrastruttura cloud. Le applicazioni sono accessibili da diversi
dispositivi attraverso un’interfaccia leggera (thin client), es. un’applicazione email su browser, o da
programmi dotati di apposita interfaccia. Il consumatore non gestisce o controlla l’infrastruttura cloud
sottostante, compresi rete, server, sistemi operativi, memoria, e nemmeno le capacità delle singole
applicazioni, con la possibile eccezione di limitate configurazioni a lui destinate (parametrizzazione).
Piattaforma come Servizio (PaaS Platform as a Service). La facoltà fornita al consumatore è quella di
distribuire sull’infrastruttura cloud applicazioni create in proprio oppure acquisite da terzi, utilizzando
linguaggi di programmazione, librerie, servizi e strumenti supportati dal fornitore. Il consumatore non gestisce
né controlla l’infrastruttura cloud sottostante, compresi rete, server, sistemi operativi, memoria, ma ha il
controllo sulle applicazioni ed eventualmente sulle configurazioni dell’ambiente che le ospita. Infrastruttura
come Servizio (IaaS Infrastructure as a Service). La facoltà fornita al consumatore è quella di acquisire
elaborazione, memoria, rete e altre risorse fondamentali di calcolo, inclusi sistemi operativi e applicazioni. Il
consumatore non gestisce né controlla l’infrastruttura cloud sottostante, ma controlla sistemi operativi,
memoria, applicazioni ed eventualmente, in modo limitato, alcuni componenti di rete (esempio firewalls).
Ulteriore modello IBM, l’intero processo di business come servizio: Business process as a service (BpaaS) il
processo aziendale intero è erogato da un servizio provider cloud, non sono servizi di core-business. Modelli
di Distribuzione: Cloud privato L’infrastruttura cloud è fornita per uso esclusivo da parte di una singola
organizzazione comprendente molteplici consumatori (es. filiali). Può essere posseduta, diretta e gestita
dall’organizzazione stessa, da un società terza o da una combinazione delle due, e può esistere dentro o
fuori le proprie sedi. Cloud comunitario (variante del c.privato) L’infrastruttura cloud è fornita per uso
esclusivo da parte di una comunità di consumatori di organizzazioni con interessi comuni (ad esempio
missione, requisiti di sicurezza, vincoli di condotta e di conformità). Può essere posseduta, diretta e gestita
da una o più delle organizzazioni della comunità, da una società terza o una combinazione delle due e
può esistere dentro o fuori le proprie sedi. Cloud pubblico L’infrastruttura cloud è fornita per un uso aperto a
qualsiasi consumatore. Può essere posseduta, diretta e gestita da un’azienda, da un’organizzazione
accademica o governativa oppure da una combinazione delle precedenti. Esiste dentro le sedi del
fornitore cloud. Cloud ibrido L’infrastruttura è una composizione di due o più infrastrutture cloud (privata,
comunitaria o pubblica) che rimangono entità distinte, ma unite attraverso tecnologie standard o
proprietarie, che abilitano la portabilità di dati e applicazioni (ad esempio per bilanciare il carico di lavoro
tra cloud). Differenze tra c. privato/pubblico: privato ha ambiente dedicato; adattato alle esigenze cliente;
costoso. Pubblico ha ambiente condiviso; piattaforme servizi ecc prefedefiniti; economico. I servizi in ottica
cloud possono quindi essere: a) infrastrutture (server) b) di piattaforma (database) c) di software (mail), il
motore cloud può essere a) pubblico o b) privato c) ibrido, una parte di motore pubblica e una parte con
componenti private. ARCHITETTURA DI RIFERIMENTO CLOUD COMPUTING, SICUREZZA E PRIVACY, ATTORI

30. PRINCIPALI - Architettura A livello macro, 3
layer = 1) cloud service consumer (interfaccia
per cliente) 2) cloud service developer (per
sviluppatore) e 3) cloud service provider che
contiene le parti orizzontali dell’architettura.
Questo (3) è centrale contiene: servizi cloud
(bpaaS, SaaS, PaaS, Iaas) + virtualizzazione
(dei server, storage, locali – dove ci sono le
risorse, e di rete) + piattaforma di gestione
cloud, con 2 sottolayer: 1) BSS – Business
Support Services che gestisce il business del
cloud e I suoi processi interni, es.gestione degli
ordini, del catalogo, delle sottoscrizioni ecc. 2)
OSS - Operational Support Services che
contiene il catalogo, la componente di
virtualizzazione, di provisioning, di gestione
dell’automazione. Qui ci sono I processi ITIL e
di gestione. Sicurezza e Privacy: il NIST sottolinea come sia un elemento che si estende a tutti i livelli del
modello dal fisico all’applicativo, imponendo l’indirizzamento dei requisiti di sicurezza come
l’autenticazione, l’autorizzazione, la disponibilità, la confidenzialità, la gestione delle identità, l’integrità,
l’audit, il monitoraggio, la risposta agli incidenti, la gestione delle policy di sicurezza. Alcuni accenti
vengono posti sull’importanza di determinare, per le diverse tipologie di servizio e relative implementazioni,
gli impatti sul business e le diverse problematiche in fase di progettazione e realizzazione. Le implicazioni di
sicurezza sono molto diverse anche in funzione dei modelli di esercizio attuati (Public Cloud, Private Cloud,
Outsourced Cloud, ecc). Un elemento molto importante è che la sicurezza è sempre una responsabilità
condivisa tra consumer e provider, con confini sempre diversi a seconda del tipo di servizio. I controlli da
attuare devono essere adeguatamente analizzati al fine di determinare quale delle parti è nella migliore
condizione per implementarli. Es. dei controlli di gestione degli account che, in uno scenario IaaS, sono
attuati dal provider per la configurazione iniziale degli utenti privilegiati, ma per la gestione delle
applicazioni restano di responsabilità del consumer. Per quanto riguarda la Privacy, i servizi in Cloud, pur
fornendo nuove e flessibili soluzioni per l’uso di risorse condivise, introducano nuovi rischi e pongano nuove
sfide per assicurare le necessarie garanzie di protezione dei dati personali degli utenti. 5 Attori principali:
Cloud Consumer; Persona od organizzazione che ha una relazione di business con, ed usa i servizi di, uno o
più Cloud Provider. Cloud Provider; Persona, organizzazione o entità responsabile di rendere il servizio
disponibile alle parti interessate. Cloud Auditor; 3’ parte che possa condurre una verifica dei servizi,
dell’esercizio dei sistemi informativi, delle prestazioni e della sicurezza della implementazione cloud. Cloud
Broker; Entità che gestisce l’uso, le prestazioni e l’erogazione dei servizi cloud e negozia le relazioni tra i
Cloud Provider e i Cloud Consumer. Cloud Carrier; Intermediario che fornisce la connettività e il trasporto
dei servizi cloud dai Cloud Provider ai Cloud Consumer. Funzioni del cloud provider nell’ambito delle 3
categorie di servizi Cloud: 1)SaaS; il provider dispiega, configura, manutiene e aggiorna le applicazioni
software in conformità ai livelli di servizio concordati con il consumer. Il consumer ha un limitato controllo
amministrativo sulle applicazioni. 2)PaaS: il provider gestisce l’infrastruttura e i componenti della piattaforma
e supporta i processi di sviluppo del consumer con strumenti tipo IDE, SDK, etc. Il consumer ha, in questo
caso, il controllo sulle applicazioni e su alcuni parametri ambientali, ma nessuno o limitato accesso alle
infrastrutture sottostanti. 3)IaaS: il provider gestisce le risorse fisiche dell’infrastruttura, inclusi i server, le reti e lo
storage. Il consumer usa le risorse messe a disposizione dal provider e, rispetto ai consumer di servizi PaaS o
SaaS, ha accesso e maggiore controllo sull’infrastruttura di sistema. Cloud Broker è riferito a 3 categorie di
servizi 1)Service Intermediation: broker fornisce servizi a valore aggiunto rispetto ai provider; esempi possono
essere: accesso ai servizi, identity management, reporting, sicurezza addizionale, etc. 2)Service
Aggregation: il broker combina ed integra servizi di più provider in uno o più nuovi servizi. 3)Service
Arbitrage: simile al Service Aggregation, ad eccezione del fatto che i servizi aggregati non sono fissi. Il
broker ha, in questo caso, la flessibilità di scegliere tra diversi provider ed agenzie sulla base di criteri di
selezione dei migliori. SOCIAL MEDIA: La spinta all’integrazione delle strategie corporate con i social media
sta diventando sempre più una necessità. I perché sono molteplici: Miglioramento della portata social
dell’impresa; Incremento del coinvolgimento dei fan; Engagement con advocates e influencer; Aumento
della lead generation; Applicazione funzionale degli strumenti di monitoraggio. Per monitori clienti,

31. competitors, ha flussi comunicativi esterni all’azienda e quindi fa marketing. SOCIAL BUSINESS: il percorso
parte dal marketing che tenta con strumenti proprietari di radunare su una piattaforma un serie di figure,
ma si estende ad altri tipi di aree come HR, customer, service IT e sales che possono sfruttare il social
business per tradurre la competenza in un nome e cognome, mettendo in comune esperienze e
competenze. Permette di fare ricerche parametriche per dettagliare la ricerca. Riuscire in altre a ottimizzare
flussi comunicativi interni all’azienda tramire una piattaforma social (Lotus IBM). Finalità collaborazione tra
dipendenti. Vantaggi del Social business: Esperienza più di valore; Aumentare la produttività; Accelerare
l'innovazione; Misurare i risultati; Mitigare il rischio; Gestire il cambiamento. Es: Una banca italiana di medie
dimensioni ha adottato strumenti social per accelerare la formazione di una cultura e di procedure comuni.
La Banca aveva identificato alcune potenziali lacune nella propria compliancy alle regole di vigilanza. Vi
era anche la necessità di sviluppare un approccio comune nel gruppo. No procedimento top-down, la
banca ha costruito dal basso una procedura: che fosse sentita come propria da ciascuno, che si
consolidasse in best practice raccogliendo il meglio di quanto presente nel gruppo. Il progetto beneficiava
della sponsorship del CEO di gruppo, che ha agito come partecipante attivo. L’iniziativa è stata affidata
alla responsabilità di HR e Comunicazione Interna. Il dipartimento IT ha fornito esclusivamente supporto
tecnico.