Infrastrutture INFormatiche Ospedaliere 2 Corso di laurea di Ingegneria Medica. Indice 5. SISTEMI INFORMATIVI BASATI SU WEB...2

Transcript

1 Indice 5. SISTEMI INFORMATIVI BASATI SU WEB INTRODUZIONE EVOLUZIONE DELLE ARCHITETTURE INFORMATICHE CLASSIFICAZIONE DEI SISTEMI INFORMATIVI BASATI SU WEB Tipologia del servizio offerto Livello di interazione Tipologia di utenti ARCHITETTURE DEI SISTEMI WEB Configurazione one tier Configurazione two tier Configurazione three tier Sistemi n tier Application server Pattern architetturali per i client web VERSO LE ARCHITETTURE BASATE SUI SERVIZI Web Service /19

2 5. Sistemi informativi basati su web 5.1 Introduzione Fra i vari modi per rispondere alle sfide di una economia globale vi è quella di valorizzare l informazione e gli strumenti per gestirla. Per questa valorizzazione, lo strumento di Internet e del Web sono una buona risposta perché permettono di raccogliere, gestire in modo correlato e distribuire in vari formati una grande quantità di sorgenti informative. 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, basi di dati differenziate per modelli e tecnologie, reti di comunicazione e processi aziendali distribuiti e interconnessi. Un sistema informativo è un Insieme coordinato delle definizioni, delle classificazioni, delle procedure, degli strumenti, delle rilevazioni e degli indicatori mediante il quale si riesce a produrre e offrire informazioni in modi e tempi utili ai fruitori del sistema stesso. Le funzioni tipiche di un sistema informativo sono: (a) l'acquisizione di dati, (b) l'archiviazione di dati, (c) l'elaborazione dei dati, (d) la comunicazione e la diffusione del risultato delle elaborazioni. Per affrontare il complesso problema di gestione dei sistemi informativi, oggi si progettano e realizzano sistemi informativi informatici distribuiti, ovvero sistemi che permettono alle organizzazioni di distribuire e gestire l informazione in rete. I sistemi distribuiti, o meglio, cooperative (quando si parla di 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. Un sistema basato su Web è spesso definito come un insieme di applicazioni software, accessibile da parte di un insieme di client che interpreta il linguaggio html (browser) e che usa come protocollo di comunicazione il protocollo http. Vedremo in seguito che questa definizione non è esaustiva in quanto è possibile installare sul client delle applicazioni che aggiungono ulteriori funzionalità al browser. Un sistema informativo basato su web è dunque un sistema basato su web che gestisce un sistema informativo. La creazione dinamica di pagine HTML è un altro punto 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 aspetto è 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 caratterizzate sia da link statici sia da pagine statiche. Le applicazioni centrate sulla base di dati sono caratterizzate dalla creazione di pagine dinamiche, ma hanno una struttura dei link statica. 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. 2/19

