Velocity è una cache out-of-process, distribuita su uno o più server, nel caso di utilizzo più server si parla di Cache Cluster.
Velocity, dal punto di vista “fisico”, è un Windows Service che deve essere installato su ciascun server appartenente al cluster. Ogni server offre una quota di risorse, in termini di memoria, da dedicare al servizio di cache distribuita. Il layer di comunicazione tra server e la tecnologia di clustering di Velocity è chiamata “Fabric”, affinchè questa possa comunicare è necessario che il “canale” privato di comunicazione tra server (tcp-port 22234) sia accessibile e libero da restrizioni (es. firewall). E’ inoltre necessario che sia accessibile il “canale pubblico”, dedicato al traffico dati (tcp-port 22233) dai CacheClient verso il cluster e viceversa.
Una volta lanciato il setup di Velocity, disponibile sia per architetture a 32 e 64 bit, è necessario impostare alcuni parametri indispensabili come il tipo di Configuration Store, il percorso o la Connection String dello stesso, le dimensioni del cluster in termini di server ed eventualmente il numero delle porte citate prima. Il parametro più significativo è la quantità di memoria che il server metterà a disposizione del cluster. Questa quantità viene inizialmente proposta dal setup, in base alle risorse disponibili, ma è possibile variarne l’entità.
Il Configuration Store di Velocity può essere di due tipi: MSSQL Server Compact Edition (.sdf) e DB di MSSQL Server. Questo è il contenitore della configurazione del cluster, sia in termini di partizioni logiche (variabili a seconda delle dimensioni del cluster) che di NamedCache ovvero contenitori logici usati dalle applicazioni. In ogni caso le informazioni contenute nel configuration store, non sono modificabili direttamente, ma solo in seguito all’esportazione in un file xml temporaneo, che deve essere successivamente reimportato in modo che le modifiche siano “salvate”.
nota: a seconda del tipo di configuration stor sarà necessario preparare una cartella condivisa, nel caso di SQL Server Compact Edition, oppure un database di SQL Server. Per ulteriori dettagli fare riferimento alla sezione “Installation and Deployment” della documentazione di Velocity.
Una volta predisposto il cluster, sarà possibile amministrarlo usando una console Powershell creata automaticamente in fase di setup. La cache di Velocity contiene un contenitore logico (namedCache) di default, utilizzabile immediatamente. Per creare una NamedCache personalizzata è sufficiente prima di tutto avviare il cluster con il comando:
start-cachecluster
quindi creare la NamedCache lanciando
new-cache –cacheName DemoCache
nota: eseguire powershell con i diritti amministrativi, per la sintassi e le opzioni dei comandi amministrativi, fare riferimento alla sezione “Cache Administration with PowerShell” della documentazione di Velicity.
Il cluster contiene ora la NamedCache appena creata, si procede quindi con la predisposizione di un’applicazione client che utilizzerà la cache.
Per utilizzare la client API di Velocity è sufficiente referenziare gli assemblies illustrati, prelevabili dalla cartella di installazione di Velocity, presente su uno dei server su cui è stato lanciato il setup.
Il codice seguente illustra l’utilizzo della client API sia in scrittura che in lettura:
Se fosse necessario, sarebbe possibile riutilizzare lo stesso codice da un’altra applicazione, stavolta WEB, che acceda alla stessa NamedCache e qundi agli stessi dati utilizzati da quella windows:
Come si nota dal codice di esempio, è necessario istruire l’api della composizione del cache cluster in termini nomi host, porta utilizzata per i dati e nome del servizio di Velocity. Successivamente si crea una DataCacheFactory che consente di specificare il tipo di client e l’abilitazione della cache locale, dettagli che saranno trattati nei successivi post.