Next: Il WWW1/27 Registratevi presso il wiki!!! Link: La Pagina di Registrazione Nel commento inserite: TW 12/13 o qualcosa di intelligibile dello stesso tenore. Usate una mail di cs.unibo.it oppure di studio.unibo.it. Ogni altra mail verrà ignorata!

Il WWW Fabio Vitali Next: Cos’è il WWW2/27

Next: I protocolli fondamentali del WWW3/27 Cos’è il WWW Il World Wide Web è un sistema per la presentazione a schermo di documenti multimediali, e per l’utilizzo di link ipertestuali per la navigazione. Il sistema è distribuito e scalato su tutta Internet, ed è basato su alcuni semplici concetti: u Il client o browser è un visualizzatore di documenti ipertestuali e multimediali. Può visualizzare testi, immagini e semplici interfacce grafiche, ma non editare documenti (salvo trucchi). u I browser hanno anche plug-in che permettono di visualizzare ogni tipo di formato speciale, e un linguaggio di programmazione interno (Javascript) che permette di realizzare semplici verifiche di dati oppure complicate applicazioni autosufficienti (Rich client) u Il server è un meccanismo di accesso a risorse locali (file, record di database, ecc.) in grado di trasmettere via socket TCP documenti individuati da un identificatore univoco u Il server può collegarsi ad applicazioni server-side ed agire da tramite tra il browser e l’applicazione cosicché il browser diventa l’interfaccia dell’applicazione. Ci sono svariati modi per farlo succedere.

Next: Evoluzioni del WWW (1)4/27 I protocolli fondamentali del WWW Alla base di WWW ci sono i seguenti protocolli: u Uno standard per identificare in maniera generale risorse di rete e per poterle specificare all’interno di documenti ipertestuali (chiamato URI). u Un protocollo di comunicazione state-less e client-server per l’accesso a risorse ipertestuali via rete (chiamato HTTP). u Un linguaggio per la realizzazione di documenti ipertestuali (HTML e ora XHTML) basato su SGML (e ora XML) e incentrato sulla possibilità di realizzare connessioni ipertestuali in linea nella descrizione strutturale del documento.

Next: Evoluzioni del WWW (2)5/27 Evoluzioni del WWW (1) Inclusione di oggetti: Mosaic introdusse il supporto per immagini in-line, e Netscape introdusse poi i plug-in per inserire oggetti di tipi diversi nel documento del browser, ed infine le applet Java. IE ha realizzato il protocollo proprietario ActiveX. Client Scripting: Netscape introdusse LiveScript, poi ribattezzato Javascript, per realizzare applicazioni client-side. IE rispose con Jscript e Vbscript. Sebbene standardizzato (da ECMA) per quel che riguarda sintassi e classi fondamentali, è sempre stato implementato differentemente da browser a browser. Adesso c’è Ajax. Stili: L’uso di trucchi per forzare HTML a rese grafiche insolite ha portato a creare linguaggi appositi per gestire gli aspetti di visualizzazione del documento. CSS permette di controllare le caratteristiche dei documenti HTML. Server-side includes: La possibilità di inserire all’interno del documento HTML ancora memorizzato sul server alcune istruzioni eseguite dal server stesso prima di spedirlo (data di oggi, utente registrato, numero di visitatori, piccole computazioni, ecc.)

