July 2009 - Posts
Disponibili da un paio di giorni il nuovo SDK e la nuova serie di Tools per Visual Studio (versione July 2009).
Windows Azure SDK: http://www.microsoft.com/downloads/details.aspx?FamilyID=aa40f3e2-afc5-484d-b4e9-6a5227e73590&displaylang=en
VS Tools per Windows Azure: http://www.microsoft.com/downloads/details.aspx?FamilyID=8d75d4f7-77a4-4adf-bce8-1b10608574bb&displaylang=en
Non ci sono grosse novità dal punto di vista delle possibilità, ma gli strumenti sono sempre più stabili e consentono di velocizzare alcune operazioni che dovevano essere fatte manualmente nelle versioni precedenti. Da segnalare come novità l'integrazione con TFS Build del processo di creazione di un Cloud Service.
Per chi va in ferie, una buona lettura su questi strumenti è il capitolo 3 del nostro libro su Windows Azure: il libro esce a settembre, ma rendiamo disponibile da oggi il draft del capitolo 3 che abbiamo consegnato in anteprima ai partecipanti a DevCon 2009 e a Remix 2009: http://devlab.devleap.it/azure03.zip. Versione Draft indica che non ha subito nessun processo di revisione quindi contiene sicuramente errori grammaticali.
Microsoft ha reso pubblico il video della mia sessione al Remix 09 su Windows Azure: http://www.microsoft.com/italy/beit/Msdn.aspx?video=3630028e-e05e-4378-a858-5c5e132b7767
Per testare in locale una applicazione Windows Azure possiamo usufruire del Development Storage, ovvero l'ambiente installato dall'SDK che simula lo storage di Windows Azure in locale. Il Development Storage si appoggia a SQL Express (o SQL Server se preferite) utilizzando una sua struttura predefinita per accogliere Blob e Queue.
Per quanto riguarda le tabelle del Table Storage occorre invece creare una struttura ad-hoc che rappresenti le proprietà definite sull'entità .NET da memorizzare sullo storage. Per un progetto Web Role o Worker Role (in pratica per un progetto Azure) Visual Studio fornisce un comodissimo menù "Create Test Table" accessibile tramite il tasto destro sul progetto stesso. Questo menù crea in locale le tabelle e le colonne necessarie per ospitare la nostra entità applicativa.
Per la creazione delle tabelle in locale viene controllata la presenza di classi derivate da DataServiceContext dove sia presente una proprietà che restituisce IQueryable<T>, dove T sta per la definizione della classe. In pratica Visual Studio cerca le classi derivate e trovando nel progetto una classe derivata da TableStorageDataServiceContext (la classe base della libreria StorageClient) che a sua volta deriva da DataServiceContext prova a vedere se abbiamo esposto una proprietà IQueryable<T>; trovata questa proprietà, Visual Studio legge la classe <T> e individua le proprietà PartitionKey, RowKey e Timestamp che arrivano per derivazione da TableStorageEntity e le proprietà della nostra classe.Potremmo però decidere di sfruttare il Cloud Storage da una applicazione on-premise e di conseguenza aver bisogno del Development Storage per testare in locale l'applicazione. In questo caso, non possiamo però usufruire del meccanismo automatizzato di Visual Studio per creare le tabelle locali in quanto il menù Create Test Tables si abilita solo su un progetto Web Role o Worker Role: in questo caso ci possiamo appoggiare ad una utility a riga di comando che esegue il prezioso lavoro di Visual Studio; in realtà, anche Visual Studio, si appoggia a questa utility quando viene invocato il menù Create Test Tables.L’utility in questione è denominata DevtableGen.exe ed è accessibile dalla directory dell’SDK di Windows Azure.
"C:\Program Files\Windows Azure SDK\v1.0\bin\DevtableGen.exe"
/forceCreate "
/server:localhost\SQLExpress" "
/database:CloudService_02"
"obj\Debug\MyApp.dll;"
Il parametro /forceCreate serve per cancellare e ricreare lo store, /server indica l’istanza di SQL Server da utilizzare, /database è ovviamente il database; l’ultimo parametro è l’elenco degli assembly dove deve esssere cercata la classe derivata da DataServiceContext che esponga una proprietà IQueryable<T>.
Sono stati pubblicati i prezzi per le licenze a consumo della piattaforma Windows Azure: http://www.microsoft.com/azure/pricing.mspx
Con il termine SQL Azure si intende, ovviamente, SQL Server in the cloud, ovvero quello che fino a 3 giorni fa era SQL Services e fino a Marzo 2009, SQL Data Services.
Sotto la voce .NET Services troviamo invece il Service Bus e l'Access Control. Ricordo che settimana scorsa è stato reinviato alla versione 4.0 la possibilità di eseguire Workflow su Windows Azure.
Non è l'M3 BMW che agli appassionati di auto sarà sicuramente venuta in mente.
Dopo le modifiche uscite ieri con la nuova CTP dei .NET Services anche l'SDK per Java si aggiorna di conseguenza (alla Milestone 3...M3 appunto). Per chi non conosce jdotnetservice due info generali
1) Obiettivo come riportato sul sito ufficiale
The purpose of this project is to provide an interoperable open source software development kit(SDK) - set of libraries, tools, prescriptive patterns & guidance & real world sample applications that will enhance productivity for Java developers. Developers will be able to leverage the .NET Services to extend their Java applications by using the Microsoft cloud services platform to build, deploy and manage reliable, internet-scale applications.
2) Sito ufficiale e download http://jdotnetservices.com/. Se avete una solution .NET Service si può provare la demo live: https://www.jdotnetservices.com/SCMWebClient/
L'altra uscita, sempre di ieri è l'aggiornamento dell'SDK per Ruby, anch'esso con lo stesso obiettivo. Il sito ufficiale è http://www.dotnetservicesruby.com/.
L'aggiornamento di ieri, per chi lavora a mano riguarda la modifica del namespace X-PROCESS-AT che è stato "girato" da http://schemas.microsoft.com/ws/2007/08/connect/roles/relay to http://schemas.microsoft.com/netservices/2009/05/servicebus/connect/roles/relay.
Per chi non ha voglia di scoprire da solo quali sono le modifiche alle classi e API della versione uscita oggi dell'SDK per i .NET Services ecco un prve riepilogo:
Nel namespace ServiceRegistry si trovano alcune nuove classi che rimpiazzano alcune classi esistenti:
ServiceRegistryGetRequest -> ServiceRegistryGetMessage
ServiceRegistryGetResponse -> ServiceRegistryGetResponeMessage
ServiceRegistryPutRequest -> ServiceRegistryPutMessage
ServiceRegistryDeleteRequest -> ServiceRegistryDeleteMessage
La proprietà DefaultRelayHostName è stata rimossa.
I namespace esterni sono stati modificati:
Queue Policy http://schemas.microsoft.com/ws/2007/08/connect
http://schemas.microsoft.com/netservices/2009/05/servicebus/connect
Router Policy http://schemas.microsoft.com/ws/2007/08/connect
http://schemas.microsoft.com/netservices/2009/05/servicebus/connect
X-PROCESS-AT http://schemas.microsoft.com/ws/2007/08/connect/roles/relay
http://schemas.microsoft.com/netservices/2009/05/servicebus/connect/roles/relay
Sono stati aggiornati anche alcuni limiti sull'utilizzo della CTP corrente: direttamente dal portale
Length of use
2000 VM hours
Active listeners per solution
25
Concurrent subscribers per router
50
Queue capacity
2 MB
Maximum message size
60 K
Come annunciato da circa un mese, oggi viene rimosso il supporto a Workflow dalla Azure Services Platform. L'area denominata .NET Services da oggi farà riferimento al Service Bus e al STS denominato Access Control.
Il motivo della rimozione dalla CTP che esce oggi è semplice: il runtime attuale si basava sulla versione 3.5 di Workflow Foundation e visto che la prossima versione sarà profondamente rivista rispetto alla attuale, anche la versione "in the cloud" verrà aggiornata alla versione 4.0. Dalle notizie ufficiali attuali sembra quindi che non uscirà mai una versione dei .NET Workflow Service che supporti workflow in versione 3.5, ma uscirà direttamente (e non prima dell'uscita di .NET 4.0) il supporto alla prossima versione.
Dal mio modesto punto di vista credo sia una mossa giusta, anche se, alla notizia del 12/6 c.a., ero rimasto stupito: ci sono molte applicazioni basate su Workflow 3.0/3.5 attualmente nelle aziende e l'idea di portarle in the cloud ha sicuramente un senso; il problema è che chi ha (come noi di DevLeap ad esempio) applicazioni 3.0/3.5 ha già fatto un pesante lavoro per la creazione degli ambienti di host del runtime quindi ha già investito nelle aree dove Azure consente di risparmiare. I workflow per essere portati in the cloud hanno bisogno di essere aggiornati con le activity specifiche per ricevere messaggi sull'endpoint pubblico esposto da Azure Services Platform. Di conseguenza, credo che tutti concordino sul tenere le applicazioni attuali basate su Workflow Foundation on-premise visto anche le pesanti modifiche che ci attendono per portare i workflow alla versione 4.0: sarà questo il momento in cui, avendo i workflow sul tavolo operatorio, a cuore aperto, avrà senso aggiungere le activity "for the cloud" e rendere il workflow sia 4.0 che Azure compliant.