SISTEMI DISTRIBUITI (Prof. De Paoli – Unimib)

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

(protocolli aggiuntivi in questo livello: protocolli di instradamento). 4) di collegamento Instrada un datagramma attraverso una serie di commutatori di pacchetto (= router) tra l’origine e la destinazione. A ogni nodo della rete i datigrammi entrano dal liv inferiore (fisico) salgono a quello di collegamento che li instrada al nuovo nodo o sistema terminale, passando di nuovo il pacchetto al livello precedente (fisico, che li spedisce). 5) fisico trasferisce I singoli bit da un nodo a quello successivo e dipende dall’effettivo mezzo trasmissivo. LIVELLO APPLICATIVO è sede delle applicazioni e dei loro relativi protocolli à applicazioni sono processi distribuiti in comunicazione, in esecuzione su host remoti; si scambiano msg per eseguire l’applicazione; es. posta, FTP, www. Un processo è un programma in esecuzione su un host. Sullo stesso host: comunicano mediante meccanismi definiti dal SO. Processi in comunicazione su host diversi: comunicano mediante meccanismi definiti dal protocollo dello starto di applicazione (HTTP). User agent è l’interfaccia tra utente e applicazione di rete. Un programma è una sequenza di istruzioni eseguibili dalle “macchine” (fisiche o virtuali) e I processi sono entità gestite dal SO e costituiti da: area di memoria ram per effettuare le operazioni e memorizzare i dati + registro che ricorda la prossima istruzione da eseguire + canali di comunicazione. Ogni processo comunica tramite I canali: canale gestisce I flussi di dati in ingresso/uscita; canale: schermo, tastiera, rete, ecc; dall’esterno ogni canale è identificato da un numero intero detto”porta”. Per il SO tutti I processi sono uguali. Il SO attiva un processo che andrà a lanciare un programma, ma tutti questi processi per il SO sono identici. Applicazione di rete tipica è divisa in 2 parti: client e server. Client inizia dialogo col server (speaks first), di solito richiede un servizio; nel caso del web il client è integrato nel browser. Server fornisce il servizio al client, su richiesta. URL Uniform Resource Locator servono a “identificare” quello con cui si vuole comunicare (indirizzo della risorsa). IP ADDRESS identifica l’host su cui l’altro processo è in esecuzione; PORT NUMBER permette all’host ricevente di identificare il processo locale destinatario del msg (il programma a cui bisogna dare i dati). URL quindi identifica un oggetto nella rete e specifica il modo per accedere ad esso: protocollo. Ha tre componenti: nome del protocollo, indirizzo dell’host (IP+PORTA) e percorso nell’host. Protocollo://indirizzo_IP [:porta]/cammino/file.

La porta è opzionale PROTOCOLLO HTTP è un protocollo di livello applicativo; usa il modello client/server. Client: browser che richiede, riceve e visualizza oggetti web. Server: web server che invia oggetti in risposta alle richieste. HTTP request, formato pacchetto e specifiche: 1) request line method/sp/url/version/cr/lf à request line identifica una request HTML. A)Metodi (tipo di operazioni che client richiede al server) GET usato per richiedere una pag web; POST usato quando utente compila una form – contenuto dei campi è posto nell’entity body. Comando serve per richiedere una pag web il cui contenuto dipende da info inviate dal client, nel body. HEAD