Next: Mode del presente e del passato (1)6/27 Evoluzioni del WWW (2) Gestione delle transazioni: meccanismi per la gestione dello stato sono stati introdotti prima da Netscape, e poi standardizzati (cookies). Meccanismi di accesso in scrittura e cooperazione a risorse WWW sono stati aggiunti all’inizio del 2000 (WebDAV). Ajax introduce HTTPrequest, molto più dinamico. Siti web dinamici: I server-side includes e le applicazioni CGI evolvono e si fondono, diventano veri e propri linguaggi o ambienti di programmazione: Perl prima, poi ASP (Javascript e Visual Basic), poi PHP, Python, Ruby, ecc. Con l’arrivo delle librerie di accesso ai database (ODBC, JDBC, EJB, ActiveModel e altre) nasce l’architettura a tre livelli (user-interface, application logic, data storage). Il browser diventa l’interfaccia di eccellenza per applicazioni gestionali distribuite. Strutturazione dei documenti: i limiti di HTML non erano soltanto nella visualizzazione, ma anche nella strutturazione. XML permette di definire linguaggi di markup più adatti ai singoli task. Framework di sviluppo: ambienti integrati di sviluppo dotati di ricche API e librerie per la realizzazione semplificata di applicazioni client-side e server-side. Sono particolarmente noti Django per Python, Rails per Ruby, tutti i framework Ajax (Prototype, JQuery, Ext, Dojo, ecc.). Interessante anche l'esperienza di Google Web Toolkit (GWT), un frameworks AjaxJavascript espresso in Java, che integrai modelli di progettazione delle parti client-side e server-side.

Next: Mode del presente e del passato (2)7/27 Mode del presente e del passato (1) Trucchi di HTML u Il linguaggio HTML non nasce per ottenere speciali effetti grafici. In generale, HTML gestisce poco le caratteristiche di skin e per niente quelle di layout. u Tuttavia i progettisti di siti web trovavano queste limitazioni frustranti e inaccettabili. Dunque inventarono svariati trucchi, che tuttora si vedono, per ottenere certi effetti grafici sulle pagine web: F Immagini di testo invece che testo (soprattutto nei bottoni) F Tabelle di layout F Spacer (single-pixel gif) F Blockquote F Il tag F Estensioni di singoli browser ( ) u Tutte queste tecniche sono ormai obsolete e ingiustificate, e debbono essere sostituite con le corrispondenti tecniche standard.

Next: Mode del presente e del passato (3)8/27 Mode del presente e del passato (2) DHTML (Dynamic HTML) u Il linguaggio HTML non nasce per realizzare applicazioni interattive sofisticate attraverso siti web. Per questo motivo sono state aggiunte tecnologie aggiuntive per ottenere questi effetti. u Tra le tecnologie più importanti, Javascript, CSS e DOM u DHTML è il termine (di origine assolutamente commerciale) associato alle tecnologie web e ai siti web che fanno (o facevano - a partire dal 1997) uso di queste tre tecnologie e delle estensioni fornite dai produttori degli specifici browser. u L’approccio DHTML (all’inizio fortemente orientato al supporto di un solo browser a dispetto degli altri) è adesso rientrato nelle tecnologie standard ed è ora possibile creare siti e pagine fortemente dinamiche senza rinunciare alla interoperabilità. Si veda soprattutto Ajax e Web 2.0. Oggi DHTML è un termine assolutamente in disuso.

Next: Mode del presente e del passato (4)9/27 Mode del presente e del passato (3) Push, Pull e Poll u il modello di funzionamento di HTTP prevede che l’interazione tra client e server sia iniziata esclusivamente dal client. Quindi il client attira a sé (pull) i contenuti richiesti. Tuttavia questo richiede che il client (o, più precisamente, l’utente) richieda ogni volta l’informazione. u In certi altri casi, invece, si vuole prediligere la immediata disponibilità di informazione anche se l’utente non le ha richieste. Quindi il server spinge al client (push) i contenuti. Questo è il funzionamento di molte applicazioni di casting (webcasting, podcasting, streaming, ecc.) e anche di tutti i sistemi di instant messaging. u Sistemi più recenti utilizzano un modello pseudo-push basato su poll: un processo automatico, ad intervalli regolari, interroga il server (poll) per sapere se ci sono nuovi contenuti. Viene usato, per esempio da RSS.

Next: Mode del presente e del passato (5)10/27 Mode del presente e del passato (4) LAMP u La risposta open source al modello DHTML/ASP di Microsoft: F Linux F Apache F MySQL F Perl (successivamente anche PHP e adesso anche Python) u Uno stack di linguaggi e protocolli per la realizzazione di siti web dinamici e interattivi, con memorizzazione delle informazioni su un database relazionale, separazione di memorizzazione, logica e distribuzione. REST u Representational State Transfer: il modello di interazione tra client e server proposto da HTTP e spesso tradito in varie implementazioni. Una corretta applicazione di REST garantisce interoperabilità, scalabilità, e uso delle caratteristiche di HTTP più avanzate.