3 5.2 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 (Information Comunication Tecnology). Le 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 quando i dati e le applicazioni risiedono in un unico nodo di elaborazione (Figura 5.1). Figura 5.1 Sistema informatico centralizzato. Viceversa, si parla di sistema informatico distribuito quando almeno una delle seguenti due condizioni è verificata (Figura 5.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 d applicazioni logicamente indipendenti che collaborano per il perseguimento d obiettivi comuni attraverso un infrastruttura di comunicazione hardware e software. Figura 5.2 Sistema informatico distribuito. 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 3/19

4 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 (mini e micro elaboratori, personal computer, reti locali di comunicazione, architetture client/server) sia nelle strutture di gestione dei dati versatili e facili da usare (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 quanto riguarda i sistemi informativi 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: 1. Il livello presentazione si occupa di gestire la logica di presentazione, quindi le modalità di interazione con l utente: contiene le modalità di interfacciamento (grafico) e di rendering delle informazioni. Questo livello è anche denominato front end delle applicazioni. 2. Il livello della logica applicativa o logica di business si occupa delle funzioni da mettere a disposizione all utente. 3. 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). Nei sistemi distribuiti, gli strati software sono installati su livelli hardware (detti tier), 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 unico tier, questa configurazione è quella classica terminale-host che caratterizzava i sistemi basati su mainframe; due livelli di distribuzione (two tiered): i livelli applicativi sono divisi tra la stazione di lavoro dell utente (tipicamente un personal computer) e il tier che ospita i dati (server dati). Sulla stazione di lavoro è realizzata la logica di presentazione e sul server dati quella d accesso ai dati; sono possibili scelte diverse per l allocazione della logica applicativa. 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 altrettanti tier dedicati, ovvero una stazione in cui risiede il front end, un tier per la logica applicativa (detto anche middle tier) e uno per la 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à e sicurezza che le moderne soluzioni distribuite non hanno ancora pienamente eguagliato. A seconda delle possibili ripartizioni dei tre livelli applicativi sui tier hardware fisici, si parla di configurazioni fat client se a livello utente si appoggia la logica applicativa e quella di accesso ai dati, piuttosto che thin client se a livello utente 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. Relativamente alla seconda configurazione (two tiered), sono possibili differenti architetture, in base alle modalità di allocazione dei tre layer applicativi, Le architetture differiscono in termini di: traffico 4/19

5 di rete, prestazioni e compiti eseguiti dalla stazione di lavoro e comportano livelli diversi di flessibilità e di facilità di modifica. Le architetture fat e thick 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ò aggiornare il client 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 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 numero più elevato di tier conferisce al sistema 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 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 anche soluzioni con più di tre tier. All inizio degli anni 90 i servizi Web venivano implementati su due tier, mentre gli attuali siti di e-business si sviluppano su 3 o più tier, ad esempio introducendo tier dedicati a supporto della comunicazione (middleware) 5.3 Classificazione dei sistemi informativi basati su web I sistemi informativi basati su Web possono essere classificati in base a: tipologia del servizio offerto, livello di interazione offerto agli utenti (semplice accesso informativo unidirezionale, oppure modifica dello stato di un applicazione Web). tipologia di utenti che possono accedere al sistema (interni, esterni o di altra natura) Tipologia del servizio offerto 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. 5/19

6 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. 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 Livello di interazione 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: 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 Tipologia di utenti Un altra 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 (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 gestione delle conoscenze sui processi aziendali. Serve principalmente a distribuire informazioni all interno dell azienda mediante news, interfacce di ricerca, e cataloghi di contenuti su cui è possibile effettuare il browsing. I servizi di 6/19

7 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, thick o fat a seconda dell applicazione. Sito Extranet: è accessibile da un gruppo di utenti ben identificato, ad esempio clienti e fornitori. E 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 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). 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 (figura 5.3). Il firewall è un dispositivo di sicurezza del sistema informativo che, 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. Figura 5.3 Protezione della Intranet aziendale attraverso firewall. 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 di meccanismi di certificazione e autenticazione degli utenti e di crittografia per la trasmissione dei dati. 7/19

8 Sito Internet Sito Intranet Sito Extranet Utenti Noti con approssimazione Dipendenti dell organizzazione Dipendenti di più organizzazioni Compiti Servizi informativi o di Supporto al lavoro dei Integrazione dei processi delle Larghezza di banda vendita dipendenti, gestione dei processi organizzazioni Bassa Alta, affidabile Alta, affidabile Compatibilità Quantità informazioni 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 Tabella Confronto di sistemi Internet, Intranet ed extranet. Scelta a priori della tecnologia della propria organizzazione, conoscenza tecnologia adottata dai partner Quantità elevate, integrazione della supply chain 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). 5.4 Architetture dei sistemi web Gli elementi essenziali di un moderno sistema Web sono: web server, che si occupa della gestione delle richieste HTTP provenienti da Internet o dalla Intranet aziendale; script engine, un processo che esegue script per la generazione di pagine HTML dinamiche; application server, che assume il ruolo di middle tier ed implementa la logica di business dell applicazione Web; DBMS server, che si occupa della gestione dei dati. Il web server (che assume il ruolo di primo tier applicativo) si colloca fisicamente tra l utente finale che accede al sistema attraverso il browser ed il sistema informativo aziendale. Il web server si occupa della presentazione delle informazioni verso i client e 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 livello applicativo che genera pagine dinamiche, nell architettura J2EE lo script engine è un servlet engine. Lo script engine genera pagine dinamiche interagendo con l application server o con il DBMS server. L elaborazione delle pagine dinamiche produce delle pagine html che vengono poi restituite al Web server che le inoltrerà successivamente all utente che ne ha fatto richiesta. 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 componenti e/o oggetti. Infine, come nei sistemi distribuiti tradizionali, il DBMS si occupa dell accesso e della gestione dei dati aziendali. A seguito di quanto illustrato, il problema di progettazione architetturale consiste nello stabilire: 8/19

