Architetture per la comunicazione nel Web

Transcript

1 1 Architetture per la comunicazione nel Web 1.1 Principi di base Su Web, le comunicazioni si caratterizzano per un paradigma di funzionamento dell interazione noto con il nome di client-server. A ciò si affianca una modalità di comunicazione nota invece come store-and-forward, costruita sulla base di esso, che caratterizza le altre due grandi famiglie di protocolli del Web: posta elettronica e news. Il presente paragrafo descrive brevemente i due principi, mentre quelli successivi descrivono gli aspetti architetturali della comunicazione su Web di tipo client-server, a partire dai principi enunciati Il paradigma client-server Il meccanismo di comunicazione alla base del Web (e usualmente delle reti in generale) è quello cosiddetto client-server. Secondo questo paradigma, la computazione è distribuita su almeno due nodi: uno, definito client, richiede un servizio ad un altro nodo, definito server, utilizzando un linguaggio comune chiamato protocollo. Il server risponde (sempre con lo stesso protocollo), indicando l esito della richiesta ed allegando eventuali risorse fornite come risultato. Nel caso del Web, il protocollo utilizzato è http, i servizi richiesti consistono nella richiesta di risorse disponibili sul server, con l eventuale passaggio di parametri inseriti dall utente in un form HTML, e la risposta prevede una notifica del successo o fallimento della richiesta, seguita dall eventuale risorsa richiesta (figura 1.1) La comunicazione store-and-forward Un altro meccanismo di comunicazione importante su Web, realizzato tramite il paradigma client-server, è quello cosiddetto store-and-forward. Secondo questa modalità di comunicazione, le informazioni vengono dapprima acquisite o generate e memorizzate, e poi inviate al destinatario, per mezzo di uno o più intermediari. Nel caso della posta elettronica, gli intermediari sono costituiti da server SMTP che gestiscono la memorizzazione e l invio dei messaggi.

2 2 Capitolo 1 Figura 1.1 Interazione tra client e server 1.2 Il client per il Web Nel Web, il browser è il client per l accesso alle risorse. Esso viene comunemente inteso come dispositivo di visualizzazione, dotato di un interfaccia grafica e basato sull uso del mouse come strumento di interazione; si noti comunque che questo suo ruolo non è del tutto scontato, in quanto esistono client, destinati ad usi specifici, che sfruttano media diversi, come l audio sia per l output delle risorse che per la navigazione (browser vocali). Risorse web preparate correttamente sono, in linea teorica, utilizzabili facilmente da qualsiasi tipo di browser. Il browser implementa le seguenti funzioni: interpretazione delle richieste dell utente. La tipica richiesta utente è relativa all accesso ad una particolare risorsa Web, e come tale viene data usualmente in due modi: o scrivendo per esteso l identificatore della risorsa, oppure attivando un link presente in una pagina Web già ricevuta dal browser. recupero delle risorse. In base all identificatore indicato dall utente, il browser è in grado di iniziare una transazione col server che ospita la risorsa, inviando il comando HTTP per richiederla, ed attendendo la risposta, che comprenderà la risorsa stessa (se esiste). Se tale risorsa è costituita da un documento ipermediale HTML, è molto probabile che, al suo interno, incorpori altre risorse, come immagini, applet Java, eventualmente suoni. Queste ulteriori risorse, che possono essere ospitate nello stesso server di quella principale ma anche in altri, vengono automaticamente richieste dal browser ai server interessati con lo stesso meccanismo della pagina principale. gestione delle risorse. In base al tipo di risorsa (espresso tramite il formalismo MIME nella risposta del server), il browser attiva l azione più adeguata per gestire la risorsa, il più delle volte allo scopo di emettere un output (e, più specificamente, visualizzare). Nell effettuare l azione, il browser può utilizzare sia codice interno che altri programmi, secondo le tipologie descritte nel seguito: codice interno: il browser normalmente contiene tutte le funzioni necessarie a visualizzare risorse nei formati standard per il Web, più alcuni formati molto