Next: Mode del presente e del passato (6)11/27 Mode del presente e del passato (5) Ajax u Asynchronous Javascript And XML: un meccanismo per generare applicazioni web client-side e server-side fortemente interattive e in grado di minimizzare il traffico di rete. Web 2.0 u La buzzword attualmente più usata. Ha un significato tecnico e uno sociale/economico/marketing F Significato tecnico: l’insieme delle tecnologie, basate sulla teoria delle architetture REST, di Ajax e di RSS, che generano siti altamente interattivi e dinamici, in grado di fornire più servizi della semplice erogazione di contenuti F Significato sociale: l’insieme degli strumenti di partecipazione attiva alla costruzione di contenuti per il web: blog, wiki, bookmark sociali, podcast, RSS, folksonomie, ecc. Tutto ciò che usa il web come piattaforma (e non sorgente), che è fortemente orientata ai dati, che sfrutta la partecipazione distribuita e il network effect, che è basata su assembly di sistemi diversi piuttosto che su applicazioni monolitiche.

Next: Architetture del World Wide Web12/27 Mode del presente e del passato (6) Cloud computing u un'architettura lato server in cui i server non sono più macchine fisiche ma cluster di istanze di macchine virtuali. u netta divisione tra tipi di macchine virtuali F usate per i calcoli: nessun disco, ciò che non è esplicitamente salvato in un altra locazione può essere perso in qualsiasi istante, nessuna certezza di completamento delle operazioni; F usate per il salvataggio di dati: dischi ai quali accedere da remoto tramite HTTP e REST, niente directory, solo coppie, grande utilizzo di funzioni di hash. NoSQL u un'architettura per database in cui F le tabelle sono viste come collezione di colonne, non righe (Google BigTable, Apache HBase) F non si usa SQL per le interrogazioni ma algoritmi di filtro applicati a più colonne separatamente e contemporaneamente (Google MapReduce, Apache Hadoop) F pochi vincoli d'integrità referenziale u grande successo dovuto anche al diffondersi dell'uso di tag messi dagli utenti. I tag sono molto difficili da gestire (schemi e tempo di computazione) nei database relazionali.

Next: Sito web statico13/27 Architetture del World Wide Web Sito web statico Sito web dinamico: server-side include (SSI) Sito web dinamico: modello a tre livelli Embedded code Full application Sito web dinamico: modello a quattro livelli Rich client: applicazioni AJAX

Next: Siti dinamici: server side include (SSI)14/27 Sito web statico n Il server contiene una quantità di file fisici memorizzati in directory e di formati immediatamente riconoscibili dal browser (HTML, GIF, JPEG ecc.) n C’è esattamente un file per ogni schermata possibile, ciascuno con un indirizzo (un URL) diverso. n Il client richiede questi file ad uno ad uno e li riceve per la visualizzazione. n Nessun contenuto visualizzato cambia rispetto al documento memorizzato su disco n Pregi: facile da realizzare, non richiede nessuna competenza tecnica n Difetti: totale mancanza di automazione e integrazione. Ogni file è indipendente dagli altri.

Next: Siti dinamici: modello a tre livelli15/27 Siti dinamici: server side include (SSI) n Il sito comprende una quantità di file fisici memorizzati in directory e di formati immediatamente riconoscibili dal browser. n C’è esattamente un file per ogni schermata possibile, ciascuno con un indirizzo (un URL) diverso. n All’interno dei file HTML ci sono commenti speciali. Ad esempio: n Questi corrispondono a specifiche azioni che vengono effettuate dal server subito prima della spedizione del file richiesto. C'è un vocabolario molto limitato di azioni che possono essere eseguite. n Pregi: fornisce una qualche forma di modularità. È ancora molto semplice da usare n Difetti: troppo limitato per essere veramente utile in contesti generali. Posso solo modularizzare frammenti che si debbono ripetere su più file e realizzare micro-espressioni di contenuti dinamici.

