componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali

Transcript

1 1 Premessa I sistemi informativi basati su Web sono usati per gestire grandi quantità di informazioni su Internet e per gestire la collaborazione tra siti distribuiti che cooperano agli stessi scopi aziendali. Scopo di questo volume è illustrare principi e tecniche riguardanti la struttura, il progetto e le tecnologie che costituiscono un sistema informativo basato su Web. Il volume non intende coprire tutti i possibili scenari d uso dei sistemi informativi basati su Web, ma piuttosto cerca di dare al lettore gli strumenti per comprendere gli scenari d uso tipici di tali sistemi, le soluzioni tecnologiche e metodologiche che ne sono alla base e i benefici che si possono ottenere usando tali sistemi. Quindi, il volume tratta gli aspetti e i problemi coinvolti nel fornire informazione e servizi attraverso Internet con riferimento particolare ai sistemi informativi e al World Wide Web. Sfruttando l infrastruttura del Web, tali sistemi informativi sono in grado di gestire informazioni multimediali, di eseguire applicazioni distribuite e cooperative basate sul concetto di servizio e di personalizzare le applicazioni, i dati e i modi di presentarli all utente in base alla personalizzazione nell accesso e nella gestione dei contenuti fondata sulla profilazione utente. Il volume descrive quindi le tecnologie usate per il Web e presenta le linee guida e le strategie per usare tali tecnologie nel progetto e nello sviluppo di sistemi informativi basati su Web. Inoltre, il volume illustra gli aspetti di sicurezza dei sistemi informativi basati su Web i quali, raggiungendo una grande quantità di utenti e mettendo a disposizione vaste fonti di dati e servizi, presentano vari problemi di autenticazione e privacy. Il volume presenta sia aspetti attuali sia tematiche avanzate riguardanti la creazione e manutenzione delle risorse del sistema informativo basato su Web e fornisce una visione il pi possibile unificata delle tecnologie e degli standard internazionali più importanti. Il volume si articola nei seguenti capitoli. Il Capitolo 1 definisce un sistema informativo basato su Web, ne descrive le caratteristiche fondamentali, discute le opportunità e i problemi legati allo sviluppo e all utilizzo di tali sistemi informativi in azienda e illustra un esempio di sistema informativo basato su Web. Tale esempio è il Portale del Sistema Informativo per il Lavoro italiano, che è una federazione di nodi a livello provinciale, regionale e nazionale che cooperano in rete per scambiarsi informazioni e servizi riguardanti l occupazione e il lavoro. Si mostra come il Web costituisca sia l interfaccia navigazionale e di accesso sia la tecnologia base per realizzare l interfaccia verso applicazioni tradizionali e basi di dati informative e statistiche. Il Capitolo 2 fornisce una panoramica dei

2 2 componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali per l uso di tali tecnologie nei sistemi informativi. Il Capitolo 3 illustra le applicazioni Web, partendo da HTTP, per arrivare alle tecnologie per la generazione di pagine dinamiche. Il Capitolo 4 presenta la progettazione di sistemi informativi basati su Web; la metodologia utilizza UML e comprende le fasi di pianificazione, analisi dei requisiti, progettazione dettagliata e cenni agli aspetti realizzativi. Il Capitolo 5 illustra i problemi di sicurezza e le soluzioni tecnologiche e organizzative per fronteggiarli. Infine, il Capitolo 6 descrive i Web service in termini di definizioni, linguaggi e ambienti per la loro specifica e per il loro uso in Sistemi Informativi Cooperativi.

3 1. Introduzione Internet e il World Wide Web (semplicemente Web nel seguito) sono oggi uno dei fondamenti su cui le organizzazioni basano i loro sistemi informativi per costruire un economia centrata sull informazione. Fra i vari modi per rispondere alle sfide di un economia globale vi è quella di valorizzare l informazione e gli strumenti per gestirla. Per questa valorizzazione, gli strumenti costituiti da Internet e dal Web sono una buona risposta perchè permettono di raccogliere, gestire in modo correlato e distribuire in vari formati una grande quantità di sorgenti informative eterogenee. Spesso tali sorgenti sono distribuite per loro natura, come per esempio in organizzazioni multinazionali, pubbliche amministrazioni o centri di ricerca. Inoltre, le fusioni aziendali, le acquisizioni, e le partnership hanno costituito un altra forte motivazione per integrare le informazioni. In questo contesto, i sistemi informativi devono oggi affrontare vari aspetti di complessità sia progettuale sia di gestione, dovuti alla presenza di varie fonti informative, di basi di dati differenziate per modelli e tecnologie, di reti di comunicazione basati su vari protocolli e infine dovuti alla presenza di processi aziendali distribuiti e interconnessi nella cooperazione. Si parla infatti spesso di applicazioni cooperative intendendo applicazioni distribuite su vari nodi, appartenenti ad unità organizzative le quali, per cooperare a uno scopo comune, necessitano di programmi che cooperano svolgendo parti di un flusso di lavoro comune. Per affrontare tali complessità, oggi si progettano e realizzano applicazioni distribuite, ovvero programmi che permettono alle organizzazioni di distribuire e gestire il carico applicativo e l informazione in rete. Le applicazioni distribuite nei sistemi informativi basati su Web aggiungono valore al patrimonio informativo aziendale e nel contempo sono lo strumento per estrarre conoscenza e dati dallo stesso patrimonio. Tale conoscenza è sia operativa che strategica, di pianificazione e di controllo aziendale. Quindi la conoscenza ha varie valenze ed è importante disporre di strumenti per gestire tale patrimonio informativo distribuito, per selezionare la conoscenza e soprattutto per distribuirla all interno e all esterno dell organizzazione, attivando scambi proficui per i clienti, per i fornitori e per la stessa organizzazione. Più in generale, nell ambiente oggi altamente competitivo dell economia dell informazione, il tempo di risposta alle esigenze aziendali è una delle 3

4 4 CHAPTER 1. INTRODUZIONE chiavi di successo; le organizzazioni hanno bisogno di sviluppare tempestivamente applicazioni specifiche, di personalizzarle facilmente e di migliorarle per aumentarne l efficacia. È quindi necessario disporre di strumenti per integrare con facilità le nuove applicazioni distribuite con i sistemi aziendali esistenti e per scalarle e modularle a seconda delle esigenze. Lo scopo dei sistemi informativi basati su Web è di integrare un insieme di funzionalità tipiche dei sistemi informativi, quali l interazione con una o più basi di dati, la gestione delle transazioni, un interfaccia utente evoluta, o la distribuzione del carico applicativo. Obiettivo è sfruttare le potenzialità informative, navigazionali e distribuite del Web, utilizzando piattaforme integrate di gestione dati, applicazioni e comunicazione, adattabili alla continua evoluzione delle tecnologie, senza spostare drasticamente o bruscamente l asse principale della struttura di base del sistema informativo aziendale. Le esigenze di sviluppo di un sistema informativo basato su Web riguardano modelli e strumenti per la gestione della tecnologia del Web nell ambito di un sistema informativo di impresa. Uno dei paradigmi di sviluppo più utilizzati è lo sviluppo di applicazioni in termini di Servizi e di Componenti che, basandosi su una piattaforma unificata, è in grado di integrare applicazioni client-server, funzionanti su sottoreti (Intranet) aziendali, con applicazioni distribuite di tipo Web su Internet. 1.1 I sistemi informativi basati su Web A questo punto è possibile definire con maggior precisione che cosa si intende per sistema informativo basato su Web e perché le organizzazioni dovrebbero considerare l idea di rendere i loro sistemi informativi basati su Web, ovvero renderne le funzionalità e i dati disponibili in rete, per esempio tramite i servizi Web. In generale, un sistema informativo basato su Web è un insieme di applicazioni che diffondono informazioni in modo interattivo con l utente basandosi su pagine e/o applicazioni Web. Esso si basa su standard come Java, JavaScript e in genere su estensioni di HTTP e HTML, e loro evoluzioni quali SOAP Service Oriented Application Protocol e XML. Attualmente si fa ampio uso anche delle tecnologie dei Web Service, come verrà descritto nel Capitolo 6. Le applicazioni che si presentano su Internet usando le tecnologie del Web sono denominate basate su Web, o più in generale sistemi informativi basati su Web (WWW-based Information Systems). Tuttavia, un sistema informativo basato su Web è diverso da una applicazione o pagina Web standard;

5 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 5 la natura e il tipo di informazione che viene resa disponibile all utente sono diverse. La pagina Web standard è unidirezionale nel fornire informazioni all utente, il quale sottopone richieste a siti basati su cataloghi o direttori seguendo link ipertestuali. Un sistema informativo basato su Web può invece definirsi come una applicazione che non solo diffonde informazione, ma anche che interagisce attivamente con l utente. Pertanto, l informazione viene fornita all utente mediante un interazione bidirezionale. In particolare, l Unione Europea ha definito nel proprio Libro Verde una classificazione dei servizi elettronici in rete e le varie tipologie di servizi elettronici in rete, i livelli di interazione e la classificazione dei siti Web. Tali classificazioni saranno illustrate nel seguito di questo Capitolo. Le informazioni trattate sono dati di varia natura (dati strutturati e non, immagini, testi, suoni, e così via) e possono anche essere link ad altre risorse informative. In particolare, su Web si può avere: 1) l accesso a pagine statiche (file) o pagine dinamiche, ottenute tramite interrogazioni a basi di dati; 2) la personalizzazione dei dati, in particolare la personalizzazione delle modalità di presentazione di informazioni; 3) l accesso senza inserimento di contenuto informativo nel sistema da parte dell utente. La tipologia dei servizi elettronici viene classificata anche rispetto alle modalità di comunicazione (servizi di interazione, servizi basati su , liste di discussione, chat, form per inserimento richieste, o altro) oppure in base ai servizi offerti e alle modalità di accesso dell utente. Queste definizioni hanno carattere ancora molto generale, ma servono a introdurre dapprima i concetti che accomunano le pagine Web ai sistemi informativi (o applicazioni) basati su Web. Entrambi i sistemi adottano estensioni all HTML di base, usando Java, Java Script, o controlli ActiveX/COM per fornire ulteriori funzionalità, oltre ai link ipermediali di base. La creazione dinamica di pagine HTML è un altro aspetto caratteristico dei sistemi informativi basati su Web; si usa una connessione a una base di dati relazionale o a oggetti per eseguire la richiesta utente. Questo elementi è diventando importante in molti settori applicativi, come il commercio elettronico, o gli acquisti on-line, dove si presenta la necessità di gestire le richieste utente e nel contempo di tenere aggiornata l informazione presente sulla pagina Web. L emergere di applicazioni su Web centrate sulla interazione con la base di dati ha portato poi a un cambiamento nel modo di intendere e progettare le pagine Web. Questo cambiamento si basa sulla distinzione fra pagine statiche e dinamiche. I sistemi a ipertesto statici, come comunemente forniti dalle pagine Web standard, possono essere caratterizzati sia da link statici sia da pagine statiche. Le applicazioni centrate sulla base di

6 6 CHAPTER 1. INTRODUZIONE dati sono caratterizzate dalla creazione di pagine dinamiche, ma hanno una struttura statica dei link. Invece, le applicazioni dinamiche forniscono sia una struttura dinamica dei link sia la creazione dinamica delle pagine. I sistemi informativi basati su Web ricadono nella categoria delle applicazioni centrate su basi di dati e di tipo dinamico Definizioni e concetti Vi sono varie definizioni di sistemi informativi basati su Web, che spaziano da quelle prettamente tecnologiche, a quelle organizzative, fino a quelle molto semplificate di sistema informativo distribuito. Un esempio di sistema distribuito è riportato nel disegno di Fig. 1.1 relativo alla struttura distribuita del sistema informativo del Ministero delle Finanze. I vari nodi (Agenzie Centrali, Dogane e Uffici delle Entrate) si affacciano ad una rete geografica proprietaria del Ministero (Intranet) e, tramite firewall, alla rete Internet. Altri enti della Pubblica Amminsitrazione sono collegati in rete tramite accesso alla RUPA (Rete Unitaria della Pubblica Amministrazione).

7 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 7 Figure 1.1: Esempio di Sistema Informativo in rete: Il ministero delle Finanze Un sistema informativo basato su Web è spesso definito come un insieme di applicazioni software, accessibile tramite il Web (o tramite una Intranet aziendale) da parte di un insieme di client, usando protocolli di comunicazione basati su HTTP come protocollo trasmissivo e HTML come linguaggio di programmazione e interazione, per arrivare a protocolli più completi dal punto di vista delle funzionalità, quali SOAP (Simple Object Access Protocol) e XML, che si fondano sul livello del protocollo standard di Internet HTTP. I client accedono alle risorse del sistema informativo invocando le applicazioni, attraverso le loro interfacce e realizzando gli opportuni binding, definiti usando elementi XML, oppure definendo i Web service, tramite opportuni linguaggi come il Web Service Definition Language (WSDL), e permettendone poi l invocazione. I sistemi informativi basati su Web sono il risultato di una evoluzione naturale del Web in azienda. Inizialmente, il Web consisteva di siti composti da pagine HTML. Successivamente, le applicazioni Web sono diventate in

8 8 CHAPTER 1. INTRODUZIONE grado di generare dinamicamente le pagine HTML. Per esempio, una mappa geografica realizzata su un sito Web inizialmente forniva solo link statici a mappe di varie città e zone o località. Più di recente, questa stessa mappa Web è divenuta una applicazione Web che fornisce indicazioni, mappe personalizzate e informazioni specifiche per l utente che personalizza le proprie richieste in base ai risultati cercati. Nonostante le loro capacità molto migliorate, le applicazioni Web sono spesso ancora limitate alle capacità di presentazione delle pagine HTML una applicazione Web è utilizzabile solo nei confini di tipo GUI (Graphical User Interface) legati alle pagine HTML. Invece, le applicazioni Web, specie se basate sui Web service, superano queste limitazioni perchè separano il sito Web, o l applicazione (il servizio) dalla sua interfaccia, di tipo HTML. Il servizio è rappresentato in XML ed è disponibile tramite il Web come documento XML. Come risultato, il sito Web contenente per esempio una mappa geografica può estendere le proprie funzionalità fino a fornire un Web service utilizzabile da un organizzazione per fornire indicazioni ai propri uffici delocalizzati, oppure alle strutture di altre organizzazioni, oppure ancora per integrare un sito con un sistema mobile, basato per esempio su un Global Positioning System (GPS) o su una rete di trasmissione di tipo wireless. Come si è visto in questa breve presentazione, il concetto di servizio, costruito sulle basi tecnologiche realizzate in altre tecnologie più mature nell area dei sistemi distribuiti (come CORBA e Java Remote Method Invocation) è uno dei concetti centrali dei sistemi informativi basati su Web. Esso permette la comunicazione applicazione-applicazione (peer-to-peer) e l interoperabilità. I servizi forniscono in particolare un modo standard per le applicazioni di esporre in rete le loro funzionalità su Web o di comunicare con altre applicazioni, indipendentemente dall implementazione dell applicazione, dai linguaggi di programmazione o dalla piattaforma esecutiva. Dunque, tramite il concetto di servizio, le applicazioni del sistema informativo basato su Web possono fornire un vasto insieme di funzioni, realizzabili indipendentemente dagli ambienti di sviluppo e facilmente invocabili da altri nodi della rete. Alcune funzioni possono semplicemente gestire la richiesta di informazioni (servizi informativi), mentre altre possono implementare processi e interazioni aziendali complessi (servizi a valore aggiunto). Inoltre, alcune applicazioni, semplicemente basate su browser, possono occuparsi di gestire la rappresentazione dei dati all utente finale, mentre altre, di natura più articolata e, per esempio, realizzate mediante Web service, abilitano i client, in modo programmatico, non solo ad usare il Web per ottenere informazioni, ma anche ad accedere ai componenti dei servizi e alle loro funzionalità, per esempio per esplorare il contenuto delle pagine e delle

9 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 9 basi di dati ad esse collegate Aspetti di strutturazione a livelli I sistemi informativi basati su Web si strutturano sui concetti di stratificazione tipici delle architetture distribuite, ovvero su architetture a tre livelli applicativi con varie possibilità di distribuzione architetturale, con numero di livelli di architettura fisica che vanno da uno a n (in generale 5). Per risolvere i problemi di separazione fra i livelli e per facilitare sia la progettazione sia la gestione di un sistema distribuito, in generale ci si basa sulla struttura logica a tre livelli mostrata in Fig.1.2 che è l architettura logica standard per i sistemi informativi basati su Web. Tramite client semplici (thin o leggeri) o sofisticati (fat), l utente interagisce con un sistema informativo distribuito tramite il layer di presentazione. Il layer applicativo gestisce la business logic e accede al layer dei dati che raggruppa sistemi di basi di dati, file, oppure applicazioni esistenti (legacy). Il layer dati pu anche referenziare sistemi esterni di gestione dati. Si sottolinea che l architettura mostrata è relativa alle applicazioni, mentre per l architettura fisica si fa riferimento a livelli fisici detti tier. Il problema di come allocare i layer logici sui tier fisici è discusso qui di seguito e approfondito nel Capitolo 2.

10 10 CHAPTER 1. INTRODUZIONE Figure 1.2: Architettura di riferimento a tre livelli In particolare, i tre livelli applicativi sono: 1. Il livello presentazione, che si occupa di gestire la logica di presentazione, quindi le modalità di interazione con l utente: contiene le modalità di interfacciamento grafico e le modalità di rendering delle informazioni. Questo livello è anche denominato front end delle applicazioni. 2. Il livello della logica applicativa o logica di business, che si occupa delle funzioni da mettere a disposizione all utente. 3. Il livello di logica di accesso ai dati, che si occupa della gestione dell informazione, eventualmente con accesso alle basi di dati, ai sistemi esterni e ai sistemi legacy. Questi tre livelli applicativi possono essere installati su vari livelli hardware, detti Tier, dove un livello rappresenta una macchina con differente capacità di elaborazione.

11 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 11 Inizialmente, un applicazione poteva essere configurata secondo tre tipologie: Single Tiered: i tre livelli sono ospitati su una singola macchina in una classica configurazione terminale - host; Two Tiered: i tre livelli sono divisi fra una macchina utente, che ospita il livello di presentazione, e la macchina server che ospita il livello di accesso ai dati; il livello di logica applicativa può risiedere sul lato utente o server o essere distribuito fra i due; Three Tiered: i tre livelli risiedono ciascuno su una macchina dedicata, ovvero una stazione di lavoro utente (di tipo PC, in generale), un server per le applicazioni e un server per la gestione dei dati. Nel caso del Web, ci si riferisce a 5 Tier architetturali, con allocazioni dei layer logici che verranno discusse nel Capitolo 2. A seconda delle ripartizioni possibili dei livelli applicativi sui tre Tier architetturali, si parla di configurazioni fat client (se a livello utente, ovvero tipicamente browser in ambiente Web, è collocata parte della logica applicativa e quella di accesso ai dati) piuttosto che thin client (se a livello utente o browser in ambiente Web- resta relegata la sola funzione di presentazione, alleggerendo le funzionalità della stazione utente e con configurazione adatta alla distribuzione di servizi a un insieme aperto di utenti). Il livello che contiene una combinazione di accesso a basi dati distribuite in rete e di oggetti di controllo e di interoperabilità/comunicazione (middleware) è spesso denominato back end del sistema. Per contro, il livello di presentazione è comunemente denominato front end. Nel caso di studio presentato nella seconda parte di questo Capitolo tali denominazioni saranno illustrate in dettaglio. Quanto detto finora si esemplifica per esempio nel caso di un grosso Ente, il Ministero delle Finanze nell architettura mostrata in Fig.1.3, dove il lato back end si basa principalmente su uno strato operativo (il middleware) che contiene gli oggetti distribuiti che realizzano la cooperazione e l accesso a basi di dati locali e remote. In Fig.1.3, sono mostrati tre ambienti applicativi diversi: IVA, Introiti Doganali (IIDD) e Registro, che interagiscono tramite il livello di presentazione dei dati con le applicazioni di pertinenza di ciascun ambiente. L interoperabilità avviene tramite il livello di middleware che permette l accesso a tre basi di dati di competenza specifica dell ambiente (BD IVA, BD Dogane e BD Registro e Imposte). Attraverso una rete geografica proprietaria,

12 12 CHAPTER 1. INTRODUZIONE (Rete del Ministero delle Finanze), i vari uffici che fanno capo al Ministero possono accedere ai dati dei tre ambienti; altri sistemi esterni possono accedere alle applicazioni tramite la stessa rete, installando un apposito livello di middleware.

13 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 13 Figure 1.3: Tre livelli nel Ministero delle Finanze La tecnologia Web, inizialmente nata per configurazioni basate su interazioni Web browser Web server, con thin client, si è evoluta per permettere l esecuzione della logica applicativa sul browser o addirittura per accedere alle risorse locali del PC utente (livello dati sul browser per l accesso ai soli dati locali). Infine, la tecnologia di incapsulamento nel Tier 3 di sistemi legacy o comunque interni alla rete aziendale, da cui il sistema informativo estrae dati e applicazioni, permette di mettere a disposizione degli altri Tier vari servizi informativi (anche transazionali). In questo modo, si ottiene l integrazione fra approccio Web e approccio transazionale classico anche per l utenza Internet, nello stile mainframe. Tipicamente, in ambienti di sistemi informativi federati, ovvero ottenuti come aggregazione di sistemi informativi esistenti che si aggregano in rete per eseguire attività in cooperazione, ma che mantengono la propria indipendenza architetturale ed organizzativa, la distribuzione più adatta dei livelli sui Tier vede un Web browser sul Tier 1, un Web server e il middleware per

14 14 CHAPTER 1. INTRODUZIONE la gestione degli oggetti distribuiti, su Tier 2, e l incapsulamento dei sistemi legacy sul Tier 3. Per tali sistemi, l architettura di integrazione ha la struttura mostrata in Fig.1.4, dove ciascun ambiente o sistema è organizzato in tre livelli ed integrato tramite tecnologie basate su XML che costituiscono il bus di interoperabilità fra organizzazioni cooperanti.

15 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 15 Figure 1.4: Architettura di sistemi federati (tratta da Sistemi Informativi vol. 5) Finora, si sono menzionati i concetti tecnologici più rilevanti: tecnologie del Web (adatte alla diffusione di servizi); tecnologie di middleware (per organizzare oggetti distribuiti) tecnologie di incapsulamento di sistemi legacy. In generale, è possibile e consigliato l uso combinato delle tre tecnologie per realizzare sistemi informativi innovativi e per realizzare le soluzioni applicative ed architetturali più adatte alle varie situazioni aziendali. Tra l altro, tale uso combinato è reso possibile dalla presenza di standard di interoperabilità collaudati e affermati, tra cui il formato di scambio dei dati

16 16 CHAPTER 1. INTRODUZIONE XML è il più conosciuto ed usato. La strategia di realizzazione di un sistema informativo basato su Web deve essere guidata di volta in volta dalle esigenze applicative Verso le architetture basate sui servizi Le architetture dei sistemi informativi basati su Web sono oggi principalmente orientate ai servizi denominate architetture SOA (Service-Oriented Architectures), che rappresentano uno stile architetturale che promuove il riuso del software creando servizi riusabili. Le architetture orientate agli oggetti promuovono il riuso riutilizzando classi o oggetti. Tuttavia, gli oggetti spesso hanno una granularità troppo fine per permettere un riuso efficace. Pertanto, sono nate le architetture orientate ai componenti, ovvero che usano i componenti software come entità riusabili. I componenti sono insiemi di classi correlate, le loro risorse e le informazioni di configurazione. Le architetture orientate ai componenti restano uno strumento potente per progettare sistemi software; tuttavia, esse non affrontano altri aspetti che emergono dal mondo aziendale. Oggi, gli ambienti aziendali sono molto complessi a causa dell uso di software e hardware diversificato, delle comunicazioni distribuite basate su Internet, dell integrazione applicativa e informativa e così via. Le architetture orientate ai servizi sono una soluzione per questi aspetti, in quanto vedono il servizio come una entità riusabile. I servizi sono tipicamente oggetti meno granulari dei componenti e si focalizzano su alcune funzionalità precise, per esempio di presentazione dati, di estrazione di informazioni o di realizzazione di una attività aziendale (pagamento, ordine, fatturazione, magazzino) logicamente unitaria, fornita in modo standard dall interfaccia del servizio. Questi servizi comunicano tra loro e con i client degli utenti finali attraverso interfacce note e ben definite. La comunicazione spazia dal semplice passaggio di messaggi fra servizi a scenari più complessi dove un insieme di servizi si coordinano per realizzare un obiettivo comune. Queste architetture permettono ai client in rete di invocare una funzionalità, per esempio di un Web service, attraverso le interfacce pubblicate. In una SOA i componenti sono i seguenti: Un servizio, che implementa la logica di business e la espone attraverso interfacce ben definite. Un registry, dove il servizio pubblica le proprie interfacce per permettere ai client di scoprire il servizio. I client (compresi client che possono a loro volta essere servizi), che

17 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 17 scoprono il servizio usando i vari registry e accedono al servizio direttamente attraverso le interfacce esposte. Un vantaggio importante di una architettura orientata ai servizi è che essa permette lo sviluppo di applicazioni ad accoppiamento debole (looselycoupled) ovvero realizzate ciascuna su una propria piattaforma hardware e software, distribuite e fruibili attraverso meccanismi di comunicazione di rete basati su protocolli standard. Per rendere disponibile tale architettura, servono meccanismi che permettono: Ai client (compresi client che possono a loro volta essere servizi), che scoprono il servizio usando i vari registry e accedono al servizio direttamente attraverso le interfacce esposte. Ai servizi vari di registrare la propria esistenza all interno di un registry e un modo per i client di ispezionare i registry alla ricerca dei servizi disponibili. Le SOA rendono la posizione dei servizi in rete trasparente; ciò significa che i client possono scoprire dinamicamente il particolare servizio che vogliono usare. Ai servizi di esporre interfacce ben definite e ai client di accedere a tali interfacce. Nel Capitolo 6, l architettura SOA è illustrata in dettaglio, con particolare riferimento alle tecnologie dei Web service. Diversamente dagli ambienti distribuiti tradizionali, i sistemi informativi basati su Web enfatizzano l interoperabilità. Infatti, essi sono i ndipendenti da particolari ambienti di programmazione, mentre gli ambienti distribuiti tendono ad essere legati a uno specifico linguaggio. Inoltre, essi possono essere collegati a vari meccanismi di trasporto in rete, per cui diventano più flessibili. Inoltre, diversamente dagli ambienti distribuiti tradizionali, i sistemi basati su Web spesso non sono legati a particolari strutture di riferimento per i client o i server. Infine, i sistemi informativi basati su Web sono di tipo ad accoppiamento debole, realizzando relazioni dette di tipo a larga grana, ovvero con possibilità per le entità cooperanti di svolgere attività autonome e, quando necessario, di collegarsi per cooperare su attività specifiche. Utilizzando XML come formato di interscambio dei dati, essi danno un ulteriore vantaggio di interoperabilità in quanto XML rende possibile lo scambio e l uso di documenti in ambienti tecnologicamente eterogenei. La realizzazione di sistemi informativi basati su Web, partendo da standard per il Web, in genere non richiede cambiamenti sostanziali nell infrastruttura di calcolo e informativa dell azienda. Invece, uno svantaggio di