9 il numero di tier fisici del sistema, ovvero consiste nel determinare quali 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. 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 one tier Configurazione one 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 5.4). 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 deattivazione 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 o nel database. Risultano invece molto più problematiche l affidabilità, dato che il malfunzionamento di un unico componente 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 che è limitata alla possibilità di upgrade della singola macchina (RAM, sostituzione CPU o dischi, ). L aspetto più critico dal punto di vista delle prestazioni risiede nel fatto che web server e DBMS sono due layer che richiedono molte risorse sia in termini di RAM che di tempo di CPU. Figura 5.4 Configurazione 1 tier Single Host. 9/19

10 Configurazione one tier con cluster Il modo più immediato per migliorare la configurazione con un tier è quello di usare un cluster in luogo del singolo host Un cluster è un gruppo di elaboratori (2 o più elaboratori) che viene identificato, dal mondo esterno, come un unico elaboratore (vedi figura 5.5) e viene utilizzato al fine di ottenere delle prestazioni migliori e di garantire un servizio più affidabile. Tipicamente le macchine del cluster cooperano con un tecnologia di load balancing (bilanciamento del carico), questo tecnologia ha il compito di garantire una equa ripartizione del carico di lavoro tra tutti gli elaboratori del cluster. Il load balancing oltre ha fornire un miglioramento delle prestazioni rende il sevizio più affidabile, se un elaboratore del cluster si guasta il load balancing suddivide il carico di lavoro tra gli elaboratori restanti senza provocare nessuna interruzione di servizio. Gli svantaggi dell utilizzo di un cluster sono legati ai problemi di gestione: i sitemi operativi per i cluster sono complicati da configurare e da manutenere. Figura 5.5 Configurazione one tier con cluster di due elaboratori Configurazione two tier Configurazione two tier two host In questa configurazione, web server e script engine sono ospitati su una stessa macchina mentre il database è in esecuzione su una macchina dedicata (figura 5.6). Inoltre, viene installato un secondo firewall che introduce un secondo dominio di sicurezza a protezione del DBMS. 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 (per il quale sono definite regole di accesso più restrittive del primo) ed il DBMS, 10/19