come il get ma viene restituito solo l’head della pagina web. B)Carattere spaziale C)URL richiesta D)Versione HTTP (es. 1.1) E)Carriage return e F)Line Feed sono due caratteri speciali. 2) Header line: righe testuali free-format che specificano caratteristiche. Sono di molti tipi e possono essere più o meno numerose. Formato generale è “header name : valore (es. User agent : Mozzila/4.0. 3) + cr/lf e altre ipotetiche righe di header. Tra header e body c’è sempre una riga vuota (composta da cr/lf) sia nelle HTTP request che response. 3) Entity body è opzionale, campo contenente dati (es. documento richiesto dal client). HTTP response, formato pacchetto e specifiche: 1) response line, identifica una HTML response – protocol/sp/status code/sp/status phrase/cr/lf. A)protocol identifica la versione del protocollo usata B)codice dello stato (200 OK: Successo, oggetto richiesto più avanti nel messaggio. 301 Moved Permanently: L’oggetto richiesto è stato spostato. Il nuovo indirizzo è specificato più avanti. 400 Bad Request: Richiesta incomprensibile al server. 404 Not Found: Il documento non è stato trovato sul server. 505 HTTP Version Not Supported). C)significato del codice di stato. 2) Headers line: insieme di linee facoltative che permettono di dare delle info supplementari sulla risposta e/o il server. Formato generale è “Header name: valore”. 3) Body contiene il documento richiesto. // HTTP per funzionare si basa su TCP: il client inizia una connessione TCP (crea una socket) verso il server (sulla porta 80); il server accetta la connessione TCP dal client; scambio di msg HTTP tra browser (che è il client HTTP) e il web server (che è il server HTTP); connessione viene chiusa. HTTP è stateless: server non mantiene informazioni sulle richieste precedenti del client, ogni richiesta è indipendente da quelle precedenti e si conclude al momento della chiusura della connessione (I protocolli che mantengono le info sono complessi). Il server web quindi non ha "memoria" di quanto comunicato precedentemente con un certo client: per questo motivo, per realizzare applicazioni web complesse, sono stati sviluppati meccanismi a livello superiore come i cookies per costruire "sessioni" e permettere al server di recuperare informazioni riguardanti un certo client. Es. Utente accede alla url

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

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

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

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

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

tramite PROGRAMMI COMPILATI: il web server invoca, su richiesta del client, un eseguibile, che può essere scritto in un qualsiasi linguaggio che supporti l’interazione con il web server, es. Java, C#, C++. O tramite SCRIPT INTERPRETATI: il web server ha un motore in grado di interpretare il linguaggio di scripting usato (PHP, Pyton e Perl). Questo implica: velocità di esecuzione ridotta (compilazione durante l’esecuzione) ma facilità di scrittura programmi e portabilità (possono essere eseguiti su macchine diverse, basta che sia presente un motore di scripting). CGI Common Gateway Interface: È un’Application Server molto elementare, definisce le caratteristiche dei programmi lato server e le modalità con cui i dati vengono trasferiti tra Web Servers e programmi. Un’applicazione CGI è un programma che legge una REQUEST ed elabora una RESPONSE, I msg sono in formato HTTP. Vantaggi: scrittura applicazioni web in modo efficiente ed ottimizzato; si può utilizzare qualsiasi linguaggio di programmazione. Svantaggi: è poco flessibile, se si cambiano i dati in quantità e tipo occorre riscrivere sia la parte di elaborazione che l'interfaccia col web server; richiede la realizzazione di tutti gli aspetti dell’applicazione (un Application Server vero e proprio fornisce maggior supporto). ARCHITETTURA CGI: 1) nel caso di un eseguibile il web server lancia lo specifico processo che esegue l’applicazione richiesta. 2) nel caso di applicazioni interpretate (simile alle macchine virtuali) viene usato un interpreteper lo scripting (in PHP, Pyton e Perl) web server lo lancia all’interprete che si occuperà di eseguire lo specifico programma. Quindi: web browser richiede script, nel web server viene individuato lo script, analizzato e tramite il parser del linguaggio viene generata la pagina HTML da fornire al browser che l’ha richiesta. MODELLO SERVLET/JSP [pag.9] JavaServer Pages è una tecnologia di programmazione web in Java per lo sviluppo di applicazioni web che forniscono contenuti dinamici in formato HTML o XML. La scrittura di apllicazioni JSP richiede la definizione di pagine HTML contentente istruzioni in Java; Le pagine vengono tradotte in Servlet (programmi Java con una struttura speciale); supporto all’esecuzione di JSP fornito da application server (come Tomcat). REQUEST e RESPONSE HTTP vengono tradotte in strutture dati in

