I tre pattern più comuni sono:
Client web thin - Utilizzato principalmente per le applicazioni basate su Internet, dove c'è poco controllo
sulla configurazione del client. Il client richiede solo un browser web standard (forms capable). Tutta la logica di
business viene eseguita sul server.
Client web thick - Sulla macchina client viene eseguita una quantità di logica di business significativa
strutturalmente. Di solito il client utilizza HTML dinamici, applet Java o controlli ActiveX per eseguire la logica di
business. Le comunicazioni con il server vengono ancora effettuate tramite HTTP.
Distribuzione Web - Oltre ad utilizzare il protocollo HTTP per le comunicazione client e server, possono essere
impiegati anche degli altri protocolli, come IIOP e DCOM, per supportare un sistema distribuito di oggetti. Il browser
web agisce principalmente da unità di distribuzione e container per un sistema distribuito di oggetti.
Questo elenco non può essere considerato completo, specialmente in un'industria dove le rivoluzioni tecnologiche
sembrano verificarsi ogni anno. Rappresenta ad alto livello i pattern strutturali più comuni delle applicazioni web.
Come per qualsiasi tipo di pattern è plausibile applicarne più d'uno ad una singola architettura.
Il pattern strutturale Client web thin è utile per le applicazioni basate su Internet, per le quali può essere
garantita solo la configurazione client minima. Tutta la logica business viene eseguita sul serve durante l'adempimento
delle richieste di pagine per il browser del client.
Questo pattern è il più appropriato per le applicazioni Web basate su Internet o per quegli ambienti in cui il client
ha un potere di calcolo minimo o nessun controllo sulla sua configurazione.
La maggior parte delle applicazioni e-commerce in Internet utilizzano questo pattern, perché non ha molto senso per il
business eliminare dei settori di clienti solo perché non dispongono delle capacità client sufficienti. Una tipica
applicazione e-commerce tenta di ottenere l'ambito di clienti più vasto possibile; dopo tutto, i soldi di un utente di
Commodore Amiga sono altrettanto buoni quanto quelli di un utente di Windows NT.
I principali componenti del pattern di architettura Client web thin sono presenti sul server. In molti modi questa
architettura rappresenta l'architettura minima di un'applicazione Web. I componenti principali sono:
Browser del client - Qualsiasi browser standard HTML abilitato ai moduli. Il browser agisce da unità
d'interfaccia utente generalizzata. Quando viene utilizzato nell'architettura Client web thin, l'unico altro
servizio che fornisce è la possibilità di accettare e restituire cookie. L'utente dell'applicazione utilizza il
browser per richiedere le pagine Web: HTML o server. la pagina restituita contiene un'interfaccia utente
completamente formattata (testo e controlli di input) che viene resa dal browser sullo schermo del client. Tutte le
interazioni utente con il sistema vengono effettuate attraverso il browser.
Server Web - Il punto di accesso principale di tutti i browser dei client. I browser dei client
nell'architettura Client web thin accedono al sistema solo attraverso il server Web, che accetta le richieste
di pagine Web (HTML statico o pagine di server). A seconda della richiesta, il server Web può avviare qualche
elaborazione dalla parte del server. Se la richiesta di pagine è relativa ad una pagina server creata con
script, CGI, ISAPI o modulo NSAPI, il server Web delega l'elaborazione all'interpreter di script appropriato o
al modulo eseguibile. In ogni caso, il risultato è una pagina HTML formattata, adatta per essere resa da un
browser HTML.
Connessione HTTP - Il protocollo più comune in uso fra i browser dei client ed i server
Web. Questo elemento strutturale rappresenta un tipo di comunicazione priva di connessione fra client e server.
Ogni volta che il client o il server invia delle informazioni all'altro, viene stabilita una nuova connessione
separata fra i due. Una variazione della connessione HTTP è una connessione HTTP protetta tramite SSL (Secure
Sockets Layer). Questo tipo di connessione codifica le informazioni trasmesse fra client e server, utilizzando
la tecnologia delle chiavi di codifica pubbliche/private.
Pagina HTML - Una pagina Web con interfaccia utente e informazioni di contenuto che non passano
attraverso alcuna elaborazione da parte del server. In genere queste pagine contengono del testo esplicativo,
ad esempio delle indicazioni o delle informazioni di aiuto, oppure dei moduli HTML di input. Quando un server
Web riceve una richiesta di pagina HTML, il server richiama semplicemente il file e lo invia, senza filtrarlo,
al client richiedente.
Pagina server - Pagine Web che passano attraverso a qualche forma di elaborazione da parte del server.
Di solito queste pagine sono implementate sul server come pagine create con script (Active Server Page, Java
Server Page, Cold Fusion Page) che vengono elaborate da un filtro sul server dell'applicazione o da moduli
eseguibili (ISAPI o NSAPI). Queste pagine potenzialmente hanno accesso a tutte le risorse presenti sul server,
inclusi i componenti della logica di business, i database, i sistemi esistenti ed i sistemi di account
commerciali.
Server dell'applicazione - Il motore principale per l'esecuzione della logica business da parte del
server. Il server dell'applicazione è responsabile dell'esecuzione del codice nelle pagine del server, può
essere sulla stessa macchina del server Web e può persino andare in esecuzione nello stesso spazio di processo
del server Web. Il server dell'applicazione è logicamente un elemento strutturale separato, poiché si occupa
unicamente dell'esecuzione della logica di business e può utilizzare una tecnologia completamente diversa dal
server Web.
La figura che segue mostra un diagramma della vista logica dell'architettura Client web thin.
Architettura Client web thin minima
All'architettura minima Client web thin mancano dei componenti facoltativi comuni che in genere si trovano nelle
applicazioni web; il più degno di nota è il database. La maggior parte delle applicazioni web utilizza un database per
rendere i dati di business permanenti. In alcune situazioni il database può essere utilizzato anche per memorizzare le
pagine stesse (questo utilizzo del database, tuttavia, rappresenta un pattern strutturale diverso). Poiché le
applicazioni web possono usare qualsiasi numero di tecnologie per rendere i dati del business permanenti, il componente
strutturale viene etichettato con il termine più generico: persistenza. Il componente Persistenza include anche il
possibile utilizzo di un TPM (Transaction Processing Monitor).
Il modo più semplice per collegare un database al sistema è di consentire agli script delle pagine server l'accesso
diretto al componente Persistenza. Persino questo accesso diretto utilizza le librerie di accesso dati standard come
RDO, ADO, ODBC, JDBC, DBLib, ecc. per eseguire il lavoro. In questa situazione le pagine server sono informate riguardo
lo schema del database. Per i sistemi di database relazionale costruiscono ed eseguono le istruzioni SQL necessarie per
ottenere l'accesso ai dati nel database. In applicazioni web più piccole e meno complicate questo può essere
sufficiente. Per sistemi più grandi e più robusti, tuttavia, l'uso di un livello completo di oggetti di business è
preferibile.
Un componente di oggetti di business incapsula la logica di business. Questo componente viene di solito compilato ed
eseguito sul server dell'applicazione. Uno dei vantaggi di avere un componente strutturale di oggetti di business è che
anche altri sistemi web o client server possono utilizzare gli stessi componenti per richiamare la stessa logica di
business. Ad esempio, un negozio basato su Internet può utilizzare le pagine server ed il pattern strutturale Client
web thin per tutta l'attività del cliente, tuttavia il reparto della fatturazione potrebbe richiedere un accesso più
sofisticato ai dati e alla logica di business e preferire l'utilizzo di un sistema client server invece di uno basato
su Web. Il sistema del reparto di fatturazione può utilizzare gli stessi componenti di business sullo stesso server di
applicazione della vetrina web, pur utilizzando il proprio software client più sofisticato.
Poiché i database relazionali sono il tipo più comune di database nei business mainstream, in genere è presente un
ulteriore componente strutturale fra il server dell'applicazione ed il database. Fornisce un servizio di mappatura fra
gli oggetti ed i database relazionali. Questo stesso livello di mappatura può essere implementato in vari modi.
Discussioni dettagliate relative a questo componente vanno oltre l'ambito di questa pagina.
Altre opzioni che in genere vengono aggiunte a questo pattern strutturale sono l'integrazione con i sistemi esistenti e
per applicazioni e-commerce un sistema di account commerciale. Entrambi si accedono tramite gli oggetti di business (o
il server applicazione per i sistemi senza un componente di oggetti di business formale). I sistemi esistenti possono
rappresentare un sistema di contabilità o un sistema di pianificazione di produzione. Il sistema di account commerciale
abilita un'applicazione web Internet ad accettare ed elaborare pagamenti tramite carta di credito. Sono disponibili
molti sistemi di account commerciale per le piccole imprese che desiderano entrare nel mercato on-line. Per le imprese
più grandi questo componente probabilmente sarebbe un'interfaccia per un sistema già esistente in grado di elaborare le
richieste con carta di credito.
Con questi componenti facoltativi la vista logica del pattern strutturale Client web thin è più completa. La vista
logica è illustrata nella figura che segue.
Vista logica del Client web thin
Molti dei componenti di un'applicazione web sono reperibili anche nelle applicazioni non basate su web. La
progettazione e l'architettura del back end di un'applicazione web non è diversa dalla progettazione di qualsiasi
mainframe sistema client/server. Le applicazioni Web impiegano l'utilizzo di database e di TPM (Transaction Processing
Monitor) (TPM) per gli stessi motivi degli alti sistemi che li usano. EJB (Enterprise Java Beans) e MTS (Microsoft's
Transaction Server) sono dei nuovi tool e delle nuove tecnologie che sono state introdotte per le applicazioni Web ma
si adattano ugualmente ad essere utilizzati in altre architetture di applicazioni.
L'architettura e la progettazione di componenti della parte server di un'applicazione web sono considerate esattamente
come quelle di qualsiasi sistema client server. Poiché questo pattern strutturale si focalizza su web e sui componenti
specifici per le applicazioni web, un'analisi dettagliata delle possibili architetture server back end va oltre
l'ambito di questo pattern.
Il principio delle dinamiche di questo pattern strutturale è che la logica di business viene eseguita solo in risposta
alla richiesta di una pagina web da parte del client. I client utilizzano il sistema richiedendo delle pagine web dal
server web con il protocollo HTTP. Se la pagina richiesta è un file HTML presente sul file system del server web, lo
recupera semplicemente e lo invia al client che lo ha richiesto.
Se si tratta di una pagina creata con script, cioè una pagina con del codice interpretabile che deve essere elaborato
prima di poter essere restituita al client, il server web delega questa azione al server dell'applicazione. Il server
dell'applicazione interpreta gli script della pagina e, se necessario, interagisce con le risorse della parte server,
come i database, i servizi email, i sistemi esistenti, ecc. Il codice creato con script ha accesso, tramite il server
dell'applicazione ed il server web, a delle informazioni speciali che accompagnano la richiesta della pagina. Queste
informazioni includono i valori dei campi dei moduli immessi dall'utente ed i parametri inseriti nella richiesta della
pagina. Il risultato finale è una pagina HTML correttamente formattata pronta per essere inviata al client.
La pagina può anche essere un modulo eseguibile, come una DLL ISAPI o NSAPI. Una DLL (o dynamic link library) è una
libreria compilata che può essere caricata ed eseguita al runtime dal server dell'applicazione. Il modulo ha accesso
agli stessi dettagli relativi alla richiesta delle pagina (valori dei campi del modulo e parametri) di cui dispongono
le pagine create con script.
Il punto chiave del comportamento dinamico di questo pattern è che la logica di business viene richiamata solo durante
l'elaborazione di una richiesta di pagina. Una volta soddisfatta la richiesta della pagina, il risultato viene inviato
al client che ne ha fatto richiesta e la connessione fra il client ed il server viene terminata. E' possibile per un
processo di business andare avanti dopo che la richiesta è stata soddisfatta ma questa non è la norma.
Questo tipo di architettura si adatta meglio alle applicazioni la cui risposta server può essere completata entro i
tempi di risposta accettabili attesi dall'utente (ed entro il valore di timeout consentito dal browser del client). Di
solito è nell'ordine di pochi secondi. Questo potrebbe non essere il pattern di architettura più appropriato se
l'applicazione deve consentire all'utente l'avvio ed il monitoraggio di un processo di business che richiede molto
tempo. L'utilizzo di tecnologie di spinta, tuttavia, può consentire al client di monitorare dei processi di lunga
esecuzione. Per la maggior parte le tecnologie di spinta utilizzano semplicemente il polling periodico del server.
Un'altra principale conseguenza di questo pattern strutturale è l'abilità limitata per le interfacce utente
sofisticate. Poiché il browser agisce come l'intero meccanismo di distribuzione dell'interfaccia utente, tutti i widget
ed i controlli devono essere disponibili tramite il browser. Nei browser più comuni e nelle specifiche HTML sono
limitati a pochi campi di immissione di testo e dei pulsanti. D'altra parte si potrebbe controbattere che
un'interfaccia utente così pesantemente limitata sia un vantaggio. Delle scarse offerte di interfaccia utente
impediscono al team di sviluppo di spendere dell'impegno lavorativo in interfacce "divertenti" e "carine", quando
basterebbero quelle più semplici.
Il pattern strutturale Client web thick estende il pattern Client web thin all'uso nella parte client dello script e
degli oggetti personalizzati come i controlli ActiveX e le applet Java. Il pattern Client web thick prende il nome dal
fatto che il client può effettivamente eseguire parte della logica di business del sistema e quindi diviene più di un
semplice contenitore di interfaccia utente generalizzata.
Il pattern strutturale Client web thick è più appropriato per le applicazioni web in cui vengono presupposte una
determinata configurazione client ed una determinata versione di browser, in cui si desidera un'interfaccia utente
sofisticata e/o in cui una certa quantità della logica di business può essere eseguita sul client. La maggior parte
della differenza fra i pattern Client web thin e Client web thick è nel ruolo che il browser gioca nell'esecuzione
della logica di business del sistema.
Le due forti motivazioni per l'utilizzo del Client web thick sono la capacità interfaccia utente migliorata e
l'esecuzione client della logica di business. Un'interfaccia utente sofisticata potrebbe essere utilizzata per
visualizzare e modificare i modelli tridimensionali o animare un grafico finanziario. In alcune istanze il controllo
ActiveX può essere utilizzato per comunicare con le apparecchiature di monitoraggio dalla parte client. Ad esempio, le
apparecchiature sanitarie che possono misurare la pressione, la glicemia ed altri segni vitali possono essere
utilizzate da un'agenzia che ha bisogno di monitorare quotidianamente dei pazienti geograficamente lontani ed essere in
grado di risparmiare le visite personali a due volte la settimana.
In alcune situazioni la logica di business può essere eseguita sul client da solo. In queste situazioni tutti i dati
richiesti per portare avanti il processo devono essere disponibili sul client. La logica potrebbe essere semplice, come
la convalida dei dati immessi. E' possibile controllare l'accuratezza delle date o confrontarle con altre date (ad
esempio la data di nascita dovrebbe essere anteriore alla della prima ammissione all'ospedale). A seconda delle regole
di business del sistema, alcuni campi potrebbero o meno essere abilitati in base ai valori immessi correntemente.
L'utilizzo più ovvio di script, applet, controlli e plugin della parte client è su Internet sotto forma di interfacce
utente migliorate. Gli script Java vengono spesso utilizzati per modificare il colore o l'immagine di un pulsante o di
una voce di menu nelle pagine HTML. Le applet Java e i controlli ActiveX vengono spesso usati per creare dei controlli
sofisticati della vista ad albero gerarchica.
Il plugin e il controllo Shockwave ActiveX è uno dei componenti di interfaccia utente più comuni in uso in Internet
oggi. Consente le animazioni interattive e viene principalmente usato per vivacizzare i siti Internet con della grafica
attraente ma anche per visualizzare simulazioni e monitorare degli eventi sportivi.
Il controllo agente della Microsoft viene utilizzato da diversi siti Internet per accettare i comandi vocali ed
eseguire delle azioni nel browser che assiste l'utente nell'esplorazione del sito web.
Al di fuori di Internet, un'azienda di software in ambito sanitario ha sviluppato un'applicazione intranet basata su
web per gestire i record dei pazienti e la fatturazione. L'interfaccia utente basata su web fa un pesante uso di script
della parte client per eseguire le convalide dei dati ed assistere l'utente nell'esplorazione del sito. Oltre agli
script, l'applicazione utilizza diversi controlli ActiveX per gestire il contenuto XML, che viene utilizzato come
schema di codifica principale per le informazioni.
Tutte le comunicazioni fra client e server, come nel pattern Client web thin, vengono effettuate con HTTP. Poiché HTTP
è un tipo di protocollo "senza connessione", per la maggior parte del tempo non c'è una connessione aperta fra client e
server. Solo durante le richieste di pagine il client manda le informazioni. Questo significa che lo script della parte
client, i controlli ActiveX e le applet Java sono limitati ad interagire con gli oggetti solo sul client.
Il pattern Client web thick utilizza determinate capacità del browser, come i controlli ActiveX o le applet Java, per
eseguire la logica di business sul client. I controlli ActiveX sono dei programmi binari eseguibili compilati che
possono essere scaricati sul client tramite HTTP e richiamati dal browser. Poiché i controlli ActiveX sono
essenzialmente degli oggetti COM, hanno pieno dominio sulle risorse della parte client. Possono interagire sia col
browser che con lo stesso sistema client. Per questo motivo i controlli ActiveX, specialmente quelli in Internet, in
genere vengono "autenticati" da terze parti di fiducia
Anche le versioni più recenti di browser HTML comuni consentono lo script sulla parte client. Le pagine HTML possono
essere inserite negli script scritti in Java Script o VB Script. Questa capacità di script consente al browser stesso
di eseguire (o piuttosto interpretare) il codice che potrebbe far parte della logica di business del sistema. Il
termine "potrebbe" viene utilizzato perché è cosa molto comune per gli script client contribuire solo agli aspetti
estranei dell'interfaccia utente, e non effettivamente far parte della logica di business. In ogni caso, potenzialmente
esistono degli elementi strutturalmente significativi (ad es. gli script) inclusi nelle pagine HTML che devono essere
espressi come tali.
Poiché il pattern Client web thick è in realtà solo un'estensione al pattern Client web thin, la maggior parte degli
elementi strutturalmente significativi sono gli uguali. Gli elementi aggiuntivi che il pattern Client web thick
introduce sono:
Script del client - JavaScript o script Microsoft® VirtualBasic® inserito nelle pagine HTML formattate.
Il browser interpreta lo script. Il W3C (un corpo di standard Internet) ha definito l'interfaccia HTML e DOM
(Document Object Model) che il browser offre per gli script client.
Documento XML - Un documento formattato con XML (eXtensible Markup Language). I documenti XML
rappresentano il contenuto (dati) senza la formattazione dell'interfaccia utente.
Controllo ActiveX - Un oggetto COM che può essere menzionato in uno script del client e "scaricato" sul
client, se necessario. Come qualsiasi oggetto COM, ha pieno accesso alle risorse del client. Il meccanismo di
sicurezza principale per la protezione delle macchine client è mediante l'autenticazione e la firma. I browser
Internet possono essere configurati a non accettarli o ad avvertire l'utente quando i controlli ActiveX stanno
per essere scaricati sul client. I meccanismi di autenticazione e di firma stabiliscono semplicemente
l'identità dell'autore del controllo tramite terze parti attendibili.
Applet Java - Un componente autonomo e compilato che viene eseguito nel contesto di un browser. Per
ragioni di sicurezza ha un accesso limitato alle risorse della parte client. Le applet Java vengono utilizzate
sia come interfaccia utente sofisticata che per scopi diversi dall'interfaccia utente, ad esempio nell'analisi
dei documenti o per incapsulare della logica di business complicata.
Bean Java - Un componente Java che implementa un determinato insieme di interfacce che lo abilitano ad
essere facilmente incluso in sistemi complessi più grandi. Il termine bean riflette la piccola natura ed il
singolo scopo che il componente dovrebbe avere. Una tazza di caffè piena in genere richiede più di un 'chicco'.
ActiveX è l'analogo dei bean Java nelle architetture centrate su Microsoft.
La figura riportata di seguito mostra un diagramma della vista logica dell'architettura Client web thick.
Vista logica del pattern dell'architettura Client web thick
Le principali dinamiche del pattern Client web thick includono quelle del pattern Client web thin con in più la
possibilità di eseguire la logica di business sul client. Come per il pattern Client web thin, tutte le comunicazioni
fra client e server si svolgono durante le richieste di pagine. La logica di business, tuttavia, può essere eseguita
parzialmente sul client con script, controllo o applet.
Quando una pagina viene inviata ad un browser del client, potrebbe contenere degli script, dei controlli e delle
applet. Possono essere utilizzati semplicemente per migliorare l'interfaccia utente o per contribuire alla logica di
business. La logica di business più semplice sono le convalide dei campi. Gli script del client possono essere
utilizzati per cercare input valido, non sono in un singolo campo ma in tutti i campi di una qualsiasi pagina web
specificata. Ad esempio, un'applicazione e-commerce che consente agli utenti di configurare i propri sistemi di
computer potrebbe utilizzare degli script per impedire che vengano specificate delle opzioni incompatibili.
Per poter essere utilizzati, le applet Java ed i controlli ActiveX devono essere specificati nel contenuto della pagina
HTML. I controlli e le applet possono lavorare in modo indipendente da qualsiasi script della pagina oppure essere
guidati da questi ultimi. Gli script in una pagina HTML possono rispondere a degli eventi speciali inviati dal browser.
Questi eventi possono indicare che il browser ha appena finito di caricare la pagina web o che il mouse dell'utente si
è spostato su una specifica area della pagina.
Hanno accesso all'interfaccia DOM (Document Object Model) del browser. Questa interfaccia è uno standard W3C per
fornire agli script, ai controlli e alle applet l'accesso al browser e al contenuto HTML delle pagine.
L'implementazione Microsoft e Netscape di questo modello è DHTML (Dynamic HTML). DHTML è più di una semplice
implementazione dell'interfaccia DOM, il suo particolare DHTML include degli eventi, che al momento della stesura di
questa documentazione non facevano parte della specifica DOM Livello 1.
Nel nucleo del DOM (Document Object Model) risiede una serie di interfacce che specificatamente gestiscono i documenti
XML. XML è un linguaggio flessibile che abilita i progettisti alla creazione di propri tag per scopi particolari.
L'interfaccia DOM abilita gli script client all'accesso ai documenti XML
L'utilizzo di XML come meccanismo standard per lo scambio di informazioni fra client e server è consentito dall'uso di
componenti speciali sul client. I controlli ActiveX o le applet Java possono essere collocati sul client per inviare e
ricevere in modo indipendente dei documenti XML. Ad esempio un'applet Java inclusa in una pagina HTML potrebbe
effettuare dal server web una richiesta HTTP di un documento XML. Il server web trova ed elabora le informazioni
richieste ed invia in risposta un documento non HTML ma formattato XML. L'applet ancora in esecuzione nella pagina HTML
sul client accetta il documento XML, lo analizza ed interagisce con il documento HTML corrente nel browser per
visualizzarne il contenuto per l'utente. L'intera sequenza si verifica nel contesto di una singola pagina HTML nel
browser del client.
La conseguenza più importante di questo pattern è la portabilità nelle implementazioni dei browser. Non tutti i browser
HTML supportano Java Script o VirtualBasic Script. Inoltre solo i client basati su Microsoft Windows possono utilizzare
i controlli ActiveX. Vi sono delle sottili differenze nelle implementazioni del DOM (Document Object Model) anche
quando una marca specifica di browser di client viene utilizzata in esclusiva.
Quando vengono utilizzati gli script, i controlli o le applet del client, il team di verifica deve eseguire la serie
completa di scenari di test per ogni configurazione client da supportare. Poiché sul client si sta eseguendo della
logica di business critica, è importante che che la funzionalità sia coerente e corretta per tutti i browser implicati.
Non dare mai per scontato che tutti i browser funzionino allo stesso modo. Non solo è possibile che browser diversi
agiscano in modo diverso con lo stesso codice sorgente, ma anche che lo stesso browser in esecuzione su diversi
sistemi operativi potrebbe mostrare un comportamento anomalo.
Il pattern strutturale Distribuzione web viene così chiamato perché il Web viene principalmente utilizzato come
meccanismo di distribuzione per un sistema client/server di oggetti distribuiti tradizionale. Da un certo punto di
vista questo tipo di applicazione è realmente un'applicazione client/server di oggetti distribuiti che include
semplicemente un server web ed un browser di client come elementi strutturali significativi. Il sistema finale è lo
stesso, che si tratti di un'applicazione con oggetti distribuiti o di un sistema di oggetti distribuiti con elementi
web. Il fatto che questi due punti di vista appartengano allo stesso sistema (ed i sistemi di oggetti distribuiti sono
sempre stati visti come sistemi che richiedono un'attenta modellazione) enfatizza ulteriormente l'argomento di questa
pagina, cioè che le applicazioni web devono essere modellate e progettate come qualsiasi altro sistema software.
Il pattern strutturale Distribuzione web è più appropriato quando esiste un controllo significativo sulle
configurazioni del client e di rete. Questo pattern non si adatta particolarmente alle applicazioni basate su Internet,
dove non c'è controllo (o poco) sulle configurazioni client o quando le comunicazioni di rete non sono affidabili.
Il maggior punto di forza di questa architettura è la sua capacità di potenziare gli oggetti business esistenti nel
contesto di un'applicazione web. Con le comunicazioni dirette e permanenti possibili fra client e server le limitazioni
dei due precedenti pattern di applicazioni web possono essere superate. Il client può essere potenziato per eseguire
una significativa logica di business ad un grado anche più elevato.
E' poco probabile che questo pattern strutturale venga utilizzato in isolamento. Più realisticamente questo pattern
viene combinato con uno o entrambi i pattern precedenti. Un sistema tipico utilizzerebbe uno o entrambi i primi pattern
strutturali per quelle parti del sistema che non richiedono un'interfaccia utente sofisticata o dove le configurazioni
client non sono sufficientemente forti per supportare una grossa applicazione client.
Il sito web CNN Interactive è uno dei siti di notizie più frequentati sulla rete. La maggior parte del suo accesso
pubblico viene effettuato con dei browser convenzionali e semplici HTML 3.2, tuttavia dietro al sito web esiste una
sofisticata rete, basata su CORBA, di browser, server ed oggetti distribuiti. Un caso pratico di questo sistema è stato
pubblicato in Distributed Computing.
Una società di software in ambito sanitario ha creato un'applicazione web per gestire i pazienti, i record sullo stato
di salute e la fatturazione. Gli aspetti finanziari del sistema vengono utilizzati solo da una minima porzione della
comunità utenti globale. La maggior parte dei sistemi di fatturazione esistenti è stata scritta in FoxPro. Il nuovo
sistema basato su web ha potenziato il vecchio codice FoxPro esistente e mediante l'uso di di alcuni programmi di
utilità di conversione ha creato dei documenti ActiveX per l'interfaccia utente e la logica di business. Il sistema
risultante è un'applicazione web basata su Client web thick per i record relativi ai pazienti e allo stato di salute,
integrata con un'applicazione web basata su Distribuzione web per le operazioni di fatturazione.
La differenza più significativa fra Distribuzione web e gli altri pattern strutturali di applicazioni web è il metodo
di comunicazione fra il client ed il server. Negli altri pattern il meccanismo principale era HTTP, un protocollo senza
connessione che limita profondamente la progettazione quando si tratta di attività interattiva fra l'utente ed il
server. Gli elementi strutturalmente significativi nel pattern Distribuzione web sono tutti quelli specificati nel
pattern Client web thin con in più questi altri elementi aggiuntivi:
DCOM - Distributed COM è un protocollo di oggetti distribuiti Microsoft. Abilita gli oggetti presenti su
una macchina a richiamare i metodi ed interagire con essi su oggetti presenti su un'altra macchina.
IIOP - Internet Inter-Orb Protocol è il protocollo CORBA di OMG per l'interazione con gli oggetti
distribuiti in Internet (o qualunque rete basata su TCP/IP).
RMI (JRMP) - Remote Method Invocation è il modo Java di interagire con gli oggetti su altre macchine.
JRMP (Java Remote Method Protocol) è il protocollo nativo per RMI, ma non necessariamente l'unico protocollo
che può essere utilizzato. RMI può essere implementato con l'IIOP di CORBA.
La figura riportata di seguito mostra un diagramma della vista logica per il pattern di architettura di distribuzione
web.
Vista logica del pattern di architettura di distribuzione web
Le principali dinamiche del pattern strutturale di distribuzione web sono l'uso del browser per produrre un sistema di
oggetti distribuiti. Il browser viene utilizzato per contenere un'interfaccia utente e alcuni oggetti business che
comunicano, in modo indipendente dal browser con gli oggetti del livello server. Le comunicazioni fra gli oggetti
client e server avvengono tramite i protocolli IIOP, RMI e DCOM.
Il principale vantaggio nell'utilizzare un browser web in questo sistema client server altrimenti di oggetti
distribuiti è che il browser contiene delle capacità integrate per scaricare automaticamente dal server i componenti
necessari. Un computer nuovo alla rete ha bisogno solo di un browser web compatibile, per iniziare ad usare
l'applicazione. Non è necessario installare manualmente sul client il software speciale, perché il browser si occuperà
di questo per conto dell'utente. I componenti vengono distribuiti ed installati sul client quando diviene necessario.
Le applet Java ed i controlli ActiveX possono essere inviati al client e messi nella cache automaticamente. Quando
questi componenti vengono attivati (come risultato del caricamento della pagina web appropriata), possono intraprendere
una comunicazione asincrona con gli oggetti del server.
La conseguenza più importante di questo pattern è la portabilità nelle implementazioni dei browser. L'utilizzo di
questo pattern richiede una rete solida. Le connessioni fra il client e gli oggetti del server durano molto di più
delle connessioni HTTP e quindi una saltuaria perdita del server, che non è un problema con le altre due architetture,
in questo pattern pone un serio problema da risolvere.
|