Abbiamo appena finito di creare e pubblicare "in the cloud" il sito della nostra prossima conferenza.
http://devleaprob.cloudapp.net
Più che di sito dovremmo parlare di applicazione; infatti il tutto è composto da
1) Pagine ASP.NET di presentazione dei contenuti
2) Servizi WCF per la gestione dell'elenco sessioni e speaker
3) Client Silverlight che recupera i dati di sessione e speaker tramite i servizi
L'applicazione è stata scritta seguendo il modello architetturale che usiamo nei nostri progetti reali e proponiamo nei nostri corsi/conferenze sin dal 2004; molti dei nostri clienti sanno di cosa parlo e molti di loro hanno anche visto il progettino reale nei nostri ultimi incontri come esempio di estensione verso Silverlight del modello architetturale.
Questo il System Diagram di Team System della parte server-side pre-cloud:
Come si nota la parte Web che ospita i servizi WCF e le pagine ASP.NET utilizza un Business Layer (DevLeapDevCon09Biz) per accedere alle informazioni. Il Biz tramite un factory (Dal) ottiene il Dal pluggabile (DalInMemory) per l'accesso alle informazioni. Il Dal restituisce entità di Business (del progetto Entities) in modo che gli altri strati applicativi vengano isolati dall'effettivo store delle informazioni.
Visto che il progetto, nato a ottobre, non aveva un database ben definito, avevamo optato (e da quì il nome DalInMemory) per creare comunque uno strato Dal pluggabile in modo da poterlo sostiuire non appena saremmo stati pronti con un database ben strutturato. In realtà non avendo il tempo necessario per progettare una buona base dati, adattabile alle nostre varie conferenza, il sito ufficiale di DevCon utilizza appunto il DalInMemory che si preoccupa di restituire l'elenco delle sessioni e degli speaker.
Questo disegno si traduce nella seguente parte di solution server-side:
Nella solution server-side non è presente la parte Silverlight, sviluppata con Luca Regnicoli in una solution separata.
Dunque...come portiamo il tutto in the cloud ?
In prima battuta abbiamo semplicemente creato un progetto "Web Role" per Windows Azure che utilizzando Biz e Dal esistenti consentiva, senza riscrivere praticamente niente, di utilizzare l'architettura esistente. Per semplificare la creazione della parte ASP.NET e WCF nel progetto Web Role sono stati linkati i sorgenti (tramite Add Link da Visual Studio 2008) del progetto web precedente. In questo modo, stanotte, dopo neanche 20 minuti di lavoro avevamo il sito DevCon in the cloud.
Ultimo step della prima fase: cambiare gli url a cui puntava il client Silverlight verso i servizi esposti http://devleaprob.cloudapp.net/SpeakerService.svc e http://devleaprob.cloudapp.net/sessionService.svc al posto dei vecchi url ospitati sul sito ufficiale di DevCon.
Chiaro che il compito è stato molto facile in quanto, non avendo una struttura dati sottostante, non c'è stato bisogno di adattamenti particolari: da quì lo Step 2.
Per complicarci la vita :-), l'idea di appoggiare i dati al Cloud Storage offerto da Windows Azure.
Grazie alla corretta progettazione della soluzione è stato semplicissimo creare uno strato DalCloud che rispettasse le interfacce definite. Quindi è stato creato il progetto DevLeap.DevCon09.Dal.Cloud che tramite la classe SpeakerDal gestisce i dati nel Cloud Storage. Più in basso un estratto di codice.
Il diagramma SD della parte server si è quindi arricchito del nuovo DAL:
Il nuovo componente DalCloud si preoccupa di lavorare con le entità Speaker e Session memorizzate nel Cloud Storage. Il nuovo progetto (DevCon2009_WebRole) rappresenta l'applicazione da portare su Windows Azure ed è stato creato tramite il template Web Role di Visual Studio.
Visto che il componente pluggabile Dal viene scelto in base al file di configurazione la nostra solution è adesso in grado di:
1) Essere ospitata in the cloud e usare il vecchio DalInMemory
2) Essere ospitata in the cloud e usare il Cloud Storage tramite DalCloud
3) Essere ospitata on-premise sul sito DevCon ufficiale e usare il vecchio DalInMemory
4) Essere ospitata on-premise sul sito DevCon ufficiale e usare però il DalCloud: visto che l'accesso al Cloud Storage viene effettuato via REST (o Data Service) è possibile accedere ai dati nel cloud da una soluzione locale.
La riprova di quello che diciamo da sempre: le cose cambiano, le tecnologie vanno avanti e l'unico segreto è progettare bene le applicazioni potendo intervenire solo nei punti necessari; in questo caso abbiamo rivisto solo il Dal per lavorare con il Cloud Storage e non abbiamo dovuto toccare nient'altro. Se, presi dalla fretta di uscire con il sito di DevCon a ottobre, avessimo fatto le cose al volo con Drag&Drop o strumenti automatizzati, non sarebbero bastate le 2 ore che ho impiegato stanotte per eseguire il porting in the cloud. Un domani che decideremo di creare anche un database SQL Server locale oppure decideremo di appoggiarsi a SQL Services in the cloud dovremmo ancora una volta creare solo un nuovo strato di accesso ai dati e cambiare una riga nel config.
La nostra solution è diventata quindi questa:
Per l'accesso ai dati ho usato le classi helper per adesso fornite insieme ai sample dell'SDK di Windows Azure (progetto StorageClient caricato direttamente dalla directory dell'SDK), in modo da non dover comporre a mano interrogazioni REST verso i servizi. Avendo però una architettura così flessibile sarebbe semplice fornire un Dal che accede ai dati via Rest, così come modificare il ServiceAgent lato client Silverlight per eseguire chiamate REST (o via ADO.NET Data Service) direttamente sul Cloud Storage (che appunto è esposto in entrambe le modalità.
Ecco il codice che lavora con il Cloud Storage:
In questo esempio ho usato un ciclo foreach per mappare le entità memorizzate nelle table del Cloud Storage rispetto alle entità applicative. Si può usare tranquillamente una query LINQ visto che dal contesto ho restituito un IQueryable<SpeakerStorageEntity> tramite la proprietà context.Speakers. Ho lasciato questo codice per una facile comprensione anche a chi non usa LINQ.
Una delle cose più interessanti dello sviluppo su Windows Azure è la possibile di eseguire il publish della soluzione sull'ambiente di staging, verificarne le funzionalità e poi portarlo in produzione. Ecco l'immagine del "manage" delle applicazioni su Windows Azure per spiegare meglio il concetto:
Come si nota la prima versione dell'applicazione (quella indicata all'inizio che usava il vecchio DalInMemory) è stata pubblicata sul server di Staging che viene esposto tramite guid.cloudapp.net; dopo averne verificato il funzionamento tramite l'icona di swap è possibile portare l'applicazione in produzione. Al momento un cui ho sviluppato il nuovo DalCloud, dopo averlo testato in locale sul Development Fabric e Development Storage, ho eseguito nuovamente il Deploy sul server di staging; verificate le funzionalità in the cloud sul server di staging, basta premere l'icona di swap per portare la versione stating in production e riportare la versione presente in production sul server di staging: questa funzionalità è molto comoda in quanto se qualcosa non va nell'applicazione in produzione è possibile tornare alla versione funzionante riswappando (si dice in italiano ?) i due ambienti. Nell'immagine si nota come la Iteration 2 del progetto sia adesso in produzione, mente la vecchia versione sia sull'ambiente di staging.
Per chi è interessato allo sviluppo in the cloud, proponiamo il corso Developing in the Cloud Preview che in giorno consente di apprendere le modalità di sviluppo, gli strumenti necessari/utili, il Cloud Storage, servizi .NET Services (Workflow, Service Bus, Access Control) esposti dalla piattaforma e Sql Services.
Affrontiamo questi temi anche alla DevCon 2009 (il cui sito è in the cloud, ma le sessioni verranno tenuto nella realtà :-)) durante una sessione plenaria che ha l'obiettivo di partire da zero e arrivare alla comprensione dell'applicazione che appunto potete già vedere in the cloud.