3 Architetture per la comunicazione nel Web 3 diffusi. Ciò include sicuramente HTML per le pagine Web e JPEG, GIF, PNG per le immagini. plugin: i plugin sono sottoprogrammi esterni, caricati al lancio del browser, la cui esecuzione avviene all interno dell interfaccia del browser stesso, a cui sono collegati tramite una API standard. I plugin vengono di solito creati dai realizzatori di un particolare tipo di file, ed a volte comportano l esecuzione automatica di qualche altro programma esterno. Spesso i visualizzatori di filmati (MPEG, Real, WindowsMedia, Quicktime) sono realizzati in questo modo, come pure i gestori di media particolari (es. suoni MIDI). helper: gli helper sono in generale programmi esterni che vengono richiamati automaticamente quando si riceve una risorsa il cui tipo risulta associato ad un particolare programma (per quanto nella categoria possono essere fatti ricadere anche i plugin). La risorsa viene automaticamente salvata in un file, che viene passato come parametro al programma helper. Un esempio di helper è Acrobat Reader, che viene richiamato per visualizzare file PDF, ma è possibile configurare il browser affinché utilizzi qualsiasi programma per trattare risorse in base al tipo MIME o all estensione del nome di file (per esempio, per utilizzare Word come helper per i documenti che finiscono con.doc) Programmazione client-side Una categoria di azioni possibili nel browser è quella dell esecuzione di programmi ricevuti come risorse. Per ovvie questioni di sicurezza, il tipo di effetti possibili con questi programmi deve essere controllato e limitato, per evitare che, tramite web, si propaghi contenuto di tipo virale. Parliamo quindi di programmazione client-side, intendendo con essa la realizzazione di programmi destinati ad essere eseguiti nell ambiente particolare costituito dal browser. Attualmente ci sono tre approcci molto diffusi alla programmazione client-side: scripting, applet Java, e pagine Flash, descritti nei paragrafi successivi Scripting client-side Per scripting si intende l incorporazione di brevi programmi (scritti in un linguaggio detto appunto di scripting) all interno del codice HTML di una pagina, in particolare all interno dell elemento script. I programmi così scritti vengono interpretati direttamente dal browser. I linguaggi di scripting sono linguaggi di programmazione per automazione, manipolazione, e personalizzazione delle funzionalità fornite da un sistema software (che di solito incorpora il linguaggio di scripting stesso). Da questo punto di vista, il linguaggio di scripting non è autonomo quanto un linguaggio di programmazione tradizionale, ma agisce, tramite opportune librerie di funzioni, sulle caratteristiche del sistema software che lo incorpora. Nel caso del browser, un linguaggio di scripting fornisce costrutti per interagire con ciò che appare nel browser (finestre, documenti HTML e CSS) e per gestire input/output utente. Il linguaggio standard per fare ciò è ECMAscript, più noto come Javascript,

4 4 Capitolo 1 con associate le librerie (sempre standard) DOM (Document Object Model) (XXX DOM?). Le librerie permettono la manipolazione delle pagine caricate e degli elementi dell interfaccia del browser. Jscript è la variante Microsoft di ECMAscript, con leggere differenze rispetto allo standard. In pratica, ECMAscript viene utilizzato per verificare il contenuto dei form o per effetti grafici sulle pagine Web. A volte la combinazione che deriva dall uso di HTML, Javascript e librerie DOM viene chiamata DHTML (Dynamic HTML), anche se non esiste una singola specifica con tale nome Applet Java Le applet Java sono invece dei programmi già compilati in un codice intermedio, il quale può essere eseguito da una macchina virtuale disponibile su quasi tutte le piattaforme. L applet viene inserita in una pagina Web per mezzo dell elemento object, ed è costituita da un file separato contenente il codice intermedio. Il tipo di operazioni possibili con una applet è limitato (niente accesso al file system, comunicazioni solo verso il server di partenza, etc), anche se di solito il livello di sicurezza è gestibile dall utente. Una applet Java può potenzialmente essere un programma completo, solo che viene mandato in esecuzione all interno di un browser. Se l applet certificata, allora può avere accesso anche alle risorse che normalmente sono protette. La certificazione ha lo scopo di assicurare l utente sulla non dannosità del codice eseguito Applicazioni Flash Similmente alle applet Java, è possibile costruire programmi in un linguaggio compilato orientato alla multimedialità (Flash), che poi vengono eseguiti da un apposito plugin installato nel browser. Il contenuto realizzato in Flash è spesso orientato alla presentazione multimediale, ed è utilizzato per creare pagine animate e con caratteristiche di interazione non standard, diverse da quanto realizzabile con l interfaccia classica del browser. I programmi in Flash vengono inseriti in una pagina Web per mezzo dell elemento object. 1.3 Il server Web Il server Web, di base, è il solo programma server che gestisce il protocollo http. Questo significa che è un daemon in attesa su una porta TCP (per convenzione, la porta 80, ma può essere configurato in modo da rispondere su altre porte), come descritto al par. XXX. L attività principale del server è distribuire risorse, secondo le richieste dei client. Le risorse distribuite sono normalmente ospitate in un sottoalbero specifico del file system (a cui il server ha accesso, cfr. figura 1.2), ma possono anche essere generate all atto della richiesta, di solito sulla base di parametri specificati dall utente all interno di un modulo HTML. Per permettere ciò, il server http