Java (classi pre-esistenti. HTTPServletRequest e HTTPServletResponse) che vengono manipolate. à APPLICAZIONI WEB (a e c) suddividono così il carico di lavoro perchè il bilanciamento dell’esecuzione fra client e server migliora le prestazioni e permette la personalizzazione delle applicazioni. Prestazioni: Alleggerire il server da computazioni elementari (es. controllo ortografico); Ridurre traffico di rete. Personalizzazione: scelta dell’organizzazione dei dati sulla pagina (es. scelta dei colori, dei dati visualizzati, ecc); Carico incrementale dei dati (no necessario caricare un’intera pagina ma solo dati che servono ad aggiornare una parte dei dati). AJAX Asynchronous Javascript and XML: è una tecnica (estensione di javascript) di sviluppo software per la realizzazione di applicazioni web interattive (RIA). Tecnologia (ma anche una metodologia e un modello d’implementazione) composta da una serie di strumenti già esistenti, che uniti insieme danno vita ad un potente modello di iterazione. Come metodologia richiama le funzioni RIA, portando piccole parti di dati piuttosto che ricaricare l’intera pagina, dal punto di vista implementativo riguarda più da vicino l’interfaccia utente UI e il rapporto sistema/utilizzatore. Tecnologie Ajax comprendono: HTML, usato x costruire le pagine web e identificare i campi per il successivo uso nel resto dell'applicazione. Un display dinamico di iterazione DOM (Document Object Model). DOM è utilizzato (tramite Javascript) per manipolare sia la struttura della pagina HTML sia le risposte XML restituite dal server DHTML o Dynamic HTML che aiuta a caricare i form in modo dinamico (aggiornamento dinamico delle pagine) con

comandi come div, span e altri elementi HTML. JavaScript, cuore del codice tramite cui funzionano le

Architetture multilivello

!  Alternative per applicazioni client-server (a) – (e)

!  Le applicazioni Web sono di tipo (a) – (c)

50

1-29

Modello Ajax

54

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

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

page import="java.util.*" buffer="16k" %> <%@ page import=“java.math.*, java.util.*” %> b) include include in compilazione pagine HTML o JSP <%@ include file="copyright.html" %> c) taglib dichiara tag definiti dall’utente implementando opportune classi d) forward determina l’invio della richiesta corrente, eventualmente aggiornata con ulteriori parametri, all’URL indicata, es. <jsp:forward page=“login.jsp” %> e) include: invia dinamicamente la richiesta ad una data URL e ne include il risultato, es. <jsp:include page=“login.jsp” %> f) useBean: localizza e distanzia (se necessario) un javaBean nel contesto specificato. Il contesto può essere la pagina, la richiesta, la sessione, l’applicazione. Es. <jsp:useBean id=“cart” scope=“session” class=“ShoppingCart” />. 4) Azioni: in XML <tag attributes>body</tag> 5) Elementi di scripting: istruzioni nel linguaggio specificato nelle direttive. Sono: a) Declaration <%! declaration [declaration] ...%> Variabili (che valgono per la durata della servlet) o metodi usati nella pagina, essi andranno a far parte della classe "servlet" generata dal compilatore JSP, la loro posizione all'interno del testo della pagina JSP è irrilevante. b) Expression <%= expression %> Una espressione nel linguaggio di scripting che viene valutata e sostituita con il risultato (il risultato viene convertito in stringa, e la stringa immersa nel codice HTML/XML nel punto corrispondente a quello dove compariva l'espressione stessa). c) Scriptlet <% codice %> Frammenti di codice che controllano la generazione della pagina, valutati alla richiesta. Le variabili valgono per la singola esecuzione, ciò che viene scritto sullo stream di output sostituisce lo scriptlet. Si può immaginare che durante la costruzione della pagina Web dinamica, il motore JSP includa senza elaborazioni i contenuti statici, procedendo dall'alto verso il basso nel documento, ed esegua immediatamente eventuali scriptlet incontrati durante l'operazione. Tecnicamente, questi scriptlet vengono inclusi nei metodi del servlet generato dalla pagina JSP, all'interno dei metodi che producono la risposta a una richiesta HTTP. Linguaggio di script ha lo scopo di interagire con oggetti java e gestire le eccezioni java. Gli oggetti impliciti sono gli elementi delle servlet (sono9, es. request, response, out, page). Tali oggetti possono essere creati: 1) implicitamente usando le direttive JSP 2) esplicitamente con le azioni 3) direttamente usando uno script (raro). Gli oggetti hanno un attributo che ne definisce la visibilità: scope. Visibilità crescente da page a request a session e a application. Sessione: da la possibilità di gestire efficientemente i cookie (come per le servlet), esiste un oggetto session implicito che può essere utilizzato