18 18 CHAPTER 1. INTRODUZIONE tali sistemi risiede, oltre che nella necessità di richiedere più firewall di protezione che in ambienti di calcolo tradizionali, nel fatto che i sistemi informativi basati su Web tendono ancora a non essere pienamente efficienti in termini di spazio e tempo di calcolo, come verrà motivato nel Capitolo 2 relativo alle architetture Motivazioni di utilizzo. Perchè una organizzazione dovrebbe considerare di realizzare un sistema informativo basato su Web? La ragione più importante che motiva l uso crescente di tali sistemi informativi è che essi promuovono l interoperabilità di piattaforme, linguaggi e sistemi diversi tramite il paradigma dei servizi e la separazione fra aspetti di presentazione e accesso, di logica applicativa e di comunicazione. Inoltre, l uso dei sistemi informativi basati su Web riduce i costi operativi, permettendo alle organizzazioni di estendere e riusare le funzionalità di sistema e le applicazioni già esistenti. Un altra motivazione è che l architettura di un sistema Web può fornire all azienda gli strumenti per espandere le proprie attività, per aumentare l efficienza dei processi aziendali e per migliorare la propria efficienza verso i clienti. Includendo nei propri servizi anche quelli offerti da partner multipli, sia l azienda sia i partner possono inoltre espandere le loro capacità e la propria base di business. Non solo i servizi possono aiutare ad automatizzare la gestione del business, ma possono rendere più snelle le interazioni con altre funzionalità, sempre realizzate come servizi, quali i pagamenti via carte di credito e i servizi di spedizione. Come risultato, ai clienti viene offerta una gamma più vasta di esperienze: più opzioni e maggiori scelte, oltre che maggiore flessibilità. Riassumendo, l utilizzo del Web nei sistemi informativi sta raccogliendo consensi perchè fornisce i seguenti principali benefici: Interoperabilità in ambienti eterogenei: possibilità di eseguire applicazioni su varie piattaforme software e hardware. Nell evoluzione delle aziende, è utile poter aggiungere nuove soluzioni applicative che riescono a comunicare fra loro tramite servizi. Servizi di Business attraverso il Web: un azienda può usare i servizi Web per sfruttare appieno i vantaggi del World Wide Web. Per esempio, può rendere disponibile a venditori e clienti i propri cataloghi prodotti attraverso un Web service per migliorare la gestione della supply chain.

19 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 19 Integrazione con sistemi esistenti: molte aziende hanno una grande quantità di dati memorizzati nei loro sistemi informativi e il costo per sostituire tali sistemi è tale che non è conveniente scartare tali sistemi legacy. I servizi Web permettono il riuso di tali sistemi. Libertà di scelta: gli standard nel campo dei servizi e del Web hanno aperto un vasto mercato di strumenti, prodotti e tecnologie. Ciò offre alle organizzazioni un ampia varietà di scelta; esse possono selezionare le configurazioni che meglio incontrano i requisiti applicativi aziendali. Inoltre, gli sviluppatori possono migliorare la loro produttività: anziché realizzare la loro soluzione personale o proprietaria, possono usufruire di componenti pronti sul mercato. Anche gli strumenti forniscono la possibilità di spostarsi rapidamente da una configurazione a un altra quando è necessario; inoltre, gli strumenti sono spesso standardizzati per cui gli sviluppatori possono usare nuovi strumenti che appaiono sul mercato, sia prodotti da vendor di server sia da sviluppatori di strumenti. Supporto a vari tipi di client: dato che il principale obiettivo dei sistemi su Web è migliorare l interoperabilità, esporre le applicazioni esistenti come servizi aumenta la possibilità di raggiungere vari tipi di client, indipendentemente dalla piattaforma del client stesso (per esempio, indifferentemente Java o Microsoft). Produttività nella programmazione: per essere produttivi nell economia dell informazione serve la possibilità di sviluppare rapidamente le soluzioni applicative, passando rapidamente dal prototipo alla produzione. La produttività migliora quando il gruppo di sviluppo può fare riferimento a standard applicativi, quali i livelli software e i Tier architetturali di cui si è parlato. È utile sottolineare che la tecnologia dei sistemi informativi basati su Web è oggi fortemente accettata da tutti i key player nell area delle tecnologie e degli strumenti di tipo Web. Questo assicura la vitalità e longevità di tale tecnologie che la loro diffusione e accettazione diventeranno sempre più estese Aspetti di progettazione e sviluppo. Lo sviluppo di sistemi informativi basati su Web ha bisogno di metodi per la raccolta e la formalizzazioni di requisiti adatti alla presenza di dati su fonti

20 20 CHAPTER 1. INTRODUZIONE informative eterogenee, di più utenti in rete e di applicazioni con notevoli requisiti a livello di interfaccia utente, di controllo della comunicazione e della sicurezza. Oggi esistono standard di modellazione per i requisiti di questo tipo, che si rifanno a visioni di impresa basati sul cogliere la logica aziendale, il modello di business e gli attori del sistema informativo in termini di una piattaforma aziendale unificata e trasversale alle varie funzioni organizzative. Per quanto riguarda le fasi di analisi, progettazione di dettaglio e implementazione, l uso di tecnologie del Web basate su metodi per il disegno di applicazioni Web si sta diffondendo ampiamente. Partendo da tecnologie di base quali HTML e CGI per arrivare alle cosiddette tecnologie abilitanti dei sistemi a moduli compilati e a script interpretati, esistono oggi soluzioni basate su sistemi di oggetti distribuiti e su XML per costruire applicazioni Web. Uno dei principali punti aperti è l integrazione dei sistemi di modellazione e programmazione tipici del Web con strumenti tipici delle basi di dati e delle applicazioni tradizionali: l architettura di integrazione con la base di dati richiede una stretta correlazione fra le applicazioni Web e la base dati a livello di semantica. Tale correlazione è utile per estrarre dati dagli archivi in modo da un lato significativo per l organizzazione, dall altro indipendente dai formati di presentazione dell informazione all interno delle applicazioni distribuite, che poi le manipolano, e a livello di presentazione che ha spesso esigenze di compatibilità di browser, esigenze di multi medialità ed esigenze di usabilità. Infine, a livello di comunicazione, i sistemi informativi basati su Web necessitano di uno strato di interoperabilità che permetta lo scambio di informazioni tra sistemi eterogenei ed indipendenti, sia a livello logico sia a livello tecnologico, in modo coordinato e collaborativo. Oggi gli strumenti di progettazione di sistemi informativi basati su Web sono principalmente strumenti basati su UML per la formalizzazione dei requisiti e l analisi, e piattaforme integrate, quali J2EE e altro per lo sviluppo di sistemi informativi basati su Web. Inoltre, tali strumenti si occupano di progettare le strutture ipermediali dei dati con l aiuto di metadati, ovvero di strutture informative usate per descrivere e identificare i vari tipi di informazioni (testi, immagini, audio, video) che compongono le pagine Web del sistema. In questo caso, i modelli vengono costruiti ed usati per indicizzare e reperire l informazione. I metadati sono usati anche per descrivere e identificare i vari profili utente del sistema informativo: i modelli vengono costruiti e utilizzati per adattare il sistema in modo che i contenuti e la presentazione delle informazioni siano adattabili alle esigenze e alle preferenza degli utenti, secondo i loro livelli di conoscenza e i loro compiti o aree di

21 1.1. I SISTEMI INFORMATIVI BASATI SU WEB 21 interesse. Alcuni ambienti integrati per lo sviluppo di sistemi informativi basati su Web hanno fatto la loro comparsa già dal 1999 (per esempio la piattaforma J2EE). Un fattore importante per il successo di piattaforme integrate per lo sviluppo e la realizzazione di sistemi informativi basati su Web è che esse sono disponibili spesso come sistemi open, che ha convinto vari produttori di software e di piattaforme di sviluppo ad adeguarsi a una serie di requisiti di impresa comuni. Le piattaforme per i sistemi informativi basati su Web si sono poi evolute per includere via via le caratteristiche che diventavano sempre più usate e salienti nell uso di tali sistemi informativi, per esempio i Web service. Tali piattaforme hanno aggiunto supporto per lo sviluppo e l esecuzione di Web service, visti come componenti e tecnologie specifici. Gli standard per i Web service assicurano l interoperabilità attraverso piattaforme e linguaggi di programmazione e la portabilità, ovvero la possibilità di far migrare le applicazioni da una piattaforma all altra. Queste nuove piattaforme incontrano i requisiti aziendali più comuni: le organizzazioni possono esporre le loro applicazioni già esistenti (legacy) come Web service e possono sviluppare e implementare nuovi Web service. Questa evoluzione delle piattaforme verso i Web service è stata ottenuta coinvolgendo aziende leader nella produzione di software. Attualmente, le piattaforme di sviluppo e di esecuzione offrono i seguenti vantaggi principali: Abilitare le applicazioni aziendali esistenti a essere estese come Web service in modo standard, facile, portabile, e interoperabile. Aiutare a estendere la ricchezza delle applicazioni sia esistenti sia nuove a un nuovo insieme di client, oltre a quelli già supportati. Abilitare l uso di tecnologie commercialmente testate, valide e robuste (come i componenti Enterprise Java Bean, le Servlets, e così via) come spina dorsale per lo sviluppo di nuovi servizi. Supportare l integrazione dei sistemi informativi aziendali esistenti in modo personalizzato per l azienda e per l utente finale, in maniera portabile. In particolare, il paradigma dei Web service si sta espandendo rapidamente grazie alle crescenti necessità di comunicazione fra applicazione e applicazione e di interoperabilità, come si vedrà nel Capitolo 6. I Web service espongono una interfaccia standard ovvero indipendente dalla piattaforma e

22 22 CHAPTER 1. INTRODUZIONE dalla tecnologia. Conformandosi a standard largamente accettati nel mondo industriale, i Web service forniscono un modo per far comunicare applicazioni software che girano su piattaforme diverse e scritte in linguaggi e ambienti di programmazione differenti; essi presentano all utente informazione dinamica e guidata dal contesto. Insieme al semantic Web, i Web services ampliano le basi e le motivazioni dell uso di sistemi informativi basati su Web. 1.2 Sicurezza La sicurezza è importante nel mondo Web così come in tutti gli ambiti delle applicazioni aziendali. Infatti, ora che le applicazioni su Web aprono il mondo delle applicazioni e dei dati aziendali a un insieme potenzialmente vasto di clienti, la sicurezza diventa un fattore davvero critico. La sicurezza dei sistemi informativi, di grande rilevanza sia per i gestori dell area ICT sia per i progettisti del sistema informatico, deve essere affrontata con giusto equilibrio. Non solo è importante proteggere il patrimonio informativo per massimizzarne il valore, ma bisogna anche evitare di proteggere oltre il necessario tale patrimonio perché si rischia di ottenere l effetto contrario, ovvero di mettere a repentaglio il valore dell informazione, che diventa di fatto blindata ed inaccessibile. In genere, i dipartimenti IT hanno mantenuto un controllo centralizzato e piuttosto alto sui loro sistemi, sia lato client sia lato server. Invece, quando il patrimonio informativo viene esposto ad ambienti meno protetti, come avviene tramite il Web, diventa importante mantenere un livello di sicurezza e controllo elevato sulle risorse più sensibili e critiche e rilasciare invece i vincoli di scurezza sulle risorse meno critiche. Una delle difficoltà della gestione di sistemi distribuiti consiste nella messa a punto di un modello di sicurezza integrato. Tale modello comprende le policies (linee guida di alto livello) e le modalità attuative delle policies stesse (meccanismi e tecnologie) e deve essere realizzabile su tutti i meccanismi e strutture organizzative che fanno parte del sistema informativo. Inoltre, la sicurezza del sistema distribuito deve essere compatibile con i meccanismi già esistenti nei nodi del sistema distribuito; nei casi in cui i clienti aziendali abbiano necessità di accedere a informazioni sicure, i meccanismi devono mantenere un alto livello di sicurezza (e di fiducia offerta all utente) pur rimanendo non ostrusivi e trasparenti. Gli aspetti chiave della sicurezza dei sistemi informativi basati su Web riguardano l autenticazione, l autorizzazione, la confidenzialità, il non ripu-

23 1.2. SICUREZZA 23 dio e la negazione di servizio distribuita. Gli standard relativi alla sicurezza dei servizi Web stanno crescendo e diffondendosi ed hanno una priorità elevata in alcune specifiche aree, per esempio nella protezione dei Server e del relativo software; in altri settori, come quello relativo ai Web service o al Web semantico, restano un aspetto tuttora in evoluzione. Il Capitolo 5 esamina gli aspetti di sicurezza illustrando problemi e soluzioni, di cui alcune di fatto standardizzate. Ai problemi di sicurezza si affiancano anche problemi di affidabilità, disponibilità e scalabilità dei servizi, riguardanti sia la piattaforma tecnologica sia glia spetti organizzativi e gestionali. Anche i Capitoli 2 e 3 affrontano alcune considerazioni su questi aspetti, in quanto l affidabilità è vista come un parametro che contribuisce a garantire la qualità dei servizi (in genere, l affidabilità si misura come numero di errori che avvengono in un certo periodo di tempo). Nei Web service, l affidabilità è più difficile da ottenere, causa la natura intrinsecamente inaffidabile del livello di trasporto sottostante, ovvero HTTP; HTTP fornisce solo un servizio di consegna best-effort e non garantisce la consegna di pacchetti o di sequenze ordinate di dal punto di vista applicativo. Un Web service è considerato tanto più affidabile quanto più semplice e automatico è il cambio di strutture di uso (pattern) e di configurazione. La disponibilità riguarda il fatto che i servizi siano immediatamente presenti e pronti per l uso quando necessario. In genere la disponibilità è misurata in termini della probabilità che un servizio sia disponibile. Infine, la scalabilità ha a che vedere con la possibilità da parte del sistema di gestire molte interazioni con i client contemporaneamente, ovvero con la possibilità di adeguare la piattaforma tecnologica alle condizioni di traffico e di carico, gestendo efficientemente le risorse di sistema e i servizi, quali la connessione alla base di dati e le transazioni. Per esempio, la piattaforma deve essere in grado di effettuare il parsing di codice XML per convalidare il contenuto dei documenti e il parsing di codice XML è un operazione compute-intensive che può degradare le prestazioni del sistema in quanto aumentano le dimensioni del carico (payload) dei messaggi. Per ottenere affidabilità, disponibilità e scalabilità, i servizi di un sistema informativo basato su Web devono essere così flessibili da poter girare su qualsiasi configurazione di server che sia appropriata ad anticipare i volumi di traffico attesi dai client e devono poter cambiare rapidamente configurazione. Per tali scopi, è utile disporre di una piattaforma di supporto per il deployment di gruppi (o cluster) di applicazioni, come si illustrerà nei Capitoli 2 e 3. Tale piattaforma è utile quando si possono gestire i cambiamenti applicativi o tecnologici, senza richiedere ai vari ambienti di riprogettare, ricodificare o rieseguire il deployment delle applicazioni.

24 24 CHAPTER 1. INTRODUZIONE 1.3 Classificazione dei sistemi informativi basati su Web I sistemi informativi basati su Web possono essere classificati in base alla tipologia del servizio offerto, in base all insieme di utenti che possono accedere al sistema (interni, esterni o di altra natura) o secondo le operazioni che gli utenti possono compiere (semplice accesso informativo unidirezionale, oppure modifica dello stato di un applicazione Web). I servizi elettronici disponibili in rete sono stati classificati dall Unione Europea (UE) all interno del proprio Libro Verde come: Servizi di informazione: servizi il cui obiettivo è quello di fornire acceso ad informazioni strutturate e classificate. Il sistema è costituito da pagine statiche o dinamiche, se le informazioni sono ottenute tramite interrogazioni a basi di dati o se vengono implementati meccanismi di personalizzazione (basati su cookie o che richiedono la registrazione degli utenti) per la presentazione delle informazioni. Il sistema può presentare inoltre link ad altre risorse informative, e comunque l utente non inserisce contenuto informativo nel sistema. Servizi di comunicazione: servizi che favoriscono e supportano la comunicazione di gruppi di utenti. I servizi di comunicazione sono stati implementati attraverso vari tipi di applicazioni come , chat oppure tramite applicazioni Web che supportano liste di discussione (newsgroup), e di richiesta di informazioni (si pensi ad esempio ai newsgroup di Linux). Nei sistemi che implementano questa tipologia di servizio, l utente è identificato (a seconda dell applicazione può fornire tuttavia una identità reale o fittizia) e le comunicazioni dell utente possono rimanere memorizzate nel sistema informativo. Servizi transazionali: supportano gli utenti per l acquisto di beni o servizi. L utente, che viene solitamente identificato dal sistema, modifica i dati e lo stato dell applicazione Web, interagendo con DBMS (eventualmente distribuiti) e servizi applicativi. La principale criticità di questa tipologia di servizi è costituita dalle problematiche di sicurezza e riservatezza dei dati trasmessi e memorizzati. Un altra dimensione che è stata considerata all interno del Libro Verde UE è il livello di interazione offerto agli utenti. I livelli di interazione previsti sono i seguenti:

25 1.3. CLASSIFICAZIONE DEI SISTEMI INFORMATIVI BASATI SU WEB25 Livello 1: sono disponibili on line solo le informazioni necessarie per avviare la procedura che porta all erogazione del servizio. L utente trova informazioni sull organizzazione, sulle attività svolte ed i contatti per richiedere ulteriori informazioni via , telefono o posta. Livello 2: è possibile scaricare e stampare on line i moduli necessari ad avviare la procedura che porta all erogazione del servizio. Non è possibile però inviare on line il modulo compilato; l utente è quindi obbligato a recarsi fisicamente presso gli uffici dell organizzazione, o ad usare un vecchio canale di comunicazione (ad esempio fax o posta) per la consegna della richiesta. Livello 3: prevede l interazione in due sensi (per esempio, la possibilità di avviare on line la procedura, con compilazione di moduli elettronici ed autenticazione utente). Ciò rappresenta una prima forma di fruizione remota del servizio, che svincola l utente dai vecchi canali di comunicazione per la consegna della richiesta. Livello 4: prevede l esecuzione on-line di un intera procedura (per esempio, nel caso di una transazione di commercio elettronico, tutte le fasi che vanno dall ordine della merce, al pagamento elettronico, alla consegna). Questo livello è caratterizzato dall assenza di moduli cartacei per erogare il servizio e non necessita di spostamenti fisici da parte dell utente, che può gestire l intera procedura dal terminale d accesso.

26 26 CHAPTER 1. INTRODUZIONE Utenti Compiti Larghezza di banda Compatibilità Quantità informazioni Sito Internet Sito Intranet Sito Extranet Noti con Dipendenti Dipendenti di approssimazione dell organizzazione più organizzazioni Servizi informativi o di vendita Supporto al lavoro dei dipendenti, gestione dei processi Bassa Alta, affidabile Alta, affidabile Integrazione dei processi delle organizzazioni Diversi browser, obiettivo massima accessibilità del sito Poche e in tempi rapidissimi Scelta a priori del browser Quantità elevate, per la gestione dei processi operativi Scelta a priori della tecnologia della propria organizzazione, conoscenza tecnologia adottata dai partner Quantità e- levate, integrazione della supply chain Table 1.1: Confronto fra sistemi Internet ed Intranet

27 1.3. CLASSIFICAZIONE DEI SISTEMI INFORMATIVI BASATI SU WEB27 Figure 1.5: Protezione della Intranet aziendale attraverso firewall Un ulteriore classificazione fornita per i servizi in rete si basa sulle modalità di accesso ai siti secondo le seguenti tre tipologie: Sito Internet: è accessibile da tutta la rete, gli utenti sono disparati e non noti a priori. Su questi siti l obiettivo principale è l accessibilità, garantire cioè la possibilità di accedere al sistema all insieme più ampio possibile di utenti. Dal punto di vista progettuale, questo costituisce lo scenario più vincolante per le scelte tecnologiche attuabili lato client. Dovendo permettere l accesso a browser diversi che vengono eseguiti potenzialmente su piattaforme diverse, dovranno essere adottate solo tecnologie standard (come verrà discusso nel paragrafo 2.4, ciò porta alla scelta di architetture thin client) ed assumere l esistenza di una connessione a banda stretta verso l utente finale. Sito Intranet: l accesso è limitato dall interno dell organizzazione. A questo livello si gestisce la conoscenza aziendale, ovvero è racchiusa la

28 28 CHAPTER 1. INTRODUZIONE gestione delle conoscenze sui processi aziendali. Una Intranet ha come principale obiettivo distribuire informazioni all interno dell azienda mediante news, interfacce di ricerca, e cataloghi di contenuti su cui è possibile effettuare il browsing. I servizi di una Intranet permettono la collaborazione fra reparti e la partecipazione degli utenti a processi decisionali. A questo livello, si ha un forte controllo sulla configurazione della piattaforma hardware della rete e dei client del sistema e possono essere adottate architetture client thin o fat a seconda dell applicazione. Sito Extranet: è accessibile da un gruppo di utenti ben identificato, ad esempio clienti e fornitori. È lo strumento di scambio di informazioni concordate tra soggetti diversi tramite accesso ad archivi (ad esempio per rendere visibili i livelli delle scorte in magazzino) e di accesso a funzionalità predefinite che consentono l integrazione della supply chain di organizzazioni diverse. Per esempio in sistemi di e-commerce, a fronte di un nuovo ordine di un cliente viene pianificata la consegna della merce tramite accesso al sistema informativo di un corriere. In questo tipologia di ambienti, è fondamentale la standardizzazione del sistema informatico in modo da poter integrare facilmente il proprio sistema informativo con il sistema informativo di clienti e fornitori (ed eventualmente rendere semplice il passaggio a nuovi fornitori). Dato il loro alto livello di standardizzazione, questo è uno scenario applicativo in cui l adozione dei Web Service risulta molto promettente. Intranet ed Extranet si basano sulla stessa tecnologia di Internet, adottano cioè principalmente i protocolli TCP/IP per la comunicazione ed HTTP per l accesso alle applicazioni. La connessione della Intranet aziendale (che a tutti gli effetti è una rete privata) verso Internet avviene attraverso un router e l accesso al sistema è protetto attraverso un firewall (si faccia riferimento alla Figura 1.5). Il firewall è un dispositivo di sicurezza del sistema informativo che (come verrà discusso nel Capitolo 2), filtra tutti i pacchetti in ingresso e in uscita dal sistema e stabilisce se un determinato pacchetto è autorizzato ad essere trasmesso alla sua destinazione oppure no, sulla base di opportune policy di sicurezza, cercando di bloccare i tentativi di intrusione e le richieste non autorizzate. Una Extranet può essere considerata come una estensione dell Intranet aziendale che consente l accesso a utenti esterni all organizzazione. In sistemi Extranet, oppure per applicazioni Web che implementano un livello di interazione elevato (dal livello 3 della classificazione UE), esistono problemi di sicurezza e privatezza delle informazioni; ciò impone l introduzione

