Riprendo da dove avevo lasciato...

L'application model di Longhorn definisce i vari aspetti caratteristici di una applicazione in termini di:

• entry point
• flusso di controllo e di navigazione
• stato e risorse
• eventi
• isolamento
• distribuzione
• aggiornamento e rollback

Faccio una distinzione tra applicazioni Web e applicazioni Windows, anche se di fatto le differenze che esistono oggi tra le due tipologie di applicazione tendono a venir meno grazie al nuovo application model.

Nel primo caso il modello applicativo consente di scrivere applicazioni Web in modo non dissimile da quanto avviene già oggi. Ma il codice può utilizzare in modo completo il livello di presentazione fornito da Longhorn. Per questo una applicazione Web non differisce poi di molto da una applicazione Windows, se non per gli aspetti collegati alla distribuzione, ovvero per il fatto che una applicazione Web risiede in ogni caso su un server. Per il resto una applicazione Web può sfruttare i controlli client, supportare multimedia e grafica, gestire eventi, ecc.
Nel secondo caso il modello applicativo di Longhorn prevede che, sebbene sia installata localmente, l'applicazione può girare sia in modalità on-line sia in modalità off-line, all'interno del browser oppure come applicazione stand-alone. A proposito delle applicazioni Windows si parla anche di NavigationApplication, ma questo è un discorso che vorrei affrontare a parte in un post futuro.
Per realizzare un'applicazione in Longhorn occorre definirne il modello ad oggetti; lo si può fare sia in via programmatica tramite codice sia in maniera dichiarativa tramite l'uso del linguaggio di markup XAML che la vera novità del nuovo application model. Una volta compilato il codice e/o il markup, all'applicazione viene associato un manifest applicativo (in cui sono indicate le dipendenze e le parti costituenti dell'applicazione) e un manifest di deployment, che riferisce al manifest applicativo (ovviamente!), ma permette anche di definire il livello di isolamento e le direttive di aggiornamento dell'applicazione.

Vorrei spendere un paio di parole sulla compilazione...

La compilazione può essere eseguita in due modi al fine di produrre due tipologie di risultato diverse, pensate per scopi diversi. Prima tipologia: si parla di CAML, ovvero compiled XAML, quando i file XMAL relativi ad una applicazione vengono compilati al fine di ottenere semplicemente IL (Intermediate Language). Seconda tipologia: si parla di BAML, ovvero binary XAML (rappresentazione binaria di XAML), quando il risultato atteso dalla compilazione è un documento, ovvero un container ottimizzato per il download a scapito della velocità di esecuzione. Infatti BAML è molto più compatto rispetto a CAML e per questo i file BAML si scaricano più rapidamente. Per contro eseguire un file BAML comporta un overhead derivante dalle operazioni di parsing da parte dell'interprete a run-time al fine di generare l'albero delle istanze delle classi definite in esso.
Altro aspetto da sottolineare riguarda MSBuild. Che cosa è MSBuild? E' il nuovo sistema di build che va a sostituire il classico Make. MSBuild è in grado di acquisire le regole di compilazione dai file di progetto .proj. Queste regole sono espresse in XML secondo un preciso schema di validazione che prevede elementi quali PropertyGroup e Property, ItemGroup e Item, Import, Task e Target. Diciamo che MSBuild assomiglia a NAnt (dove è possibile definire le direttive del processo di compilazione in XML), ma rispetto a questo presenta degli aspetti che lo rendono superiore.

To be continued...