Concetto: Pattern di architettura Web
I pattern di architettura Web rappresentano un'applicazione, o anche solo una parte di un'interfaccia di applicazione, come modelli comuni riutilizzabili.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

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.

Client web thin

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.

Applicabilità

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.

Usi conosciuti

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.

Struttura

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.

Il diagramma è descritto nel contenuto.

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.

Il diagramma è descritto nel contenuto.

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.

Dinamiche

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.

Conseguenze

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.

Client web thick

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.

Applicabilità

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.

Usi conosciuti

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.

Struttura

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.

Il diagramma è descritto nel contenuto.

Vista logica del pattern dell'architettura Client web thick

Dinamiche

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.

Conseguenze

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.

Distribuzione web

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.

Applicabilità

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.

Usi conosciuti

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.

Struttura

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.

Il diagramma è descritto nel contenuto.

Vista logica del pattern di architettura di distribuzione web

Dinamiche

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.

Conseguenze

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.