Tra i possibili tipi di applicazione che possono beneficiare di una cache distribuita come quella di Velocity, ci sono sicuramente le applicazioni Asp.Net, che dispongono già di una cache (quella appunto di ASP.Net) matura, stabile e con un ricco set di funzionalità che la completano.
Esaminando la tabella comparativa, si noterà che molte delle features della cache di ASP.Net non sono coperte da Microsoft Velocity, quest’ultimo framework, infatti, non ha l’obiettivo di sostituire la cache di ASP.NET.
Quali sono dunque i punti di contatto tra ASP.Net e Microsoft Velocity? Questa immagine prova ad illustrarlo:
Il team di Velocity ha realizzato il session provider Microsoft.Data.Caching.DataCacheSessionStoreProvider, in grado di sfruttare il cluster e la relativa cache distribuita per memorizzare le sessioni di ASP.Net.
E’ da sottolineare che cache e session non sono la stessa cosa, sinteticamente: la prima si utilizza per evitare ad esempio roundtrip sullo storage ed in genere per migliorare le prestazioni di una applicazione, mentre la seconda serve per rendere stateful un’applicazione.
Il cluster di Velocity si affianca quindi ai più noti session provider InProc, StateServer e SQLServer, offrendo un’alternativa scalabile, performante ed affidabile grazie soprattutto alla High-Availability (descritta nel precedente post), che permette di tollerare situazioni di “guasto” all’interno ad esempio di una web farm.
Per utilizzare il Session Provider di Velocity, occorre prima creare una named cache, utilizzando Powershell ed avendo facoltà di abilitare o meno l’HA:
new-cache -CacheName session -Secondaries 1
E’ sufficiente quindi agendo sul web.config, istruire ASP.Net ad utilizzare il provider di sessione di Velocity:
…impostare alcuni settaggi aggiuntivi riguardanti la Client API:
…il puntamento al cluster, che nel caso di questa applicazione web assolve il duplice ruolo di web server e di cache host
…infine il logging:
A questo punto, l’applicazione web utilizzerà, in maniera trasparente, il cluster di Velocity per memorizzare tutte le sessioni. E’ comunque possibile sfruttare parallelamente Velocity come cache “classica”, memorizzando ad esempio il catalogo prodotti che, come spiegato nel primo post, sarà caricato in cache una sola volta per tutti i client, in questo caso le diverse istanze della web application in esecuzione sui diversi server della farm.
La sequenza di screenshot sotto riportata, simula la navigazione di un’applicazione ASP.Net richiedendo la stessa pagina da 3 Web Server differenti, dimostrando come la sessione (cookieless solo per scopi dimostrativi) sia di fatto gestita da Velocity.
Utilizzando infine la Client API, nelle ultime 3 screenshot, è stato dimostrato un esempio di condivisione della cache out-of-process di Velocity tra diversi tipi di applicazione in questo caso ASP.Net e WinForm.