11 tempo che può essere utile al sistema di Intrusion Detection (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 sui due tier. Resta comunque critica la disponibilità del sistema, dato che è sufficiente il guasto di un componente per bloccare l intero sistema. Figura 5.6 Configurazione 2 tier Dual Host. Configurazione two tier con clusters 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 tier grazie all utilizzo di cluster realizzati con due o più nodi di elaborazione. Si possono prevedere sistemi ad alta affidabilità anche per la parte di storage 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 avere il limiti di upgrade tipicihe di una singola macchina. Come già detto sopra la replicazione infine consente di migliorare le prestazioni poiché il carico viene distribuito dai load balancer in modo bilanciato sui server attivi Configurazione three tier La figura 5.7 riporta lo schema architetturale di un sistema Web che viene adottato nei moderni centri di elaborazione dati. Nella figura sono stati riportati, a titolo puramente indicativo, dei cluster con due nodi di elaborazione per ogni tier, nella pratica il numero di cluster e di nodi di elaborazione per cluster vengono definiti caso per caso in funzione delle esigenze specifiche del sistema. 11/19

12 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 questo tier è protetto da un ulteriore livello di firewall e risiede fisicamente nella DMZ2, mentre Web server e Script engine, che si occupano della presentazione, risiedono nella DMZ di primo livello. Questa soluzione architetturale presenta il più alto livello di prestazioni, disponibilità e scalabilità, ma è una soluzione costosa e generalmente complessa da mantenere. Figura 5.7 Configurazione 3 tier con cluster per ogni tier. 12/19

13 Configurazione architetturale Vantaggi Svantaggi 1 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 2 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 2 tier con cluster Prestazioni: distribuzione del carico di lavoro sui server/ processi in modo bilanciato Scalabilità: se necessario, è possibile 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 3 tier con cluster Sicurezza: maggiore livello di sicurezza dovuto al terzo livello di firewall Prestazioni: load-balancing dinamico Scalabilità: se necessario, è possibile aggiungere nuove macchine server Disponibilità: capacità di fail-over a livello dei singoli oggetti 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 Complessità: ambienti generalmente molto complessi da configurare e da manutenere Tabella Vantaggi e svantaggi delle architetture Web 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 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. 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. 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. 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 (Application Program Interface) dell application server 13/19

14 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 Application server Un application server è un software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un contesto distribuito. Si tratta di un complesso di servizi orientati alla realizzazione di applicazioni per il web, multilivello ed enterprise, con alto grado di complessità. L'application server è composto da moduli realizzati secondo standard ben definiti ed accettati dalla comunità mondiale dei programmatori. Un esempio di tali standard è il protocollo HTTP, normalmente utilizzato per la trasmissione di informazioni sul web. Al suo interno, un application server disporrà quindi di componenti che consentono ad un'applicazione di lavorare facilmente con lo standard HTTP. I moduli normalmente presenti in un application server sono: contenitore di componenti server-side gestore degli accessi degli utenti e della sicurezza gestione accesso a database o in generale a sorgenti di dati esterne gestore transazioni interfaccia per l'accesso a sistemi legacy altri componenti per massimizzare le prestazioni, come connection pool, load balancer, caching, ecc. Tipicamente le tecnologie su cui si basano gli application server sono due: Microsoft.NET e Java di Sun. Tra le due, Java è nettamente più diffusa e accettata, e annovera numerose implementazioni sia commerciali che open source: JBoss, WebLogic, Geronimo, ecc. Gli standard di Java non sono unicamente frutto della Sun, ma sono il risultato di un rapporto sinergico tra l'azienda americana e la partecipazione libera di sviluppatori in tutto il mondo. Gli standard su cui si fonda la tecnologia.net sono invece stabiliti direttamente da Microsoft. Nel mondo Java, gli application server compatibili con le specifiche della Sun sono detti application server J2EE (Java 2 Enterprise Edition: è la versione "enterprise" della piattaforma java, è costituita da un insieme di specifiche che definiscono le caratteristiche e le interfacce di un insieme di tecnologie pensate per la realizzazione di applicazioni di tipo enterprise e mission critical) L'adozione di application server offre particolari benefici soprattutto nei settori dello sviluppo, dell'esecuzione e della gestione integrata dei sistemi. I principali vantaggi possono essere così riassunti: Semplificazione delle attività di sviluppo: gli application server creano un ambiente nel quale si possono utilizzare gli strumenti di sviluppo più diffusi sul mercato, consentendo di produrre e distribuire rapidamente applicazioni transazionali altamente scalabili. In generale, questi ambienti comprendono modelli e strumenti di ausilio per sviluppare le applicazioni, riducendo i tempi di realizzazione e messa in esercizio dei programmi negli ambienti distribuiti. Supporto di vari linguaggi, strumenti e piattaforme: a seconda dell'application server utilizzato, le applicazioni possono essere scritte nel linguaggio preferito dal programmatore. Riusabilità del codice: la riusabilità del codice deriva sia dalla programmazione orientata agli oggetti spesso utilizzata in questi casi, sia dall'utilizzo dell'approccio a componenti. Una volta sviluppata la logica applicativa, essa può essere condivisa e riutilizzata. 14/19

15 Gestione delle transazioni. L'application server facilita la gestione delle operazioni basate su transazioni, assicurando l'integrità transazionale e gestione affidabile dei DBMS multipli per le risorse e i dati. Il sistema di gestione delle transazioni gestisce le interazioni con i database e le funzioni di commit, rollback e recovery. Scalabilità e alte prestazioni. Gli application server supportano il partizionamento delle applicazioni e la distribuzione in rete dei componenti e offrono caratteristiche architetturali che permettono di erogare elevate prestazioni quali il multithreading, il bilanciamento dinamico dei carichi di lavoro (load balancing), il caching e il pooling degli oggetti e delle connessioni ai database. Estensibilità. L'architettura modulare degli application server e il supporto per i server e per i moduli applicativi che possono essere caricati dinamicamente, consente alle aziende di estendere facilmente le funzionalità dei loro sistemi e delle relative applicazioni. Robustezza. L'architettura basata sui componenti degli application server e il bilanciamento dinamico dei carichi assicurano l'alta disponibilità dei sistemi. I componenti del server e la logica applicativa possono essere riconfigurati, aggiunti o rimossi senza interruzioni nell'erogazione dei servizi agli utenti. Queste caratteristiche sono particolarmente importanti per garantire l'alta disponibilità del sistema, requisito necessario per il buon esito delle operazioni mission-critical aziendali. Sicurezza. Gli application server offrono funzioni specifiche di sicurezza end-to-end, necessarie per l'esecuzione delle applicazioni aziendali che richiedono particolari misure di sicurezza e riservatezza dei dati. Per le comunicazioni tra client e server, vengono impiegati algoritmi standard e ampiamente testati e collaudati sul web, come quelli offerti dal protocollo SSL. Il logging e il tracking degli eventi forniscono protezione dagli accessi non autorizzati 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, thick, 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 thick 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 HTML dinamico ed esegue Applet Java o controlli ActiveX. Eseguire la logica applicativa sul client può migliorare l usabilità dell applicazione oppure le prestazioni del sistema. 15/19

16 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. Infine, un client viene considerato fat se sul browser si appoggia una porzione significativa della logica applicativa e quella di accesso ai dati 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, è opportuno 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. 5.5 Verso le architetture basate sui servizi I linguaggi di programmazione delle ultime generazioni sono linguaggi orientati agli oggetti e promuovono il riuso di 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 che usano i componenti software come entità riusabili dove i componenti sono insiemi di classi correlate. 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, che permettono ai client in rete di invocare una funzionalità/servizio attraverso delle interfacce pubblicate, sono chiamate architetture SOA (Service-Oriented Architectures). 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 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 (loosely-coupled) ovvero dotate di vita propria, realizzate ciascuna su una propria piattaforma hardware e software, distribuite e accessibili attraverso una rete di comunicazione mediante protocolli standard. Per rendere disponibile tale architettura, servono meccanismi che permettono: ai client di accedere ai servizi e ai registry disponibili in rete; ai servizi 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); 16/19