29 1.4. UN CASO DI STUDIO 29 di meccanismi di certificazione e autenticazione degli utenti e di crittografia per la trasmissione dei dati che saranno oggetto del Capitolo 4. Infine, altre classificazioni proposte per i sistemi informativi basati su Web si basano sugli obiettivi e sulle tipologie di utenti a cui è rivolta un applicazione Web. Si parla di applicazioni B2B (Business to Business) se l applicazione è rivolta principalmente alla cooperazione di imprese (si ricade pertanto nel caso delle Extranet) mentre si parla di applicazioni B2C (Business to Consumer) per applicazioni (tipicamente di commercio elettronico) rivolte al singolo cliente. Nel caso in cui gli enti che erogano il servizio siano Pubbliche Amministrazioni, si hanno le varianti G2G (Government to Government) o G2C (Government to Citizen). 1.4 Un Caso di Studio Scopo di questa parte del Capitolo è illustrare un esempio di sistema informativo basato su Web che sarà utilizzato come base per gli esempi d di tutto il volume. Si tratta di un sistema informativo in ambito Pubblica Amministrazione. Il caso permette di illustrare sia gli aspetti tecnologici sia gli aspetti strategici ed organizzativi legati all impiego di un sistema basato su Web. Infatti i sistemi informativi basati su Web, quando progettati ed usati correttamente e strategicamente, possono aumentare la disponibilità o la raggiungibilità e fruibilità dei servizi applicativi, anche se, come si è detto e come verrà motivato dettagliatamente nel Capitolo 2, l impiego delle tecnologie tipiche del Web può in generale abbassare le prestazioni delle applicazioni e renderne più complessi il progetto, la realizzazione e la gestione. Il sistema informativo descritto in questa sezione è il Portale Istruzione, Formazione e Lavoro della Regione Lombardia. Esso opera a livello del Mercato del Lavoro del territorio lombardo ed è stato realizzato tramite un progetto specifico svoltosi fra il 2001 e il Il Portale è operativito dal Gennaio 2004 e si inquadra nelle linee guida del Piano italiano di E- Government, che prevede Portali a livello regionale integrati nel Sistema Informativo Lavoro nazionale. Il Portale Istruzione, Formazione e Lavoro della Regione Lombardia (Fig. 1.6 è stato realizzato come sistema informativo basato su Web in quanto sono presenti i seguenti requisiti: Interoperabilità fra applicazioni eterogenee. Integrazione, per ambienti che contengono vari sistemi informativi, secondo la logica degli Enterprise Information Systems (EIS) o Sistemi

30 30 CHAPTER 1. INTRODUZIONE Figure 1.6: Accesso al Mercato del Lavoro

31 1.4. UN CASO DI STUDIO 31 Informativi d Impresa. Integrazione tra fonti di dati eterogenee che devono rimanere autonome ma accessibili e consultabili in modo uniforme. Diversi tipi di client da supportare, quali semplici browser o client leggeri, applicazioni J2EE, fino ad arrivare a dispositivi wireless, PDA, e così via. Livello di complessità, prestazioni e costi tale da motivare la complessità dello sviluppo e della gestione di un sistema basato su Web, per ottenere i vantaggi legati all interoperabilità, al supporto a client diversi e accesso a dati differenziati. Gli strumenti messi a disposizione dal sistema regionale devono risultare accessibili in modo uniforme da vari attori e da vari punti geografici, mantenendo l autonomia dei siti partecipanti. Le applicazioni, realizzate prevalementemente con tecnologie del Web, permettono l interazione fra enti della Pubblica Amministrazione e tra questi enti e i privati per lo scambio di pratiche e di informazioni varie riguardanti le offerte e le richieste di lavoro oltre a indicatori sulle tendenze del mercato del lavoro e a informazioni su pecorsi professionali ed educativi di riqualificazione (Fig Lo scenario applicativo presentato ha tutti i requisiti che sono stati elencati sopra i quali sono in generale validi per molti dei sistemi informativi della Pubblica Amministrazione. Infatti, le Pubbliche Amministrazioni sono organizzazioni con struttura distribuita federata, formata da nodi diversi, eterogenei e indipendenti che svolgono attività interne (di tipo amministrativo) e in cooperazione fra loro, per esempio per fornire servizi a cittadini, imprese ed altri enti. Il caso di studio illustrato entra nel dettaglio del nodo regionale 1. Successivamente si illustra la partecipazione di tale nodo alla rete nazionale del Sistema Informativo per il Lavoro, i cui nodi si conformano alla struttura del nodo lombardo Architettura di riferimento del Portale Istruzione, Formazione e Lavoro della Regione Lombardia Il Portale Istruzione, Formazione e Lavoro della Regione Lombardia è l elemento di comunicazione sul territorio lombardo per i vari punti che si occupano di mercato del lavoro, quali le Province, i Centri per l Impiego, le Aziende/Agenzie 1 Sistema Borsa Lavoro Lombardia, sito

32 32 CHAPTER 1. INTRODUZIONE private di ricerca e selezione di personale, e gli Enti nazionali, quali l INAIL, l INPS e il Ministero del Lavoro. Tali enti sono i nodi del sistema. La Fig.1.7 mostra la pagina Web di accesso del sistema del Portale Regionale, in particolare la pagina della Fiera dei Lavori. Sono evidenziate le tre aree Istruzione, Formazione e Lavoro. Le aree risultano accessibili separatamente, ma raccordate, per permettere la navigazione interallacciata fra le tre tematiche di competenza dell Assessorato al Lavoro (istruzione, formazione e lavoro). L obiettivo è che l utente possa navigare nell area Lavoro per cercare le offerte disponibili e, nella stessa sessione, collegarsi all area Formazione oppure riceverne direttamente proposte di corsi o stage per una sua riqualificazione rispetto alle tendenze del mercato del lavoro. In tal modo, si realizza la strategia progettuale che mira a realizzare un Portale che sia strumento attivo di prevenzione alla disoccupazione, grazie alla disponibilità di dati aggiornati e attendibili rispetto all andamento del Mercato del Lavoro.

33 1.4. UN CASO DI STUDIO 33 Figure 1.7: Home page della Fiera dei Lavori - L elemento innovativo del Portale Regionale è la Fiera dei Lavori, ovvero l insieme dei servizi a valore aggiunto disponibili nel Portale. Tali servizi creano un punto di incontro attivo fra domanda di lavoro da parte dei cittadini e offerte di lavoro da parte delle imprese. Nel seguito si indicheranno come domanda la disponibilità dell utente Cittadino e offerta la proposta di lavoro dell utente Impresa. La realizzazione di una Fiera dei Lavori è fra gli obiettivi primari strategici del Portale in quanto è strumento di prevenzione della disoccupazione. I servizi a valore aggiunto per il lavoro si affiancano ai servizi detti di base, che sono stati comunque ristrutturati e migliorati durante il progetto del Portale. Tali servizi, principalmente di tipo amministrativo per i cittadini, le imprese e gli enti, permettono la gestione delle pratiche amministrative legate per esempio al cambiamento di stato occupazionale dei cittadini. Esse automatizzano le procedure burocratiche legate alle Comunicazioni obbligatorie delle Imprese (assunzione, licenziamento, cambio lavoro, posizione

34 34 CHAPTER 1. INTRODUZIONE INPS e INAIL e altro), che devono circolare fra Enti in formato elettronico. I servizi a valore aggiunto che costituiscono la Fiera dei Lavori riguardano la gestione delle domande di lavoro, in termini di Curriculum Vitae in formato standard Europeo (da parte dei cittadini), e delle offerte di lavoro (da parte delle imprese) sia sulla base di dati situata nel Portale Regionale sia nelle basi dati distribuite nei Centri Provinciali per l Impiego. I servizi riguardano inoltre l incontro fra domande e offerte, tramite un motore di ricerca mirato ad accoppiare al meglio le domande e le offerte che provengono al Portale da parte dei due attori cittadini e imprese, oppure dai loro intermediari pubblici (Centri per l Impiego) o privati (Agenzie di Ricerca e Selezione di Personale, Società di Lavoro Temporaneo e così via). Il motore di ricerca inoltre può personalizzare il servizio di ricerca di lavoro in base ad esigenze specifiche dei cittadini e delle imprese, utilizzando criteri di vicinanza territoriale del lavoro, ricerche mirate a specifiche fasce di utenza (disoccupati di lungo periodo, giovani, neolaureati, ecc.), di selezione di occupazioni simili, e in genere sulla base di filtri di ricerca definibili dagli utenti. Nel caso in cui il motore di ricerca non riesca a realizzare l incontro domanda offerta, oppure nel caso di disponibiltà non soddifatte da più di un certo periodo (in genere sei mesi), il Portale può consigliare al cittadino percorsi formativi e di riqualificazione. Per svolgere questo ruolo attivo, sia nella ricerca sia nel suggerimento di percorsi formativi, il Portale è costituito da funzionalità avanzate di discovery, di reportistica e di accesso a fonti statistiche, con funzionalità di tipo data mining e data warehouse. La componente di interoperabilità del Portale che permette l accesso alle basi di dati dei vari enti collegati al Portale (Centri per l Impiego, Operatori Privati) è realizzata mediante la tecnologia dei Web service (si veda Capitolo 6) che risultando flessibile e poco invasiva per i nodi della federazione, permette agli attori del sistema Portale di mettere in comune dati e applicazioni. Infatti, i Web service pemettono di realizzare funzioni invocabili da remoto e non necessitano di cambiare sostanzialmente la struttura delle applicazioni già installate, ma richiedono che esse si interfaccino al sistema di interoperabilità in termini di servizi, ovvero esponendo le operazioni che ne permettono l invocazione in rete da siti remoti. Uno schema delle funzionalità del Portale Regionale della Lombardia è riportata in Fig.1.8. I cittadini e le imprese accedono al Portale per motivi di consultazione (accesso alla Vetrina dell Assessorato al Lavoro), oppure per caricare nella base dati di Portale rispettivamente una domanda o un offerta di lavoro. Il Portale presenta un interfaccia Web per il caricamento dei dati e per la navigazione nel sistema. Tale interfaccia corrisponde al livello

35 1.4. UN CASO DI STUDIO 35 Presentazione illustrato precedentemente in termini di architetture a tre livelli (layer). Essa permette il caricamento dati via Web e la consultazione di un ampia banca dati relativa a domande e offerte di lavoro. Il Motore di Ricerca realizza l incontro fra domanda e offerta operando sia sulle domande e le offerte caricate direttamente nella base dati del Portale regionale sia sulle domande e le offerte caricate e memorizzate nei domini collegati (Province, Operatori Privati convenzionati o accreditati, dominio nazionale a livello del Ministero del Lavoro). I dati vengono utilizzati dalle procedure di matching del motore di ricerca, ma restano di proprietà e fisicamente memorizzati nella base dati detta di pertinenza, ovvero legata al dominio dove il cittadino o l impresa hanno caricato la domanda e l offerta rispettivamente. Un Indice centralizzato nel Portale regionale permette di identificare la base di dati dove risiede il dato Master del cittadino (o dell impresa) mantenendo allineate copie multiple dei dati tramite riferimento alla copia Master. Infatti, secondo le norme italiane in materia di servizi all impiego, un cittadino o un impresa possono recarsi in vari punto di accoglienza sul territorio e presentare una domanda/offerta più volte, con variazioni del contentuo. È il sistema a gestire le copie del dato tramite l indice regionale, sia per gestire la coerenza dei dati sia per registrare il fatto che è presente una sola domanda/offerta associata a una persona/impresa, anche se i dati caricati sono multipli. Questo permette anche di non alterare le statistiche occupazionali. Infine la Fig. 1.8 mostra la componente Fruizione delle Basi di Dati Informative, che è realizzata tramite la componente di l interoperabilità verso i domini locali, ovvero con le applicazioni e i dati locali distribuiti nei nodi provinciali e nazionali della rete.

36 36 CHAPTER 1. INTRODUZIONE Figure 1.8: Schema delle funzionalità della Fiera dei Lavori Nel seguito, viene descritto il modello dei servizi del Portale Regionale nella componente Fiera dei Lavori; successivamente è descritta in dettaglio l architettura del Portale, mostrandone i servizi di interoperabilità, di cooperazione applicativa e di accesso ai dati in un tipico ambiente sistema informativo basato su Web. Infine, si mostra l architettura del sistema a rete nazionale, le cui componenti sono i nodi regionali, provinciali e nazionali, ciascuno con architettura funzionalmente analoga a quella del nodo della Regione Lombardia Modello dei servizi Il Portale è lo strumento per realizzare l integrazione fra strutture operanti sul territorio nelle seguenti tre aree tematiche: Istruzione: servizi relativi al mondo dell educazione (scuole, politiche di supporto economico, informazioni sul mondo della scuola e delle

37 1.4. UN CASO DI STUDIO 37 La competenza dell Area Lavoro può essere suddivisa in cinque sottoaree: università). Formazione: per la promozione di corsi di formazione professionale a diversi livelli. Esempi di servizi che la Fiera dei Lavori offre in queste due aree sono: servizi per i giovani che hanno compiuto il percorso scolastico, per favorire il loro ingresso nel mercato del lavoro; indicazioni per il sistema della formazione, derivanti dalle attività di monitoraggio del mercato del lavoro; servizi di programmazione di interventi formativi, con il fine di qualificare e motivare fasce di disoccupati di lunga durata. Lavoro: per la pubblicazione di domande e offerte di lavoro, il loro incrocio, e per la diffusione di strumenti informativi in grado di supportare l incontro effettivo tra domanda e offerta di lavoro in ambito regionale. Esempi di servizi offerti in questa area sono l oggetto della presentazione di questa sezione. Area Servizi Amministrativi. Mette in comunicazione le diverse realtà amministrative (enti provinciali, previdenziali e altro) legate al mondo del lavoro in ambito provinciale e regionale. Area Fiera dei Lavori. Rappresenta il momento centrale della iniziativa, dove vengono erogati i servizi finalizzati a realizzare l incontro tra domanda e offerta di lavoro. Esempi di servizi sono il supporto alla redazione di un Curriculum Vitae (CV) da parte del lavoratore e dell offerta di lavoro da parte dell impresa, la ricerca guidata on-line di occasioni di lavoro/profili richiesti, il feed-back per l utente delle occasioni di lavoro/domande corrispondenti al profilo/offerta inserito/a e la gestione personalizzata dell interazione con il sistema (per esempio, Web, telefono, cellulare, fax, ). Area Formazione e Orientamento. Arricchisce l offerta informativa rivolta ai lavoratori permettendo loro di eseguire la ricerca guidata on-line di occasioni formative e il feed-back delle occasioni formative corrispondenti al profilo inserito. Questa area rappresenta il momento di integrazione fra Area Lavoro e le due aree tematiche Orientamento e Formazione.

38 38 CHAPTER 1. INTRODUZIONE Area Banche Dati. Si tratta di servizi di riferimento per il reperimento di informazioni nelle tematiche connesse al mondo del lavoro e della formazione. Area Servizi Informativi. Si tratta di servizi di tipo magazine on line, community e campus lavoro, oltre a servizi di , news, newsgroup, rivolti a tutti gli attori (cittadini, imprese, enti locali e nazionali) interessati a informazioni sul mercato del lavoro, sull orientamento e sulle occasioni formative. Mentre per i servizi amministrativi, si richiede di inserire una infrastruttura di comunicazione in un ambiente operativo già definito (quello delle Province e dei Centri per l Impiego Provinciali), le componenti relative alla Fiera dei Lavori presentano aspetti pià complessi quali ad esempio gli aspetti di integrazione dati, formati comuni di scambio dati, interazione con gli utenti e comunicazione fra sistema di ricerca lavoro e sistema di supporto decisionale costituito dalle basi dati informative. Inoltre, aspetto importante è che la Fiera dei Lavori si rivolge anche al mercato dei Privati, accreditati e/o abilitati, quali le Società di Ricerca e Selezione o le Società di Lavoro Temporaneo. Il vantaggio di questi attori nell adesione ai servizi del Portale consiste nella possibilità di accedere ad una banca dati della domanda e offerta vasta ed aggiornata, oltre che opportunamente condivisa. Da tale banca dati essi possono sia attingere sia pubblicare informazioni. A loro volta, i Privati devono mettere a disposizione parte del contenuto delle loro banche dati, anche se a discrezione della singola Società, previa autorizzazione del soggetto rappresentato e comunque in forma anonima, per mantenere il loro ruolo di intermediari per conto delle Imprese. Infatti, il Portale consente la navigazione nelle banche dati dei diversi operatori privati per scegliere, nel panorama delle opportunità offerte, quale risultato meglio risponde alle esigenze degli utenti Cittadini e Imprese. Tale condivisione di dati deve avvenire nel pieno rispetto dei vincoli dettati dalla Legge sulla Privacy e salvaguardando il business privato, che si concretizza nella manutenzione di ulteriori dati sul cliente, oltre a quelli resi pubblici sul Portale, e negli usuali servizi di colloquio e preselezione. Flussi informativi Il modello di servizio del Portale può essere definito partendo dalle interazioni con i Cittadini (o persone in cerca di occupazione), con le Imprese e

39 1.4. UN CASO DI STUDIO 39 con il mondo dei Privati, allo scopo di realizzare l incontro tra domanda e offerta. Si schematizzano alcune situazioni che il Portale affronta, fornendo la specifica dei principali flussi informativi con riferimento all architettura presentata e la specifica dei principali flussi informativi in termini di evento che attiva la richiesta di un servizio, di problemi che vanno risolti nell erogazione del servizio e di soluzioni per realizzare efficacemente il servizio. Nella descrizione, al termine domanda di lavoro del cittadino viene spesso sostituito il termine Curriculum Vitae (CV). Le soluzioni sono distinte in soluzioni lato front-end del Portale, inteso come accesso via Web (o altri canali) da parte degli utenti, e lato back-end del Portale, inteso come accesso automatico, tramite sistema di interoperabilità, agli applicativi e alle basi dati degli enti collegati al Portale. L aspetto front-end e back-end sarà poi chiarito tecnicamente nei paragrafi successivi dedicati all architettura del Portale. Sintetizzando, il front-end di un sistema distribuito costituisce l interfaccia utente, quella parte di software cioè che ha il compito di generare le pagine con le quali l utente interagisce e di gestire le elaborazioni locali, come la creazione di reports. È importante sottolineare come in questo caso tutti gli accessi ai dati della Fiera dei Lavori, le ricerche, gli inserimenti di nuove informazioni e la consultazione di quelle già registrate, avvengano per mezzo dei servizi di front-end, anche per tutti quegli utenti che condividono dati con il portale e pertanto sono collegati con esso anche attraverso il suo back-end. Il back-end è costituito dai servizi che si occupano di fornire al Portale i dati provenienti da tutte le fonti collegate ad esso e di gestire la connessione e l accesso; si occupa infatti di fornire le informazioni e parte della logica applicativa. Un primo flusso informativo riguarda la comunicazione fra Lavoratore e Portale, schematizzabile come segue. Evento: il lavoratore pubblica il proprio CV sul Portale. Problemi: la pubblicazione deve essere anonima e contenere sufficienti informazioni per permettere al motore di matching, componente specializzata del motore di ricerca, del Portale di trovare risultati soddisfacenti. Sarà discrezione del lavoratore rendere pubblico il proprio nominativo (per esempio, solo dopo aver conosciuto l attore interessato al suo profilo lavorativo). Soluzioni front-end: il Portale supporta un formato standard del dato CV e ne permette la compilazione guidata on-line basandosi su un vocabolario interno di professioni e competenze. Soluzioni back-end: La struttura del CV deve scindere le in-

40 40 CHAPTER 1. INTRODUZIONE formazioni anagrafiche da quelle riguardanti le competenze professionali. I dati professionali legati al CV devono poter essere acceduti da Enti esterni mentre i dati rimanenti sono disponibili solo su autorizzazione del proprietario secondo la legge sulla Privacy. Altro flusso riguarda la comunicazione fra Impresa e Portale. Tale flusso schematizzabile come segue. Evento: l impresa pubblica un offerta di lavoro sul Portale. Problemi: la pubblicazione deve essere anonima e contenere sufficienti informazioni per permettere alle procedure di Portale di ricerca di incontro Domanda-Offerta di trovare risultati soddisfacenti. Soluzioni front-end: il Portale supporta un formato standard del dato Offerta di Lavoro e ne permette la compilazione guidata on-line basandosi su un vocabolario interno di professioni e competenze. Soluzioni back-end: La struttura del CV deve essere in grado di scindere le informazioni anagrafiche da quelle contenenti le competenze professionali. I dati professionali legati al CV devono poter essere acceduti da enti esterni mentre i dati rimanenti sono accessibili solo su autorizzazione del proprietario secondo la legge sulla Privacy. Un terzo esempio riguarda il flusso informativo fra Privati (per esempio, società di Ricerca e Selezione) e Portale, schematizzabile come segue. Evento: il Privato accede al Portale per esaminare i CV che corrispondano a certi criteri oppure pubblica sul Portale i CV prelevandoli dalla propria banca dati, mantenendo in locale dati riservati e di propria competenza. Problemi: il privato si interfaccia al Portale via Web; il Portale fornisce servizi di interrogazione e browsing guidati e basati su criteri selettivi significativi (per esempio, catalogazioni per fasce di età, competenze, o aree geografiche). Soluzioni front-end: il Portale dispone di un motore di ricerca ottimizzato per confrontare le strutture dati del CV e dell Offerta. Soluzioni back-end: Le informazioni accessibili sono solo quelle

41 1.4. UN CASO DI STUDIO 41 professionali; per le informazioni anagrafiche è necessaria l autorizzazione del proprietario. Il motore di ricerca applica criteri flessibili di selezione (basati su affinità e su algoritmi di ranking e feedback utente) per l ottimizzazione delle ricerche. Il motore adegua le proprie funzionalità di ricerca lentamente nel tempo, osservando l andamento degli accessi. Impresa Tutte le operazioni sono svolte previa registrazione al Portale. Questo permette sia il controllo degli accessi sia la profilazione utente per il miglioramento dell usabilità del sito e l adattamento delle funzionalità di matching. In Fig.1.9 sono schematizzate le funzionalità del Portale rivolte all impresa. Figure 1.9: Servizi per l attore Impresa Gestione offerte: L impresa deve poter inserire, modificare e cancellare

42 42 CHAPTER 1. INTRODUZIONE un offerta di lavoro strutturata in tre sezioni: Sezione anagrafica: rappresenta la parte privata dell offerta e contiene i dati anagrafici dell impresa che la sottopone. Questi dati possono essere utilizzati per la ricerca, ma possono essere pubblicati solo su esplicito consenso del proprietario dei dati stessi; Sezione professionale: comprende dati di tipo pubblico e utili per effettuare la ricerca per l incontro tra domanda ed offerta. Al suo interno si trovano informazioni quali: numero di persone richieste, profilo professionale, età, luogo di lavoro; Sezione storica: a fini statistici, il sistema tiene traccia, per ogni offerta, delle modifiche e degli accessi effettuati. Status offerte: Nel caso un offerta venga accettata da un lavoratore, l impresa deve poter ottenere dal Portale i dati identificativi del lavoratore in questione per contattarlo (eventualmente tramite l Ente Privato che lo rappresenta). L offerta viene monitorata in modo da permettere all impresa che l ha pubblicata di conoscere il numero di volte in cui l offerta è stata proposta, per poter essere rapportata con il numero di lavoratori effettivamente interessati. Matching profili affini: Il sistema esegue gli algoritmi di matching tra CV e offerte, producendo off-line le risposte precise relative all incrocio domanda/offerta e, in caso di mancato matching, le alternative di lavoro considerate idonee perchè è e gli eventuali percorsi formativi suggeriti al lavoratore per riqualificarsi in funzione dell andamento delle offerte aziendali monitorate su un certo intervallo temporale. Ricerca libera: Oltre a ricerche basate sulle offerte di lavoro inserite, una impresa deve poter effettuare ricerche su tutte le banche dati, sia del Portale sia collegate al Portale stesso (per esempio, quelle delle Province). La ricerca può svolgersi precisando vincoli su uno o più dei campi riportati qui sotto.

43 1.4. UN CASO DI STUDIO 43 Per i profili professionali Tipo di professione Specializzazioni Area geografica Età Titolo di studio Per le Offerte di lavoro Tipo di professione Area geografica Per le Occasioni formative Tipologia di formazione Ambito di lavoro Prerequisiti Lavoratore Tutte le operazioni possono essere svolte previa registrazione al Portale. Anche in questo caso, la registrazione permette sia il controllo degli accessi sia la profilazione utente. In Fig.1.10 vengono mostrate le funzionalità rivolte all attore Lavoratore. Gestione CV : Il lavoratore inserisce, modifica e cancella il proprio CV che permette di definire il profilo professionale. Un CV è suddiviso nelle tre componenti: Sezione anagrafica: rappresenta la parte privata del CV e contiene i dati anagrafici del lavoratore. Questi dati possono essere pubblicati solo su esplicito consenso del proprietario dei dati stessi, ma possono essere utilizzati nell ambito di ricerche statistiche (per esempio, per fasce d età o per zona geografica), come previsto dalla normativa sulla Privacy, in particolare per le basi di dati di tipo statistico. Sezione professionale: contiene dati di tipo pubblico e utili per effettuare la ricerca per l incontro tra domanda ed offerta. Comprende informazioni quali il profilo professionale, il titolo di studio, la qualifica, e altro. Sezione storica: per scopi statistici, di ogni CV va tenuta traccia delle modifiche e degli accessi effettuati. Allo scopo di mettere in

44 44 CHAPTER 1. INTRODUZIONE Figure 1.10: Servizi per l attore Lavoratore

45 1.4. UN CASO DI STUDIO 45 condizione gli Enti Privati di trarre vantaggio dei servizi di Portale, all interno della sezione professionale di un CV devono essere inseriti, se necessario, i dati relativi all Ente che li rappresenta. Status CV : Nel caso un impresa, o l Ente Privato che la rappresenta, fosse interessata al CV pubblicato, deve essere possibile ottenere dal Portale i dati identificativi del lavoratore; ovviamente, la notifica della sezione privata di un CV può avvenire solo su consenso del proprietario dei dati. Per agevolare questa operazione, la richiesta di permesso alla pubblicazione deve avvenire previo invio al lavoratore di un quadro informativo che descrive l impresa interessata alla sua figura professionale, o l Ente Privato che rappresenta l impresa. L offerta è monitorata in modo da permettere al lavoratore che l ha pubblicata di conoscere il numero di volte in cui il profilo è stato proposto. Questo permette un confronto con il numero di imprese effettivamente interessate e consente alle procedure di reportistica di produrre dati statistici sull andamento del mercato del lavoro. Matching profili affini: Oltre a ricerche basate sulle offerte di lavoro inserite, un lavoratore può effettuare ricerche libere, utilizzando un apposito vocabolario per uniformare la terminologia e agevolare la ricerca. Tale vocabolario è uno degli aspetti di principale rilevanza fra le specifiche del Portale perché ne influenza notevolmente le caratteristiche di efficacia e di usabilità. Le ricerche possono essere svolte su tutte le banche dati collegate al Portale, tramite il lato back-end dell architettura. La ricerca può svolgersi precisando vincoli su uno o più campi, come si è descritto per l attore Impresa. Il collegamento tra le funzionalità di matching tra CV e offerte formative è ritenuto un altro servizio attivimo del Portale. Il collegamento viene realizzato partendo da un valore di Soglia: se non esiste un matching perfetto e le domande/offerte si trovano sotto un certo livello di soddisfazione (espresso dal valore di soglia fissato dagli amministratori del sistema), il Portale: suggerisce le soluzioni vicine ovvero simili a quelle desiderate; indica percorsi formativi che risultano opportuni per la riqualifica del lavoratore, a seconda delle competenze mancanti; riporta all amministratore di Portale i risultati e suggerisce eventuali variazioni dei valori di Soglia.

46 46 CHAPTER 1. INTRODUZIONE Lo schema della base dati di Portale comprende apposite relazioni di collegamento fra area Lavoro e area Formazione che si traducono in opportuni link a livello Web. Lo stesso schema basato su Soglia collega il Portale: ad enti formativi accreditati (per esempio Università, Centri di Formazione che si registrano al Portale); ad altri Portali di regioni che vorranno consorziarsi in entità interregionali (è in fase di studio un accordo fra Regione Lombardia, Regione Piemonte e Regione Veneto per l interoperabilità fra i rispettivi Portali); ai sistemi di enti della Pubblica Amministrazione Locale e Centrale (quali UnionCamere e Ministero del Lavoro). Centri per l Impiego Provinciali, Enti privati I Centri per l Impiego Provinciali (C.I.P.) e gli Enti accreditati e/o abilitati hanno a disposizione funzioni analoghe a quelle viste per i Lavoratori e le Imprese, con alcune varianti, come viene ora illustrato. Incrocio CV/offerte. Il Portale permette al C.I.P. o all Ente di effettuare il matching tra gruppi di CV, per ottenere le offerte che soddisfano le domande di lavoro. A differenza dei servizi messia disposizione del Lavoratore e delle Imprese, in questo caso l utente ha la possibilità di eseguire ricerche multiple in blocco. Incrocio offerte/cv. Il Portale permette al C.I.P. o all Ente di effettuare il matching tra un gruppo di offerte per ottenere i CV che si avvicinano alle offerte di lavoro. Incrocio CV/formazione Il Portale deve permettere al C.I.P. o all Ente di ottenere da un gruppo di CV presentati l elenco delle occasioni formative per ogni richiesta di lavoro. A differenza delle funzionalità messe a disposizione del Lavoratore e delle Imprese, in questo caso l utente ha la possibilità di fare ricerche multiple in blocco. Vediamo ora come si modifica il flusso informativo del servizio di preselezione eseguito dai Privati in seguito all introduzione della Fiera dei Lavori. Il primo elemento innovativo rispetto all analisi precedente è l introduzione del ruolo attivo del lavoratore nel processo di selezione dell impiego. Non

47 1.4. UN CASO DI STUDIO 47 pi dunque esclusivo compito dell impresa la ricerca di un candidato per la propria offerta, ma anche il singolo privato può richiedere informazioni circa le possibilità di impiego. I due flussi di inserimento dei dati, quello dei curricula e quello delle offerte, procedono in modo parallelo ed in seguito compito dell algoritmo di incontro domanda - offerta valutare quali di essi siano compatibili e di segnalarli agli interessati. I passi successivi ricalcano quelli visti in precedenza, ma con la sostanziale differenza che una prima parte della fase di contatto pu avvenire per mezzo del Portale in modo da permettere una prima selezione dei candidati da ambo le parti. Infine è interessante come tutte le attività amministrative che seguono l assunzione di un nuovo dipendente possano ora essere svolte con la mediazione della Fiera dei lavori e che le procedure di feedback e profilazione utente vengano svolte automaticamente dal sistema in base alle scelte di ciascun attore Architettura dettagliata del Portale Le funzionalità elencate nella sezione precedente costituiscono il modello dei servizi del Portale. Dettagliando l architettura di massima del sistema mostrata in Fig.1.8, si mostrano i moduli in Fig.1.11, dove si evidenziano le funzioni dei vari sottosistemi. Front-End. Costituisce l interfaccia visiva del Portale definita in termini di pagine Web fruibili da un qualunque utente registrato. I servizi realizzati nel front-end sono servizi di content-management e servizi di Community destinati a gestire i contenuti del sito Web e le varie comunità di attori che afferiscono al Portale, con relative news e magazine on-line. Alcune aree standard gestite a livello di content-management sono l Area di informazioni generali, l Area normativa, e l Area Servizi Comunità. Inoltre, vi è la possibilità di immissione di aree ad accesso pubblico e privato per rendere più efficace il livello di comunicazione con la molteplicità dei fruitori del Portale. Le aziende, le scuole, gli atenei, piuttosto che gli organismi di mediazione (per esempio, Enti non profit o Associazioni sindacali) possono fruire, attraverso la registrazione per categoria di appartenenza, di newsletter tematiche facilitanti l aggiornamento degli studi nei settori di interesse come pure l aggiornamento di alcune procedure formali che interessano esclusivamente una determinata categoria di utenti. Sottosistema di memorizzazione. Vi fanno riferimento le basi dati contenenti le informazioni necessarie all incontro tra domanda e offerta, le applicazioni di gestione dei dati inseriti e l Indice Anagrafico. I servizi

48 48 CHAPTER 1. INTRODUZIONE Figure 1.11: Architettura dettagliata del Portale

49 1.4. UN CASO DI STUDIO 49 sono realizzati dai moduli del Motore di Ricerca, in grado di gestire contenuti sia a livello globale sia a livello di macro-area individuata. In quest ultimo caso, il motore visualizza velocemente le ricorrenze di qualunque argomento, mantenendosi sul livello e nell area di interesse cui si giunti tramite la navigazione. Il motore garantisce la rapida e selettiva possibilit di navigare in qualunque zona del sistema, secondo le comuni regole ipertestuali. Pagine adeguate e specifiche, realizzate con uno stile grafico chiaro, permettoni di usufruire di altre modalità di navigazione tra i contenuti. Tra queste: una mappa chiara, pulita e ben strutturata di tutto il sistema che, con un semplice clic, permetta di raggiungere direttamente la pagina e i link desiderati; una ricerca temporale, in cui siano segnalati gli aggiornamenti e le novità; una possibilità di ricerca gerarchica per argomenti; un indice alfabetico generale e completo per tutti i contenuti del sistema; l accessibilità piena al glossario, per la soluzione immediata di dubbi di significato. Infatti, una fruizione ottimale dei contenuti è conseguita attraverso un complesso meccanismo redazionale di classificazione dei medesimi: tale meccanismo si rivela vantaggioso nell offerta di servizi di individuazione e di informazione per gli utenti. Il meccanismo di classificazione utilizzato permette un facile ed immediato accesso ai contenuti, una configurabilità (definizione delle categorie) semplificata ed estensibile (aggiunta di nuove categorie). Lo strumento di classificazione permette la classificazione dei contenuti in base a una tassonomia di contenuti secondo due modalità: Automatica e Manuale. Nella classificazione automatica, la base è un sistema di classificazione automatica dei contenuti centrato intorno a un thesaurus di termini. L amministratore deve poter istruire il sistema in modo che successivamente possa classificare sulla tassonomia i contenuti gestiti dal sistema. Con la classificazione manuale, l amministratore cataloga manualmente i contenuti, associandoli ad uno o più contenitori della tassonomia. In Fig sono mostrati i passi di ricerca semplice e per blocchi di dati. Prima di poter essere analizzati, i dati inseriti dagli utenti del

50 50 CHAPTER 1. INTRODUZIONE Portale devono essere adeguatamente preparati ed adattati alle esigenze del motore di ricerca. Questo primo passo permette di estrarre da ciascun documento le informazioni principali e caratteristiche in modo da classificarlo correttamente all interno della struttura della base di dati. Esso costituisce la base del processo di ricerca e può influenzarne l efficacia. Dunque, i dati indicati come generici sono formattati secondo il processo di classificazione/catalogazione e confluiscono nella base dati di Portale, insieme ai dati che invece arrivano in formato standardizzato (formattati). A partire dalle informazioni contenute nelle basi dati informative riguardanti l andamento del mercato del lavoro, il sistema estrae informazioni di tipo statistico utili per la valutazione dei dati di Portale e costruisce opportune strutture matriciali di appoggio. La ricerca dei dati può anche avvenire a seguito di specifiche query utente. Sarà poi il Motore di Matching ad effettuare l incontro domanda/offerta e a produrre risultati ordinati secondo un ranking. Il processo di feedback ha il compito di adattare l algoritmo di ricerca in base alle esigenze di un utente o di gruppi di essi in modo da facilitare il reperimento dei dati tenendo traccia delle operazioni svolte in precedenza e traendo da esse informazioni utili al miglioramento delle prestazioni e della rilevanza delle informazioni reperite. I meccanismi di ricerca illustrati devono apparire trasparenti all utente finale che deve poter fruire di tutte le funzionalità senza conoscere le applicazioni che ne permettono la realizzazione. Il motore di ricerca deve dunque presentare i servizi esposti in precedenza per ogni tipo di utente. Si distinguono Servizi di ricerca classica e Servizi di ricerca avanzata. I primi prevedono la ricerca libera all interno della base di dati del Portale attraverso la specifica di termini in base ai quali condurla oppure un approccio guidato al servizio che prevede la compilazione di alcuni parametri fondamentali in base ai quali selezionare le risorse desiderate, specificando ad esempio quale sia la professione interessata o la zona in cui si cerca occupazione. I Servizi di ricerca avanzata permettono all utente di richiede al motore di ricerca l analisi dei propri dati e l individuazione delle offerte che possono risultare compatibili con essi. Viene effettuato un matching in base ai campi fondamentali quali la professione specificata, le competenze, i titoli di studio e le zone lavorative e viene fornita una valutazione dei risultati in base alla corrispondenza di tutti i campi. Vengono inoltre suggerite altre possibilità che si renderebbero disponibili nel caso venissero in-

51 1.4. UN CASO DI STUDIO 51 trapresi determinativi percorsi formativi o scolastici. L interfaccia con il Sistema Informativo Regionale Direzionale e di Controllo Gestione è schematizzato come un modulo che alimenta il Data Warehouse regionale. La funzionalità offerta dal Portale consiste nel visitare le basi di dati dei C.I.P. e delle Province per alimentare il Data Warehouse con dati statistici e di sintesi, su iniziativa di un Web Service in esecuzione a livello di Portale per conto del Data Warehouse. L interfaccia con il Sistema Informativo della Banche Dati consiste in funzionalità di alimentazione e reporting tramite Web Service di Portale, utilizzando i dati della base dati di Portale e l Indice Anagrafico. Viceversa, le Banche Dati sono collegate al Portale tramite link per fornire accesso alle occasioni formative e accesso agli Indici professionali. Figure 1.12: Il Processo di ricerca dati nel Portale Sottosistema di interoperabilità e Back-end. Gestisce la comunicazione

52 52 CHAPTER 1. INTRODUZIONE tra il Portale e tutti gli operatori del Mercato del Lavoro collegati ad esso sia per quanto riguarda l area amministrativa, sia per lo scambio e l aggiornamento dei dati nella Fiera dei Lavori. Operando attraverso questo sottosistema è possibile accedere alle informazioni esterne al Portale senza doverne replicare la fonte, in modo da poter garantire un servizio più ampio e dettagliato senza appropriarsi in modo indebito dei dati appartenenti ad altri enti, ma limitandosi a condividere le risorse che essi decidono di rendere pubbliche. La tecnologia utilizzata per la realizzazione di questo componente è quella dei Web Service, che assicura una soluzione poco invasiva per gli operatori coinvolti e permette di stabilire una comunicazione efficace nonostante la forte eterogeneit delle piattaforme utilizzate dagli attori in questione. La descrizione delle interfacce dei servizi segue le specifiche standard per i Web Service (Web Service Description Language - WSDL) ed la loro memorizzazione interessa un registry privato, secondo le specifiche di esposizione dei servizi disponibili, utilizzando lo standard Universal Description, Discovery and Integration - UDDI. Per ricercare CV e offerte di lavoro presenti nella base dati del Portale e negli archivi dei principali attori operatori del mercato del Lavoro quali i C.I.P. e gli Enti accreditati e/o abilitati, il sottosistema di interoperabilità mette a disposizione le funzionalità di back-end sia lato Portale che lato Operatore. Tali funzionalità creano una infrastruttura di scambio informazioni tra i vari archivi per la realizzazione sia delle funzionalità sia in area Amministrativa sia in area Fiera dei Lavori. Questo modo di operare lascia la competenza delle informazioni all entità che le possiede senza quindi ricorrere ad pericolose replicazioni di dati. Per le operazioni di tipo Amministrativo, i C.I.P. hanno a disposizione alcune interfacce di funzioni studiate in modo da rendere possibile la modifica autonoma del software gestionale in possesso dei C.I.P.. Tra le funzionalità di back-end legate all area Amministrativa vi sono: l ottenimento dello status del lavoratore; l interrogazione dell archivio dati da un C.I.P.all altro; l allineamento dati. Per arricchire il ruolo del Portale, in particolare nei servizi rivolti ad attori privati quali gli Enti accreditati e/o abilitati, vengono messe a disposizione alcune delle funzionalità di front-end anche sul lato back-

53 1.4. UN CASO DI STUDIO 53 end. Questo permette di creare una serie di servizi direttamente integrabili con i sistemi in possesso degli Operatori di Mercato. Tra le funzionalità di questo tipo si distinguono: matching CV/offerte di lavoro: dato un blocco di CV sono fornite le offerte di lavoro adatte ad ognuno di essi; matching CV/offerte formative: dato un blocco di CV sono fornite le offerte formative rivolte ad ognuno di essi; matching offerte di lavoro/cv: dato un blocco di offerte di lavoro sono forniti i CV adatti ad ognuna di esse. Indipendentemente dall area funzionale, sono a disposizione tutti i servizi necessari alla gestione dell Indice Anagrafico dei Lavoratori così da permettere agli utenti del Portale di ottenere tutte le informazioni relative ad un lavoratore indipendentemente dal C.I.P.al quale egli è iscritto. Indici Anagrafici La possibilità da parte di un Lavoratore di iscriversi ad un qualunque C.I.P. sul territorio nazionale porta a possibili duplicazioni e inconsistenza delle informazioni. Per eliminare questi problemi, il Portale prevede l Indice Anagrafico dei Lavoratori che permette di riconoscere e gestire eventuali duplicazioni all interno dell intera infrastruttura. L indice, che ha valenza nel Dominio regionale, permette di: mettere a conoscenza di tutti i C.I.P. della posizione di un qualunque lavoratore iscritto presso qualunque altro Centro della Regione; propagare le modifiche riguardo allo stato di disoccupazione di un lavoratore su tutti i sistemi provinciali della Regione presso cui è iscritto. Nella cooperazione con altri Portali Regionali, è prevista la possibilità di far riferimento, per l individuazione di un lavoratore, all Indice Anagrafico Nazionale dei cittadini (in fase di realizzazione con circa 9 milioni di record).

54 54 CHAPTER 1. INTRODUZIONE Nel Back-end lato Operatore, gli operatori del Mercato del Lavoro mettono a disposizione informazioni che permettono una ricerca efficiente sia dei dati relativi alla domanda e offerta di lavoro sia dei dati di tipo amministrativo. Questo scambio di informazioni avviene a seguito dell invocazione di una funzione messa a disposizione dagli operatori stessi. Pertanto sono definite le interfacce WSDL dei servizi che gli Operatori del Mercato del Lavoro devono implementare. Il Portale fa riferimento a queste funzioni per accedere alle informazioni contenute nelle banche dati non di propria competenza. Tra le funzionalità rivolte a tutti gli Operatori del Mercato si hanno: ricerca CV: questa funzionalità viene invocata dal motore di matching domanda e offerta del Portale per la ricerca di CV con particolari caratteristiche; ricerca offerta: questa funzionalità viene invocata dal motore di matching domanda e offerta del Portale per la ricerca di offerte con particolari caratteristiche. Sottosistema di sicurezza e profilazione. Posto trasversalmente agli altri sottosistemi, questo modulo mette a disposizione un adeguata infrastruttura per l autenticazione e il tracciamento di un qualunque utente collegato al Portale. Sistemi Esterni. Il Portale è inoltre fonte di informazione sia per il Data Warehouse regionale direzionale e di controllo gestione sia per le Basi Dati Informative che contengono statistiche sul mercato del Lavoro. Tali sistemi appartengono alla categoria dei Sistemi Esterni e/o Legacy nell architettura a tre livelli vista per i sistemi Web; quindi, essi sono collegati al Portale tramite il livello Accesso ai Dati. In particolare, fra i Sistemi Esterni si trova il Sistema Informativo Statistico delle basi dati informative, abbreviato qui in SISTAT, che raccoglie tutti i dati esistenti nel sistema, li rende omogenei nel formato, nella nomenclatura e nelle classificazioni, in modo che siano accessibili per l intero processo di servizio di incontro tra domanda e offerta. Si tratta di un sistema informativo in grado di fornire un quadro conoscitivo di elevata qualità a supporto dei servizi di orientamento per percorsi formativi e lavorativi. Il flusso delle informazioni tra il Sistema Informativo regionale e SIS- TAT è bidirezionale, in modo da permettere il continuo aggiornamento

55 1.4. UN CASO DI STUDIO 55 dei dati in base alle tendenze espresse dal mercato dell occupazione, quali la nascita di nuove figure lavorative o di nuovi percorsi formativi. All interno di SISTAT vi sono quattro basi di dati. Sistema integrato di classificazione del lavoro, delle professioni e della formazione. Fornisce una classificazione dei lavori e delle professioni, applicabile trasversalmente a ciascuna delle basi di dati informative e utilizzabile anche per le attività amministrative. Tale classificazione è coerente con le disposizioni internazionali e con le principali nomenclature utilizzate nell ambito delle statistiche ufficiali (ISCO98, Excelsior, ISTAT) ed interfacciabile con un vocabolario che interpreti e riporti all interno della base di dati il linguaggio utilizzato dai lavoratori e dalle imprese. Banca dati delle professioni. Questa base dati presenta e descrive i profili professionali presenti nel territorio regionale, organizzati in raggruppamenti omogenei, tenendo anche conto della classificazione precedente. L intero sistema è realizzato in modo da poter associare ad ogni professione un grado di prossimità ad altre mansioni, un percorso formativo caratteristico e i titoli di studio necessari. Guida ragionata alle opportunità formative. Questa base dati integra le fonti già esistenti a livello regionale al fine di realizzare una guida di tutte le opportunità di formazione scolastica e professionale che possa integrarsi con le altre basi di dati in modo da suggerire le professioni collegate a ciascun percorso. Indicatori sul mercato del lavoro e sulla formazione. Questa base dati mette a disposizione un quadro di riferimento sulla struttura del mercato economico e del mercato del lavoro, sottolineando i flussi che li caratterizzano. Inoltre, il SISTAT utilizza e alimenta il Data Warehouse regionale. La grande mole di informazioni fornita dai vari utenti e processata dal sistema deve essere classificata e riorganizzata per poterne estrarre nuove indicazioni e suggerimenti. Tale compito viene svolto dal Data Warehouse, che per mezzo di tecniche di Data Mining, individua nella massa incoerente dei dati le linee di sviluppo del mercato del lavoro e le caratteristiche nascoste ad una prima osservazione superficiale.

56 56 CHAPTER 1. INTRODUZIONE Altre Considerazioni Il sistema Portale Regionale Istruzione, Formazione e Lavoro della Regione Lombardia è gestibile mediante strumenti di amministrazione che limitano al massimo l utilizzo di tecniche di programmazione. Risulta personalizzato per classi di utenza abilitate ad accedere in quanto qualificati come autorizzati alla fruizione dei vari servizi di tipo regionale e permette la modifica dinamica della navigazione senza interrompere il servizio. Il Portale comprende anche funzioni che facilitano la fruibilità del sistema durante l edizione dei contenuti: un sistema di basi di dati, interrogabile da parte degli autori di contenuto, permette di avvalersi dell intero archivio di quanto già pubblicato o, comunque, di soddisfare richieste di ricerca di materiale multimediale presente e già immagazzinato dal sistema. Il sistema di content management si appoggia ad un core tecnologico in grado di adottare tecnologie XML/XSL per la rappresentazione dei contenuti. Come repository dei contenuti è garantita la compatibilità con database relazionali e XML. Inoltre il sistema garantisce alta scalabilità e portabilità e può essere integrato con i principali Application Server di mercato. Il sistema consente l inserimento di porzioni di portali esterni tenendo presente le condizioni di usabilità (medesimo look&feel e metafora di interazione) e di filtraggio del contenuto in base alle regole di personalizzazione (ruolo, profilo). Il sistema si basa sulle strutture di interoperabilità a livello di rete regionale messe a disposizione da Lombardia Integrata. Infine, poiché il sistema tratta dati personali, ai sensi della Legge 675/96, il sistema soddisfa le misure di sicurezza minime previste dal DPR 318 del 28/7/1999 per sistemi che trattano dati di questo tipo. Per le finalità che il Portale si propone, il sistema gestisce la profilazione degli utenti i quali hanno modo di trasmettere e ricevere i dati di loro interesse in maniera strettamente privata. Per questi scopi, sono implementati meccanismi di autenticazione basati su metodologia di tipo SSO (Single Sign-On), ovvero a password unificata per l accesso a tutti i siti cui l utente ha autorizzazione. Le informazioni accessibili da parte di un utente sono limitate a quelle di propria pertinenza grazie a una profilazione utenza che comprende modalità di accesso in grado di mantenere facilità di accesso, sicurezza delle transazioni di autenticazione e gestione unica delle autenticazioni che mantenga la coerenza in tutte le

57 1.5. IL SISTEMA INFORMATIVO FEDERATO NAZIONALE 57 aree e per tutte le tipologie di utenti. In particolare il repository delle utenze viene gestito da un Directory Server che, interrogato dai vari Server applicativi, verifica l accessibilità alle singole utenze. Questo, oltre a rendere più efficiente il sistema di gestione a livello di amministrazione delle utenze, rende affidabile nel tempo l integrazione tra le singole macchine e alleggerisce le problematiche dell autenticazione e della sicurezza. 1.5 Il sistema informativo federato nazionale Il Sistema Nazionale per il Lavoro (SIL) si configura come una federazione di nodi del tipo Portale Regionale della Lombardia, illustrato nella sezione precedente. Come mostrato in Fig.1.13, il SIL è una federazione di nodi a livello di Province, Regioni, Enti Nazionali (quali INPS e INAIL e Ministero del Welfare), che operano in logica di cooperazione applicativa per supportare le politiche occupazionali. Esso fornisce sia servizi amministrativi sia servizi a valore aggiunto, quali l incontro fra domanda e offerta di lavoro o la gestione di informazioni statistiche nelle basi di dati informative del sistema. Il Sistema Nazionale permette a cittadini, imprese, agenzie private operanti nell area dell impiego e agli Enti nazionali di cooperare su aspetti relativi alla ricerca di lavoro e su temi occupazionale, in maniera interoperabile e uniforme, mediante interfacce basate su Web, basi di dati condivise, strumenti informativi e di analisi statistica (data warehouse e basi dati informative). A livello provinciale, il livello foglia della rete dei servizi, il modello di Servizio per il Lavoro ha comportato la revisione delle strutture architetturali dei Sistemi Informativi dei Centri per l impiego Provinciali mediante inserimento di server provinciali e di hardware per i call center, mediante la realizzazione di applicativi e basi di dati per l interoperabilità e lo scambio di dati su lavoratori e imprese e mediante piattaforme per la formazione a distanza (e-learning). Di tale livello si è occupato il progetto di E-Government SINTESI, che ha realizzato la cooperazione applicativa all interno del singolo Ente Provincia, verso le altre province del progetto (Province Lombarde e Pugliesi aggregate tramite i nodi Regione Lombardia e Regione Puglia rispettivamente) e verso enti pubblici e privati (Enti di Formazione e orientamento, Università, Ministero, Società Private di ricerca e se-

58 58 CHAPTER 1. INTRODUZIONE Figure 1.13: Architettura gerarchica dei nodi provinciali, regionali, nazionale nel sistema informativo a rete per i Servizi all Impiego

59 1.5. IL SISTEMA INFORMATIVO FEDERATO NAZIONALE 59 lezione). La ristrutturazione ha adeguato gli applicativi agli standard di programmazione e di comunicazione di tipo XML, HTTP, SOAP, e agli ambienti per il Web, per la realizzazione di motori di ricerca e per la messa in sicurezza degli ambienti applicativi. A livello nazionale, i servizi sono stati realizzati nel progetto Borsa Continua Nazionale del Lavoro (BCNL) a cura del Ministero Del Welfare. La presenza nel progetto di INAIL, INPS ed UNIONCAMERE è funzionale all obiettivo della interoperabilità delle basi dati sia ai fini della applicazione di quanto previsto dal Decreto Legislativo 181/00 in merito ai flussi unitari di comunicazione dalle imprese verso i servizi per l impiego sia per quanto riguarda l unitarietà del sistema informativo anagrafico delle imprese. L architettura del Portale di ogni Provincia/Regione è identica all architettura del Portale Regionale che costituisce il modello architetturale di riferimento nazionale Interoperabilità: la Ricerca distribuita Una caratteristica del motore di ricerca a livello del SIL è la possibilità di interagire con le basi di dati di tutti gli enti coinvolti all interno della rete dei servizi. Questo realizza un livello di interoperabilità fra enti aderenti alle iniziative dei Portali nazionali, nel senso che costituisce un esempio di servizio distribuito in rete. In particolare, il motore di ricerca sfrutta le risorse informative e applicative in rete per espandere il proprio campo di azione e migliorare la qualità del servizio offerto. Esso accede, consulta ed esplora tutte le fonti disponibili per la ricerca di informazioni adatte alle esigenze utente. Non essendo possibile per evidenti motivi di congruenza fra le basi di dati e di privatezza delle informazioni replicare ogni singola fonte, il motore stesso è distribuito presso tutte le fonti permettendo così ad alleggerire il carico di lavoro del sistema centrale e diminuire il numero di dati trasportati attraverso la rete, con vantaggi sia dal punto di vista della velocità della comunicazione sia dal punto di vista della sicurezza. La Figura 1.14esemplifica la struttura del servizio di ricerca distribuito. Il processo di ricerca si compone di alcune fasi centralizzate gestite dal sistema e di alcune fasi distribuite operanti sugli enti esterni. Quando l utente sottopone la ricerca, il motore centrale formatta la query in

60 60 CHAPTER 1. INTRODUZIONE base ai parametri specifici dell utente, occupandosi poi di invocare un Web Service su ognuno dei sistemi remoti trasmettendo il testo della ricerca ed avviando la medesima ricerca sulle basi di dati locali. La porzione remota del motore esegue la ricerca sulla base di dati del proprio sistema, ne riceve i risultati e li invia di nuovo al richiedente in formato standard XML. Una volta ricevute le risposte desiderate è ancora il motore centrale che si occupa di fondere le informazioni, di valutarle e di visualizzarle, osservando il comportamento dell utente e registrandone le preferenze in modo da poter aggiornare il suo profilo. L intero meccanismo è esemplificato in Fig1.14. Figure 1.14: Il Processo di ricerca dati nei nodi della rete nazionale La soluzione adottata permette anche a ciascun ente di decidere autonomamente quali e quante informazioni rendere visibili ed agevola anche il processo di trasmissione dei dati grazie all adozione dello standard XML. L uso dei Web Services permette inoltre la comunicazione con qualunque sistema e definisce uno standard per l erogazione di

61 1.5. IL SISTEMA INFORMATIVO FEDERATO NAZIONALE 61 servizi remoti in seguito facilmente espandibile e soprattutto facilmente implementabile Aspetti realizzativi Il sistema nazionale incorpora le principali caratteristiche del Portale Regionale della Lombardia. Esso comprende anche un applicativo a livello nazionale che consente di gestire e controllare le informazioni statistiche alla base del processo di incontro domanda-offerta e un interfaccia utente che permette di valutare l efficacia dei meccanismi realizzati. Tale interfaccia consiste in una serie di pagine Web con le quali l utente può gestire i propri dati e utilizzare i servizi offerti dal Portale. Gli strumenti amministrativi implementati sono utilizzati per gestire i meccanismi di classificazione e il thesaurus: il primo serve a effettuare una catalogazione automatica per mezzo del classificatore di Bayes dei dati che l utente inserisce in linguaggio naturale in modo da permettere agli algoritmi di ricerca di sfruttare informazioni strutturate, facendo in modo che là dove invece essa non lo sia la si adatti attraverso questo strumento. Il secondo si occupa dell aggiornamento e della manutenzione del thesaurus. 2 Per permettere la ricerca uniforme fra basi dati eterogenee e distribuite, il motore di ricerca utilizza il thesarus, ovvero un vocabolario comune delle mansioni e delle professioni. E stato realizzato un vocabolario di termini da utilizzare nel mercato del lavoro, che unifica la terminologia utilizzata dai CIP, dalle regioni e dai principali attori privati coinvolti. Tale vocabolario si basa anche su termini di classificazione standard italiane ed europee (ISCO98, Excelsior, ISTAT). I sistemi di autenticazione e sicurezza sono basati su firma elettronica e sistemi di identificazione elettronica (carta d identità elettronica, firma digitale, smart card) con integrazione verso i sistemi di Carta Nazionale e Carta Regionale dei Servizi. Si prevede l utilizzo di piattaforme multicanale per il contatto con il cittadino e l impresa, senza escludere vie di contatto tradizionali (call 2 Le scelte implementative nella realizzazione del prototipo si basano su Java; la realizzazione delle pagine Web dinamiche si basa su tecnologia JSP e Servlet. Per l interoperabilità, sono stati utilizzati i Web Service (in particolare WebSphere); le basi dati sono DB2 e Sql Server.

62 62 CHAPTER 1. INTRODUZIONE center, dove previsto), tuttavia integrando le modalità di tipo servizio di Portale tramite l accesso diversificato a basi dati condivise. L utilizzo di Indici Regionali condivisi nella rete nazionale serve per l identificazione delle posizioni dei lavoratori nelle basi dati federate nel sistema nazionale. Il collegamento ad altri sistemi nazionali realizza il raccordo fra Enti per esempio per l inoltro delle comunicazioni obbligatorie delle Imprese con INPS e INAIL, tramite i Portali Regionali. L architettura standard adottata per ogni nodo è riassunta in Fig.1.15, dove è evidenziato il concetto di Dominio, utile per circoscrivere gli ambiti organizzativi e tecnici di competenza delle province, delle regioni, del nodo nazionale e degli operatori privati. Figure 1.15: Schema di riferimento per il singolo dominio La struttura (tracciato record) degli indici per identificare univocamente un cittadino nel sistema informativo a rete è mostrata in Fig.1.16.

63 1.5. IL SISTEMA INFORMATIVO FEDERATO NAZIONALE 63 In particolare, è mostrato il campo most recent che serve ad identificare la localizzazione dei dati anagrafici più aggiornati relativi a una certa persona.

64 64 CHAPTER 1. INTRODUZIONE Figure 1.16: Struttura degli indici 1.6 Osservazioni conclusive In questo capitolo si sono illustrati i principi fondamentali dei sistemi informativi basati su Web descrivendo gli aspetti logici dei sistemi informativi e della loro progettazione, gli aspetti architetturali e tecnologici e descrivendo un caso applicativo di Sistema Informativo in rete nell ambito della Pubblica Amminsitrazione.

65 2. Architetture dei Sistemi Informativi basati su Web In questo capitolo vengono presentati i componenti hardware e software che costituiscono l architettura dei moderni sistemi informativi basati su Web. I sistemi Web negli ultimi 10 anni si sono evoluti da sistemi puramente informativi ad applicazioni complesse che supportano funzionalità mission critical per le aziende. Affidabilità, tolleranza ai guasti e sicurezza sono pertanto requisiti fondamentali per le architetture dei sistemi attuali. Nel presente capitolo verrà fornita una panoramica dei componenti, dei servizi e delle tecnologie che costituiscono l architettura di un sistema informativo basato su Web. Il paragrafo 2.1 presenta brevemente l evoluzione storica delle architetture informatiche; il paragrafo 2.2 introduce alcune classificazioni che sono state proposte per i sistemi informativi basati su Web. Il paragrafo 2.3 descrive quali sono i componenti hardware e software adottati e discute vantaggi e svantaggi delle possibili soluzioni architetturali. Il paragrafo 2.4 infine si focalizza sul problema di progettazione architetturale del Web client. 2.1 Evoluzione delle Architetture Informatiche Nell ambito dei Sistemi Informativi, il termine architettura indica l insieme delle scelte tecniche e organizzative che influiscono sullo sviluppo e sull utilizzo delle risorse tecnologiche di tipo ICT. Come discusso nel Capitolo 1, i sistemi informativi attuali si basano sui sistemi informatici che ne costituiscono la componente automatizzata. Le 3

66 architetture dei sistemi informatici si sono sviluppate ed evolute nel corso degli anni passando da schemi centralizzati a modelli distribuiti, maggiormente rispondenti alle necessità di decentralizzazione e di cooperazione delle moderne organizzazioni. In particolare, si parla di sistema informatico centralizzato (o semplicemente sistema centralizzato)quando i dati e le applicazioni risiedono in un unico nodo elaborativo (Figura 2.1). Terminali utente Archivi centralizzati Applicazioni Fig 2.1: Sistema informatico centralizzato Viceversa, si parla di sistema informatico distribuito (sistema distribuito) quando almeno una delle seguenti due condizioni è verificata (Figura 2.2): le applicazioni, fra loro cooperanti, risiedono su più nodi elaborativi (elaborazione distribuita); il patrimonio informativo, unitario, è ospitato su più nodi elaborativi (base di dati distribuita). In termini generali, quindi, un sistema distribuito è costituito da un insieme di applicazioni logicamente indipendenti che collaborano per il perseguimento d obiettivi comuni attraverso un infrastruttura di comunicazione hardware e software. I sistemi centralizzati sono nati con l informatica moderna negli anni 50 e si sono sviluppati negli anni 60 e 70 grazie all evoluzione dei mainframe, all introduzione dei sistemi operativi time-sharing, ed allo sviluppo dei sistemi di gestione di basi di dati centralizzati di tipo gerarchico e reticolare. La nascita e lo sviluppo, negli anni 70 e 80, di nuove tecnologie più economiche, sia nell hardware sia nelle strutture di gestione dati versatili e facili da usare (mini e micro elaboratori, personal computer, reti locali di comunicazione, 4

67 Terminali utente Terminali utente Archivi locali Rete Archivi locali Applicazioni Applicazioni Archivi locali Applicazioni Fig 2.2: Sistema informatico distribuito architetture client/server, interfacce utente di tipo grafico, modelli evoluti per la strutturazione dei dati) ha portato alla crisi del modello centralizzato e ha promosso la realizzazione di sistemi distribuiti. Ciò nonostante, nei primi anni 90 il modello distribuito è stato sottoposto a forte critica per le maggiori complessità progettuali e di gestione. L architettura di un sistema distribuito può essere, in termini generali, molto complessa. È possibile però, come si è illustrato in breve nel Capitolo 1, riconoscere tre livelli logici di distribuzione, in letteratura spesso indicati come layer, che trovano corrispondenza in altrettanti strati software nei quali vengono partizionate le applicazioni: Il livello presentazione si occupa di gestire la logica di presentazione, quindi le modalità di interazione con l utente: contiene le modalitàdiinterfacciamento (grafico) e di rendering delle informazioni. Questo livello è anche denominato front end delle applicazioni. Il livello della logica applicativa o logica di business si occupa delle funzioni da mettere a disposizione all utente. Infine il livello di logica di accesso ai dati si occupa della gestione dell informazione, eventualmente con accesso ai database o a sistemi legacy (con sistema legacy si intende un sistema ereditato dal passato sviluppato con tecnologie di vecchia generazione, ad esempio un applicazione COBOL, che tuttavia è ancora molto importante per l organizzazione). I livelli due e tre costituiscono il back-end dell applicazione. Nei sistemi 5

68 distribuiti, i livelli logici software sono installati su livelli hardware (detti tier), dove un livello rappresenta in generale una macchina, di diversa capacità elaborativa. Da questo secondo punto di vista, un applicazione può essere configurata con: un livello di distribuzione (Single Tiered): tutti e tre i livelli software sono assegnati ad un unica macchina, questa configurazione è quella classica terminale-host che caratterizzava i sistemi basati su mainframe (sistema centralizzato); due livelli di distribuzione (Two Tiered): i livelli applicativi sono divisi tra la stazione di lavoro dell utente (tipicamente un personal computer) e la macchina server che ospita i dati. Sulla stazione di lavoro è realizzata la logica di presentazione e sulla macchina server quella d accesso ai dati; sono possibili scelte diverse per l allocazione della logica applicativa e di parte della presentazione e della gestione dei dati. Questa configurazione è stata implementata nella prima generazione di sistemi client/server negli anni 80; tre livelli di distribuzione (Three Tiered): i tre livelli applicativi sono suddivisi fra altrettante macchine dedicate, ovvero una stazione di lavoro utente (di tipo PC, in generale), un server intermedio (detto anche middle tier) e un server di gestione dei dati. La prima configurazione, pur rappresentando il vecchio modello centralizzato, mantiene ancora una propria validità. Infatti, i sistemi mainframe, Single Tiered per eccellenza, garantiscono un livello di prestazioni, affidabilità esi- curezza che le moderne soluzioni distribuite non hanno ancora pienamente eguagliato. Attualmente questa configurazione viene proposta nei progetti di server consolidation per ridurre i costi di gestione di sistemi informativi basati su Web (per eseguire quindi applicazioni basate su tecnologie recenti e non necessariamente applicazioni legacy Cobol). Relativamente alla seconda configurazione, sono possibili sei differenti architetture (Figura 2.3), in base alle modalità di allocazione dei tre layer applicativi, Le architetture differiscono in termini di: traffico di rete, prestazioni e compiti eseguiti dalla stazione di lavoro e comportano livelli diversi di flessibilità e di facilità dimodifica. La Tabella 2.1 mostra la possibile ripartizione dei tre layer architetturali su tre tier: P, A e D indicano rispettivamente i layer di Presentazione, di Gestione della logistica Applicativa e di Gestione Dati. 6

69 Presentazione Distribuita Presentazione Remota Applicazione Distribuita Gestione dati Remota Applicazione e Dati Distribuiti Gestione dati Distribuita C l i e n t Presentazione Presentazione Presentazione Presentazione Presentazione Presentazione Logica Applicativa Logica Applicativa Logica Applicativa Logica Applicativa Presentazione NETWORK Gestione Dati Gestione Dati Logica Applicativa Logica Applicativa Logica Applicativa Logica Applicativa Gestione Dati Gestione Dati Gestione Dati Gestione Dati Gestione Dati Gestione Dati S e r v e r Fig 2.3: Classificazione delle architetture 2-tier A seconda delle possibili ripartizioni dei tre livelli applicativi sui tier hardware fisici, si parla di configurazioni fat client se a livello utente (ovvero tipicamente browser in ambiente Web) si appoggia la logica applicativa e quella di accesso ai dati, piuttosto che thin client se a livello utente (o browser in ambiente Web) resta relegata la funzione di presentazione, alleggerendo le funzionalità della stazione utente. Si parla infine di thick client quando la logica applicativa è distribuita in modo intermedio, tra client e server. Config /Tier Tier 3 D D D D D,A D D D,A D D D,A D,A D,A, P Tier 2 D D D,A A A D,A A A D,A, A,P A,P P P P Tier 1 D,A, P A,P A,P A,P A,P P P P P P P P P Tab 1: Classificazione delle architetture 3-tier Facendo riferimento alla Figura 2.3 le configurazioni su due livelli Presentazione distribuita e Presentazione remota corrispondono a client thin, viceversa le restanti configurazioni corrispondono a client fat. Se si consid- 7

70 erano invece sistemi su tre livelli (si faccia riferimento alla Tabella 1), si ha che: Le configurazioni da 1 a 5 riguardano situazioni fat client, maggiormente indicate per realtà interne (sistemi Intranet). Le configuazioni da 6 a 13 riguardano situazioni thin client, adatte alla distribuzione di servizi a un insieme aperto di utenti (sistemi Internet); Le configurazioni 4, 5, 7, 8 e da 10 a 13 realizzano la separazione fisica fra utenti (tier 1) e dati (ospitati unicamente nel tier 3), attraverso l introduzione di una macchina intermedia (tier 2). Tali configurazioni sono quindi particolarmente sicure riguardo all accesso ai dati da parte degli utenti. La tecnologia Web, inizialmente nata per fornire informazioni su Web browser (tier 1) mediante un Web server (tier 2) (configurazioni da 6 a 13), si è negli ultimi tempi evoluta per permettere l esecuzione di logica applicativa sul Web browser (configurazioni da 2 a 5) o anche per accedere alle risorse locali del tier 1 (configurazione 1); Le architetture fat client storicamente hanno introdotto diversi svantaggi che hanno origine nella necessità di amministrare diverse macchine client anziché un singolo server, come avveniva per i sistemi centralizzati. Se un applicazione viene aggiornata frequentemente, in configurazioni fat e thick gli aggiornamenti devono essere effettuati su tutte le macchine client e ciò comporta elevati costi di gestione. In generale, nei sistemi informativi basati su Web, i problemi di amministrazione si sono notevolmente ridotti grazie al fatto che le applicazioni possono essere installate centralmente sul Web server e l utente può farne il deployment (l installazione dei layer software sui tier fisici) automaticamente accedendo al Web server con il proprio browser (ad esempio, effettuando il download di applet o controlli ActiveX). Tuttavia, questa operazione richiede di introdurre alcune ipotesi sulla configurazione in termini di versione del browser, piattaforma, ecc., della macchina client che accede al sistema (ad esempio se l applicazione viene realizzata attraverso controlli ActiveX potrà essere eseguita solo su client basati di piattaforma Windows). Un sistema a tre livelli (tier) conferisce alle infrastrutture ICT maggiori caratteristiche di scalabilità e flessibilità. Le configurazioni fat e thick a due livelli non sono particolarmente indicate se la logica applicativa distribuita è particolarmente onerosa dal punto di vista della richiesta di potenza di calcolo (CPU o RAM). In queste situazioni, è più conveniente centralizzare la logica 8

71 applicativa su un server intermedio. In questo modo è sufficiente garantire la robustezza e l efficienza del server intermedio che viene condiviso tra i diversi client. Inoltre, il server viene dimensionato in modo da garantire un predeterminato livello di prestazioni per un certo numero di utenti contemporaneamente attivi, numero che è ragionevole assumere sia sempre inferiore al numero totale degli utenti che hanno accesso al sistema informativo. Il server intermedio consente inoltre di ridurre il carico al DBMS server. Il middle tier infatti mantiene connessioni permanenti con il DBMS ed il numero di sessioni aperte tra il tier intermedio ed il DBMS è in generale inferiore al numero di connessioni aperte tra i client ed il tier intermedio. Nelle implementazioni reali si adottano spesso soluzioni con più ditretier. All inizio degli anni 90 i servizi Web venivano implementati su due o tre tier, mentre gli attuali siti di e-business si sviluppano su 5 tier, partizionando ulteriormente su più layer software la logica di Presentazione oppure introducendo tier dedicati a supporto della comunicazione (middleware) Server Farm Nei moderni sistemi, i tier fisici possono essere realizzati anche come server farm, ovvero come un insieme di elaboratori che condividono il carico elaborativo, le applicazioni e, a seconda delle configurazioni, i dati. Una server farm è gestita dagli altri livelli come un unica risorsa. Il vantaggio dell introduzione di server farm rispetto ad una singola macchina consiste in un minore costo di acquisto dell hardware e nella maggiore affidabilità e scalabilità del sistema. Infatti, secondo il principio del downsizing proposto all inizio degli anni 80 e considerato tutt ora valido, server di fascia bassa hanno costi inferiori a server di fascia alta o mainframe, a parità di potenza di calcolo complessiva installata. Nella letteratura dei sistemi informatici sono state proposte diverse definizioni di affidabilità del sistema. Nel seguito con il termine affidabilità (detta anche disponibilità dal termine inglese availability) si farà riferimento alla probabilità che il sistema sia operativo ad uno specifico istante temporale t aprescindere da eventuali guasti avvenuti nell intervallo di funzionamento [0,t). MTTF MTTF+MTTR,doveMTTF L affidabilità viene espressa attraverso la relazione (Mean Time To Failure) indica il tempo medio di guasto e MTTR (Mean Time To Repair) esprime il tempo medio di riparazione del sistema. Sistemi ad alta affidabilità sono in generale caratterizzati da MTTF elevato e/o da un MTTR basso. L introduzione di una server farm comporta un aumento dell affidabilità del sistema poichè un tier fisico risulta non accessibile se tutte le macchine componenti della server farm risultano non operative. L af- 9

72 fidabilità teorica di un insieme di macchine che offrono lo stesso insieme di servizi e condividono il carico applicativo èdatoda1 i (1 a i), dove a i è l affidabilità della i-ma macchina della server farm. La produttoria esprime la probabilità che tutte le macchime siano guaste. In generale questo valore è solo teorico poichè, in caso di guasto, una singola macchina dovrebbe essere in grado di sostenere il carico applicativo dell intera server farm. I sistemi vengono solitamente dimensionati assumendo che si guasti una singola macchina ed accettando un degrado delle prestazioni fissato a priori. Con scalabilità di una infrastruttura IT si intende la capacità dell infrastruttura di soddisfare richieste crescenti da parte degli utenti (o di un maggiore numero di utenti) con aggiornamenti adeguati. Quando un sistema si dice non scalabile, generalmente significa che il costo aggiuntivo per far fronte a un dato aumento di traffico o di dimensione è eccessivo, oppure la crescita non è attuabile (ad esempio non è possibile installare ulteriori CPU o memoria RAM all interno di una macchina). I sistemi basati su server farm risultano molto scalabili poichè è possibile far fronte ad un incremento dei requisiti introducendo ulteriori macchine senza essere soggetti ai vincoli di upgrade di una singola macchina, e per il principio del downsizing, con costi contenuti. Le server farm possono essere realizzate secondo due principi progettuali: Cloning (clonazione) o Partitioning (partizionamento). Nel primo caso, su ognuno dei nodi costituenti vengono installate le stesse applicazioni software ed i medesimi dati. Le richieste sono poi instradate ai vari membri appartenenti all insieme dei cloni usando un sistema di load-balancing. Un insieme di cloni dedicati allo svolgimento di un particolare servizio è detto RACS (Reliable Array of Cloned Services); ed ogni clone implementa lo stesso insieme di funzionalità. La clonazione del servizio permette di raggiungere vantaggi sia di scalabilità che di tolleranza ai guasti (fault tolerance) in termini di disponibilitàdel servizio stesso. Infatti se un clone subisce un guasto, un altro nodo può continuare ad erogare quel servizio. I RACS si possono presentare in due configurazioni: shared-nothing e shareddisk. Nella prima configurazione (si faccia riferimento alla Figura 2.4) i dati memorizzati sono replicati su ogni clone e risiedono in un disco fisso locale ad ogni clone; quindi, un aggiornamento di dati deve essere applicato ad ognuno dei cloni. Di conseguenza questa configurazione risulta problematica per i servizi write-intensive, mentre presenta prestazioni migliori per applicazioni di tipo read-only, quali l accesso a pagine statiche o il download di file o immagini dai Web server. Nella configurazione shared disk, spesso chiamata cluster, iclonicondivi- 10

73 Fig 2.4: Configurazione shared-nothing dono un server di memorizzazione che gestisce i dischi fissi (Figura 2.5). Fig 2.5: Configurazione shared-disk o cluster La tecnica di partizionamento prevede viceversa la duplicazione dell hardware e del software ma non dei dati, che invece vengono ripartiti tra i nodi (Figura 2.6). Ogni nodo svolge quindi una funzione specializzata; ad esempio il sistema Web di vendite di un azienda può essere suddiviso per tipologie di clienti o per linee di prodotto ed ognuna è gestita da un nodo. Il partizionamento è completamente trasparente alle applicazioni e le richieste vengono inviate alla partizione che possiede i dati rilevanti. Ad esempio, se viene implementato un partizionamento per linee di prodotto (A, B,..), le richieste di accesso alla linea di prodotto A verranno indirizzate al server che è in grado di accedere ai dati della linea di prodotto A. Questa tecnica però non migliora la disponibilità poiché i dati sono memorizzati su un singolo server e in caso di guasto la parte di servizio da esso gestita non risulta più accessibile. 11

74 Applicazione 1 Applicazione 2 Applicazione 3 Applicazione 4 Fig 2.6: Partizionamento Questa caratteristica è nota come proprietà digraceful degradation (degrado parziale) dei sistemi distribuiti: a differenza dei sistemi centralizzati, in caso di malfunzionamento non tutto il sistema risulta inaccessibile, ma solo alcune funzionalità non risultano più disponibili. Per risolvere il problema di indisponibilità di alcune funzionalità applicative in caso di guasto, si impiega spesso la clonazione dei singoli server che costituiscono la partizione, creando in tale modo dei pack. Si parla allora di RAPS (Reliable Array of Partitioned Service), una soluzione che garantisce sia scalabilità che disponibilità del servizio (Figura 2.7). Fig 2.7: RAPS Sistemi n tier La suddivisione dei layer software in tier hardware fisici non si ferma ai soli tre livelli illustrati fin qui, ma può essere ulteriormente suddivisa fino ad un 12

75 livello numero n di livelli (n-tiered architecture) generico, dove varie macchine dedicate sono utilizzate per supportare sistemi di data warehouse, gateway server, database server, e così via. Suognitier, è possibile implementare una server farm, che riduce i costi hardware attraverso il downsizing. Inoltre, se la logica applicativa è allocata su più tier, possono essere adottati server specializzati, rimuovendo così eventuali colli di bottiglia del sistema con l introduzione di nuovi server là dove risulta necessario e rendendo altamente scalabile l architettura complessiva. Come verrà discusso nel paragrafo successivo, i moderni sistemi informativi basati su Web si basano su 5 tier. In particolare, la presentazione viene realizzata attraverso tre tier: il browser dell utente, il Web server che garantisce l accesso alle pagine ed agli oggetti statici e lo Script engine che si occupa della generazione delle pagine dinamiche. I tier 4 e 5 corrispondono all application server e al DBMS. Il numero di tier inoltre può crescere se vengono introdotti server dedicati a supporto dello strato di comunicazione, ovvero del middleware. Per esempio, quando più sorgenti di informazioni sono integrate tra loro e consultate in tempo reale, è possibile introdurre tra le varie sorgenti informative e l application server un database gateway (si faccia riferimento alla Figura 2.8). L application server esegue le funzionalità applicative basandosi su una visione unificata dei dati. Il database gateway fornisce un accesso trasparente ai DBMS della rete e traduce le chiamate API dell application server nella sintassi della sorgente dei dati remota. Ciò evita che lo sviluppatore debba conoscere i dettagli dei database remoti e delle relative modalità e linguaggi di accesso. Questa trasparenza della localizzazione comporta inoltre la trasparenza rispetto a problemi di migrazione: se una sorgente di dati viene spostata, o convertita in una nuova struttura, è necessario modificare soltanto il database gateway senza modificare l application server o la logica di front-end del sistema informativo. È necessario osservare che anche se viene introdotto un maggior numero di tier fisici gli strati logici (layer) software è pari a tre in quanto gli applican gateway o i database gateway vengono considerati solitamente strato di logica applicativa. L introduzione di un maggiore numero di tier fisici comporta la riduzione dell affidabilità complessiva del sistema. Infatti il sistema risulta accessibile se e solo se tutti i suoi componenti sono funzionanti, l affidabilitàèdata da i a i dove a i indica l affidabilità dell i-mo tier fisico. Poichè a i < 1per ogni i, l affidabilità complessiva è inferiore all affidabilità di ogni tier fisico componente. Per questo motivo i sistemi n tier introducono molto spesso server farm. 13

76 Fig 2.8: Esempio di sistema 4-tier 2.2 Architetture dei sistemi Web Gli elementi essenziali di un moderno sistema Web sono: il Web server che si occupa della gestione delle richieste HTTP provenienti da Internet o dalla Intranet aziendale; lo Script engine, un processo che esegue script per la generazione di pagine HTML dinamiche; l Application server, che assume il ruolo di middle tier ed implementa la logica di business dell applicazione Web; il DBMS server, che si occupa della gestione dei dati; i componenti di sicurezza: firewall e Intrusion Detection System (IDS). Il Web server si colloca fisicamente tra l utente finale che accede al sistema attraverso il browser (che assume il ruolo di primo tier applicativo) ed il sistema informativo aziendale. Il Web server si occupa della presentazione delle informazioni verso i client ed in particolare restituisce direttamente ai client che ne hanno fatto richiesta pagine HTML statiche o oggetti statici, come ad esempio immagini o file di altra natura (ad esempio cataloghi informativi dei prodotti). Nel caso in cui sia necessario generare una pagina dinamica, il Web server interagisce con lo Script engine. Lo Script engine è un processo che genera una pagina dinamica (come verrà discusso nel Capitolo 3, nell architettura J2EE lo Script Engine è un Servlet Engine, un processo che esegue nel proprio spazio di indirizzamento una Servlet). Lo Script engine genera pagine dinamiche interagendo con l Application server o con il DBMS server. Le pagine dinamiche vengono poi restituite al Web server che le inoltrerà successivamente all utente che ne ha fatto richiesta. 14

77 Come discusso in precedenza, l application server ha il ruolo di middle tier, implementa la logica di business dell applicazione ed in alcuni casi svolge il ruolo di contenitore di oggetti (supporta cioè l esecuzione di un oggetto distribuito, come ad esempio un Enterprise Java Bean od un componente Microsoft DCOM/.Net). Infine, come nei sistemi distribuiti tradizionali, il DBMS si occupa dell accesso e della gestione dei dati aziendali. I principali componenti di sicurezza di un sistema Web sono il firewall e l Intrusion Detection System. Il firewall è costituito da un insieme di componenti hardware e software il cui obiettivo generale è collegare una rete ritenuta fidata con una insicura. Un firewall controlla, implementando opportune policy di sicurezza, il traffico in entrata e in uscita dalla rete da proteggere con lo scopo di prevenire, rilevare e annullare eventuali attacchi e richieste non autorizzate. Esistono tre tipologie di firewall: (i) packet filtering, (ii) application proxy, (iii) stateful inspection packet filter. Un firewall packet filter effettuata la ritrasmissione di un pacchetto basandosi su regole che fanno riferimento unicamente allheader di un pacchetto (indirizzo IP del mittente e del destinatario, e per i sistemi che operano a livello TCP, numero di porta del processo mittente e destinatario). In generale i firewall di questa tipologia offrono ottime prestazioni ma risultano di difficile configurazione in quanto le policy di sicurezza sono definite ad un livello molto basso. Un firewall application proxy è un programma applicativo eseguito da un host che connette due reti. Mentre con i firewall packet filtering, se le regole di sicurezza lo consentono, le comunicazioni vengono instaurate direttamente tra i processi client e server, viceversa con l adozione di firewall application proxy i client devono stabilire una connessione con il firewall application proxy e richiedere al proxy di stabilire una connessione con il servizio di destinazione. Le policy di sicurezza dei firewall application proxy sono a più alto livello rispetto al packet filtering e possono essere espresse anche con una granularità maggiore. Consentono infatti di effettuare l autenticazione degli utenti e possono consentire o negare l accesso a specifiche funzionalità erogate dalla stessa applicazione o servizio. Complessivamente si hanno maggiori garanzie di sicurezza rispetto al packet filtering introducendo tuttavia maggiori requisiti di calcolo. Infine, un firewall stateful inspection packet filtering effettua la funzione di filtraggio basandosi sul contenuto dei pacchetti ricevuti in precedenza e sulla base dello stato complessivo della connessione esistente tra client e server. Lo stateful inspection packet filtering può essere considerata una soluzione intermedia tra packet filtering ed application proxy e cerca di fornire i vantaggi di entrambe le soluzioni: efficienza, flessibilità ed efficacia della policy di sicurezza. Con intrusion detection si intende il processo di monitoraggio degli eventi di un sistema, o di una rete di calcolatori, il cui obiettivo è individuare le intru- 15

78 sioni definite come il tentativo di compromettere la confidenzialità, l integrità o la disponibilità del sistema. Un IDS è un sistema software o hardware che automatizza il processo di monitoring e analisi degli eventi. Molto spesso l IDS è in grado di interagire con il firewall in modo da reagire automaticamente ad un attacco. Ad esempio se l IDS rileva che un utente esterno non autorizzato (intruso nella terminologia della sicurezza) sta cercando di accedere al sistema, può richiedere al firewall di chiudere le connessioni attive, impedire qualsiasi altra connessione che ha come origine l indirizzo IP dell intruso e notificare allamministratore che un attacco è in atto. Sono stati proposti vari meccanismi per rilevare e riconoscere un attacco. Tipicamente la fase iniziale di un attacco al sistema avviene secondo uno schema prevedibile il cui primo passo consiste nell analisi della rete o del sistema alla ricerca di un punto di ingresso ottimale. Esistono attualmente due tipologie di IDS: network based ed host based. Gli IDS network-based effettuano il rilevamento degli attacchi analizzando i pacchetti di rete basandosi su un insieme di sensori distribuiti nella rete ed eseguiti in modo nascosto (stealth, è necessario considerare che uno dei primi obiettivi di un attacco potrebbe essere quello di disattivare l IDS). I principali vantaggi sono dovuti dal fatto che pochi sensori possono monitorare una rete di grandi dimensioni e l introduzione dell IDS non ha un grande impatto sulla rete preesistente. Viceversa gli svantaggi sono dovuti dal fatto che sono poco efficienti in situazioni di congestione, non possono analizzare dati cifrati e non sono in grado di rilevare se un attacco ha avuto successo. Gli IDS host based sono viceversa installati su ogni macchina che deve essere protetta ed operano sulle informazioni raccolte su singoli host a livello di sistema operativo o, in alcuni casi, di applicazione. I principali vantaggi sono: è possibile analizzare gli attacchi con estrema precisione determinando quale processo ed utente sono stati coinvolti, è possibile stabilire l esito degli attacchi e riconoscere attacchi non rilevabili dagli IDS network-based, infine possono essere utilizzati anche se i dati vengono cifrati. Gli svantaggi sono dovuti dalla difficoltà di gestione e scalabilità del sistema IDS dovendo installare il software su ogni singola macchina, non sono efficaci per attacchi che coinvolgono l intera rete e richiedono capacità di calcolo e di memorizzazione aggiuntive. Solitamente gli IDS host based sono installati sui server che contengono dati sensibili o che eseguono applicazioni mission critical mentre gli IDS network based vengono introdotti nei punti di entrata e uscita di reti protette. Il problema di progettazione architetturale consiste nello stabilire: il numero di tier fisici del sistema, ovvero consiste nel determinare quali 16

79 elementi (Web server, Script engine, ecc.) devono essere installati su macchine fisiche separate; quante macchine devono essere introdotte ad ogni tier fisico; come collegare tra di loro le diverse macchine; come introdurre i componenti di sicurezza. Nella parte restante del capitolo verranno analizzate le possibili soluzioni architetturali secondo le quali è possibile implementare un sistema informativo basato su Web. La presentazione procederà seguendo un approccio storico e con complessità crescente e verranno analizzati vantaggi e svantaggi delle soluzioni proposte. Configurazione 2 tier single host Questa configurazione introduce un unica macchina fisica che supporta l esecuzione di Web server, script engine e DBMS (si faccia riferimento alla Figura 2.9). La configurazione è stata adottata all inizio degli anni 90 quando le funzionalità implementate dalla logica applicativa erano molto limitate e le pagine dinamiche venivano realizzate con script CGI, PERL o TCL. Per generare una pagina dinamica, il Web server invocava un programma di script esterno che veniva riavviato ad ogni invocazione, con effetti molto negativi sulle prestazioni del sistema (overhead dovuto all attivazione e disattivazione dei processi ed alla apertura e chiusura delle connessioni verso il DBMS). Il principale vantaggio di questa configurazione è costituito dalla semplicità di installazione e manutenzione poiché si deve gestire una sola macchina. Inoltre, risulta semplice mantenere lo stato dell applicazione, che può essere memorizzato nello Script engine (ad eccezione della tecnologia CGI) o nel database. Risultano invece molto più problematiche l affidabilità, dato che il malfunzionamento di un unico componente fisico blocca l accesso all intero sistema, e la sicurezza poiché se un intruso è in grado di superare il firewall, ha accesso diretto alla macchina che contiene i dati aziendali. Risultano problematiche anche le prestazioni e la scalabilità del sistema. L aspetto più critico dal punto di vista delle prestazioni risiede nel fatto che Web Server e DBMS sono due processi che richiedono molte risorse sia in termini di RAM che di tempo di CPU. La scalabilità del sistema inoltre è limitata alla possibilità di upgrade della singola macchina (RAM, sostituzione CPU o dischi,... ). Per il principio di downsizing, il costo del sistema risulta basso solo se non è richiesto hardware ad alte prestazioni. 17

80 Fig 2.9: Configurazione 2 tier Single Host Configurazione 3 tier Dual host In questa configurazione, Web server e Script engine sono ospitati su una stessa macchina (si faccia riferimento alla Figura 2.10) mentre il database è eseguito su una macchina dedicata. Inoltre, viene installato un secondo firewall che introduce un secondo dominio di sicurezza a protezione del DBMS. Solitamente il firewall esterno è un packet filter mentre il firewall interno è di tipo application proxy. La rete a cui risulta collegato il Web server viene detta DMZ (Demilitarized Zone), che consiste in un segmento, o insieme di segmenti, della rete localizzati tra reti protette e non protette. Questa configurazione è stata adottata nei sistemi aziendali a partire dalla seconda metà degli anni 90. Il secondo livello di firewall garantisce una migliore protezione ai dati aziendali: infatti, anche se un intruso è in grado di scardinare il primo livello di firewall ed accedere al Web server, gli sarà necessario del tempo aggiuntivo per violare il secondo firewall ed il DBMS, tempo che può essere utile all IDS e agli amministratori per rilevare e bloccare l attacco. Inoltre, il dimensionamento della macchina dedicata all esecuzione di Web server e Script engine e del server dedicato all esecuzione del DBMS risulta meno critico. Solitamente, il middle tier esegue operazioni CPU intensive, mentre il DBMS operazioni I/O intensive; pertanto, è possibile introdurre macchine specializzate con canali di I/O molto efficienti per il DBMS e CPU ad alte prestazioni per il tier intermedio. Rispetto alla configurazione precedente, la scalabilità del sistema è maggiore potendo intervenire separatamente su tier intermedio e data tier. Resta comunque critica la disponibilità del sistema, dato che è sufficiente il guasto di un componente fisico per bloccare l intero sistema. 18

81 Fig 2.10: Configurazione 3 tier Dual Host Configurazione 3 tier con server farm Per migliorare disponibilità, scalabilità e prestazioni è necessario replicare i componenti critici del sistema (quali il Web server, o lo Script engine). La replicazione è applicabile ad ogni livello e, a seconda dello schema di replicazione adottato, vengono introdotte server farm in configurazione RACS o RAPS. Tipicamente per l esecuzione del Web server, dello Script engine e dell Application server vengono introdotte server farm in configurazioni RACS shared nothing. Invece il DBMS viene replicato secondo schemi shared disk che si appoggiano su un server di memorizzazione o che sfruttano tecnologie moderne di storage networking (sistemi SAN, Storage Area Network, e NAS, Network Attached Storage) che consentono a più server di condividere un insieme di dischi attraverso reti ottiche ad alta velocità. La replicazione dei componenti critici migliora la disponibilità del sistema, poiché, se cade uno dei processi, il suo carico di lavoro viene distribuito sugli altri processi in esecuzione ed il sistema continua ad erogare il proprio servizio. Inoltre, migliora la scalabilità del sistema dato che, se si presenta un collo di bottiglia ad un qualsiasi livello è possibile introdurre nuove istanze di processi e nuove macchine server là dove risulta necessario, senza le limitate possibilità di upgrade di una singola macchina. La replicazione infine consente di migliorare le prestazioni poiché il carico viene distribuito dai load balancer in modo uniforme sui server attivi. Per quanto riguarda il Web server, la richiesta di una pagina Web (che di solito contiene diversi elementi e dà luogo a richieste HTTP multiple) può essere eseguita in parallelo dalle varie macchine che costituiscono la server farm, riducendo i tempi di risposta del sistema. La replicazione può essere attuata in modo semplice per applicazioni stateless; risulta invece più problematica quando è necessario mantenere lo stato delle sessioni utenti. Le soluzioni che possono essere adottate consistono nell introdurre load balancer evoluti che indirizzano le richieste provenienti da 19

82 uno stesso client allo stesso server che mantiene lo stato della sessione. I load balancer devono essere dotati di una certa intelligenza ed operano in generale a livello 7 dello stack ISO/OSI. Infatti, il semplice indirizzo IP del client può non essere sufficiente per discriminare l utente collegato al sistema, dato che tutti gli utenti di una stessa Intranet potrebbero presentare verso l esterno lo stesso indirizzo IP. Il problema di gestione dello stato della sessione si complica ulteriormente se si vuole rendere trasparenti i guasti agli utenti e garantire la continuità di sessione. Con tali esigenze, le sessioni eseguite da un server guasto devono essere recuperate dagli altri server che lo sostituiranno e subentreranno nell esecuzione delle richieste seguenti degli utenti connessi al server guasto. La soluzione adottata in questi casi consiste nel memorizzare in modo permanente lo stato della sessione nel DBMS, con lo svantaggio di aumentare il carico nel sistema per l aggiornamento dello stato della sessione. Tale soluzione deve pertanto essere introdotta se a livello applicativo èeffet- tivamente necessario mascherare all utente il guasto e garantire la continuità di sessione. Il problema del mantenimento della sessione si presenta anche se vengono introdotti i protocolli HTTPS o SSL per effettuare connessioni sicure verso gli utenti. I protocolli di sicurezza infatti richiedono l esecuzione di un protocollo piuttosto complesso (per esempio a causa delle interazioni dovute per l autenticazione tra client e server) che coinvolge client e server per la generazione di una chiave di sessione che viene utilizzata poi per effettuare comunicazioni sicure attraverso schemi di crittografia simmetrica. La chiave di sessione viene generata da un server e non viene condivisa con altri server; pertanto tutte le richieste provenienti dallo stesso client devono essere indirizzate verso lo stesso server. Come indicato in Figura 2.11, in alcuni sistemi il problema viene semplificato introducendo un server Web dedicato alla gestione delle connessioni sicure. Configurazione 5 tier con server farm La Figura 2.12 riporta lo schema architetturale di un sistema Web che viene adottato nei moderni centri di elaborazione dati. L architettura assegna tier dedicati per l esecuzione di Web Server, Script engine ed Application server. La gestione del parallelismo, della replicazione, della sicurezza e della disponibilitàè garantita a livello di application server ed è trasparente al programmatore applicativo. Nell application server viene centralizzata la business logic; con le moderne tecnologie, l application server ha il ruolo di contenitore di oggetti riusabili (Enterprise Java Beans e componenti DCOM/.Net) che possono essere invocati da qualunque applicazione aziendale e non necessariamente dal Web. Per questo motivo la farm che supporta l esecuzione 20

83 Fig 2.11: Configurazione 3 tier con Server farm dell application server è protetta da un ulteriore livello di firewall e risiede fisicamente nella DMZ2, mentre Web server e Script engine, che si occupano unicamente della presentazione, risiedono nella DMZ di primo livello. Nei sistemi più evoluti, il bilanciamento e la gestione dei malfunzionamenti avviene a livello degli oggetti applicativi ed il numero di processi allocati ed istanze di oggetti è stabilito a run-time in base alle reali condizioni di carico del sistema (infrastrutture che implementano meccanismi di self-management e self-healing che cioè si auto-riconfigurano in seguito a variazioni di carico o di guasto, dette anche sistemi di Autonomic Computing). Questa soluzione architetturale presenta il più alto livello di prestazioni, disponibilità e scalabilità, ma è una soluzione costosa e generalmente complessa da mantenere. Fig 2.12: Configurazione 5 tier con Server farm Le architetture presentate sono caratterizzate da complessità e costi crescenti, ma offrono maggiori prestazioni e garanzie di scalabilità e tolleranza ai guasti. I vantaggi e gli svantaggi delle varie architetture sono riassunti in Tabella 2. 21

84 Configurazione Vantaggi architetturale 2 tier single host Costo: basso, se non serve hw ad alte prestazioni Complessità: soluzione semplice da installare e manutenere Mantenimento dello stato: semplice memorizzato su una singola macchina 3 tier dual host Prestazioni: dimensionamento più efficace di Web Server e DBMS server Scalabilità: possibilità di intervenire separatamente su middle tier e data tier che hanno requisiti prestazionali differenti Sicurezza: dati su macchine distinti sono più sicuri 3 tier con server farm Prestazioni: distribuzione del carico di lavoro sui server/ processi in modo bilanciato Scalabilità: se necessario, èpos- sibile aggiungere nuove macchine server Disponibilità: fail-over, se cade uno dei processi, il suo carico di lavoro viene distribuito sui processi funzionanti e il sistema continua a fornire il servizio 5 tier con server farm Sicurezza: maggiore livello di sicurezza dovuto al terzo livello di firewall Prestazioni: load-balancing dinamico Scalabilità: se necessario, èpos- sibile aggiungere nuove macchine server Disponibilità: capacità di failover a livello dei singoli oggetti Svantaggi Prestazioni: legate alle caratteristiche della macchina, Database e Web Server competono per le risorse Scalabilità: limitata dalla possibilità di upgrade della macchina Disponibilità: se cade un componente, il sistema non è più accessibile Sicurezza: dati non difesi se il firewall viene superato Scalabilità: limitata dalla possibilità di upgrade della macchina Disponibilità: un componente fermo blocca ancora il sistema Soluzione architetturale complessa sia in termini di gestione e configurazione sia per le problematiche di implementazione del load balancing (per il mantenimento delle sessioni) che di gestione dello stato della sessione (la memorizzazione nel DBMS è onerosa dal punto di vista delle prestazioni) Complessità: ambienti generalmente complessi da manutenere Tab 2: Vantaggi e svantaggi delle architetture Web 22

85 2.3 Pattern architetturali per i client Web Sinora la descrizione dell architettura dei sistemi Web si è focalizzata sull infrastruttura del sistema del fornitore del servizio. Nel presente paragrafo vengono discusse invece le scelte architetturali che interessano il lato client, thin o fat, dell applicazione Web. Architetture thin vengono utilizzate principalmente se l applicazione Web deve essere accessibile attraverso Internet e vi è uno scarso controllo sulla configurazione dei client. L unica assunzione introdotta in questo caso èche il client sia un browser standard in grado di visualizzare form HTML. Tutta la logica applicativa è viceversa eseguita sui server del fornitore del servizio. Architetture thin possono essere introdotte per ovviare ad alcuni vincoli restrittivi addizionali sulle configurazioni dei browser o della rete. Per esempio, le impostazioni di sicurezza di alcuni browser possono aver disabilitato i cookie e questo impedisce l uso di alcuni meccanismi per la gestione dello stato delle sessioni. In alcuni casi, alcuni problemi possono avere origine se gli utenti dell applicazione Web accedono ad Internet attraverso un firewall. I firewall molto spesso limitano le tipologie di accessi consentiti verso i sistemi esterni e consentono l utilizzo dei soli protocolli HTTP/HTTPS attraverso le porte standard (80 e 443). Le architetture fat sono utilizzate quando è possibile assumere come nota una certa configurazione del client e se si desidera un interfaccia utente sofisticata oppure si vuole eseguire una parte significativa della logica applicativa sulla macchina client. In questo scenario architetturale, il client utilizza tipicamente Javascript ed esegue Applet Java o controlli ActiveX. Eseguire la logica applicativa sul client può migliorare l usabilità dell applicazione oppure le prestazioni del sistema. Per esempio, se il client è in grado di effettuare la verifica dei dati inseriti nei campi di una form, è possibile bloccare gli input non validi prima che vengano inviati al server, riducendo così il traffico in rete e il carico sul server remoto. Architetture fat possono essere impiegate anche per effettuare il deployment di un applicazione ad oggetti distribuiti di tipo tradizionale. In questo caso, oltre al download di applet o controlli ActiveX, si ha anche la possibilità di effettuare il download dello stub di oggetti remoti ed accedere alle funzionalità implementate da oggetti distribuiti di sistemi client/server tradizionali. Nella comunicazione, oltre al protocollo HTTP vengono utilizzati altri protocolli come IIOP (Internet Inter-ORB Protocol) in sistemi Java e CORBA, o il protocollo DCOM in ambienti Microsoft. Questo paradigma architetturale consente di superare le limitazioni imposte dal protocollo HTTP (principalmente legate al fatto che il protocollo è connectionless) e permette di instaurare una comunicazione stabile e duratura 23

86 tra le parti comunicanti. Questa scelta è appropriata se si ha il controllo sulle configurazioni dei client e della rete, la quale deve permettere connessioni affidabili. Facendo riferimento ancora all applicazione della borsa del lavoro si supponga di voler consentire l introduzione dell indirizzo all interno del curriculum attraverso una form ad autocompletamento. In altri termini (vedi Figura 2.13), il sistema completa automaticamente il campo Città dopo che l utente ha digitato il proprio codice di avviamento postale. Ciò può essere realizzato scaricando sul client l intera lista <CAP, Città > (Figura 2.13, soluzione 1), oppure il browser deve effettuare una richiesta aggiuntiva per ottenere tale informazione (Figura 2.13, soluzione 2). Entrambe le soluzioni sono insoddisfacenti: nel primo caso, la lista dei codici postali potrebbe avere dimensioni di molti megabyte e richiedere diversi minuti per il caricamento; nel secondo caso un interazione aggiuntiva in cui il browser invia il CAP ed ottiene la pagina HTML modificata con l informazione della città richiede comunque alcuni secondi. La soluzione migliore consiste nell introdurre un client fat in cui viene scaricato lato client lo stub di un oggetto distribuito che instaura una connessione permanente con un oggetto lato server corrispondente. L oggetto lato server ha accesso ad un data base di corrispondenze <CAP, Città >. La richiesta da parte dello stub lato client avviene attraverso i protocollo di middleware di (Figura 2.13, soluzione 3) ed il tempo di risposta in questo caso sarà dell ordine dei millisecondi se la banda della rete è sufficientemente ampia invece dei secondi richiesti per la generazione di una nuova pagina HTML completa. Per una stessa applicazione, è possibile implementare architetture client diverse per diverse classi di utenti. Per esempio, in un sistema di e-commerce, il cui obiettivo è raggiungere un insieme di utenti più ampio possibile, èop- portuno adottare un architettura thin per gli accessi al sistema delle vendite mentre è possibile implementare un architettura thick o fat per realizzare le interfacce di accesso alla manutenzione del sistema. Questo secondo approccio èconveniente perché esiste un certo grado di controllo sulla configurazione del client quando si possiede la macchina con cui si accede al sistema. Le architetture thin hanno riscosso un grande successo nella seconda metà degli anni 90 per semplificare la gestione dei client e consentire un accesso rapido alle applicazioni in condizioni di banda limitata. Attualmente, grazie all evoluzione delle tecnologie di rete ed ai tool di management remoti delle piattaforme client (come ad esempio Marimba, Java WebStart o Tivoli) questi aspetti risultano meno rilevanti. 24

87 Richiesta per la form indirizzo Tempo di risposta dell ordine dei minuti Web Server Soluzione 1: Download della lista <CAP, Città> e le funzioni Javascript aggiornano la form quando il campo CAP viene completato Invio dalla funzione Javascript della Form Web Server Soluzione 2: Il gestore Javascript cattura l evento di completamento del CAP e invia la form al server che restituisce la pagina HTML con il campo Città completato Tempo di risposta dell ordine dei secondi Client Object Stub Lo stub invia il CAP all oggetto lato server Tempo di risposta inferiore al secondo Server Object Application Server Web Server Soluzione 3: L oggetto client comunica direttamente con il server per ottenere i dati della Città Fig 2.13: Creazione di form con autocompletamento 25

88 3. Tecnologia web 3.1 Introduzione Il capitolo precedente ha presentato come sono organizzati i sistemi e come le informazioni che essi contengono possono essere scambiate utilizzando Internet come canale di comunicazione. Limitandosi al rapporto tra Web Server e Web Client (o Web Browser), HTTP (HyperText Transmission Protocol) e HTML (HyperText Markup Language) rappresentano, rispettivamente, il protocollo di comunicazione e il formato delle informazioni. Per meglio comprendere come questi due aspetti siano correlati, si immagini di avere a disposizione un Web Browser e di voler accedere alla pagina del proprio gruppo musicale preferito. Dal punto di vista dell utente i passi da fare sono semplici e limitati alla digitazione dell URL corretto nel Web Browser e nell attesa che la pagina HTML venga visualizzata. In realtà, nel momento in cui si richiede la pagina, il Web Browser tramuta questo desiderio dell utente in una richiesta costruita secondo il formato HTTP all interno della quale è presente l URL richiesto. Il Web Server, destinatario di tale richiesta, verifica che la pagina HTML richiesta sia effettivamente a disposizione e, in caso affermativo, la invia, sempre attraverso il protocollo HTTP, al Web Browser richiedente. Il Web Browser, a questo punto, trasforma le informazioni ricevute in HTML nella corrispondente schermata visualizzata all utente. La Figura 3.1 riassume questa interazione evidenziando l ordine dei passi e la direzione delle informazioni. In realtà, lo schema ora esposto rappresenta la situazione più semplice in cui le pagine HTML scambiate sono dette statiche. Infatti, la pagina visualizzata dal Web Browser è sempre la stessa fino a che la versione sul Web Server non viene modificata, e indipendentemente dall utente che la richiede, la pagina è sempre identica. Si immagini ora due utenti distinti, Luca e Paolo, che si collegano dalle proprie case al medesimo sito di commercio elettronico per la vendita di libri. Si supponga che il primo selezioni una copia della Divina Commedia, mentre il secondo una copia commentata dei Promessi Sposi. A questo punto sarebbe verosimile che, nel momento in cui Luca e Paolo richiedono la pagina con il dettaglio del proprio carrello della spesa, ognuno ottenga una pagina differente con i dati del proprio libro. Questa situazione è in netto contrasto con quanto definito per le pagine statiche. Infatti la stessa pagina 1

89 ha un aspetto diverso a seconda dell utente che la richiede. In realtà la pagina in questione non potrebbe mai essere una pagina statica, ma deve essere una pagina dinamica, una pagina cioè che viene generata nel momento in cui viene richiesta. In questo caso la richiesta HTTP inviata dal Web Browser deve contiene non solo l URL della pagina, ma anche un identificativo dell utente che indica al Web Server qual è l utente che formula la richiesta. Sulla base di queste informazioni, il Web Server genera la pagina con i dati relativi all utente richiedente e la invia come se fosse una normale pagina HTML al Web Browser. Una prima soluzione tecnologica in grado di supportare uno scenario simile a quello appena descritto è fornito dalle Common Gateway Interface (CGI). In questo contesto, si suppone di avere sulla macchina server una serie di applicativi in grado di ricevere in ingresso alcuni dati e di restituire una pagina HTML dipendente dai dati ricevuti. Questi applicativi, essendo il Web Server opportunamente configurato, sono disponibili all utente e invocabili dal client. Ogni applicazione, infatti, è vista come una risorsa a disposizione e, pertanto, è associata ad un URL. Supponendo quindi che il client richieda la risorsa secondo il seguente URL: ciò che avviene può essere schematizzato nel seguente modo: 1. Il server riconosce dall URL che la risorsa richiesta dal cliente è un eseguibile (xyz.exe) 2. Il server codifica i parametri inviati dal cliente e riempie le variabili d ambiente (es: request method, query string, content length, content type) 3. Il server lancia in esecuzione l applicazione richiesta con i parametri passati dal client (prova=1). 4. L applicazione stampa la sua risposta sullo standard output. La risposta può essere una pagina web o di altro tipo MIME come dichiarato nella risposta stessa. 5. Il server ridireziona lo standard output sulla rete e quindi verso il client. Lo schema di funzionamento è definito in Figura 3.2 e si può notare che le uniche modifiche rispetto alla Figura 3.1 sono legate al solo funzionamento 2

90 (1) URL (2) HTTP Request (5) HTTP Response (3) Cerca pagina (4) Invia pagina Utente Web Browser Web Server Risorse Figura 3.1: Interazione Web Browser - Web Server classica del Web Server e sono totalmente trasparenti al Web Browser. Per questo motivo i sistemi in grado di effettuare questo tipo di operazioni cadono sotto il nome di estensioni HTTP lato server. CGI rappresenta il capostipite di questo tipo di tecnologia solitamente associata a soluzioni quali: ASP (Active Server Pages) di Microsoft, JSP (Java Server Pages) di Sun, e PHP Hypertext Preprocessor. Attraverso queste tecnologie, è quindi possibile fare in modo che l interazione tra client e server sia stateful indipendentemente dal fatto che il protocollo HTTP su cui l interazione poggia sia stateless per definizione. Questa caratteristica del protocollo HTTP, se da un lato ne aumenta la robustezza, dall altro lato impone che le informazioni sul cliente e sullo stato della transazione in atto vengano memorizzate lato client o lato server. Dualmente, anche lato client è possibile aumentare la dinamicità della pagina in modo tale da diminuire il numero di richieste verso il server. L esempio tipico è la possibilità di verificare, data una form, che tutti i dati obbligatori siano stati inseriti e che il loro formato sia corretto. Il Web Browser, infatti, è in grado di compiere queste operazioni che permettono di evitare l invio di dati non corretti al server il quale, una volta rilevata l anomalia, non farà altro che richiedere i dati medesimi. All interno delle tecnologie lato client si trovano tra le altre JavaScript di Sun e VBScript di Microsoft. Tutte le tecnologie che in questa introduzione sono state semplicemente elencate hanno il pregio di trasformare il Web da un mezzo per la pubblicazione di informazioni ad un più complesso sistema utilizzabile per fornire servizi e per realizzare applicazioni web. Scopo quindi del presente capitolo è entrare nel dettaglio di alcune delle tecnologie nominate per capire come passare da un semplice sito Web ad una applicazione Web. Inizialmente viene presentato il pattern MVC (Model View Controller): un pattern definito prima dell avvento del Web, ma che modella in modo opportuno la struttura tipica delle applicazioni Web evidenziando il flusso operativo tra i vari attori in gioco. I paragrafi successivi si occupano, innanzitutto, di descri- 3

91 (1) URL (2) HTTP Req (8) HTTP Res (3) Cerca pag (7) Invia pag Estensione lato Server (4) Cerca pag (5) Invia pag Utente Web Browser Web Server Risorse (6) Genera pag Figura 3.2: Interazione Web Browser - Web Server con estensioni lato server vere ad un primo livello di dettaglio il linguaggio HTML per la realizzazione di pagine Web. Successivamente, vengono presentate due tecnologie server fortemente correlate tra di loro, e cioè le servlet e le pagine JSP. Il capitolo si chiude con una discussione relativa alle tecniche solitamente adottate per la realizzazione di applicazioni basate su Web che richiedono il salvataggio dello stato e quindi richiedono l implementazione del concetto di sessione Web. 3.2 Model-View-Controller (MVC) Pattern Le applicazioni Web, così come le applicazioni interattive in generale, hanno la prerogativa di essere applicazioni in grado di reagire all intervento dell utente. Possibili interventi dell utente possono essere: lo spostamento o il clic del mouse, la selezione di un pulsante o l inserimento di un testo. Naturalmente, a seconda dello stato in cui si trova l applicazione le operazioni ammesse per l utente sono ben definite e spesso portano ad una modifica dello stato stesso. La consapevolezza di cosa e come un utente può intervenire viene definita da ciò che l utente vede e quindi dal tipo di informazioni visualizzate al momento sullo schermo. Costruire una applicazione interattiva al di là delle tecnologie coninvolte, richiede la capacità di governare questo flusso operativo. A tal proposito, basandosi sul linguaggio di programmazione Smalltalk è stato definito e formalizzato il design pattern MVC (Model View Controller) che fornisce un modello per la realizzazione di applicazioni interattive. Essendo le applicazioni Web un particolare tipo di applicazioni interattive, il pattern MVC può essere applicato anche in questo ambito tenendo comunque in considerazione le caratteristiche dei sistemi e i vincoli imposti dai protocolli sottostanti. Entrando nel dettaglio, il design pattern MVC è composto da tre elementi organizzati come in Figura 3.3: Model: rappresenta lo stato e le operazioni disponibili; 4

92 invoca aggiorna Client Controller Model presenta notifica View Figura 3.3: MVC Design Pattern View: definisce il modo con il quale il modello deve essere presentato all utente; Controller: interpreta l azione dell utente e invoca le operazioni del Model opportune. Dal punto di vista operativo la View, a seconda del tipo di applicazione, può essere composta da una serie di finestre, o da pagine HTML, con le quali l utente interagisce. Nel momento in cui l utente richiede l invocazione di una particolare funzionalità, tale richiesta viene tramessa al controller. In prima battuta, il controllo può essere pensato come un selettore che, individuata la funzionalità richiesta, invoca uno dei metodi messi a disposizione dal Model aggiornando in tal modo lo stato dell applicazione. Il Model, infatti, è definito da una serie di metodi che costituiscono la logica di business e dalla rappresentazione dello stato dell applicazione. Nel momento in cui lo stato viene variato è compito del Model notificare questa variazione alla View per la presentazione dello stato aggiornato. Una suddivisione dei ruoli così precisa, sebbene faccia aumentare il tempo di elaborazione delle richieste dell utente, ha il vantaggio di rendere questi tre aspetti maggiormente indipendenti tra loro. Infatti è possibile offrire diverse viste alla stessa applicazione (per esempio, HTML, WAP, GUI), oppure modificare la logica di business avendo però il vincolo di non modificare la rappresentazione dello stato che risulta essere il punto di incontro di tutte e tre i componenti. Una rivistazione del design pattern MVC è richiesta nel momento in cui si considerano le applicazioni Web. Queste applicazioni, infatti, si poggiano su HTTP e quindi, come detto nell introduzione al presente capitolo, su un protocollo di tipo stateless. Questa caratteristica, infatti, non permetterebbe in alcun modo al modello (posizionato sul lato server) di notificare 5

93 <html> <head> <title>primo Esempio</title> </head> <body> <p>testo allineato a sinistra</p> <center>in mezzo</center> <p align="right">a destra</p> <p>questo e un testo diviso su<br/> due righe</p> </body> </html> Figura 3.4: Esempio di pagina HTML direttamente il cambiamento di stato al browser (che risiede sul lato client). A questo proposito, viene introdotto il design pattern MVC 2 che prende in considerazione queste limitazioni e propone una soluzione adatta al mondo Web in cui sono coinvolte le tecnologie server descritte di seguito e cioè Servlet e JSP. 3.3 HTML HTML è un linguaggio in grado di definire la struttura e il contenuto delle pagine, visualizzabili attraverso un Web Browser, dette appunto pagine HTML. Ad un primo livello di approssimazione (si veda l esempio in Figura 3.4) una pagina HTML è un insieme di marcatori rappresentati da tag i quali racchiudono porzioni di testo. Un tag, identificato da un nome racchiuso tra parentesi angolari, identifica un particolare comando che deve essere applicato alla porzione di pagina che questi racchiude. In alcuni casi un tag è un vero e proprio delimitatore di testo in quanto è definito da un tag di apertura (nella forma <nome-tag>) e di chiusura (</nome-tag>). Il tag di apertura è spesso caratterizzato anche da una serie di attributi che meglio specializzano il comando. Sebbene non sia ancora stato ancora presentato l insieme dei comandi a disposizione e riferendosi di nuovo all esempio di Figura 3.4, è facile immaginare che Primo esempio rappresenti il titolo della pagina, mentre in mezzo viene visualizzato al centro della pagina. A seconda del tipo di comando, il tag corrispondente non sempre racchiude del testo ma può essere composto dal solo tag di apertura all interno del quale possono essere definiti alcuni attributi. Per fare un esempio, il tag 6

94 <br/> indica che quanto definito successivamente deve essere posizionato in una nuova riga di testo senza lasciare alcuna interlinea con il paragrafo precedente. Un tag di questo tipo, detto anche tag vuoto (empty tag) si riconosce dal fatto che il simbolo di slash / chiude il nome del comando nel tag di apertura. Sulla base di questa prima descrizione dei tag, ipotizzando di voler simulare il funzionamento di un Web Browser, è possibile schematizzare il suo comportamento come un sistema che: ogni volta che incontra un tag di apertura (<nome-tag>) o un tag vuoto (<nome-tag/>) attiva la formattazione relativa, eventualmente specializzata dalle informazioni contenute negli attributi; stampa tutti i caratteri che incontra; ogni volta che incontra un tag di chiusura (</nome-tag>) disattiva la formattazione. La Figura 3.5 mostra la struttura generale che ogni pagina HTML deve rispettare. In primo luogo, affinchè una pagina HTML possa dichiararsi tale, essa deve essere racchiusa all interno del tag <html>. All interno di questo tag deve essere necessariamente presente il tag <body>, che rappresenta il corpo della pagina, all interno del quale verranno inseriti tutti i testi e le immagini realmente visualizzate all interno del Web Browser secondo lo stile definito dai rispettivi tag. È al contrario facoltativo, anche se fortemente consigliato, il tag <head> che racchiude tutti i tag necessari alla definizione degli attributi generali di una pagina (per esempio, il titolo della pagina, il tipo di codifica adottato) e delle meta informazioni spesso utilizzate dai motori di ricerca per indicizzare le pagine. Dettagli sui principali tag saranno presentati nelle sezioni che seguono. In particolare, la prossima sezione raccoglierà i tag più significativi che vengono inclusi all interno dell intestazione della pagina HTML, mentre quelle successive si occuperanno degli elementi inseribili all interno del corpo della pagina. Riguardo a ciò, una sezione è dedicata all inserimento del testo e alla sua formattazione, una seconda sezione all utilizzo di immagini e una terza alla realizzazione di tabelle Intestazioni di pagina Tra le varie informazioni che possono essere inserite all interno del tag <head> particolarmente utilizzato è il comando <title> il quale, come descritto in 7

95 <html> <head> <!-- definizione delle proprieta della pagina --> </head> <body> <!-- contenuto della pagina visualizzato dal Web browser --> </body> </html> Figura 3.5: Struttura di una pagina HTML precedenza, permette di definire una descrizione che al momento della visualizzazione della pagina nel browser verrà visualizzata sul titolo della finestra attiva. In aggiunta, il tag <meta>, permette di associare alla pagina una serie di meta informazioni in grado di meglio definirne il contenuto. In particolare, è possibile definire due tipi di meta informazioni. Il primo tipo associa al tag meta l attributo http-equiv grazie al quale è possibile definire il tipo di codifica con il quale la pagina HTML deve essere letta dal Web Browser. Il codice di seguito riportato fornisce un esempio di possibile utilizzo: <meta http-equiv=content-type content=text/html;charset=iso > In questo caso il Web browser viene informato del fatto che le informazioni che troverà di seguito saranno conformi al linguaggio HTML e che la codifica utilizzata permetterà la visualizzazione dei caratteri accentati richiesti dalla lingua italiana (iso è anche identificata dal valore Latin1). Il secondo tipo di meta informazioni, molto più generale, è costituito da coppie <nome, valore> secondo lo schema di codice: <meta name=nome content=valore> Pur essendoci vincoli riguardo al nome della meta informazioni esistono alcuni nomi standard. Ad esempio, la meta informazione keywords permette di definire una serie di parole chiave da assegnare al documento. Questo tipo di informazione viene spesso utilizzata dai motori di ricerca per indicizzare le pagine Web che i crawler individuano all interno di Internet. Allo stesso modo nomi quali author e description vengono spesso utilizzati per me- 8

96 morizzare all interno della pagina informazioni su chi ha realizzato la pagina e una breve descrizione in formato testuale del suo contenuto Gestione del testo e delle immagini All interno di una pagina Web, così come in tutti i documenti, il testo viene formattato in modo differente a seconda della sua valenza. Per questo motivo una porzione di testo in HTML può assumere un ruolo diverso (paragrafo, titolo, citazione, ecc.) a seconda del tipo di tag che lo contiene. Così come negli attuali sistemi di videoscrittura esistono degli stili predefiniti per formattare il testo anche in HTML. Volendo fornire solo gli elementi di base per la strutturazione di un testo in HTML si considerano: Tag <p>. Utilizzato per identificare il testo normale solitamente giustificato a sinistra. Due paragrafi successivi sono distanziati da una interlinea doppia. Nel caso si voglia andare a capo senza tale interlinea è necessario utilizzare il tag <br/>. Tag <h1>, <h2>, <h3>, <h4>, <h5>, <h6>. Rappresentano i sei livelli con i quali è possibile strutturare un documento definito all interno di una pagina Web. Ognuno di questi tag è utilizzato per definire un titolo a diversi livelli. Tutti questi tag possono essere arricchiti attraverso diversi attributi che permettono di meglio definire lo stile del testo. Tra questi l attributo color permette di cambiare il colore del testo, mentre size la dimensione del carattere. Tabella 3.1: Classi di font predefinite Arial, Helvetica, sans-serif Verdana, Arial, Helvetica, sans-serif Courier New, Courier, mono Georgia, Times New Roman, Times, serif Geneva, Arial, Helvetica, sans-serif Allo stesso modo è anche possibile modificare il font del testo anche se in HTML esistono alcune limitazioni dovute al fatto che il font selezionato deve essere obbligatoriamente installato sulla macchina dove il Web Browser è in esecuzione. Per questo motivo in HTML sono predefinite cinque classi di 9

97 font, visualizzate in Tabella 3.1, ognuna delle quali è caratterizzata da una lista di font ammissibili. Il Web Browser, quando incontra questo attributo, cerca nell ordine in cui appaiono, i font specificati e formatta il testo secondo il primo dei font realmente installati sulla macchina. Vista la diffusione dei font indicati risulta verosimile che almeno uno della lista sia effettivamente installato e, quindi, non ci siano errori nella visualizzazione. Sebbene sia buona prassi limitarsi a questi font, è sempre possibile indicare un font diverso, fatto salvo essere sicuri che ogni macchina che visualizza la pagina abbia installato il font richiesto. Riferendosi sempre al tag <p> e alla famiglia di tag <hx> l attributo align permette di definire l allineamento della porzione di tag racchiuso. In dettaglio, gli allineamenti ammessi sono a sinistra (valore left), a destra (valore right) e centrato (valore center). Non è consentita la possibilità di giustificare il testo. Indipendentemente dal tipo di font e di allineamento, i tag <b>, <i> e <u> permettono di definire, rispettivamente, un testo in grassetto, in corsivo e sottolineato. Oltre al testo, uno dei contenuti tipici di una pagina HTML è rappresentato dalle immagini che, dal punto di vista fisico, non sono incluse nella pagina, ma solo collegate ad essa. In altre parole, nel caso il Web browser visualizzi una pagina HTML con una immagine, questo significa che almeno due file sono presenti nel Web Server: uno con il codice HTML e uno con l immagine. Va sottolineato che non tutti i formati sono supportati dal Web Browser. Immagini codificate secondo il formato BMP e TIFF, per esempio, non sono supportate. Al contrario immagini GIF, JPEG, PNG sono le più indicate vista la loro ridotta dimensione in termini di spazio. Dal punto di vista sintattico, l associazione di una pagina HTML ad una immagine è definita dal tag <img>. Questo tag attraverso l attributo src definisce il nome del file contenente l immagine Link A differenza di un documento tradizionale, un documento definito secondo il linguaggio HTML deve, per definizione, essere ipertestuale. Questo significa che il fruitore del documento può passare da un punto ad un altro del documento ipertestuale sulla base dei concetti che vengono espressi e non necessariamente essere costretto a leggerlo dall inizio alla fine. Lo strumento che HTML mette a disposizione per permettere di definire questi salti all interno del contenuto dei documenti o tra documenti differenti 10

98 <h1>il mio libro</h1> <a href="#capitolo1">capitolo 1</a> <a href="#capitolo2">capitolo 2</a>... <a name="capitolo1"/> <p>capitolo 1</p>... <a name="capitolo1"/> <p>capitolo 2</p>... <p>per informazioni leggete anche il <a href="suo.html"> suo libro </p> <h1>il suo libro</h1>... <p>se volete approfondire l'argomento leggete il <a href="mio.html#capitolo1"> capitolo 1</a> dell'altro libro </p> mio.html suo.html Figura 3.6: Link interni alla pagina e tra pagine è il link. Il link non è un concetto autonomo, ma è definito dai due elementi che collega: la sorgente e la destinazione del link. La sorgente può essere una porzione di testo o una immagine che, se selezionata, sposta il controllo alla risorsa definita dalla destinazione. Una destinazione può essere definita sia nella stessa pagina in cui è presente la sorgente (in questo caso si parla di link interno) sia in una pagina esterna. Partendo dalla sorgente, il tag <a> racchiude la porzione di testo o l immagine che si vuole rendere selezionabile. Questo tag ammette l attributo href che definisce la destinazione, cioè la pagina o il punto all interno della pagina che il browser dovrà visualizzare nel momento in cui l utente avrà cliccato sulla sorgente. Mentre nel caso in cui la destinazione sia una pagina diversa è sufficiente assegnare l URL della pagina all attributo href, nel caso la destinazione sia un punto preciso all interno della pagina, il tag <a> viene usato anche per specificare la cosiddetta àncora. L ancora infatti rappresenta un punto all interno di una pagina identificata da un nome. In questo caso, il tag <a>, ammette un attributo name che conterrà l identificativo dell ancora. In questo caso il tag <a> è un tag vuoto. La Figura 3.6 riassume tutte queste alternative per la definizione di link tra due pagine. 11

99 <table> <tr> <td><!-- contenuto della cella 1,1 --></td> <td><!-- contenuto della cella 1,2 --></td> <td><!-- contenuto della cella 1,3 --></td> </tr> <tr> <td><!-- contenuto della cella 2,1 --></td> <td><!-- contenuto della cella 2,2 --></td> <td><!-- contenuto della cella 2,3 --></td> </tr> </table> Figura 3.7: Definizione di una tabella 2x3 Va sottolineato che l attributo href non necessariamente deve recare l URL di una pagina HTML ma, al contrario, può indicare una qualunque risorsa. In questo modo un link può essere usato per spostare il controllo verso un video, un file musicale, un documento RTF, o un indirizzo di posta elettronica Tabelle Le tabelle sono un elemento fondamentale per la progettazione delle pagine HTML. Sebbene il loro utilizzo inziale fosse solo rivolto alla presentazione di dati in forma schematica, le tabelle sono spesso utilizzate per organizzare anche gli elementi grafici. Una tabella, per definizione è un insieme di righe e di colonne, il cui numero, non è dichiarato esplicitamente, ma derivato dall organizzazione dei tag che definiscono i componenti della tabella stessa. Introducendo la sintassi attraverso l esempio di Figura 3.7, il tag <table> definisce una tabella in HTML e raggruppa una serie di tag <tr> uno per ogni riga che costituisce la tabella. A sua volta, ogni riga è composta da una serie di tag <td> in grado di definire le celle della tabella. In questo caso è facile intuire che il numero di righe sia 2, mentre le colonne siano 3. È importante sottolineare che il contenuto delle celle di una tabella è definito solamente all interno del tag <td>. Allo scopo di dare risalto ad una delle righe di una tabella, anziché utilizzare il tag <tr>, è possibile utilizzare il tag <th> che permette di definire la riga secondo uno stile diverso, che viene solitamente utilizzato per la prima riga che costituisce l intestazione della tabella. 12

100 <form name="form1" method="post" action=""> <p>user: <input name="user" type="text" id="user"></p> <p>password: <input name="pwd" type="text" id="pwd"></p> <p><input type="submit" name="submit" value="invia"></p> </form> Figura 3.8: Definizione di una form Form Una applicazione Web si distingue da un semplice sito Web per il fatto che è possibile instaurare una conversazione tra l utente e il Web Server. Nel caso di un sito statico, come discusso nell introduzione, il ruolo del client è semplicemente limitato alla richiesta di pagine e, di conseguenza, il ruolo del Web Server è quello di inviare le pagine richieste. Nel caso di applicazioni Web, quindi pagine dinamiche, il client può anche inviare informazioni che permettono al Web Server di attivare le proprie funzionalità ed eventualmente restituire il risultato delle stesse secondo una serie di pagine personalizzate. Le form, in HTML, permettono appunto al client di inserire e comunicare al Web Server le informazioni richieste dall applicazione. In linea generale una form è costituita da uno o più elementi in grado di memorizzare informazioni e da un pulsante che impacchetta queste informazioni e, in conformità con il protocollo HTTP, le spedisce al Web Server. Dal punto di vista sintattico la Figura 3.8 mostra una tipica form utilizzata per l autenticazione secondo la coppia nome utente e password. Come ovvio, il tag <form> identifica la form; essa racchiude una serie di tag <input> ognuno dei quali corrisponde ad un particolare sistema di inserimento dati. A seconda del valore assegnato all attributo name del tag input è possibile avere, tra gli altri: type = text per la creazione di una casella di testo; type = checkbox per la creazione di una casella a scelta multipla; type = radiobutton per la creazione di una casella a scelta singola; type = submit per la creazione di un pulsante di invio; type = reset per la creazione di un pulsante di ripristino; 13

101 type = hidden utilizzato per la gestione di informazioni controllate dall applicazione. Ai parametri è possibile associare un valore predefinito utilizzando l attributo value. Al di là degli elementi che è possibile inserire in una form, è di fondamentale importanza soffermarsi sugli attributi del tag form. L attributo action, infatti, definisce attraverso un URL chi è in carico di analizzare i dati. A seconda della tecnologia server utilizzata, questo attributo può riferirsi a sistemi CGI, pagine ASP, o pagine JSP. In ogni caso, ciò che avviene a fronte di una richiesta di submit, è l impacchettamento delle informazioni inserite dall utente e il loro invio all URL indicato secondo il protocollo specificato nell attributo action. Questo attributo, infatti, ammette due valori: GET e POST. Tali valori riflettono i due modi supportati da HTTP per la spedizione di dati. Nel primo caso i dati vengono accodati all URL della pagina indicata nell attributo action nella forma url?nome_parametro1=valore_parametro1& nome_parametro2=valore_parametro2} dove: nome parametro è il nome associato al tag <input>; valore parametro è il valore inserito dall utente. Nel secondo caso, metodo POST, i dati vengono inglobati all interno del corpo del messaggio e non sono visibili direttamente, con il vantaggio di poter inviare una maggiore quantità di informazioni. Attraverso il metodo GET, infatti possibile inviare al massimo 1024 byte e solo dati in formato testo. Con il metodo POST, al contrario, possibile inviare anche immagini e contenuti multimediali complessi quali audio, immagini e video. 3.4 JavaScript Le pagine HTML costruite secondo il linguaggio presentato nel paragrafo precedente possono essere arricchite con semplici script. Solitamente, questi script, sono rivolti alla validazione di dati inseriti all interno della pagina stessa, oppure alla richiesta di conferma di invio di dati al server. JavaScript rappresenta uno dei linguaggi al momento disponibili a questo scopo. Con una sintassi vicina al linguaggio Java, in JavaScript sono presenti alcuni 14

102 oggetti che permettono di interagire con gli elementi della pagina. Si hanno quindi a disposizione oggetti quali: document, form, ecc. Il codice JavaScript è inglobato all interno della pagina HTML e delimitato dal tag <script>. Uno script è eseguito al lato client e invocato per due motivi: è richiamato da un altro script; è intercettato l evento a cui lo script è associato. In particolare, gli eventi definiti e possibili sono i seguenti: onabort (interruzione caricamento immagine) onclick onchange (cambia il valore di un elemento) onerror onload onmouseover onreset onselect (selezione di un elemento di input) onsubmit onunload 3.5 Gestione delle sessioni Web Una sessione rappresenta un singolo uso coerente di un sistema Web e richiede solitamente l accesso a diverse pagine e una forte interazione con la logica applicativa del sistema. La realizzazione di sessioni è abbastanza complessa a causa della natura stateless del protocollo HTTP. Al termine dell esecuzione di una richiesta HTTP, il Web server chiude la connessione verso il browser e non esiste un meccanismo semplice che consenta di tener traccia dello stato del client che sta utilizzando il sistema per associare la richiesta corrente alle precedenti. Per risolvere questo problema il W3C ha introdotto un meccanismo per la gestione dello stato nel client: i cookie. 15

103 Un cookie è un insieme di dati memorizzati, su richiesta del Web server, sul client. I dati vengono forniti dal browser ad ogni richiesta HTTP. La specifica ammette una dimensione massima di 4 KByte, ed i seguenti parametri: nome del cookie; valore del cookie; scadenza, indica il tempo di sistema in secondi per cui il browser dovrà mantenere il cookie; dominio di appartenenza del cookie; percorso, espresso come path nel dominio; richiesta di connessione sicura, fa sì che i dati del cookie vengano trasmessi attraverso una connessione sicura. Un server richiede al browser di memorizzare i cookie aggiungendo all intestazione HTTP delle linee del tipo: Set-Cookie: sessionid=12345; path=/; expires 8/6/2005 Set-Cookie: totalecarrello=0; path=/; expires 8/6/2005 Se il browser è configurato per accettare i cookie queste stringhe vengono accettate e memorizzate sul client in una posizione dipendente dallo specifico browser. Alla successiva richiesta il browser invierà nella richiesta HTTP la seguente stringa: Cookie: sessionid=12345; totalecarrello=0 Se il dominio non è impostato esplicitamente, viene considerato come dominio il nome di domino completo del documento che ha creato il cookie. Il cookie viene trasmesso solo quando il browser richiede l accesso ad una risorsa appartenente al dominio ed al percorso specificato nel cookie. In questo modo un server del dominio non potrà impostare un cookie valido per I cookie costituiscono un meccanismo base con cui è possibile realizzare sessioni Web. Il mantenimento dello stato di una sessione può essere realizzato in quattro modi diversi: 1. inserimento di tutte le variabili di stato nei cookie; 16

104 2. inserimento di una chiave univoca in un cookie e suo utilizzo con un dizionario gestito dal server; 3. inclusione di tutti i valori delle variabili di stato come parametri inseriti nella richiesta HTTP; 4. inclusione di una chiave univoca come parametro in ogni richiesta HTTP. La prima soluzione è molto semplice, tuttavia esistono delle limitazioni dovute dalla massima dimensione dei cookie (4 KByte) ed al massimo numero di cookie che possono essere associati ad uno stesso dominio (20 cookie). Inoltre, i dati possono essere rappresentati unicamente come stringhe di testo e non è possibile utilizzare oggetti strutturati per mantenere lo stato della sessione. La limitazione reale è dovuta comunque dal fatto che le impostazioni di sicurezza dei browser possono impedire l uso dei cookie. Pertanto è possibile adottare soluzioni che si basano su cookie in sistemi Intranet mentre il loro utilizzo è meno auspicabile, per le considerazioni svolte nel Capitolo 2, nei sistemi di e-commerce o ambienti Internet. La seconda soluzione prevede di memorizzare sul client il cookie contenente l identificatore di un oggetto che viene gestito dal Web server e che memorizza lo stato della sessione. In questo modo vengono superati i problemi di dimensione e numero di cookie per dominio e la rappresentazione dello stato è di più alto livello, non si ha cioè una rappresentazione piatta dell informazione di stato come nel primo caso. Restano comunque aperti i problemi sulle impostazioni del browser ed inoltre al termine di una sessione le risorse allocate sul server per la memorizzazione dello stato devono essere liberate (vengono introdotti meccanismi di time out delle sessioni per eliminare informazioni di sessioni che non si sono concluse correttamente). La soluzione alternativa all uso dei cookie consiste nell utilizzare alcuni parametri nascosti che vengono inseriti nelle form inviate all utente, che verranno rimandati al server con le richieste successive. Nella soluzione tre e quattro ogni richiesta HTTP viene generata dinamicamente in modo da includere nei parametri lo stato della sessione o, come nel caso precedente l identificatore dell oggetto di sessione (si faccia riferimento al paragrafo 3.3.5). I parametri possono essere inviati utilizzando sia il metodo POST che il metodo GET. In questo ultimo caso le URL verranno generate dinamicamente in modo da includere nei parametri le variabili di stato o l identificatore dell oggetto di sessione (meccanismo di rendirizzamento delle URL). 17

105 Esempio 1) Personalizzazione di un sito Web Il sito consente all utente di scegliere la combinazione dei colori delle pagine. Il tema default è caratterizzato dal colore bianco per lo sfondo e colori più scuri, come nero o blu per i testi. Sono inoltre utilizzati altri colori per rendere più gradevole la veste grafica delle pagine. Il tema contrasto è caratterizzato dal colore nero per lo sfondo e colori più chiari, come giallo o bianco per i testi così da facilitare la lettura grazie a contrasti molto forti. La gamma cromatica e gli elementi grafici sono stati ridotti per semplificare la fruizione dei contenuti. Il tema relax, infine, è caratterizzato da colori pastello poco luminosi con contrasti più morbidi. Anche per questo tema sono stati ridotti la gamma cromatica e gli elementi grafici per semplificare la fruizione dei contenuti. È possibile memorizzare questa informazione in un cookie che memorizza convenzionalmente ad esempio i valori 1, 2, 3, corrispondenti rispettivamente ai tre tipi di temi, oppure trasmettere la scelta effettuata a ogni interazione con il sito web come parametro nascosto nelle form che vengono fatte compilare all utente nell ambito delle normali interazioni con il sito. Esempio 2) Prenotazione spettacolo Si vuole realizzare un sito di prenotazione on line per i clienti abbonati di un cinema. Gli utenti dovranno indicare il giorno dello spettacolo e il tipo di abbonamento; l abbonamento dà diritto a un prezzo scontato, variabile con le fasce orarie. Si supponga che siano disponibili gli spettacoli illustrati in Tabella 3.5. L utente prima sceglie la giornata desiderata, indicando l abbonamento di cui usufruisce, e ottiene l elenco degli spettacoli disponibili, che successivamente può prenotare indicando il numero dei posti (Figura 3.9). L utente ha la sensazione di utilizzare il sito nell ambito di un unica sessione di prenotazione, e al momento della scelta dello spettacolo suppone che il sistema ricordi che questa scelta è operata per un certo giorno e per un certo tipo di abbonamento. D altra parte, come illustrato nel paragrafo precedente, il collegamento al sito avviene tramite una sequenza di richieste HTTP di accesso a pagine del sito, che vengono generate in modo indipendente l una dall altra. Per gestire la sessione in questo caso esaminiamo le quattro possibilità indicate in precedenza. Soluzione 1 - Dati e cookie In questo caso non verrà memorizzata lato server alcuna informazione sulla sessione in corso. Nei cookie restituiti al 18