per la sessione: utilizza lo stesso sistema delle servlet; sessione server side; la sessione scade dopo un determinato time-out. Tutte le JSP che partecipano alla gestione della sessione di interazione con un utente possono memorizzare informazioni nell’oggetto implicito session. Attenzione alla memoria richiesta per la gestione della sessione degli

utenti ed al tempo in cui questa è mantenuta. FUNZIONAMENTO JSP Il client richiede via HTTP un file .JSP. Il file .JSP viene interpretato e accede a componenti lato-server (Java Beans, Servlet) che generano contenuti dinamici. il risultato viene spedito al client sotto forma di pagine HTML. La richiesta viene inviata ad un Java Servlet che genera i dati dinamici richiesti dall’utente. Il Servlet richiama un file .jsp, che si occupa di formattare in HTML i risultati e inviarli all’utente. JAVABEAN sono classi scritte in Java secondo una particolare convenzione. Sono utilizzate per incapsulare più oggetti in un oggetto singolo (il bean), cosicché tali oggetti possano essere passati come un singolo oggetto bean invece che come multipli oggetti individuali. Al fine di funzionare come una classe JavaBean, una classe di un oggetto deve obbedire a certe convenzioni in merito ai nomi, alla costruzione e al comportamento dei metodi. Queste convenzioni rendono possibile avere tool che possono usare, riusare, sostituire e connettere JavaBean. Le convenzioni sono: la classe deve avere un costruttore senza argomenti; le sue proprietà devono essere accessibili usando get, set, is e altri metodi (metodi accessori) seguendo una convenzione standard per i nomi; la classe dovrebbe essere serializzabile (capace di salvare e ripristinare il suo stato in modo persistente); non dovrebbe contenere alcun metodo richiesto per la gestione degli eventi. Lo scope determina la vita del bean: page è lo scope di default (viene messo in pageContext ed acceduto con getAttrubute) request (viene messo in ServletRequest ed acceduto con getAttrubute) session e application: se non esiste un bean con lo stesso id, ne viene creato uno nuovo. Il type permette di assegnargli una superclasse (al posto della classe si puo’ usare il nome del bean. beanName="nome" nome è la classe o un file serializzato). È raccomandabile usare MVC con le pagine JSP in modo da dividere il livello di presentazione da quello dell'elaborazione della request e dalla memorizzazione dei dati. Le normali servlet o pagine JSP dedicate vengono utilizzate per processare i dati. Dopo che l'eleborazione è terminata, il controllo passa ad una pagina JSP che serve solo a visualizzare l'output. Quest'ultima pagina JSP dovrebbe contenere solo HTML, XML e action e tag JSP; la pagina dovrebbe far uso dei JavaBeans per ottenere i dati. Quindi, nello sviluppo di un'applicazione web la convenzione vuole che nelle JSP ci sia meno codice Java possibile e quello presente vada a richiamare codice Java nativo (oggetti e metodi) implementato in classi separate

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

programmazione. Essendo basati su XML per la rappresentazione dei dati per tutti i protocolli e le tecnologie dei Web services, possono raggiungere la più completa indipendenza dal linguaggio di programmazione e dalla piattaforma utilizzata. Sono strutturati a livello, ogni livello ha le sue finalità. Nomi/protocolli/linguaggi per regolamentare/implement varie funzioni. 1)Architettura in base ai ruoli:

