Windows DNA Parte prima
In questi giorni, se vi capitasse di assistere ad un qualsiasi seminario per sviluppatori sponsorizzato dalla Microsoft, sentireste parlare molto dell'architettura DNA (Windows D istributed Inter N et A pplications). Se visitate il sito http://www.microsoft.com/dna , potrete leggere alcuni articoli tecnici veramente fenomenali il cui scopo è quello di dare ai capi progetto abbastanza informazioni riguardo a DNA da poter inguaiare l'intera squadra degli sviluppatori. Benchè gli esempi di DNA siano completi e ricchi di dettagli, ogni sviluppatore ASP attivo (leggi: stressato dal troppo lavoro) difficilmente ha il tempo di tenersi aggiornato sull'ultima release di OLEDB , tanto meno ha il tempo per scavare a fondo montagne di codice dimostrativo in quei casi in cui non è neppure convinto che ciò serva a qualcosa.
Lo scopo di questo articolo è di fornire una panoramica concisa, ma funzionale, alla filosofia su cui si basa Windows DNA e di spiegare perchè un qualsiasi team di sviluppo di applicazioni web dovrebbe considerare l'adozione di tale strategia.
DNA 101
Per i lettori che non sono familiari col termine, Windows DNA è un termine usato nel marketing ma applicato allo sviluppo di applicazioni multi-tier nell'impresa tramite i tool di sviluppo microsoft (Visua Studio, SQL Server, Microsoft Transaction Server e ASP, principalmente). I 'tier', o strati, anche detti 'layer', a cui ci si riferisce sono il Data Access (accesso ai dati), Business Logic e il Presentation Layer (Strato di Presentazione).
La metafora Server-Client impiegata nel modello è abbastanza semplice da capire. Ogni strato del modello fornisce servizi ad uno degli altri strati relativamente alla sua classificazione funzionale. In altre parole, lo strato Data Access fornisce servizi di accesso dati allo strato di business logic ed a quello di presentazione. Quindi, quando un'applicazione richiede l'accesso ad informazioni residenti nel database, essenzialmente essa richiede allo strato Data Access di preparare l'informazione per essere utilizzata, piuttosto che accedere direttamente all'informazione nel database. Ciò equivale grossomodo a chiamare il centralino per richiedere un numero di telefono, piuttosto che cercarselo da soli nell'elenco.
Ciascuno dei tre strati è definito dalle seguenti classificazioni funzionali:
Strato Data Access : Gestisce l'inserimento, l'aggiornamento e la lettura di dati (a prescindere dal formato specifico in cui sono rappresentati, siano essi volatili o persistenti, quali Microsoft Message Queues ( MSMQ ) o SQL Server).
Starto Business Logic : Modella il processo reale per la cui automatizzazione l'applicazione è progettata. Per esempio, in un'applicazione di commercio elettronico, lo strato business logic potrebbe contenere codice per validare una carta di credito, gestire l'inventario e rintracciare i profili elettronici dei clienti.
Strato di Presentazione : Rappresenta lo strato che gestisce tutte le interazioni con l'utente qualunque esse siano. Nel contesto delle ASP e delle applicazioni web, questo layer consiste nelle pagine ASP e nei vari browser web presenti sul mercato.
L'architettura DNA prevede che ogni strato possa essere implementato indipendentemente utilizzando un algoritmo basato su tecnologie Microsoft: la gestione dei dati avviene tipicamente usando SQL Server 7.0 o MSMQ, la Business Logic si basa sull'incapsulamento in componenti COM e la presentazione è implementata da Microsoft Office (attraverso VBA), applicazioni VB o codice ASP. Microsoft afferma che in questo modo l'applicazione di livello enterprise raggiunga il massimo livello possibile di scalabilità e performance. Alla luce di un recente test independente , queste affermazioni sono corrette.
Mi interessa veramente?
Nello sviluppo di Active Server Pages, Microsoft ha creato una delle più potenti piattaforme di sviluppo di applicazioni Internet sul mercato. La versione di IIS in arrivo con Windows 2000 promette di dare agli sviluppatori ASP ancora più potenza, portando con se nuovi meccanismi di controllo del flusso, gestione dell'errore customizzabile, integrazione con XML, miglioramento della performance e maggiori possibilità di fine-tuning.
Un'obiezione che si sente comunemente da parte degli sviluppatori web è questa: dal momento in cui ASP è talmente potente da permettere agli sviluppatori di modellare la business logic e l'accesso ai dati dentro le Active Server Pages (n.d.t. è anche lo strato di presentazione, vedi questo articolo ), per quale motivo gli sviluppatori dovrebbero aumentare la complessità del loro codice introducendo una vera e propria architettura multi-tier?
La risposta è semplice! Il fatto che ASP permetta lo sviluppo dei diversi livelli non significa che vada necessariamente utilizzato così. Infatti, ci sono tre ragioni molto importanti per non farlo: 1-Performance, 2-Flessibilità, 3-Manutenzione del codice e supporto.
Performance
ASP riceve il suo potere dalla tecnologia Active Scripting sviluppata da Microsoft. Questa tecnologia permette agli sviluppatori di utilizzare dei sottoinsiemi (compilati a livello di esecuzione) di VB, Java e Perl per eseguire una serie di comandi in forma di script.
Quando dico 'compilati a livello di esecuzione' intendo dire che il codice nei file ASP è compilato ed eseguito ogni volta che la pagina è richiesta da un client. A seconda di cosa fa il codice, della quantità di codice che viene eseguito e del numero di utenti in un determinato momento sul server, la performance di questo codice interpretato può variare notevolmente.
D'altra parte, la maggior parte dei componenti COM contiene un insieme di istruzioni precompilate che vengono eseguite assai più velocemente dello scripting. Usati in congiunzione con Microsoft Transaction Server, i componenti COM possono aumentare notevolmente la velocità e la scalabilità del vostro sito, benchè i costi di sviluppo restino limitati.
In rete ci sono parecchi articoli che discutono i benefici dei componenti COM rispetto ad ASP, per quanto riguarda le performance.
Mantenere la flessibilità
La caratteristica migliore del codice compilato a tempo di esecuzione è probabilmente la facilità con cui può essere modificato. Dal momento che il codice viene compilato solo quando è eseguito, gli sviluppatori possono cambiare e far 'evolvere' il codice continuamente senza tutte le complicazioni che gli sviluppatori di VB e C++ affrontano quotidianamente. Questa flessibilità è solo un'impressione, comunque.
Il vero segreto della flessibilità nel modello Windows DNA è COM. Come probabilmente sapete, COM è una delle feature alla base di Windows e fornisce una piattaforma attraverso cui gli sviluppatori, utilizzando una vasta gamma di linguaggi e strumenti, possono creare applicazioni standard che forniscono e 'consumano' servizi in modo consistente in ambiente Windows (senza considerare il fatto che senza COM non avremmo nemmeno ASP).
Un componente COM creato in un certo linguaggio è generalmente accessibile ad ogni altro ambiente di sviluppo abilitato per COM e, quindi, può essere integrato in ogni applicazione abilitata per COM. Ciò significa che la business logic creata per un'applicazione e-commerce può essere resa disponibile a Microsoft Office, VB, eccetera. Ciò offre moltissima flessibilità per quanto concerne i modi in cui gli utenti potenziali dell'applicazione possono accedere e manipolare informazione critica.
Un esempio semplice potrebbe includere un insieme di componenti COM sotto forma di DLL scritte in VB e installate su NT sotto IIS. Questi componenti potrebbero, in una ipotetica soluzione per l'e-commerce via web, fornire l'accesso alla base di dati che rappresenta i libri giacenti in magazzino e le regole per la vendita al dettaglio, ma allo stesso tempo, anche fornire accesso al responsabile per le vendite della ditta, il quale, attraverso un estensione ad Excel, avrebbe accesso alle informazioni sulle vendite e sull'inventario. Contemporaneamente, un impiegato addetto al magazino nel palazzo accanto potrebbe utilizzare un'applicazione VB per tener conto di quanti libri della Wrox ci sono in stock, utilizzando lo stesso identico gruppo di componenti COM. Insomma, tante soluzioni diverse da un unico codice.
Certo, un qualsiasi 'purista' ASP potrebbe sostenere che tutte queste interfacce utente si possano implementare in ASP con minori grattacapi amministrativi, assicurandosi che il codice compilato di ognuna delle applicazioni client sia installato come si deve. Questo è vero, ma quando il responsabile delle vendite si aspetta che i dati gli siano presentati sotto forma di flessibile tabella pivot, il purista ASP deve affrontare da solo la progettazione di un intera interfaccia multi-dimensionale. Quando si tratta di implementare un'applicazione per il controllo di un inventario e si hanno moltissimi dati, è necessario che le performance siano ottimali. Immaginate di dover cercare l'ultima edizione di "Professional Active Server Pages", in un caso come questo VB è in grado di realizzare un prodotto di qualità superiore (per quanto riguarda le performance) normalmente in meno tempo di quanto occorra per produrre qualche pagina decente ASP/HTML che faccia lo stesso lavoro. In aggiunta, quando considerate che alcuni dipartimenti dell'organizzazione potrebbero non aver accesso alla Intranet della ditta o ad Internet, la business logic contenuta nei componenti puo essere riutilizzata in un insieme di applicazioni stand-alone, mentre il purista ASP si troverebbe impantanato nel creare da capo grosse parti del progetto.
Naturalmente, non ci sono regole fisse che dicono che tutta la business logic debba essere contenuta in componenti compilati quali DLL in Visual Basic. Se preferite ancora utilizzare VBScript e ASP come piattaforma di sviluppo, date un occhiata ai nuovi Windows Script Component . In essi troverete la flessibilità di COM combinata con la flessibilità del codice compilato a tempo di esecuzione.
Come evitare di impazzire
Normalmente, la manutenzione e il supporto di grosse applicazioni enterprise non è un gioco da ragazzi. Basta chiederlo alla gente che ha implementato quei siti per gli investimenti e le aste online. Business logic complessa mescolata con presentazioni e interfacce dinamiche, con l'aggiunta di grosse quantita di dati in continuo mutamento: uno scenario che può degradare nel caos più completo più velocemente di quanto riusciate a dire "ASP".
Immaginatevi questa situazione. Il vostro team di sviluppatori ha appena snocciolato un gigantesco e complicatissimo sistema per la compra-vendita di azioni online ad un cliente. Il team, composto da 10 puristi ASP, ha usato una media di 16 ore al giorno per i passati due mesi scrivendo migliaia e migliaia di linee di codice ASP, HTML, CSS e XML, pronti per il grande giorno quando l'applicazione deve essere lanciata. Il grande giorno arriva! Il sito riceve parecchi milioni di visite nelle prime ore. Un successo fenomenale.
Due mesi passano e il sito diventa il più popolare di tutti i servizi borsistici in rete. A quel punto il vostro cliente decide che vogliono cambiare la veste grafica del sito ed offrire alcuni nuovi servizi, incluso assicurazione sulla vita e investimenti tipo venture capital. Il cliente vuole che i nuovi servizi si integrino totalmente con la nuova struttura del sito, in modo da poter fornire ai clienti un portfolio unico a cui possono accedere per ammirare i loro beni. Vi rendete conto che, dal momento che la business logic dell'applicazione è intrinsecamente legata alle funzionalità di presentazione e di accesso ai dati, ciò non sarà una semplice aggiunta, ma richiederà una riscrittura di dimensioni enormi di parecchie parti del codice.
L'architettura Windows DNA, però, offre una soluzione che facilita la manutenzione. Dal momento che tutta la business logic per la prima fase dell'applicazione era contenuta in un insieme di componenti COM completamente separati dalla parte di presentazione, risulterà semplice cambiare l'intero layout del sito senza bisogno neppure di guardare alla business logic. Aggiungere i servizi è ugualmente semplice. Basta creare alcune DLL in VB che implementino i COM in grado di supportare la nuova business logic. DNA permette un approccio chirurgico nel supportare e manutenere le vostre applicazioni per produrre risultati più velocemente.
Implementare Windows DNA
È importante capire che libri interi sono stati scritti su questo argomento, quindi è fondamentalmente assurdo pensare di poter trovare una discussione completa dei pro e dei contro dell'architettura DNA in un articolo con meno di 2000 parole, ma spero di aver identificato uno scenario importante.
Il prossimo articolo in questa serie introdurrà una semplice applicazione DNA ed inizierà ad esplorare la creazione di un generico strato Data Access con MS SQL 7.0, Microsoft Data Engine, Microsoft Access 2000 e Microsoft Visual Basic 6.0.
In seguito, discuterò il design e l'implementazione dello strato di business logic e di quello di presentazione. Alla fine tirerò le somme con una discussione di come altre tecnologie internet quali DHTML, XML e Remote Scripting si collochino all'interno dell'architettura DNA. Alla fine dovrebbero esserci cinque articoli e voi dovreste a quel punto saperne abbastanza da poter partire sul binario giusto.
Nel frattempo, tirate un occhio a queste risorse (online e non) per informazioni ulteriori:
Link correlati
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