Next: Tre livelli: embedded code (1)16/27 Siti dinamici: modello a tre livelli Parte dei contenuti è statica e memorizzata su file, ma la parte importante è generata in output da un'applicazione server-side. Questa spesso raccoglie dati da query su un DBMS, le elabora e le trasforma, e le spedisce come risposta al browser. L'application logic (a volte business logic) si modularizza rispetto allo storage per poter usufruire delle velocità e funzionalità dei DB indipendentemente dalla logica dell'applicazione. u Embedded code u Full application Tipicamente associata a modelli applicativi di tipo LAMP Storage Application Logic + Presentation Browser Internet

Next: Tre livelli: embedded code (2)17/27 Tre livelli: embedded code (1) n Il sito è in realtà un'applicazione. Esso contiene alcuni file fisici memorizzati in directory e di formati immediatamente riconoscibili dal browser. C'è un file per ogni tipo di funzionalità (servizio) offerto. n I file HTML contengono commenti speciali con codice inserito in qualche linguaggio di programmazione (PHP, ASP, ecc.). La parte puramente HTML è ripetuta su ogni risposta spedita dal server, mentre le istruzioni embedded generano codice HTML di volta in volta diverso. PHP Test Stai usando il browser.

Next: Tre livelli: full application (1)18/27 Tre livelli: embedded code (2) n La singola pagina HTML può contenere (e di solito contiene) molti blocchi codice embedded. La parte HTML è il template, mentre il codice fornisce la parte dinamica dell'applicazione. n Tuttavia si deve fare attenzione a mantenere sincronizzati tutti i template per quel che riguarda la presentazione. Un cambio di look al sito richiede di modificare ogni singolo file. Questa commistione di codice e template può essere considerata fragile e poco pulita. n Pregi: assolutamente potente. Si può realizzare qualunque applicazione server-side con poco sforzo e in maniera fortemente integrata ai template HTML n Difetti: architettura fragile: cambiamenti al codice possono esporre problemi di visualizzazione del template e viceversa modifiche al look possono cambiare il comportamento dell'applicazione.

Next: Tre livelli: full application (2)19/27 Tre livelli: full application (1) Si attua una separazione forte tra logica di applicazione e presentazione. Risiedono fisicamente su file diversi e vengono modificati in momenti diversi del processo di produzione, garantendo l'interdipendenza. In tutti i casi, il server esegue il file di programma e alla fine genera un singolo output dell'intera stringa del documento HTML. Ci sono vari modi per ottenerlo, ma questi sono i più comuni: u Il template viene generato da istruzioni nel linguaggio usato, ma contenute in un file separato, che viene richiamato all'interno del programma che gestisce la logica principale dell'applicazione u Il template viene contenuto in un file HTML statico che viene letto in una variabile del programma e sapientemente mescolato con ilcontenuto HTML dinamico, generato dal programma lavorando sulle stringhe. u Si usa un motore di template per PHP, ASP, ecc. Ogni produzione del programma diventa una variabile che viene usata all'interno del template, che è un file HTML. Il motore di template esegue il programma, poi carica il template e ne fa l'unione.

Next: Siti dinamici: modello a quattro livelli (1)20/27 Tre livelli: full application (2) Pregi: si crea un'importante separazione tra application logic e presentazione. Questo permette di separare i processi di generazione e test dell'applicazione da quelli di progettazione della parte visibile del sito. Difetti: Questa separazione non è ancora completa. Ma si applica solo al template (layout complessivo, decorazioni, schemi di colori, parti fisse della pagina, ecc.). Il codice HTML di ogni singolo pezzo di output è ancora deciso dall'applicazione. u Ad esempio, che l'output di una query venga restituito come lista o come tabella è ancora una decisione dell'application logic. u Ad esempio, generare output personalizzati per device molto diversi è ancora difficile.