106 Figura 3.9: Pagine della sessione prenotazione biglietti 19

107 Tabella 3.2: Esempio prenotazioni on line Cod- Data Ora Titolo Prezzo Prezzo spett abb. A abb. B Film100 23/03/ Film1 7 5 Film101 23/03/ Film1 8 6 Film102 23/03/ Film2 7 Non disp.... Tabella 3.3: Oggetto di stato lato server IDsess Data Abbonamento /03/2005 A /03/2005 B client verranno inserite le informazioni necessarie a proseguire la sessione (data e abbonamento), insieme alla pagina web che consente di effettuare le prenotazioni. Questa soluzione può essere utile per memorizzare la tipologia di abbonamento anche al di là della singola prenotazione, e riconoscere successivamente il cliente come un abbonato di tipo A. Soluzione 2 - Identificativo di sessione e cookie In questo caso viene creato un identificativo di sessione (123 nell esempio di Tabella 3.5) e vengono memorizzate lato server le informazioni necessarie a gestire le successive richieste dell utente. Vengono memorizzati lato server l identificativo della sessione e la data (si faccia riferimento alla Tabella 3.5), che potranno essere memorizzati nella base di dati o in oggetti applicativi lato server, come verrà discusso nel seguito. Al client viene inviato il cookie che contiene l identificativo di sessione 123, con una scadenza. La scadenza potrà essere utilizzata per limitare la durata della sessione alla giornata in corso. In questo modo l utente, ricollegandosi nella stessa giornata, verrà riconosciuto e potrà proseguire nell operazione, altrimenti ricomincerà la selezione dello spettacolo con un altra sessione. Soluzione 3 - Dati e parametri Analogamente a quanto descritto nella soluzione 1, le variabili di stato di sessione vengono gestite tramite parametri nascosti. In questo caso le informazioni vengono tutte inserite come parametri nella seconda form di prenotazione. Questa soluzione è attuabile 20

