Il Compute Emulator

L'ambiente che sta facendo girare la nostra semplice applicazione è il simulatore locale di Windows Azure che si è installato con l'SDK e che prende il nome di Windows Azure Compute Emulator dalla versione 1.3 (prima di novembre 2010 l'emulatore si presentava come Development Fabric).

Figura 48. L'applicazione in funzione su un'istanza di Azure
(clic per ingrandire)

L'ambiente di simulazione consente di gestire più istanze emulando il comportamento del Fabric Controller e del relativo load balancer di Windows Azure: vengono utilizzati più processi per redirigere le richieste a diverse "applicazioni" che girano in contemporanea.

Ad esempio, provando a mettere 5 nel numero delle istanze (doppio click sul progetto evidenziato nell'immagine)

Figura 49. Aggiungere istanze
(clic per ingrandire)

e riavviando l'applicazione si ottengono 5 finestre di diagnostica sul simulatore.

Figura 50. Diagnostica del simulatore
(clic per ingrandire)

È sufficiente avviare il Task Manager per verificare i processi creati dall'emulatore con il nome di WaIISHost.exe.

Figura 51. I processi relativi alle istanze evidenziate nel Task Manager
(clic per ingrandire)

Come si nota sono presenti anche 5 istanze del debugger (WatDebugger.exe) oltre ai classici processi w3wp.exe in cui IIS sta facendo girare realmente la nostra applicazione di esempio.

Sono anche presenti 5 istanze del motore di diagnostica e alcuni processi che iniziano con DF: DF è l'acronimo di Development Fabric, che, fino a novembre 2010, come accennato in precedenaza, era il nome di quanto oggi conosciamo con Windows Azure Compute Emulator: in pratica, l'emulatore.

Figura 52. I processi "DF" del Development Fabric
(clic per ingrandire)

Ogni processo rappresenta una istanza in deploy e ogni istanza in deploy utilizza una directory diversa su disco per simulare l'accesso al disco fisso fisico della macchina che ospita l'instanza sul cloud.

In pratica l'ambiente, ad ogni operazione di deploy, crea una directory apposita e installa l'applicazione e le sue componenti all'interno di tale directory. È importante sottolineare che se vogliamo eseguire unit test, piuttosto che semplicemente controllare le operazioni effettuate dall'applicazione sulla directory corrente, è fondamentale controllare il numero di deployment per rintracciare la directory corretta sul file system.

Ad esempio:

C:UsersRobertobAppDataLocaldftmps0deployment(73)resdeployment(73).DevLeap.AzureBookManager.DevLeap.AzureBookManager.FrontEnd.0

rappresenta la directory locale dove l'emulatore ha effettuato il deploy della prima instanza (l'instanza zero) dell'applicazione.