DOCUMENT VERSION
Status: draft
Author: Andrea Boschin
Last Update: 14/10/2005
Current Version: 1.0.0
ABSTRACT
Nel presente documento viene illustrata l'architettura dell'applicazione denominata IMHO codename "Pellestrina", allo scopo di definire l'ambiente in cui verranno collocati i moduli applicativi e l'interazione esistente tra essi. Nello stesso documento verranno anche definiti i punti di estensibilità presso i quali potranno agganciarsi eventuali moduli esterni sviluppati in seguito anche da terze parti.
OBBIETTIVI E SCELTE ARCHITETTURALI
La progettazione dell'architettura di IMHO codename "pellestrina" ha avuto essenzialmente due obbiettivi. Il primo di essi è stato la necessità di realizzare una piattaforma collaborativa che consentisse a postazioni distribuite di concorrere nella gestione di uno o più siti web (blog). Per risolvere questa esigenza si è scelto di suddividere l'applicazione in una parte server ed una client. La parte server avrà la responsabilità di consentire a diversi utenti l'accesso ai contenuti per la creazione di post, la loro categorizzazione, la schedulazione delle attività e la sincronizzazione con i siti veri e propri. Il client sarà la vera e propria interfaccia utente che permette la fruizione delle funzionalità in base ai permessi dell'utente e ai siti ad esso assegnati. La prima scelta architetturale quindi è stata quella di utilizzare .NET Remoting per consentire la comunicazione tra Client e Server.
La tecnologia .NET Remoting è parsa la più efficace e al tempo stesso anche quella più flessibile e adattabile alle esigenze applicative. In seguito a questa scelta e alla necessità di compiere attività sincrone e asincrone anche schedulate si è deciso di realizzare la parte server come un Windows Service che esponga da un lato una serie di "Remote Providers", ognuno dei quali deputato ad un certo ambito dell'applicazione, e dall'altro si occupi di effettuare le operazioni asincrone verso i siti web e di gestire le schedulazioni. In particolare la scelta di avere un certo numero di provider anzichè uno solo è data dalla necessità di ridurre al minimo il numero dei metodi esposti da un singolo oggetto per migliorare le performances del server.
Ulteriori considerazioni hanno consigliato l'adozione di una struttura a Provider anche per la parte di accesso ai dati che è rsidente completamente nella parte server. Tale struttura consente di migrare facilmente e rapidamente l'applicazione su diversi tipi di database. Infatti nonostante inizialmente l'applicazione sia basata su un database Microsoft Access, sarà opportuno in seguito consentire l'adozione di database più potenti quali Sql Server o Oracle. La scelta attuale di utilizzare un database Access è dovuta alla volontà di semplificare al massimo l'installazione del software e di esplorare innanzitutto il gradimento del prodotto prima di orientarsi a prodotti più complessi e costosi.
Il secondo obbiettivo cui l'architettura doveva rispondere era la necessaria espandibilità dell'applicazione, innanzitutto per consentire in futuro lo sviluppo di moduli aggiuntivi, realizzati per soddisfare esigenze specifiche, ma anche per consentire una più facile customizzazione e per spronare la realizzazione di estensioni di terze parti. Per raggiungere questo obbiettivo si è scelto di suddividere l'applicazione in moduli, ognuno dei quali viene caricato nella parte client al momento dell'avvio dell'applicazione. Ad ognuno dei moduli in fase di inizializzazione viene fornito un handle di una finestra host cui essi può agganciarsi con uno o più componenti dei quali in seguito intercetterà gli eventi. Al verificarsi di questi eventi i moduli applicativi, in completa autonomia si collegano al server ed espletano le proprie funzionalità usando i provider remoti definiti specificamente per il loro funzionamento oppure quelli di altri moduli da cui essi dipendono.
COMPONENTI ARCHITETTURALI
Nello schema qui sotto riportato sono definiti in dettaglio i componenti che danno vita all'architettura dell'applicazione e il rapporto che li lega. Lo schema è suddiviso innanzitutto nelle due parti che compongono l'applicazione, Il Client e il Server. Ecco a partire dall'alto quali sono i vari componenti e le funzionalità che essi espletano:
PLUGGABLE USER INTERFACE
L'interfaccia utente, è il fulcro attorno al quale ruota l'estensibilità dell'applicazione. Essa ha la caratteristica di poter acquisire nuove componenti, all'interno di una struttura ben definita, consentendo a tali componenti di vivere autonomamente e di comunicare con gli strati inferiori dell'applicazione. Questa struttura che sarà oggetto di un successivo articolo, espone delle aree entro le quali uno dei moduli applicativi possono agganciare componenti dai quali poi riceveranno notifica degli eventi cui si sono iscritti. L'interfaccia è composta da una form denominata host, che espone le seguenti aree:
-
Group Bar
-
Toolbar
-
Status Bar
-
Content Area
All'interno di queste aree un modulo può agganciare dei controlli che derivano da opportune classi, che forniscono un subset minimo di funzioni per l'accesso all'interfaccia. La registrazione di queste componenti avviene nel momento dell'istanziazione del modulo sottostante che sfrutta i metodi dell'interfaccia IHost che riceve come unico parametro nel costruttore.
MODULES
Il "Modulo" è l'unità minima che concorre al funzionamento dell'applicazione. Esso viene istanziato dinamicamente sulla base di alcune informazioni che vengono reperite nell'elenco dei moduli installati presente nel file di configurazione. In questo modo chiunque è in grado di registrare un nuovo modulo semplicemente realizzando una classe che estende la classe astratta ImhoModule. In un'architettura 3-tier il modulo è lo strato intermedio che si interpone tra interfaccia e datalayer. L'applicazione definisce al suo interno un certo numero di moduli qui elencati:
-
Membership Management
-
Site Management
-
Post Management
-
...
(l'elenco dei moduli deve essere completato)
All'atto della propria creazione un modulo registra presso l'applicazione host i propri controlli e contestualmente si iscrive agli eventi che questi espongono. Per alcuni casi specifici l'host esporra alcuni metodi che consentono la condivisione di componenti di interfaccia anche tra moduli diversi (da valutare). Il modulo accede agli strati inferiori dell'applicazione per mezzo del Controller, sia esso quello standard o uno custom. I moduli inoltre utilizzano il meccanismo dei Principal per determinare quali sono le azioni che possono essere compiute da ogni utente.
CONTROLLER
Scopo primario del controller è quello di mascherare alle parti superiori dell'applicazione le presenza dei provider remoti. Esso a tutti gli effetti si comporta come una façade istanziando i provider remoti e di chiamandone i metodi per ottenerne i risultati in modo del tutto trasparente per gli strati superiori. Inoltre esso è un Singleton, e quindi è accessibile da parte di qualunque modulo senza che la sua referenza debba essere passata da un module ad un altro.
COMMUNICATION SINKS
La comunicazione tra il client e il server avviene per mezzo dei comuni protocolli di rete attraverso messaggi http o tcp in formato binario o SOAP. Questo tipo di comunicazione, unita alla scelta di usare la modalità "Single Call" per i provider remoti fa si che da un lato sia necessario proteggere il canale di comunicazione che altrimenti potrebbe essere facilmente intercettato e dall'altro che sia obbligatorio stabilire un modo per evitare di ripetere l'autenticazione ad ogni chiamata. I channel sinks assolvono proprio a queste esigenze. Primo fra essi, il SessionSink-Client, di occupa di affiancare ad ogni messaggio tra client e server un GUID che rappresenta la sessione corrente. La controparte server del Server del SessionSink rilevata la presenza del GUID verifica la corrispondenza con una sessione nella cache oppure la ricostruisce interrogando la base dati. La cache delle sessioni ha lo scopo di minimizzare l'accesso alla base dati nei momento di intenso utilizzo da parte del client. Assieme alla sessione sul server viene ricostruito anche il Principal all'interno del thread che sta eseguendo la chiamata, per propagare la gestione dei parmessi anche al server. Il secondo sink, denominato Encryption Sink usa una chiave condivisa tra client e server per crittare e decrittare i messaggi in transito tra le due controparti. Al momento la chiave è memorizzata all'interno del file di configurazione sia sul client che sul server, ma è auspicabile che essa possa essere specificata dall'utente al momento della prima registrazione del server sul client.
REMOTE PROVIDERS
Il provider remoto è una classe che estende MarshalByRefObject, il cui compito è di eseguire sul server i metodi chiamati dal client. Nella maggior parte dei casi il provider remoto dovrà accedere alla base dati e lo farà per mezzo del provider dati discusso nel prossimo paragrafo. Tuttavià il provider remoto può anche compiere operazioni differenti dall'accesso ai dati come a titolo esemplificativo: Impartire comandi di controllo al server, interfacciarsi ad altre componenti dell'architettura, etc... In sostanza il provider è il mezzo con cui il client potrà operare sui dati e sull'engine centrale dell'applicazione. E' possibile registrare ulteriori provider "custom", inserendo le loro caratteristiche all'interno del file di configurazione. In questo modo chiunque potrà sviluppare providers a supporto delle componenti custom registrate negli strati superiori dell'applicazione.
DATA PROVIDER
Il data provider ha lo scopo di astrarre la base dati utilizzata e di contenere al suo interno le chiamate al database esponendole per mezzo di metodi. L'architettura di imho prevede che per l'accesso ai dati e il mapping su oggetti si faccia uso della libreria ORM iBatis. Tale libreria utilizza uno o più file xml che determinano le query da compiere per ottenere i dati. Questo file è parte integrante del dataprovider e deve essere contenuto in esso come embedded resource.
RELEASE HISTORY
| Date |
Description |
Author |
| 16/10/2005 |
Rilascio al pubblico |
Andrea Boschin |