108 per dati di dimensioni limitate, in quanto comporta un appesantimento nelle interazioni tra client e server, poiché richiede il trasferimento ripetuto dei dati e la loro gestione dall applicazione a ogni richiesta inviata al server. Soluzione 4 - Identificativo di sessione e parametri Come nella soluzione 2, viene creato un identificativo di sessione e i dati relativi vengono memorizzati lato server. Viene inserito un parametro nascosto nella seconda form. Questo parametro verrà inviato unitamente ai parametri inseriti esplicitamente dall utente nella seconda form (scelta film e numero di posti), consentendo di gestire correttamente la richiesta di prenotazione. 3.6 Servlet Una servlet è un componente Java definito dalle specifiche J2EE che può essere eseguito da un Web server Java-enabled per l implementazione di nuovi servizi. Le servlet sono state concepite per realizzare in tecnologia Java il middle tier che, come discusso nel capitolo precedente, consente l accesso da parte dei client ai servizi di back end ed implementa le regole di business. Le servlet costituiscono anche uno dei meccanismi più utilizzati per la creazione di pagine Web dinamiche e consentono inoltre di realizzare molte altre funzionalità tra cui: Forward delle richieste ad altri server e gestione delle connessioni: le servlet possono implementare i meccanismi di load balancing (a livello applicativo, ossia a livello 7 del modello ISO/OSI) e partizionamento funzionale di sistemi RAPS. Una servlet può inoltre mantenere più connessioni aperte verso processi client riducendo il numero di connessioni (onerose dal punto di vista delle prestazioni) verso i sistemi di DBMS. Proxy per le applet: una applet eseguita da un browser può, per ragioni di sicurezza, stabilire delle connessioni solo verso il Web server da cui è stata scaricata. Se l applet richiede l accesso ad un servizio o DBMS disponibile su una macchina diversa dal Web server, la servlet può realizzare la connessione per l applet ed assume quindi il ruolo di proxy. Personalizzazione o realizzazione di nuovi protocolli: le servlet consentono di estendere i protocolli Internet esistenti (come ad esempio SMTP, FTP, POP, ecc.) o di realizzare nuovi protocolli. Essenzialmente, ogni protocollo che si basa sul meccanismo richiesta/risposta può essere realizzato attraverso una servlet. 21