5 Architetture per la comunicazione nel Web 5 GET /b/f/file.html 200 OK (file.html) CLIENT SERVER a b c d a è la radice del sottoalbero del web server, definita nella configurazione. e f g file.html Figura 1.2 Il server Web e le risorse statiche ha la possibilità di attivare programmi scritti in qualsiasi linguaggio, in grado di manipolare tali parametri e creare un output in una forma trasferibile all utente come se fosse una risorsa statica. A questo scopo si usano varie tecniche cosiddette server-side, descritte nei paragrafi successivi. In ogni caso, anche i programmi che generano dinamicamente le risorse sono ospitati nel sottoalbero, in punti specifici determinati a priori per questioni di sicurezza. La distribuzione di risorse su richiesta non è però l unica azione compiuta dal server web: altri compiti gestionali fanno parte delle sue attività, come l identificazione della risorsa, del suo tipo MIME, l eventuale autenticazione dell utente (poiché è possibile anche proteggere alcune risorse dall accesso pubblico), ed infine la registrazione degli eventi. Per comprendere meglio la complessità della gestione di un server Web, esaminiamo come avvengono i vari passi nel server Web più diffuso, Apache: 1. Traduzione da URI a nome di file: i server Web hanno la possibilità di far corrispondere a dei percorsi virtuali a dei percorsi reali nel proprio albero dei documenti; in questi casi, è necessario che in prima battuta gli URI richiesti dai client vengano tradotti. 2. Verifica dell identità dell utente: Per quanto non utilizzata spesso, c è sempre

6 6 Capitolo 1 la possibilità di concedere l accesso a determinate risorse in modo controllato. Il primo passo è la verifica dell identità dell utente, effettuata tramite username e password nel caso più semplice, oppure tramite firma digitale se si utilizza https. 3. Verifica dei privilegi di accesso: una volta identificato l utente, bisogna verificare se ha diritto di accedere alla risorsa. 4. Altre forme di autenticazione (per esempio, gestite da moduli che confrontano l utente con dati presenti su basi di dati). 5. Determinazione del tipo MIME dell oggetto richiesto: ciò permette sia di istanziare opportunamente la risposta, sia eventualmente di attivare moduli per la gestione di determinati tipi di documenti. 6. Fixups : estensioni ancora poco utilizzate. 7. Invio della risposta al client. 8. Registrazione degli eventi in appositi file di log (accessi, risorse richieste, eventali errori). In Apache, ogni passo è gestito da uno o più moduli tramite un apposita API. Parte dei moduli sono sviluppati direttamente dagli sviluppatori di Apache e sono parte del suo codice, altri sono stati prodotti da altri, spesso per la connessione con altri programmi esterni (per lo scripting, CGI, etc), ed è possibile aggiungerne ulteriori, sviluppati in proprio, per sviluppare funzionalità particolari Programmazione lato server Per programmazione lato server si intende quella serie di tecniche che consentono di creare dinamicamente risorse da distribuire tramite un server Web. Questo può essere ottenuto tramite programmi in grado di generare, su richiesta, flussi di dati che vanno a costituire formati tipici del Web, come HTML, CSS, JPEG, GIF (ma in linea di principio qualsiasi tipo di file gestibile dal browser). La programmazione lato server è utilizzata per accedere a basi di dati tramite un interfaccia Web, per autenticare gli utenti, etc. In questo modo, si possono costruire applicazioni interattive simili a quelle usuali, per quanto con qualche limitazione (dovuta all interazione tra client e server, che comporta la ricostruzione dell interfaccia ad ogni passo). In particolare, l accesso a basi di dati è estremamente diffuso, in quanto sempre più spesso i dati che costituiscono le pagine Web provengono da archivi che li conservano in forma strutturata, sia per facilità di manipolazione che che l oggettiva esigenza di mantenere grandi quantità di dati. Poichè l utente può fornire dei dati al server tramite i form HTML, la risorsa creata dal programma sul server spesso dipende proprio da tali dati. Si pensi per esempio all output di un motore di ricerca, costruito dinamicamente sulla base delle parole chiave impostate dall utente ed a partire da una ricerca su un database contenente la descrizione delle pagine Web. A questo scopo, è necessario che ci sia un interfaccia ben definita tra server http e programmi fisicamente residenti sulla macchina server, che permetta lo scambio di dati nell una e nell altra direzione: il programma dovrà ricevere i vari dati relativi alla specifica transazione, inclusi gli eventuali parametri forniti dall utente, mentre il server dovrà ricevere