Next: Siti dinamici: modello a quattro livelli (2)21/27 Siti dinamici: modello a quattro livelli (1) Nel modello a quattro livelli, il livello di application logic genera un output completamente privo di aspetti presentazionali (ad esempio, un file XML) e lo dà in pasto a un altro livello, che chiamiamo appunto presentazione (anche presentation logic) Presentation modifica completamente il documento posizionando le varie parti dell'output dentro al template in maniera completa e assoluta, prendendo anche micro-decisioni riguardo a quale HTML usare di volta in volta. Template diversi possono applicarsi allo stesso output per personalizzarsi su specifici tipi di device mantenendo assolutamente intatta l'application logic. Storage Application Logic Browser Internet Presentation

Next: Rich client: Ajax e il web 2.022/27 Siti dinamici: modello a quattro livelli (2) Esistono motori di template che funzionano in questa maniera, ma francamente la soluzione ottimale è semplicemente usare XSLT per generare il documento HTML finale. Un processo della catena di produzione dell'output (ad esempio usando tomcat) o semplicemente l'ultima istruzione della application logic del programma richiama il motore XSLT sul documento XML prodotto, e restituisce in output il documento HTML finale. Pregi: completa e definitiva separazione tra application logic e presentation logic; architettura semplice, modulare, immediatamente ripetibile. Difetti: i difetti di tutte le applicazioni server-side. Si veda la prossima slide

Next: Rich client: Ajax e il web 2.023/27 Rich client: Ajax e il web 2.0 Tradizionalmente la programmazione client-server ha sempre criticato la presenza di application logic sul client. u Poco controllo sull'ambiente operativo u Difficoltà di distribuzione di versioni e patch u Possibilità di intromissioni da codice maligno che si spaccia per il client autorizzato. Tuttavia il WWW ha alcune obiezioni a queste critiche u ogni passo dell'applicazione richiede di consultare il server, eseguire una funzione dell'application logic, generare l'HTML finale, riceverlo e visualizzarlo. Questo può portare via molto tempo. u Ogni passo dell'applicazione ha un proprio URL, che richiede specifiche politiche di naming e di caching piuttosto complesse da gestire Inoltre ha risposte specifiche alle critiche di cui sopra: u I browser sono ambienti indipendenti dal sistema operativo, e (più o meno) sono standardizzati u Il codice comunque può risiede sul server ed essere distribuito al client ogni volta, in modo da garantire che giri sempre l'ultima versione. u Per lo stesso motivo, codice maligno non può essere iniettato da terze parti malevoli.

Next: Un confronto24/27 Rich client: Ajax e il web 2.0 All'inizio dell'esecuzione del servizio, il browser carica una normalissima pagina HTML, che contiene codice Javascript e alcune librerie Ajax. Scopo delle librerie Ajax è duplice: u Garantire di fornire una libreria di funzioni comuni e indipendenti dallo specifico sistema operativo e browser utilizzato u Fornire librerie utili per la realizzazione di applicazioni client side in maniera facile (ad esempio, l'interazione con il server o la generazione di frammenti di output). Il documento HTML contiene solo le parti fisse (template, ecc.) e le funzioni javascript. Il programma parte e attraverso un'apposita chiamata di libreria (XMLHttpRequest) chiede al server dati presentation-independent da convertire in HTML e visualizzare sulla pagina. Qui possiamo avere: u Esiste comunque un'applicazione server-side che genera l'XML e lo passa al client: cioè si sposta sul client solo la presentation logic u Sul server esiste solo il minimo indispensabile per fare interrogazioni ai server e ottenere le risposte alle query (si spostano sul client sia la presentation logic sia la application logic).

Next: Conclusioni25/27 Un confronto Storage Application Logic + Presentation HTML Internet Storage Application Logic HTML Internet Presentation Storage Application Logic HTML Internet Presentation Storage Application Logic HTML Internet Presentation Tre livelliQuattro livelliAjax

Next: Riferimenti26/27 Conclusioni Qui abbiamo parlato di u Storia degli ipertesti u Evoluzione ed involuzione del WWW u Struttura e principali concetti del WWW