109 L esecuzione delle servlet può avvenire all interno del processo del Web server oppure all interno di processi specializzati chiamati Servlet Engine o Servlet Container. Se l esecuzione avviene all interno del Web server la comunicazione è più efficiente, mentre l adozione di Servlet Engine consente di adottare un maggiore numero di tier fisici (si faccia riferimento al capitolo 2). Le servlet temporanee vengono lanciate e fermate per ogni richiesta dei client, come accadeva per gli script CGI. Viceversa, le servlet permanenti vengono mantenute attive finchè il Web server che le esegue non viene riavviato e quindi possono, durante il loro ciclo di vita, soddisfare più richieste applicative. Le servlet temporanee sono un ottimo meccanismo per risparmiare risorse e fornire servizi di uso poco frequente. Servlet permanenti vengono utilizzate se il tempo di start-up è elevato (per esempio se è necessario stabilire una connessione con un DBMS), oppure se è necessario realizzare una funzionalità permanente (ad esempio un servizio accessibile attraverso Remote Method Invocation) oppure se è necessario rispondere ai client nel più breve tempo possibile. La configurazione della servlet come temporanea o permanente è stabilita dall amministratore del sistema definendo un opportuno parametro di configurazione della servlet nel web server nella fase di deployment. Un Web server comunica con le servlet attraverso i metodi definiti nell interfaccia javax.servlet.servlet, costituita principalmente dai metodi init(), service() e destroy(). Quando una servlet viene attivata, viene invocato il metodo init() che consente alla servlet di compiere le operazioni di inizializzazione come ad esempio stabilire connessioni permanenti verso altri server oppure effettuare l apertura dei file. Se la servlet è permanente il metodo init() viene invocato all avvio del Web server, se la servlet è temporanea invece il metodo init() viene eseguito per ogni richiesta dei client. Viene garantito che l esecuzione del metodo init() abbia termine prima che venga iniziata l esecuzione di una qualsiasi altra chiamata alla servlet. Nelle servlet permanenti, il metodo init() viene invocato una sola volta a meno che la servlet non venga riavviata. Il metodo service() è il cuore della servlet. Una qualsiasi richiesta da parte di un client viene tradotta in una invocazione a service(). Richiesta e risposta vengono scambiate attraverso due oggetti passati come parametro che appartengono alle classi ServletRequest e ServletResponse rispettivamente. È importante considerare che più invocazioni al metodo service() possono essere eseguite contemporaneamente. Pertanto se il metodo service() richiede l accesso a risorse esterne come file, database o applicazioni legacy ad esempio, è necessario garantire che l esecuzione concorrente non dia luogo alle problematiche della programmazione parallela come ad esempio stallo o corse critiche (si faccia riferimento ai testi specializ- 22

110 zati sull argomento), ossia è necessario garantire che l esecuzione del metodo service() sia thread-safe. Il metodo destroy() infine viene richiamato per permettere alla servlet di rilasciare le risorse di sistema (file aperti, connessione verso altri server) prima che la sua esecuzione abbia termine. Il Web server tipicamente attende la terminazione di eventuali metodi service() prima di invocare destroy(); l esecuzione di un metodo destroy() prima della terminazione di un metodo service() può generare errore. L esempio riportato in Figura 3.10 implementa una servlet che genera una pagina HTML dinamica. Il browser invia al Web server una form HTML in cui l utente ha indicato il proprio nome. Il Web server invocherà successivamente il metodo service() della servlet. La pagina HTML verrà generata dinamicamente ed inviata poi dal Web server al browser richiedente. Il metodo getparameter() della classe ServletRequest accetta come parametro una stringa che identifica un parametro della form HTML e ne restituisce il valore anch esso di tipo stringa (i valori numerici dovranno pertanto essere convertiti opportunamente). La pagina HTML visualizzerà pertanto il nome che l utente ha indicato nella form. Il package javax.servlet.http contiene inoltre diverse classi che semplificano la realizzazione di pagine dinamiche attraverso le servlet. La classe HTTPServlet fornisce un implementazione del metodo service() che inoltra la richiesta HTTP a metodi come doget(), dopost() che sono specializzati a elaborare richieste HTTP rispettivamente di tipo GET e POST. Un esempio relativo all utilizzo dell interfaccia HttpServlet è fornito in Figura Il lettore che ha familiarità con lo sviluppo delle applet Java ha sicuramente riconosciuto una stretta corrispondenza tra servlet e applet (anche le applet ad esempio hanno i metodi init() e destroy() mentre il corrispondente del metodo service() è il metodo start()). La corrispondenza si ha anche per quanto riguarda i meccanismi per la sicurezza. Così come il browser può impedire ad una applet di accedere a file locali ad esempio, anche il Web server può limitare le operazioni eseguite dalle servlet. L esigenza di fornire meccanismi di sicurezza nasce dal fatto che una servlet può provenire da varie sorgenti (può essere scritta dal webmaster, può essere acquistata, oppure può essere stata scaricata da un altro sito). Sulla base della provenienza della servlet è necessario associare alla servlet un certo livello di fiducia. Il meccanismo di sicurezza implementato per le servlet è noto come sandboxing che verrà ripreso più in dettaglio nel capitolo 5. Una sandbox è un area in cui alle servlet viene assegnato un autorità limitata per accedere alle risorse del server. Per esempio è possibile negare alle servlet l accesso al file system o alla rete a meno che non venga concesso un livello (stato) di autorizzazione superiore. È necessario considerare che una servlet a cui 23