7 Architetture per la comunicazione nel Web 7 la risorsa generata dal programma. Le varie tecniche utilizzabili per la programmazione server-side differiscono per la modalità di interazione tra server e programma, e per il luogo ove il codice è situato. I paragrafi successivi descrivono tre modalità generali di programmazione server-side Common Gateway Interface (CGI) Storicamente, il primo modo di generare dinamicamente risorse è stata la tecnica del CGI (Common Gateway Interface). Adottando l approccio CGI, l URI richiesta dal browser identifica un programma, che risiede in un sottoalbero ben preciso e protetto del file system (per questioni di sicurezza), il cui output è ciò che riceverà il browser come risposta a seguito della richiesta. Il programma CGI viene mandato in esecuzione dal server http passandogli come parametri, sotto forma di variabili d ambiente, tutti i dati relativi alla transazione, inclusi quelli forniti dall utente. Tra questi, ci saranno anche dati aggiuntivi come l indirizzo IP del client, il documento richiesto, etc. Nel caso l utente abbia compilato un form gestito con il metodo POST, quanto inserito nei campi verrà messo a disposizione del programma CGI sullo standard input. La figura 1.3 illustra il meccanismo di funzionamento dei programmi CGI sul server. La tabella seguente descrive alcune delle variabili d ambiente fornite al programma CGI. Tabella 1.1 Alcune variabili d ambiente CGI QUERY-STRING La lista di coppie campo-valore corrispondenti ai controlli di un form (usata con il metodo GET) PATH-INFO Informazioni aggiuntive messe dopo l URL CONTENT-TYPE Usata con il metodo POST, indica il tipo MIME delle informazioni che arriveranno CONTENT-LENGTH Usata con il metodo POST, indica quanti byte arriveranno sullo standard input del programma CGI Il programma deve essere in grado di emettere sull output standard (come se stampasse a video) il flusso di byte che costituirà la risorsa restituita al client dal server http, preceduta dall intestazione MIME secondo il protocollo HTTP. La risorsa è normalmente un file HTML, per cui il programma deve generare del testo che costituisca codice HTML valido, ma può anche essere un immagine (o altro file gestibile dal browser), per cui il programma CGI deve emettere i bytes nel formato corretto (per esempio, seguendo le specifiche di JPEG o GIF). Il programma può essere scritto in qualsiasi linguaggio che abbia accesso alle variabili d ambiente definite da CGI, sia direttamente che tramite librerie. Attualmente, il linguaggio più usato per i programmi CGI è il Perl, per la sua particolare attitudine alla manipolazione di stringhe. Un esempio banale di programma CGI in Perl è il seguente: #!/usr/bin/perl