Service provider è il fornitore del servizio; implementa il servizio e lo rende disponibile su Internet. Da una prospettiva business rappresenta il proprietario del servizio, dal punto di vista architetturale è la piattaforma che ospita l’accesso al servizio. Service requestor è il responsabile dell’invocazione del servizio. Il service requestor localizza il Web service usando il service broker, invoca il servizio richiesto che viene eseguito dal service provider. Da una prospettiva business è il cliente richiedente la soddisfazione di determinate funzioni, da prospettiva architetturale questa è l’applicazione che effettua la ricerca e invoca o inizializza un’interazione con il servizio. Service registry è l’elenco logicamente centralizzato dei servizi. Il registry fornisce un punto centrale dove gli sviluppatori possono pubblicare nuovi servizi e trovarne uno già esistente. Il registry si comporta da intermediario (broker) per le società ed i loro servizi 2)Architettura in base a stack dei protocolli: La pila, ancora in fase di evoluzione, possiede 5 strati principali: Network i web services devono essere accessibili tramite rete per essere invocati da un service requestor. I Web services che sono disponibili comunemente su Internet utilizzano a questo strato HTTP (altri protocolli cmq sono supportati) XML-Based Messaging rappresenta l’uso di XML come protocollo per lo scambio dei messaggi. Il protocollo scelto per lo scambio di messaggi XML è SOAP (standard document-centric utilizzato per ‘avvolgere’ i msg e le chiamate di procedura remota usando XML. Il msg SOAP viene spedito come richiesta HTTP di tipo POST) Service Description strato responsabile della descrizione dell’interfaccia pubblica di un Web service. WSDL è lo standard de facto, basato su XML, per la descrizione di un servizio. Oltre a garantire l’interoperabilità, definisce l’interfaccia e il modo in cui si interagisce con il servizio. Service Publication e Service Discovery rappresenta lo strato responsabile della centralizzazione dei servizi fornendo le funzionalità di pubblicazione e ricerca di un servizio. Attualmente, lo standard utilizzato, basato su XML è UDDI. Service Flow descrive come comunicazioni service-to-service, collaborazioni e flussi sono eseguiti. XML è un linguaggio di markup, permette di: definire tag e loro grammatica (come devono essere strutturati) indipendentemente da sistema usato e dal fornitore. Rispetto all'HTML, l'XML ha uno scopo diverso: il primo definisce una grammatica per la descrizione e la formattazione di pagine web e, in generale, di ipertesti, il secondo è un metalinguaggio utilizzato per creare nuovi linguaggi atti a descrivere documenti strutturati. HTML ha un insieme ben definito e ristretto di tag, con l'XML è possibile definirne di

propri a seconda delle esigenze. A supporto di XML ci sono I linguaggi schema (permettono di creare nuovi linguaggi XML): DTD (Document Type Definition) è un documento attraverso cui si specificano le caratteristiche strutturali di un documento XML attraverso una serie di "regole grammaticali". In particolare definisce l'insieme degli elementi del documento XML, le relazioni gerarchiche tra gli elementi, l'ordine di apparizione nel documento XML e quali elementi e quali attributi sono opzionali o meno. XSD (XML Schema) come la DTD, serve a definire la struttura di un documento XML. Tecnica più recente ed avanzata della DTD. XML SCHEMA definisce la struttura che deve avere il documento; definisce gli attributi e gli attributi che possono apparire in un documento, definisce quali elementi sono “figli” e il loro numero; definisce se l'elemento è vuoto o può includere testo; definisce i tipi di dati per gli elementi e gli attributi e definisce valori di default e fissi per elementi e attributi. Migliore di DTD in quanto: XML schema sono estendibili a future aggiunte; sono più ricchi e più utili di DTD; sono scritti in XML; supportano data types e namespace. XML è portable (trasportabile) in quanto un XSD associato ad un documento permette al ricevente di validare (vedere se è strutturato bene) il

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

informazioni caratterizzate da una chiave unica. Attraverso un tModel è possibile definire: technical fingerprints per Web services; namespaces utili per identitificare business entities o per classificare business entities, business service, e tModels. La realtà è che UDDi non è così diffuso anche se ha il supporto di compagnia quali IBM e Microsoft. È molto usato in piccoli ambienti, ma a tale scopo è troppo complesso e fornisce troppi tipi di dato. Microsoft, IBM, ecc hanno spento I loro nodi UDDI pubblici nel 2006. SOAP Simple Object Access Protocol: è un protocollo (per SOA) leggero che permette lo

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

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

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

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

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

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

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

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

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

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"

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

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

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

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

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

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,

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.