111 import java.io.*; import javax.servlet.*; public class SampleServlet implements Servlet { private ServletConfig config; //config stabilisce lo stato della configurazione iniziale //della servlet public void init (ServletConfig config) throws ServletException { this.config = config; } public void destroy() {} // in questo caso non necessario rilasciare risorse public void service (ServletRequest req, ServletResponse res ) throws ServletException, IOException { res.setcontenttype( "text/html" ); PrintWriter out = res.getwriter(); out.println( "<html>" ); out.println( "<head>" ); out.println( "<title>una Servlet di esempio</title>" ); out.println( "</head>" ); out.println( "<body>" ); out.println( "<h1>una pagina Web generata dinamicamente</h1>" ); out.println( "<p>benvenuto nel sistema " +req.getparameter("nomeutente")+ "</p>" ); out.println( "</body>" ); out.println( "</html>" ); out.close(); } } Figura 3.10: Generazione di pagine dinamiche attraverso servlet 24

112 import java.io.*; import javax.servlet.http.*; public class SampleHttpServlet implements HttpServlet { public void doget(httpservletrequest req, HttpServletResponse res ) throws ServletException, IOException { ); } res.setcontenttype( "text/html" ); PrintWriter out = res.getwriter(); out.println( "<html>" ); out.println( "<body>" ); out.println( "<p>servlet invocata con il metodo GET</p>" out.println( "</body>" ); out.println( "</html>" ); out.close(); public void dopost(httpservletrequest req, HttpServletResponse res ) throws ServletException, IOException { ); } } res.setcontenttype( "text/html" ); PrintWriter out = res.getwriter(); out.println( "<html>" ); out.println( "<body>" ); out.println( "<p>servlet invocata con il metodo POST</p>" out.println( "</body>" ); out.println( "</html>" ); out.close(); Figura 3.11: Esempio di HttpServlet 25

113 è stato assegnato il massimo livello di autorizzazione ha accesso completo alle risorse del server e della rete e può anche bloccare l esecuzione del Web server Gestione delle sessioni nelle servlet Le classi di supporto alla gestione delle sessioni che possono essere utilizzate con le servlet sono Cookie e HTTPSession. La classe HTTPSession è più semplice da utilizzare, tuttavia non consente la condivisione delle informazioni attraverso istanze multiple del browser di uno stesso utente. Un cookie deve essere creato ed associato ad una risposta HTTP e verrà fornito in seguito come parte dell header HTTP di tutte le richieste successive. Ad esempio, è possibile memorizzare il totale del carrello attraverso il cookie TOTALE CARRELLO. Il metodo service della servlet che realizza la funzionalità di selezione di un item nel carrello inizializzerà i dati della sessione attraverso le seguenti linee di codice: float totalecarrello=0;... Cookie c=new Cookie("TOTALE_CARRELLO", Float.toString(totaleCarrello)); response.setcontenttype("text/html"); response.addcookie(c); È necessario osservare che i cookie memorizzano stringhe e pertanto i valori numerici devono essere convertiti esplicitamente. Richiamare il valore di un cookie è leggermente più complesso. Il metodo getcookies() della classe ServletRequest infatti restituisce tutti i cookie del dominio memorizzati sul client. È necessario allora ricercare uno specifico cookie nell elenco fornito. Inoltre più cookie sul client possono avere lo stesso nome pertanto è necessario garantire a livello applicativo l univocità dei cookie. Il codice seguente individua il valore del cookie TOTALE CARRELLO: Cookie c = null; Cookie cookies[] = request.getcookies(); if (cookies!= null) { for(int i=0, n=cookies.length; i < n; i++) { c = cookies[i]; if (c.getname().equals(totale_carrello)) { try { sum = Float.parseFloat(c.getAttribute()); } catch (NumberFormatException ignored) { sum = 0; 26

114 } } } break; } Le servlet consentono la gestione delle sessioni anche attraverso la classe HTTPSession. La sessione corrente viene restituita invocando il metodo get- Session() della classe HTTPServletRequest, una specializzazione della classe ServletRequest definita nel package javax.servlet.http. Le variabili di stato della sessione possono essere richiamate o modificate invocando rispettivamente i metodi getattribute() e putattribute(). Il seguente esempio effettua l aggiornamento del totale del carrello in seguito all inserimento di un nuovo item: Float totalecarrello = (Float) (session.getattribute ("TOTALE_CARRELLO")).floatValue(); totalecarrello= totalecarrello+newitem.getprice(); session.putattribute ("TOTALE_CARRELLO", totalecarrello); 3.7 JSP (Java Server Pages) Le Java Server Pages possono essere considerate un evoluzione della tecnologia servlet, il cui obiettivo è realizzare pagine dinamiche separando la progettazione dell interfaccia grafica dalla logica applicativa che ne genera il contenuto. Ciò consente di separare i compiti di web designer e degli sviluppatori, che dispongono di conoscenze e competenze profondamente diverse, e di semplificare lo sviluppo e la manutenzione delle applicazioni Web. I designer possono ad esempio ridefinire il layout di una pagina senza che ciò richieda modifiche al codice che ne genera il contenuto dinamico. Gli sviluppatori possono invece realizzare codice che può essere facilmente modificato e riusato da applicazioni, e molto frequentemente, da pagine differenti. Le pagine JSP sono state definite da Sun Microsystem e sono parte integrante delle specifiche J2EE; la tecnologia ASP (Active Server Pages) ha caratteristiche molto simili a JSP e si inserisce all interno della piattaforma.net proposta da Microsoft. Una pagina JSP è essenzialmente una pagina HTML che contiene parti aggiuntive per l esecuzione della logica applicativa che genera il contenuto dinamico. Per realizzare ad esempio un accesso ad un DBMS, il codice HTML della pagina JSP definisce la formattazione della parte statica della pagina, mentre l accesso al DBMS può essere realizzato attraverso l invocazione di un metodo di un oggetto. Come con le servlet, al browser viene restituita una pagina HTML. 27

115 Poiché nelle servlet i tag HTML devono essere scritti come parte del codice di una classe (si faccia riferimento alla Figura 3.10), se la presentazione di un applicazione Web deve essere modificata è necessario allora modificare il codice che la genera e ricompilare il codice sorgente delle servlet. Dato che i Web designer non hanno la stessa dimestichezza degli sviluppatori con la scrittura e compilazione del codice, con le servlet il cambiamento di una pagina Web richiede la partecipazione di più soggetti e la modifica risulta dispendiosa in termini di tempi di sviluppo. Figura 3.12: Processo di compilazione di una pagina JSP Le pagine JSP sono state proposte per risolvere questo problema come un estensione delle API delle servlet. Una JSP viene compilata in una servlet prima di essere utilizzata (si faccia riferimento alla Figura 3.12). Il primo accesso ad una pagina JSP implica che la pagina JSP venga compilata in una servlet. I successivi accessi alla pagina verranno supportati direttamente dalla servlet, che restituisce al client la pagina HTML richiesta. Il processo di compilazione è completamente trasparente, in caso di modifica da parte di un Web designer, la pagina JSP viene ricompilata automaticamente al primo accesso. Sebbene le pagine JSP siano un meccanismo di alto livello per la creazione di servlet, esse presentano ulteriori vantaggi: è possibile combinare in modo semplice template statici (HTML, XML) 28

116 e componenti (ad esempio JavaBean o EJB) per la generazione dinamica dei contenuti; l accesso alla logica applicativa può avvenire attraverso tag in una sintassi XML-like che maschera ai web designer la complessità di accesso ai componenti ed i dettagli di basso livello del codice; gli sviluppatori implementano componenti che possono essere riutilizzati all interno di altre pagine o applicazioni; i Web designer possono modificare la presentazione senza conseguenze sulla logica applicativa e gli sviluppatori possono effettuare modifiche alla logica applicativa senza dover modificare le singole pagine Elementi delle pagine JSP Le pagine JSP sono molto simili alle pagine HTML, entrambe infatti includono tag compresi tra parentesi angolari, tuttavia le pagine HTML vengono processate dai browser, mentre le pagine JSP vengono eseguite dai Web server per la generazione dinamica dei contenuti. I tag delle pagine JSP possono inoltre definire operazioni come ad esempio l invocazione di un metodo oppure introdurre scriptlet, blocchi di codice Java che verranno eseguiti al momento della richiesta della pagina. Le possibili componenti di una pagina JSP sono le seguenti: direttive: istruzioni eseguite dal JSP Engine espressioni: placeholder (segnaposti), variabili o espressioni Java che vengono valutate dinamicamente scriptlet: blocchi di codice inseriti all interno della pagina JSP dichiarazioni: definiscono variabili che poi vengono utilizzate in espressioni e scriptlet commenti: stringhe che vengono ignorate dal JSP engine azioni: oggetti finalizzati ad un migliore incapsulamento del codice (utilizzati principalmente per l uso di componenti) Le direttive sono istruzioni che vengono processate al momento della compilazione della pagina JSP in una servlet. Le direttive sono introdotte per importare opportune librerie di linguaggio oppure per includere file. Le direttive vengono definite all interno della coppia <@ 29

117 Le dichiarazioni JSP sono simili alla dichiarazione di variabili nei linguaggi di programmazione e vengono utilizzate per definire variabili che vengono usate poi all interno di espressioni e scriptlet. Le dichiarazioni vengono definite all interno di <%! e %>. Le espressioni sono istruzioni che vengono considerate come dei placeholder per variabili o espressioni Java che vengono valutate a tempo di e- secuzione. Le espressioni vengono utilizzate per inserire valori direttamente nella pagina HTML di output e sono comprese tra la coppia <%=, %>. Ad esempio il valore della variabile nomeutente può essere inserita in una pagina HTML attraverso l espressione <%=nomeutente%> oppure il risultato dell invocazione del metodo calcolatotalecarrello() del componente carrello può essere visualizzato mediante l espressione <%=carrello.calcolatotalecarrello()%>. In generale, le espressioni vengono valutate ed il loro risultato viene convertito in stringa e inserito nella pagina. Espressioni e le scriptlet hanno accesso oltre che alle variabili anche ad un insieme di oggetti predefiniti tra cui i principali sono: request, response, session, application e out. Gli oggetti session e application verranno discussi nel prossimo paragrafo. L oggetto request viene utilizzato per accedere all intestazione della richiesta HTTP (per esempio per stabilire se i parametri vengono ottenuti attraverso GET o POST). I metodi principali dell oggetto request sono getparameter() che, come per l esempio visto per le servlet, consente di accedere al valore di un parametro specificato in una form HTML, ed il metodo getcookies() che restituisce l array dei cookie salvati sul client. L oggetto response invece viene utilizzato per specificare le proprietà della pagina fornita come risposta come per esempio le dimensioni del buffer utilizzato per la trasmissione response.setbuffersize() oppure per forzare la trasmissione di una pagina creata parzialmente (response.flushbuffer()). Infine l oggetto out viene utilizzato per stampare output sulla pagina Web (corrisponde all oggetto System.out del linguaggio Java). Ad esempio le due espressioni <%=nomeutente%> e <%=out.print(nomeutente)%> sono equivalenti. Le scriptlet sono blocchi di codice Java inseriti all interno della pagina JSP, che consentono di specificare codice più complesso rispetto a quanto esprimibile con le sole espressioni. Le scriptlet vengono definite all interno di <% e %> ; sono ammessi i costrutti di base tipici della programmazione strutturata nella sintassi Java come if-then-else, while-do, switch, ecc. ed è possibile accedere agli oggetti predefiniti descritti in precedenza. Anche se fanno parte della specifica, l uso di scriptlet all interno delle pagine JSP è sconsigliato poiché in questo modo si perdono gli obiettivi che hanno portato 30

118 alla definizione dello standard: la separazione tra la struttura grafica della pagina ed il codice che genera i contenuti. I commenti possono essere inseriti ovunque all interno della pagina JSP e vengono racchiusi all interno di <%-- e --%>. Può essere comunque utilizzata la sintassi dell HTML racchiudendo il commento nei tag <%!-- e --%>. Infine, le azioni (action) sono un meccanismo che consente di suddividere ulteriormente la logica applicativa dalla presentazione utilizzando componenti, come i JavaBean o gli EJB, e tag library. Una JSP può dichiarare l uso di un JavaBean attraverso l action <jsp:usebean id= nomebean class= package.class />. L esempio riportato in Figura 3.13 utilizza il JavaBean db oggetto della classe DbBean che consente di ottenere la descrizione dei libri selezionati dall utente del sito commercio elettronico per la vendita dei libri. L action <jsp:usebean id= db class= DbBean /> è equivalente alla scriptlet <% DbBean db = new DbBean() %>. La pagina di esempio include un intestazione ed un piè di pagina che vengono ottenute attraverso la direttiva di include dei due file header.html e footer.html. La pagina JSP viene generata a partire da una form che invia come parametri la login dell utente e l insieme dei libri selezionati durante la sessione Web. Tali informazioni vengono ottenute dall oggetto request. Se effettivamente dei libri sono stati selezionati durante la navigazione allora ne verrà visualizzata la descrizione altrimenti verrà visualizzato un messaggio di errore che indica che nessun libro è stato selezionato Implementazione del pattern MVC attraverso JSP La specifica JSP prevede due alternative architetturali per lo sviluppo delle applicazioni conosciute come Model 1 e Model 2. Il Model 1 è riportato in Figura La richiesta del browser viene inviata direttamente alla pagina JSP che è responsabile della sua esecuzione. Esiste una separazione tra la presentazione e la generazione dinamica dei contenuti dato che l accesso ai data base avviene attraverso JavaBean, tuttavia l architettura è adeguata solo per semplici applicazioni e non è praticabile per implementazioni complesse. L uso indiscriminato dell architettura infatti può portare ad una grande porzione di codice Java implementato come scriptlet all interno della pagina JSP. Inoltre, in questo modo ogni pagina JSP è responsabile della gestione dello stato dell applicazione e la verifica dell autenticazione dell utente e sicurezza del sistema. L architettura Model 2 è riportata in Figura 3.15 ed implementa il pat- 31

119 page language="java" info="visualizzazione libri selezionati da un utente del sito di commercio elettronico" %> <html> <body> include file="header.html" %> <jsp:usebean id="db" class="dbbean" /> <%-- Gli identificatori dei libri selezionati dall utente sono inviati come parametri della form di accesso alla JSP--%> <%! String selections[]; %> <%-- login dell utente inviata come parametro della form di accesso alla JSP--%> <%! String nomeutente= request.getparameter(nomeutente);%> <p>selezioni dell utente:</p> <%=nomeutente%> <% <!-- insieme degli identificatori dei libri selezionati dall utente--> selections = request.getparametervalues("items"); if (selections!= null) { %><ul> <% for(int x = 0; x < selections.length; x++) { %><li> <!-- La descrizione di un libro viene ottenuta attraverso il metodo getinfo() che accetta come parametro l id del libro nel data base--> <%= selections[x] %> : <%= db.getinfo(selections[x]) %> <% } %></ul><% } else { %> <p>nessun libro stato selezionato</p> <% } %> <br> <%@ include file="footer.html" %> </body></html> Figura 3.13: Pagina JSP per la visualizzazione dei dettagli dei libri contenuti nel carrello 32

120 Figura 3.14: Architettura Model 1 tern MVC. La componente di presentazione (View) è realizzata dalla pagina JSP. Il Controller viene implementato attraverso una servlet che ha il compito di ricevere tutte le richieste HTTP e di effettuarne il dispatching. Sulla base cioè della richiesta del browser, il controller stabilisce se è necessario istanziare nuovi JavaBean che verranno poi utilizzati dalle pagine JSP oppure può scegliere la vista e quindi la pagina JSP a cui inoltrare le richieste. Lo stato dell applicazione viene gestito dal Model implementato attraverso JavaBean (o EJB). Figura 3.15: Architettura Model 2 33

121 Il vantaggio di questo secondo modello risiede nel fatto che non esiste logica applicativa all interno della componente di presentazione, la View realizzata come pagina JSP, che deve generare contenuti accedendo ai componenti ed inserendo i contenuti dinamici all interno di template statici. È pertanto possibile distinguere chiaramente i compiti ed i ruoli di Web designer e sviluppatori. Inoltre la servlet costituisce l unico punto di accesso all applicazione ed è responsabile dell autenticazione dell utente e della sicurezza del sistema. In questo modo l applicazione nel suo complesso risulta più semplice da gestire e modificare Gestione delle sessioni in JSP Le pagine JSP di default appartengono ad una sessione Web. È possibile avere accesso alle informazioni di stato di una sessione attraverso l oggetto session. L oggetto session viene identificato da un ID univoco memorizzato nel client dell utente attraverso i cookie. Le informazioni di stato vengono identificate attraverso una chiave univoca e memorizzate come oggetti (in modo strutturato quindi) all interno dell oggetto session; l oggetto session non può memorizzare tipi primitivi. La gestione del carrello con le pagine JSP avviene nel modo seguente: <% Carrello carrello = new Carrello(); session.putattribute("carrello", c); %> in questo modo l oggetto carrello è accessibile a più pagine JSP che appartengono alla stessa sessione. L istanza può essere richiamata all interno di una pagine JSP attraverso la seguente action: <% Carrello carrello = (Carrello) session.getattribute("carrello", c);; %> La chiamata di session.getattribute() restituisce il riferimento ad un generico Object è quindi importante effettuare il cast al tipo corretto prima di utilizzare un oggetto. La partecipazione di una pagina JSP ad una sessione non è comunque obbligatoria, l esclusione dell uso delle sessioni avviene attraverso la direttiva: <%@ page session = "false" %> Non esiste alcun limite al numero di oggetti che possono essere mantenuti in una sessione, sebbene l uso di oggetti di grandi dimensioni possa degradare le prestazioni. Di default la maggior parte dei server prevede che 34

122 Figura 3.16: Gestione delle sessioni in JSP una sessione abbia una durata massima di 30 minuti. È possibile stabilire la durata di una sessione attraverso l invocazione di session.setmaxinvalidationinterval(int secs). La Figura 3.16 riporta una rappresentazione della gestione delle sessioni in JSP. Gli oggetti possono essere condivisi da più pagine che appartengono alla stessa sessione, tuttavia questo non è l unico meccanismo supportato dalla tecnologia JSP. Gli oggetti possono essere creati esplicitamente attraverso le action o attraverso le scriptlet ed hanno uno scope che può essere specificato come attributo al momento della creazione. I possibili livelli di scope, ordinati con visibilità decrescente sono i seguenti: application: l oggetto è visibile da tutte le pagine che appartengono alla stessa applicazione; session: l oggetto è accessibile dalla pagina che ha creato l oggetto ma anche da tutte le pagine che appartengono alla stessa sessione e che verranno richiamate in seguito; request: l oggetto è accessibile dalle pagine che supportano l esecuzione di una stessa richiesta applicativa (viene utilizzato con il meccanismo di forward che inoltra una richiesta ad un altra pagina JSP); 35