8 8 Capitolo 1 GET /cgi-bin/x1?par1=val1&par2=val2 200 OK (output del programma x1) CLIENT cgi-bin è per convenzione la directory che ospita i programmi CGI nel sottoalbero del server Web. Il programma x1 riceve i parametri (par1 e par2) passati dal client, costruisce una risorsa emettendo dei dati sullo standard output. La risorsa viene restituita al client. SERVER a cgi-bin b c d e f g x1 x2 x3 file.html Figura 1.3 I programmi CGI print "Content-type: text/html\r\n\r\n"; print "<html>\n<head><title>titolo</title>"; print "</head\n"; print "<body>"; print "<p>ciao, Plutone.</p>"; print "</body></html>"; Anche senza conoscere il linguaggio, il funzionamento appare semplice: la prima istruzione print emette un intestazione MIME minimale, che dichiara il tipo HTML, e le linee successive producono un documento HTML. Tutto ci viene passato al server Web, e da questo al browser dell utente. Un meccanismo più raffinato ma sostanzialmente simile è quello delle servlet, programmi Java eseguibili sul lato server Scripting lato server Un altro meccanismo importante è quello dello scripting lato server: in questo caso, l URI richiesta dal browser identifica una risorsa costituita da codice HTML mescolato a spezzoni di scripts. Analogamente allo scripting client-side (ma con

9 Architetture per la comunicazione nel Web 9 importanti differenze dal punto di vista dell esecuzione), all interno delle pagine Web può infatti essere inserito del codice in un linguaggio di scripting, separato dal codice HTML per mezzo di un apposita sintassi che dipende dal linguaggio (usualmente è racchiuso in uno pseudo-tag, per esempio <? script?>. Questo è un esempio di documento HTML contenente del codice PHP: <html> <head> <title>esempio 1</title> </head> <body> <h1>esempio con PHP</h1> <p> <? echo "questo è un semplice script";?> </p> <? echo "<p>ed anche questo!</p>";?> </body> </html> Il server http è in grado di richiamare un modulo esterno di gestione in corrispondenza di determinati tipi di file richiesti dal browser (usualmente riconosciuti tramite l estensione o il tipo MIME). Il modulo verifica la presenza di script, individuando l eventuale presenza dello pseudo-tag che li contiene. Se lo pseudo-tag esiste, allora ne interpreta il contenuto e l output che questo produce viene sostituito all intero pseudo-tag. Se nello stesso documento compare più volte lo pseudo-tag, ognuno viene intepretato e sostituito, e lo stato della computazione viene mantenuto da uno all altro. Questo significa che, per esempio, è possibile definire una variabile all interno di un primo script, avere poi del codice HTML, e poi utilizzare la variabile precedentemente definita in un altro script ancora. L esecuzione normalmente affidata ad un programma esterno costituito dall interprete dello specifico linguaggio utilizzato, essendo il modulo unicamente un tramite tra questo ed il server Web. Si noti inoltre che l esecuzione viene effettuata ex-novo ad ogni richiesta, non una volta per tutte. Ciò che il client riceve è una risorsa Web che non ha più traccia degli scripts inseriti inizialmente. Per esempio, il documento dell esempio precedente giungerà al browser come segue: <html> <head> <title>esempio 1</title> </head> <body>

10 10 Capitolo 1 <h1>esempio con PHP</h1> <p> questo è un semplice script </p> <p>ed anche questo!</p> </body> </html> Le istruzioni echo hanno prodotto come output la stringa che hanno come argomento, e che, in programmi più utili, viene ricavata dinamicamente da un database o costruita dipendentemente da quanto passato dall utente come input. L input utente (per esempio, quanto inserito in un form) diventa disponibile sotto forma di variabili nella sintassi del linguaggio di scripting. La figura 1.4) schematizza i vari passaggi illustrati. CLIENT GET /b/f/file.php 200 OK (file.php) SERVER file.php (sorgente) <html> <head> <title>esempio 1</title> </head> <body> <h1>esempio con PHP</h1> <p> <? echo "questo è un semplice script";?></p> </body> </html> <html> <head> <title>esempio 1</title> </head> <body> <h1>esempio con PHP</h1> <p> questo è un semplice script"; </p> </body> </html> file.php (dopo la compilazione) MODULO PHP Figura 1.4 Scripting lato server Ovviamente, una pagina può anche essere totalmente costituita da script: l importante è però che al termine della sua esecuzione sia stata completamente sostituita con codice HTML (o altro formato leggibile dal client). Le risorse contenenti script lato server, diversamente dai programmi CGI, non sono ospitate in directory speciali ma possono essere situate ovunque, come i documenti HTML.