17 ai servizi di esporre interfacce ben definite e ai client di accedere a tali interfacce. In Figura 5.8 è riportato il diagramma standard dell architettura orientata ai servizi Fig. 5.8 Architettura orientata ai servizi Diversamente dagli ambienti distribuiti tradizionali, i sistemi informativi basati su Web enfatizzano l interoperabilità. Infatti sono indipendenti da particolari ambienti di programmazione, mentre gli ambiente distribuiti tendono a essere legati a uno specifico linguaggio, possono essere collegati a vari meccanismi di trasporto in rete, per cui diventano più flessibili e spesso non sono legati a particolari strutture di riferimento per i client o i server. Inoltre i sistemi SOA si appoggiano a XML e questo consente la condivisione di documenti in ambienti eterogenei. Gli svantaggi più rilevanti di un sistema informativo basato su web con architettura orientata ai servizi sono: necessitano di un maggior grado di sicurezza questi sistemi tendono ancora a non essere efficienti in termini di spazio e tempo di calcolo Perchè una organizzazione dovrebbe considerare di realizzare un sistema informativo basato su Web? Forse, la ragione più importante che motiva l uso crescente di tali sistemi informativi è, come già detto sopra, legata al fatto che essi promuovono l interoperabilità di piattaforme Inoltre, l uso dei sistemi informativi basati su Web sta aumentando anche perché essi riducono 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, i vantaggi dei sistemi informativi basati sul Web con architetture orientati ai servizi sono: 17/19

18 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. 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 Web Service I web services sono un implementazione concreta del modello SOA per applicazioni web in cui sono stati definiti dei protocolli tutti i meccanismi di comunicazione necessari per individuare ed eseguire il servizio. Diamo di seguito una descrizione sommaria di tali protocolli (vedi figura 5.9). Web Services Description Language (WSDL) è un linguaggio XML-based, il cui scopo è descrivere in modo astratto i web services. Universal Description, Discovery, and Integration (UDDI) è una piattaforma XML-based ideata allo scopo di gestire la registrazione e la ricerca di servizi. La registrazione consiste di tre componenti: White Pages indirizzo, contatto, identificatori di riconoscimento; Yellow Pages categorizzazione industriale basata su tassonomie standard; Green Pages informazioni tecniche del servizio Simple Object Access Protocol (SOAP) è un protocollo XML-based utilizzato per scambiare messaggi in una rete di calcolatori e solitamente utilizza HTTP (è comunque possibile utilizzare anche altri protocolli come FTP, SMTP, ). SOAP viene comunemente utilizzato come livello di base nella comunicazione previste per l utilizzo di un web service. 18/19

19 UDDI WSDL WSDL SOAP Fig. 5.9: protocolli di comunicazione dei web services Nella figura 5.10 riportata di seguito viene mostrato lo schema concettuale dello stack di comunicazione impiegato per individuare ed eseguire un web service. Fig. 5.10: schema concettuale dello stack di comunicazione per i web services 19/19