11 Architetture per la comunicazione nel Web 11 Esempi di linguaggi di scripting server-side sono PHP ed ASP, entrambi molto diffusi. È possibile però utilizzare anche Javascript, ed eventualmente anche altri linguaggi. Di nuovo, un meccanismo simile ma più raffinato è quello delle Java Server Pages (JSP), tecnologia che si basa sulle servlet ma con una modalità simile allo scripting Java Enterprise Edition La specifica di Java Enterprise Edition (J2EE) prevede, oltre alle caratteristiche di base del linguaggio (raccolte sotto la specifica Standard Edition, J2SE), una serie di tecnologie aggiuntive mirate alla realizzazione di applicazioni complesse di tipo client-server, tipiche di contesti aziendali e non necessariamente basate sull uso del Web (su cui comunque ci concentreremo). Diversamente da CGI e scripting generico, le tecnologie proprie di J2EE si basano strettamente su concetti orientati agli oggetti. Gli elementi costitutivi sono essenzialmente tre: servlet : classe Java con metodi per la gestione di richieste e risposte HTTP (in particolare, GET e POST). Java Server Pages (JSP): documenti in cui può essere presente codice Java mescolato a HTML. Vengono automaticamente compilati in servlet. componenti software: Java Beans ed Enterprise Java Beans, gestiscono funzioni specifiche e sono progettati in modo da renderne semplice il riuso. Nella versione Enterprise, fruiscono di opzioni avanzate quali la persistenza degli oggetti e la distribuzione. In questa introduzione verranno trattati sono i primi due elementi, e si accennerà al concetto di applicazione Web. Inoltre, affinché servlet e JSP siano realizzabili, è necessario un elemento software detto contenitore, descritto nel seguito. Il contenitore Il contenitore di servlet è un elemento software che lavora in cooperazione con il server Web, oppure che incorpora un server Web. Le funzioni generali di un contenitore includono: decodifica delle richieste dei client; gestione del ciclo di vita delle servlet; eventuale gestione delle sessioni e del contesto; supporto alla creazione della risposta http; in sistemi di alto livello, anche supporto alla replicazione e distribuzione del carico, sicurezza e persistenza In pratica, un contenitore di servlet e JSP, è in grado di compilarle e mandarle in esecuzione alla prima chiamata, attivandone i metodi quando richiesto, e passando gli opportuni parametri costituiti da quanto passato dal client assieme alla richiesta.

12 12 Capitolo 1 Il contenitore di riferimento è Apache Tomcat, un prodotto open source che implementa le specifiche relative a servlet e JSP, e che incorpora un server Web, anche se può essere utilizzato congiuntamente ad altri server Web per migliorarne le prestazioni. Servlets Similmente ai programmi CGI, le servlet gestiscono in toto una richiesta, per mezzo di appositi metodi. Alla richiesta della risorsa corrispondente alla servlet, il contenitore istanzia l oggetto servlet, e chiama un metodo specifico a seconda del tipo di messaggio ricevuto dal client (GET, POST o HEAD). Java Server Pages (JSP) JSP mescola il concetto di servlet con le tecniche proprie dello scripting lato server. Una pagina JSP è costituita da codice HTML inframmezzato a frammenti di codice Java, racchiusi nello pseudo-tag <% codice java %>. Alla prima richiesta, il contenitore compila automaticamente la pagina JSP in una servlet con lo stesso comportamento, che quindi sarà poi computazionalmente più efficiente. In questo modo, il programmatore ha a disposizione la semplicità di sviluppo propria dei linguaggi interpretati, senza il ciclo di compilazione, ma l efficienza è quella propria dei programmi compilati. Applicazioni Web Un applicazione web ùn insieme di file e directory disposti secondo uno schema standard descritto nella specifica delle servlet versione 2.2. L insieme contiene file HTML, immagini, pagine JSP, classi Java (servlet e Java beans), ed eventuali descrittori in XML, organizzati in modo opportuno a partire da una directory radice che è a sua volta ospitata dall albero del contenitore nella directory webapps. la figura 1.5 illustra lo schema di disposizione. Un applicazione web può essere racchiusa in un archivio WAR, che altro non è che un archivio JAR con un estensione per indicare che il contenuto è un applicazione Web. Nel sottoalbero delle applicazioni Web del contenitore ( webapps, appunto) è possibile anche inserire direttamente un archivio WAR, che il contenitore sa come gestire. In questo modo è possibile distribuire l applicazione in modo più semplice I sistemi di gestione del contenuto Negli ultimi anni si sono diffusi dei sistemi che permettono la gestione di siti Web in modo più astratto di quanto possibile secondo il paradigma usuale, in cui i contenuti sono codificati nei linguaggi per le pagine Web da sviluppatori che, facendo ciò, codificano anche la struttura Web del sito stesso. In questo modo, lo sviluppatore finisce per occuparsi anche di questioni di cui non dovrebbe occuparsi, come editare i contenuti; d altra parte, spesso i siti sono strutturati in modo ripetitivo, per cui parte del lavoro consiste nella replica di pagine esistenti, con modifiche proprio ai contenuti. Nei sistemi di gestione del contenuto, lo sviluppatore definisce una struttura generale per il sito, spesso con dei linguaggi specifici, e gli utenti vengono messi in grado di inserire i contenuti con appositi strumenti di authoring e senza la

13 Architetture per la comunicazione nel Web 13 webapps appl1 appl2 pagine JSP pagine HTML, immagini, etc radice dell' applicazione WEB-INF descrittore web.xml WEB-INF servlet bean Figura 1.5 Schema di una generica applicazione Web necessità di conoscere HTML o altro. Come esempio, si pensi ad un sito per la gestione dei corsi universitari: una volta impostata una struttura in cui la pagina di un corso sia costituita dal programma del corso, informazioni sul docente, ed un insieme di risorse didattiche, dando anche delle opzioni amministrative per inserire nuovi corsi o cancellare quelli vecchi, il lavoro dello sviluppatore Web potrebbe essere finito. Strumenti di questo tipo vengono chiamati Content Management Systems (CMS), o sistemi di gestione del contenuto. Possono essere generici, cioè adatti alla costruzione di qualsiasi tipo di sito, sia specializzati per determinate categorie, incorporando quindi a priori parte della struttura o delle possibili strutture del sito. Tra i prodotti generici, quello forse più diffuso è Zope, il quale è dotato di un suo linguaggio di programmazione interno (DTML) che viene usato all interno di pagine interpretate dal sistema. Un altro CMS generico è OpenCMS. I primi esempi di CMS sono nati però proprio tra i prodotti specialistici, in particolare tra i software nati per la gestione di comunità virtuali (con registrazione utenti, sistema di inserimento e pubblicazione di notizie, forum, archivio file, etc): tra questi, molto noti sono PHPNuke e Slashcode. Una volta impostato un sito con un CMS (il che significa essenzialmente

14 14 Capitolo 1 crearne la struttura), gli utenti abilitati possono inserire e modificare i contenuti in modo strutturato, spesso passando attraverso sistemi di flusso documentale che gestiscono il ciclo di editing-approvazione-pubblicazione tipico di situazioni in cui il materiale da pubblicare via Web debba essere prima accettato da un moderatore o un responsabile. Nei sistemi CMS specialistici la struttura è spesso predefinita, per cui basta impostare l aspetto grafico del sito, selezionare le opzioni volute, e poco altro. Si noti che i CMS sono di solito realizzati con tecnologie lato server più tradizionali: di fatto aggiungono uno strato astratto alle architetture di comunicazione su Web, e sono a tutti gli effetti delle vere e proprie applicazioni Web, realizzate in PHP (come PHPNuke), Python (come Zope), J2SE (come OpenCMS), Perl (Come Slashcode), etc. Gli stessi CMS generici sono un supporto per CMS più specifici (come per esempio Plone, costruito su Zope). A volte i CMS incorporano un server Web proprio, a volte agiscono in interazione con un server Web preesistente. CMS e XML Una particolare categoria di CMS è quella che fa uso di XML come sorgente di contenuti per i siti Web. L idea consiste nel mantenere in formato XML i vari contenuti che costituiscono un sito Web, descrivendo nello stesso linguaggio anche la struttura del sito e le varie opzioni estetico-funzionali che lo caratterizzano. Il CMS si occupa di tradurre i contenuti in risorse gestibili dal client, il che significa sia in HTML (ed immagini), sia in WAP, sia, se necessario, in formati più adatti alla stampa come PDF. Il sistema più importante in questa categoria è Apache Cocoon, che fornisce un motore di traduzione di XML in altri linguaggi basandosi sui fogli di stile XSLT. Su Cocoon sono stati poi costruiti dei CMS più astratti ancora, come Apache Forrest e Wyona.