Introduzione a .NET Framework 3.0

David Chappell
Chappell & Associates

Luglio 2006

Relativo a:
.NET Framework 3.0 (precedentemente noto con il nome WinFX)
Sviluppo Windows

Riepilogo: Microsoft .NET Framework 3.0 offre un'ampia gamma di innovative tecnologie, ognuna espressamente indirizzata a soddisfare le attuali esigenze nell'ambito dello sviluppo di applicazioni (29 pagine stampate).

In questa pagina

Descrizione di .NET Framework 3.0 Descrizione di .NET Framework 3.0
Scenario di applicazione di .NET Framework 3.0 Scenario di applicazione di .NET Framework 3.0
Tecnologie di .NET Framework 3.0 Tecnologie di .NET Framework 3.0
Opzioni di distribuzione di .NET Framework 3.0 Opzioni di distribuzione di .NET Framework 3.0
Conclusioni Conclusioni
Per saperne di più Per saperne di più

Descrizione di .NET Framework 3.0

L'obiettivo dello sviluppo software è sempre lo stesso: creare le migliori applicazioni nei tempi più brevi Tuttavia, lo standard qualitativo richiesto è sempre più elevato, dal momento che le piattaforme di sviluppo migliorano di giorno in giorno. In Windows, ad esempio, l'interfaccia originale Win32 è stata inglobata nella più funzionale interfaccia .NET Framework. La versione .NET Framework 1.0 del 2002 e la versione .NET Framework 2.0 del 2005 offrivano entrambe un ambiente di sviluppo notevolmente migliorato e più produttivo per gli sviluppatori di software Windows.

.NET Framework 3.0, precedentemente noto con il nome WinFX, rappresenta l'ultima fase di questa evoluzione. Le applicazioni basate su questa nuova versione del framework possono essere create con Visual Studio 2005, strumento abituale per la maggior parte degli sviluppatori Windows. .NET Framework 3.0 rappresenta inoltre un'evoluzione a sé stante, poiché aggiunge caratteristiche innovative a quelle già disponibili nella versione 2.0. Dopo il rilascio, previsto per la fine del 2006, .NET Framework 3.0 sarà disponibile per Windows Vista, Windows Server 2003 e Windows XP.

Questo documento offre un quadro completo di .NET Framework 3.0 e dei relativi componenti, allo scopo di illustrare le caratteristiche della nuova versione, esaminare le modalità di utilizzo delle tecnologie disponibili e fornirne al tempo stesso una breve spiegazione.

Le sfide inerenti allo sviluppo di moderne applicazioni

Oggi anche la creazione di una normale applicazione non è cosa da poco, e presuppone requisiti rigorosi. Pur mantenendo la loro importanza, i tradizionali aspetti relativi all'utilizzo dei dati memorizzati e alla possibilità di accesso tramite un browser Web non sono più sufficienti. Inoltre, le applicazioni moderne pongono tutta una serie di nuove problematiche, come quelle illustrate di seguito.

  • Le organizzazioni hanno una visione delle attività sempre più orientata ai processi. Poiché con la maggior parte delle applicazioni i processi di business vengono parzialmente automatizzati, può risultare utile che gli aspetti automatizzati siano resi espliciti a livello di codice. A tale scopo, un metodo efficace è rappresentato dall'utilizzo di tecnologie per il flusso di lavoro, un approccio che richiede il supporto di applicazioni basate su flussi di lavoro.

  • Le applicazioni in genere comunicano tra loro, sia all'interno che all'esterno dell'organizzazione. Inoltre, i programmi più recenti devono spesso conformarsi ad un'architettura orientata ai servizi (SOA, Service-Oriented Architecture), esponendo parte delle proprie funzionalità come servizi interoperabili accessibili da altre soluzioni. La realizzazione di questi obiettivi richiede il supporto di applicazioni orientate ai servizi.

  • Gli utenti delle applicazioni necessitano in genere di un metodo per comunicare la propria identità. Le tecnologie disponibili per la definizione e l'utilizzo di identità digitali sono numerose e i problemi come gli attacchi di phishing sono frequenti. Pertanto, le applicazioni attuali e i relativi utenti necessitano di un controllo efficace dell'identità digitale per gli utenti.

  • Un'interfaccia utente moderna richiede caratteristiche nettamente superiori rispetto al passato. Per offrire un reale valore di business, è in genere necessario elaborare documenti di vario tipo, utilizzare elementi grafici a due o tre dimensioni, visualizzare filmati e altro ancora. Tutti questi elementi devono inoltre essere accessibili sia per i client Windows nativi che per i browser Web. Per soddisfare queste esigenze è necessario un approccio unificato a interfacce utente diverse.

Dal momento che le attuali applicazioni devono affrontare una se non tutte queste problematiche, anche la piattaforma su cui vengono sviluppate deve essere in grado di fornire gli strumenti per affrontare tali sfide attraverso metodi coerenti ed efficienti. L'obiettivo di .NET Framework 3.0 per le applicazioni Windows è esattamente questo.

L'approccio di .NET Framework 3.0 alla risoluzione delle problematiche

Come illustrato nella figura 1, la versione di .NET Framework 3.0 è basata sulla release precedente. Di fatto, non essendo stato modificato nulla della versione 2.0, le applicazioni già esistenti sviluppate su questa piattaforma continueranno a funzionare senza problemi. Tuttavia, .NET Framework 3.0 introduce quattro nuovi componenti: Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace e Windows Presentation Foundation. In questa sezione verrà fornita una breve panoramica delle caratteristiche offerte da .NET Framework 2.0 e da ciascuno dei nuovi componenti.

.
Figura 1

Figura 1: .NET Framework 2.0, la piattaforma per le applicazioni Windows

Benché sia tuttora possibile scrivere soluzioni che utilizzano direttamente l'interfaccia Win32, .NET Framework è diventato l'ambiente più comunemente utilizzato per lo sviluppo delle nuove applicazioni Windows. Di seguito sono elencati i componenti più importanti.

  • ASP.NET, che supporta la creazione di applicazioni accessibili dal Web.

  • ADO.NET, che consente alle applicazioni di accedere a vari tipi di dati, inclusi i dati relazionali.

  • Windows Form, che supporta la creazione di interfacce utente di tipo grafico (GUI, Graphical User Interface) per applicazioni Windows.

  • System.XML, che consente alle applicazioni di interagire con dati in formato XML, utilizzando lo standard XSLT e il linguaggio XPath.

Rispetto alla versione precedente, .NET Framework 2.0 aggiungeva diverse utili funzionalità, inclusa una tecnologia notevolmente migliorata per la creazione di applicazioni Web ASP.NET, il supporto per le applicazioni a 64 bit in esecuzione su sistemi Windows a 64 bit e un nuovo metodo alla gestione delle transazioni. Come descritto più avanti, mentre alcune parti di .NET Framework 2.0 risultano decisamente obsolete rispetto ai nuovi componenti della versione 3.0, le tecnologie della versione 2.0 rimangono un aspetto fondamentale anche in questa nuova release.

Windows Workflow Foundation: supporto di applicazioni basate sui flussi di lavoro

Il concetto di "flusso di lavoro" è semplice: una serie di operazioni eseguite in un certo ordine. Qualcuno potrebbe persino obiettare che, dal momento che eseguono un processo, tutte le applicazioni implementano un flusso di lavoro. Tuttavia, l'approccio tradizionale alla creazione di applicazioni in C# o Visual Basic o in altri linguaggi di programmazione consiste nel rendere implicite a livello di codice le varie fasi dei processi. Si tratta di un metodo indubbiamente efficace, ma il fatto di incorporare il processo in una logica di programma lo rende difficile da implementare e modificare.

L'utilizzo di tecnologie per il flusso di lavoro per l'implementazione di una logica dei processi può rivelarsi un metodo efficace per risolvere questo problema. Anziché inserire la logica all'interno di codice ordinario, le varie fasi dei processi vengono definite esplicitamente e quindi eseguite da un motore del flusso di lavoro. Il risultato è un'implementazione ottimizzata dei processi stessi.

I motori del flusso di lavoro non rappresentano una novità; attualmente, ne esistono diversi destinati a Windows e altri sistemi, senza contare inoltre che in alcuni prodotti Microsoft ne esistono di già incorporati. Tuttavia, dal momento che l'approccio basato sui flussi di lavoro sta diventando il più diffuso per lo sviluppo di applicazioni, l'ipotesi di fornire un'unica tecnologia per il flusso di lavoro per Windows appare sensata. Windows Workflow Foundation, il cui acronimo ufficiale è WF, ha esattamente questo scopo. Offrendo un'unica tecnologia per il flusso di lavoro per Windows, WF costituisce la piattaforma di sviluppo per tutte le applicazioni basate sui flussi di lavoro e sarà utilizzato da tutte le soluzioni Microsoft, incluse le applicazioni 2007 Microsoft Office system e Windows SharePoint Services, nonché dalle applicazioni di altri produttori.

Tuttavia, l'utilizzo di un'unica tecnologia per il flusso di lavoro non è privo di problematiche. Ad esempio, come può un singolo approccio soddisfare tutti i requisiti delle diverse applicazioni basate sui flussi di lavoro? La risposta di WF consiste in un approccio generalizzato all'elaborazione di un generico flusso di lavoro. Come illustrato nella figura 2, un flusso di lavoro di WF altro non è che un gruppo di attività eseguite dal motore WF. Ogni attività è rappresentata da una classe e può contenere qualsiasi operazione ritenuta necessaria dall'autore del flusso di lavoro. Le attività possono essere riutilizzate in diversi flussi di lavoro, semplificando in tal modo l’eventuale modifica di soluzioni automatizzate per gestire nuove necessità.

Figura 2

Figura 2

Un'altra problematica legata all'offerta di una tecnologia comune per il flusso di lavoro è rappresentata dalla tradizionale separazione tra flussi di lavoro umani e di sistema. Le applicazioni basate sui flussi di lavoro utilizzate prevalentemente dagli utenti devono essere flessibili e consentire operazioni come la modifica dei processi in corso. Invece, quelle utilizzate principalmente dai sistemi, ovvero dalle soluzioni software, tendono a essere più statiche, ma devono offrire la massima efficienza. Essendo progettato per entrambi i tipi di utilizzo, WF include caratteristiche orientate alle persone, come la capacità di modificare i flussi di lavoro in fase di esecuzione, accanto al supporto per comportamenti più orientati al sistema.

Offrendo con WF una tecnologia per il flusso di lavoro comune a tutte le applicazioni Windows, .NET Framework 3.0 rende disponibile per tutti gli sviluppatori questo utile paradigma per lo sviluppo di soluzioni software. Con la diffusione di una concezione del software sempre più orientata ai processi, l'utilizzo dei flussi di lavoro è destinato ad aumentare.

Windows Communication Foundation: supporto di applicazioni orientate ai servizi

Indipendentemente dal fatto che sfruttino o meno un motore di workflow, la maggiora parte delle applicazioni necessitano di comunicare tra di loro. Negli ultimi anni i metodi che rendono possibile tale comunicazione hanno compiuto un notevole passo avanti, grazie alla decisione dei principali produttori di supportare, dopo anni di disaccordo, protocolli comuni per la comunicazione tra applicazioni. Basato sul protocollo SOAP, questo accordo globale sui Web service semplifica notevolmente l'interoperabilità fra applicazioni sviluppate su diverse piattaforme, quali J2EE e .NET Framework. Grazie a questa standardizzazione l'idea di un'architettura orientata ai servizi è ora molto più percorribile per la maggior parte delle organizzazioni.

Naturalmente, esiste già un gran numero di tecnologie per la comunicazione tra applicazioni. In .NET Framework 2.0, ad esempio, è possibile scegliere fra le seguenti tecniche:

  • Web service ASP.NET, che consentono comunicazioni interoperabili basate su SOAP.

  • .NET Remoting, focalizzato sulla comunicazione tra applicazioni .NET.

  • Enterprise Services, che offre il supporto per applicazioni transazionali scalabili.

  • System.Messaging, che supporta i messaggi accodati tramite Microsoft Message Queuing (MSMQ).

  • Web Services Enhancements (WSE), un'estensione dei Web service ASP.NET che fornisce il supporto per le specifiche più recenti, ad esempio WS-Security.

Tutte queste tecnologie sono ugualmente valide e ognuna riveste un ruolo specifico. Ma perché esistono diverse soluzioni per affrontare essenzialmente lo stesso problema? Perché non creare invece un'unica piattaforma per la comunicazione tra applicazioni basata su servizi interoperabili?

Questa è esattamente la funzione di Windows Communication Foundation (WCF). Anziché costringere gli sviluppatori a utilizzare tecnologie diverse con API (Application Programming Interface) diverse a seconda del tipo di comunicazione, WCF, precedentemente noto con il nome in codice "Indigo", offre un approccio comune basato su un'unica API. Nell'ambiente .NET Framework 3.0, la maggior parte delle applicazioni comunicherà tramite WCF, invece di utilizzare una delle tecniche elencata precedentemente.

WCF fornisce ampio supporto per la comunicazione interoperabile tramite SOAP, caratteristica essenziale degli ambienti di elaborazione attuali. Le funzionalità disponibili includono il supporto per varie specifiche WS-*, tra cui WS-Security, WS-ReliableMessaging e WS-AtomicTransaction. Tuttavia, WCF non richiede SOAP, pertanto è possibile utilizzare altri metodi, incluso un protocollo binario ottimizzato, l'accodamento di messaggi tramite MSMQ e semplici comunicazioni basate su REST. WCF segue inoltre un approccio alle comunicazioni esplicitamente orientato ai servizi. Anziché fornire un contesto trasparente alle comunicazioni tra gli oggetti, WCF astrae la complessità interponendo il modello a servizi tra le parti comunicanti. Uno degli obiettivi di questo approccio è sciogliere alcuni degli accoppiamenti rigidi che possono presentarsi nei sistemi a oggetti distribuiti, riducendo la possibilità di errori e facilitando la modifica delle interazioni.

La capacità delle applicazioni di comunicare in una singola azienda o fra varie organizzazioni rappresenta un aspetto fondamentale del software recente. .NET Framework 3.0 risolve questa sfida grazie all'approccio orientato ai servizi di WCF.

Windows CardSpace: controllo efficace delle identità digitali degli utenti

Nella maggior parte dei casi, su Internet l'identità digitale degli utenti è rappresentata semplicemente da un nome utente. Questa identità, associata a una password, viene utilizzata per accedere ad account di posta elettronica, negozi e persino banche o altri istituti finanziari online. Tuttavia, benché siano semplici da utilizzare ovunque, nomi utente e password presentano alcuni svantaggi. Di seguito sono illustrati i due più importanti.

  • Gli utenti faticano a ricordare tutti i nomi utente e le password per i diversi siti. Per risolvere il problema, molti utilizzano gli stessi valori per tutti i siti, andando però incontro a maggiori rischi per la sicurezza.

  • Nomi utente, password e altre informazioni personali possono essere sottratti attraverso un attacco di phishing: viene inviato un messaggio e-mail contraffatto per indurre la vittima dell'attacco a effettuare l'accesso a un sito Web che riproduce, ad esempio, il sito della banca dell'utente. In genere, il sito contraffatto viene controllato dal phisher, che può quindi utilizzare il nome utente e la password della vittima per accedere al sito reale.

Per ridurre le conseguenze di questi problemi, è necessario adottare un nuovo approccio per la gestione delle identità digitali, di cui Windows CardSpace, precedentemente noto con il nome in codice "InfoCard", è parte integrante. Per aiutare gli utenti a tenere traccia delle proprie identità digitali, viene infatti creata una scheda di informazioni per ciascuna di esse. Nei siti Web che accettano la registrazione mediante CardSpace, ogni volta che un utente tenta di effettuare l'accesso viene visualizzata una schermata di selezione di CardSpace come quella illustrata nella figura 3. Ogni scheda corrisponde a un'identità digitale che l'utente può scegliere per accedere al sito. In tal modo, anziché memorizzare tutta una serie di nomi utente e password, gli utenti possono limitarsi a selezionare la scheda da utilizzare. Inoltre, dal momento che ogni scheda può contenere informazioni diverse, gli utenti sono in grado di sapere esattamente quali informazioni sono state trasmesse ai vari siti.

Figura 3

Figura 3

Le identità rappresentate dalle varie schede vengono create da uno o più provider di identità. Qualsiasi organizzazione può offrire provider di identità e, anziché limitare le identità fornite a semplici nomi utente e password, vengono in genere utilizzati meccanismi avanzati di crittografia per l'identificazione degli utenti. Anche CardSpace include un provider di identità eseguibile sui computer client, grazie al quale gli utenti possono creare identità la cui autenticazione non dipende da una password. Invece che adottare il classico approccio basato su password, i siti Web possono accettare le identità di CardSpace generate automaticamente per ridurre i potenziali problemi associati all'identificazione tramite password.

Se l'accesso a un sito non prevede l'utilizzo di password, i phisher non saranno in grado di sottrarre informazioni di questo tipo. Tuttavia, se un phisher riesce a indurre un utente ad accedere a un sito fittizio, potrebbe entrare in possesso di altre informazioni personali, ad esempio di natura medica. Per prevenire questo problema, è necessario che gli utenti siano in grado di distinguere i siti reali da quelli creati espressamente per gli attacchi di phishing. A tale scopo, l'organizzazione proprietaria di un sito Web può ottenere un certificato di garanzia elevata, un nuovo tipo di certificato il cui processo di acquisizione, diversamente dai semplici certificati SSL attuali, è molto più rigoroso e include una severa procedura di verifica dell'identità dell'organizzazione che lo richiede. Un certificato di questo tipo può inoltre contenere il logo della società, insieme ad altre informazioni, per consentire agli utenti di stabilire se il sito che lo utilizza sia legittimo o meno. Quando un utente accede a un nuovo sito, CardSpace visualizza in una schermata standard le informazioni contenute nel certificato del sito stesso. In base all'attendibilità del certificato, in questa schermata verranno indicati diversi livelli di garanzia dell'identità del sito. L'obiettivo è incoraggiare gli utenti a decidere esplicitamente l'attendibilità di un sito, aiutandoli quindi a identificare i siti che è effettivamente possibile considerare attendibili.

In realtà, Windows CardSpace rientra in un più ampio metasistema delle identità. Interamente basato su protocolli pubblici aperti, questo metasistema definisce un metodo per utilizzare in maniera coerente diverse tecnologie di identità digitale tra diverse piattaforme, inclusi i sistemi operativi diversi da Windows, e diverse applicazioni, tra cui browser Web diversi da Internet Explorer. Offrendo un metodo comune per la selezione delle identità, oltre ad altre caratteristiche per Windows, CardSpace occupa un ruolo fondamentale all'interno del metasistema e, risolvendo il problema basilare dell'identità, riveste una posizione di primo piano anche nell'ambito di .NET Framework 3.0.

Windows Presentation Foundation: approccio unificato a interfacce utente diverse

L'interfaccia utente è un componente importante di quasi tutte le applicazioni, chiamata a soddisfare le esigenze di utenti con aspettative sempre maggiori. Accanto alle tradizionali interfacce grafiche a menu, le applicazioni possono trovarsi a dover visualizzare filmati, eseguire animazioni, utilizzare elementi grafici a due o tre dimensioni e accedere a documenti di vario tipo. Tutte queste operazioni devono essere possibili indipendentemente dalla modalità di accesso, ad esempio da un client desktop standalone oppure tramite un browser Web.

Ad oggi, sono disponibili diverse modalità per programmare l'interfaccia utente in Windows. Ad esempio, uno sviluppatore può utilizzare Windows Form in .NET Framework per generare un'interfaccia utente grafica Windows. La creazione di un'interfaccia basata su browser richiede l'utilizzo di codice HTML e in alcuni casi di applet Java o codice JavaScript. La visualizzazione di filmati può essere eseguita in Windows Media Player o utilizzando il software Flash Player di Adobe, mentre i documenti possono essere salvati nei formati di Microsoft Word, nel formato PDF di Adobe o altri ancora. Il problema, per gli sviluppatori, è chiaro: generare un'interfaccia coerente per diversi tipi di client utilizzando diverse tecnologie non è per niente facile.

L'obiettivo primario di Windows Presentation Foundation (WPF), in precedenza noto con il nome in codice "Avalon", è risolvere questa problematica. Offrendo una solida base tecnica per tutti gli aspetti dell'interfaccia, WPF semplifica notevolmente le attività di sviluppo. Grazie a un approccio più evoluto, che include il supporto per la riproduzione di filmati, animazioni, elementi grafici a due o tre dimensioni e diversi tipi di documenti, gli utenti possono contare su nuove modalità di utilizzo delle informazioni. Inoltre, fornendo una piattaforma comune per client desktop e browser, WPF semplifica lo sviluppo di applicazioni compatibili con entrambi.

La figura 4 fornisce un esempio di interfaccia realizzata tramite WPF includendo immagini, grafica live e tridimensionale e molto altro ancora. Anziché dover disporre delle competenze necessarie per le diverse tecnologie, gli sviluppatori possono creare interfacce di questo tipo in maniera più coerente.

Figura 4

Figura 4

Uno dei problemi che da tempo gli sviluppatori di interfacce utente si trovano ad affrontare è strettamente legato ai diversi ruoli richiesti per lo sviluppo di interfacce efficaci. Gli sviluppatori software sono necessari per creare la logica alla base dell'interfaccia, ma raramente sono in grado di definirne anche l'aspetto. I designer, specialisti dell'interazione tra computer e persone, rappresentano in genere la figura più indicata per questo ruolo. Tuttavia, le tecnologie meno recenti, come Windows Form, sono focalizzate interamente sullo sviluppatore e d'altra parte non esiste alcun metodo realmente efficace di collaborazione tra sviluppatori e designer. Per risolvere questo problema, WPF si fonda su XAML (eXtensible Application Markup Language), un linguaggio basato su XML che consente di specificare l'interfaccia utente in modo dichiarativo, anziché a livello di codice. Grazie a ciò, è notevolmente più semplice creare e utilizzare con gli strumenti disponibili una specifica di interfaccia basata su una rappresentazione grafica eseguita da un designer. Di fatto, espressamente a questo scopo, Microsoft ha realizzato un prodotto innovativo, denominato Expression Interactive Designer, che insieme ad altre soluzioni di terze parti consentirà ai designer di definire l'aspetto grafico di un'interfaccia e di ottenerne automaticamente una definizione XAML che gli sviluppatori possono importare direttamente in Visual Studio, in fase di sviluppo, per creare la logica richiesta.

Una volta creata un'applicazione WPF standalone, eseguibile direttamente in Windows, gli sviluppatori possono accedere a qualsiasi funzionalità di WPF. Tuttavia, per creare un'applicazione client eseguibile all'interno di un browser Web, è necessario innanzitutto sviluppare un'applicazione browser XAML, comunemente denominata XBAP.Basata sulla stessa piattaforma delle applicazioni WPF standalone, un'applicazione XBAP consente di riprodurre lo stile dell'interfaccia utente all'interno di un'applicazione browser scaricabile. Se lo desiderano, gli sviluppatori possono addirittura utilizzare lo stesso codice per entrambi i tipi di applicazioni, senza dover disporre necessariamente di competenze diverse per client desktop e browser. Come tutte le applicazioni Internet di questo tipo, le applicazioni XBAP scaricate dal Web vengono eseguite in un sandbox sicuro, che limita le attività che l’applicazione può eseguire. Allo stesso tempo, nelle applicazioni XBAP è comunque consentito l'utilizzo di un nutrito sottoinsieme di funzionalità dell'interfaccia utente disponibili nelle applicazioni WPF standalone.

Sia le applicazioni WPF standalone che le applicazioni XBAP includono il supporto per le più recenti tecnologie grafiche di WPF, inclusa l'accelerazione hardware, il supporto della grafica vettoriale e altro ancora. Grazie alle potenti funzionalità di grafica, WPF consente di scegliere fra numerose opzioni di rappresentazione grafica dei dati non disponibili in Windows Form o altre tecnologie precedenti. Inoltre, WPF fornisce la base per XML Paper Specification (XPS), che definisce un formato standard per la visualizzazione, la distribuzione e la stampa di documenti a formato fisso.

L'interfaccia utente rappresenta una componente complessa e importante delle moderne applicazioni. Attraverso WPF, .NET Framework 3.0 offre una soluzione più completa e integrata per affrontare le problematiche poste dall'interfaccia. L'obiettivo è consentire a sviluppatori e designer, responsabili della creazione di interfacce, di lavorare in maniera più efficiente.

Scenario di applicazione di .NET Framework 3.0

Un modo per comprendere il funzionamento di un gruppo di tecnologie consiste nell'osservare un esempio del loro utilizzo. Si pensi, ad esempio, a un'applicazione che consenta a clienti e agenti di inoltrare la richiesta di una polizza assicurativa. L'implementazione di una simile applicazione con .NET Framework 3.0 avrebbe un aspetto simile a quello illustrato nella figura 5.

Figura 5

Figura 5

La logica di business dell'applicazione, illustrata in alto a sinistra, è implementata tramite un flusso di lavoro WF. La gestione delle richieste di copertura assicurativa è un processo articolato in più fasi, che include la valutazione della domanda rispetto alle regole di emissione dell'organizzazione, verificando eventualmente il credito del richiedente e ottenendo persino l'approvazione di un responsabile. Il flusso di lavoro implementa ciascuna fase sotto forma di attività, sfruttando di volta in volta il software necessario. Per accedere ai dati memorizzati, ad esempio, le attività del flusso di lavoro rappresentato utilizzano ADO.NET.

In questo caso, la compagnia assicurativa mette a disposizione un call center, attraverso il quale gli utenti possono inoltrare telefonicamente la richiesta. Il software client utilizzato dal personale del call center, illustrato in alto a destra, è implementato come applicazione WPF standalone. Tale client comunica con la logica di business dell'applicazione tramite WCF, sfruttando un protocollo binario ottimizzato per la comunicazione WCF-WCF. Come si osserva nella figura, il personale del call center utilizza Windows CardSpace per selezionare l'identità per l'accesso all'applicazione.

I clienti possono richiedere una copertura assicurativa direttamente dal Web, così come gli agenti possono inoltrare le varie domande. A questo scopo, l'applicazione utilizza ASP.NET per comunicare con i browser Web. Come si nota nell'angolo in basso a sinistra, i clienti che utilizzano Internet Explorer per accedere all'applicazione tramite una normale interfaccia HTML possono comunque utilizzare CardSpace per selezionare l'identità con cui desiderano presentarsi.

Anche i produttori di soluzioni di terze parti possono implementare un meccanismo di selezione dell'identità per altri browser e sistemi operativi client, estendendo il metasistema delle identità a client e browser Web non Windows.

Avendo bisogno di un'interfaccia più funzionale per accedere all'applicazione su Internet, gli agenti assicurativi possono utilizzare XBAP rispetto a una normale interfaccia HTML. Come si nota nella parte centrale inferiore della figura, questo tipo di interfaccia consente a questa tipologia di utenti di utilizzare buona parte delle funzionalità dell'interfaccia disponibili nell'applicazione desktop WPF utilizzata dal call center. Poiché entrambe le interfacce sono basate sulla stessa piattaforma, gli sviluppatori dell'applicazione possono riutilizzare lo stesso codice in entrambi i tipi di client. Inoltre, come avviene con client di altro tipo, gli agenti possono utilizzare CardSpace per selezionare l'identità con cui desiderano accedere all'applicazione.

Infine, è probabile che l'applicazione debba accedere ad altre applicazioni e viceversa. Se ad esempio per l'approvazione di un cliente è richiesta una verifica del credito, molto probabilmente tale verifica verrà eseguita effettuando una chiamata a un servizio esterno. In alternativa, l'applicazione può accettare le richieste direttamente da altri programmi, esponendo i servizi che queste applicazioni esterne possono richiamare. In casi come questi, illustrati in basso a destra, l'applicazione sfrutta WCF per comunicare utilizzando Web service standard. Il supporto per SOAP integrato in WCF rende l'interazione con queste applicazioni estremamente agevole, a prescindere dalla tecnologia con cui sono sviluppate.

Questo scenario offre un esempio di utilizzo di alcuni dei più importanti componenti di .NET Framework 3.0 in una normale applicazione. Poiché diverse opzioni non sono state menzionate, questo semplice esempio non deve essere considerato rappresentativo di tutte le potenzialità offerte da questo set di tecnologie. Piuttosto, l'obiettivo è fornire un'idea precisa di come i vari componenti di .NET Framework 3.0 possano essere utilizzati in modo congiunto nella risoluzione di scenari di business reali.

Tecnologie di .NET Framework 3.0

Per comprendere appieno i vantaggi offerti da .NET Framework 3.0, è utile approfondire il discorso riguardante le tecnologie che lo compongono. In questa sezione viene fornita un breve tutorial per ciascuna delle cinque tecnologie di .NET Framework 3.0. Per una descrizione più dettagliata, vedere “Per saperne di più” alla fine di questo white paper.

.NET Framework 2.0

Figura 6

Figura 6

Oggi .NET Framework 2.0 rappresenta un componente fondamentale dell'ambiente di sviluppo Windows, oltre a costituire la base di .NET Framework 3.0. La figura 6 illustra le due parti che compongono il framework: Common Language Runtime (CLR) e la libreria di classi .NET Framework. Alcuni componenti di .NET Framework 3.0, inclusi WF, WCF e WPF, vengono spesso implementati come estensioni della libreria di classi .NET Framework. Tuttavia, come già detto in precedenza, mentre alcune parti della libreria di classi continuano a rappresentare una componente importante dell'ambiente di sviluppo, altre sono state sostituite dalle nuove tecnologie introdotte in .NET Framework 3.0. ASP.NET, ad esempio, è ancora la tecnologia di base per la creazione di applicazioni accessibili dal browser, mentre ADO.NET è tuttora impiegato per l'utilizzo dei dati archiviati. Al contrario, ora gli sviluppatori .NET Framework 3.0 possono utilizzare WPF anziché Windows Form per creare un'interfaccia grafica Windows nativa e in genere preferiranno WCF ai Web service ASP.NET, .NET Remoting o Enterprise Services. Nonostante questi cambiamenti, è importante comprendere che anche nell'ambiente NET Framework 3.0 la versione precedente del framework continua a rivestire un ruolo centrale nelle attività di sviluppo.

Windows Workflow Foundation

Una struttura orientata ai processi, basata su un flusso di lavoro, può rappresentare l'approccio ideale per gran parte del software Windows. Per consentire agli sviluppatori di creare ed eseguire queste applicazioni basate sui flussi di lavoro, WF fornisce i componenti illustrati nella figura 7.

Figura 7

Figura 7

Come descritto in precedenza, un flusso di lavoro è costituito da un certo numero di attività. Sia i flussi di lavoro che le attività sono rappresentati da classi, pertanto entrambi possono essere creati direttamente a livello di codice. Inoltre, in WF è disponibile Workflow Designer, uno strumento grafico per la creazione di flussi di lavoro integrato in Visual Studio. Indipendentemente dalla modalità di creazione del flusso di lavoro, le attività che lo compongono possono essere elaborate dalla libreria di attività di base, o BAL (Base Activity Library), di WF o da qualsiasi altra fonte.

Dopo essere stato definito, il flusso di lavoro viene eseguito dal motore di runtime di WF, che sfrutta un gruppo di servizi di runtime per conservare lo stato del flusso di lavoro, tenere traccia della sua esecuzione e molto altro ancora. Tutti questi elementi (i servizi di runtime, il motore di runtime e lo stesso flusso di lavoro) rientrano in un processo di hosting, che può consistere in un qualsiasi processo Windows, da un semplice processo relativo a una console o un'applicazione WPF in esecuzione in un desktop a un processo server scalabile.

Per comprendere WF è richiesta una conoscenza minima dei relativi componenti, ognuno dei quali è descritto brevemente nelle sezioni successive.

Flussi di lavoro

Per descriverlo con una parola, un flusso di lavoro non è altro che un gruppo di attività. WF fornisce un supporto integrato per due tipi di flussi di lavoro:

  • Flussi di lavoro sequenziali, che eseguono attività secondo un ordine definito. Come un normale diagramma di flusso, un flusso di lavoro sequenziale può contenere rami, cicli e altre strutture di controllo. Tuttavia, per impostazione predefinita, le attività vengono eseguite in sequenza, una dopo l'altra.

  • Flussi di lavoro delle macchine a stati, che implementano una tradizionale macchina a stati finiti. Come tutte le macchine a stati, l'attività da eseguire in un momento prestabilito viene determinata dalla combinazione dello stato corrente con l'evento ricevuto.

L'opzione sequenziale è utile per i flussi di lavoro ben definiti, come quelli utilizzati per i processi interamente basati su software. Essendo relativamente semplici da creare e comprendere, la maggior parte degli sviluppatori li percepisce inizialmente come più familiari. L'utilizzo dei flussi di lavoro delle macchine a stati è preferibile quando il percorso di esecuzione è meno prevedibile, ad esempio nel caso in cui un flusso di lavoro implichi l'interazione con altri utenti, che potrebbero cancellarlo in qualsiasi punto. Utilizzare un flusso di lavoro sequenziale in una situazione di questo tipo è possibile, purché venga creato un ramo per ogni passaggio, in cui viene chiesto di eseguire una determinata operazione a seconda che il flusso di lavoro sia cancellato o meno. Modellare questo tipo di comportamento utilizzando una macchina a stati è notevolmente più semplice, poiché l'eventuale richiesta di cancellazione del flusso di lavoro è solo uno degli eventi che possono essere ricevuti e gestiti in qualsiasi punto.

Il supporto per i flussi di lavoro delle macchine a stati è un esempio dell'obiettivo di WF di soddisfare le esigenze di utenti e sistemi al tempo stesso. Un altro esempio è il supporto disponibile in WF per la modifica dei flussi di lavoro in esecuzione. Può capitare che un utente coinvolto in un flusso di lavoro desideri improvvisamente aggiungere o eliminare un passaggio o comunque modificare il processo in fase di esecuzione. Per consentire tali operazioni in condizioni controllate, WF consente allo sviluppatore che crea il flusso di lavoro di specificare se e come è possibile modificarlo in fase di esecuzione.

Libreria di attività di base

La possibilità di creare attività personalizzate rientra nell'ambito dell'impegno assunto da Microsoft volto a incoraggiare lo sviluppo di un ecosistema WF con numerose attività riutilizzabili. Tuttavia, per semplificare le cose, è meglio partire da un set comune di attività fondamentali, fornito dalla libreria di attività di base, o BAL (Base Activity Library).

Per utilizzare le attività contenute in questa libreria non sono necessari flussi di lavoro. Specialmente all'inizio, tuttavia, gran parte degli sviluppatori potrà constatare che la libreria di attività di base semplifica le operazioni di sviluppo. Tra le attività disponibili rientrano le seguenti:

  • IfElse: esegue le attività contenute in due o più percorsi possibili a seconda che una determinata condizione sia o meno soddisfatta.

  • While: esegue ripetutamente una o più attività purché una determinata condizione sia true.

  • Sequence: esegue un gruppo di attività una alla volta secondo un ordine prestabilito.

  • Parallel: esegue due o più gruppi di attività in parallelo.

  • Code: esegue un blocco di codice definito.

  • Listen: rimane in attesa di un evento specifico, quindi esegue una o più attività una volta ricevuto l'evento.

  • InvokeWebService: esegue una chiamata a un Web service.

  • State: rappresenta uno stato nella macchina a stati di un flusso di lavoro.

  • EventDriven: definisce una transizione contenente una o più attività che devono essere eseguite alla ricezione di un evento specifico in uno stato particolare.

  • Policy: consente di definire ed eseguire regole di business sfruttando il motore di regole fornito da WF.

Anziché definire un linguaggio particolare per specificare i flussi di lavoro, WF segue un approccio più generale basato sull'utilizzo delle attività. La libreria di attività di base fornisce un solo "linguaggio", ma gli utenti di WF possono comunque definirne uno personalizzato.

Strumenti di Windows Workflow Foundation: Workflow Designer

Uno dei vantaggi della creazione di applicazioni tramite flussi di lavoro consiste nella possibilità di definire il flusso di lavoro graficamente. Lo scopo dello strumento Workflow Designer di WF, illustrato nella figura 8, è esattamente questo. Per impostazione predefinita, le attività contenute nella libreria di attività di base vengono visualizzate nella casella degli strumenti, per consentire agli sviluppatori di trascinarle nell'area di progettazione dello strumento allo scopo di creare un flusso di lavoro.

Figura 8

Figura 8

Alcuni sviluppatori preferiscono scrivere codice anziché utilizzare strumenti di progettazione grafica. WF consente anche questo tipo di approccio, che talvolta è persino necessario, poiché le attività vengono generalmente sviluppate direttamente a livello di codice. È inoltre possibile combinare i due approcci e creare flussi di lavoro utilizzando sia Workflow Designer sia la codifica diretta. L'obiettivo è consentire agli sviluppatori di seguire di volta in volta l'approccio più produttivo. Inoltre, per garantire un maggiore supporto degli strumenti, è possibile formulare i flussi di lavoro in XAML, il linguaggio utilizzato da WPF. Infatti, per impostazione predefinita i flussi di lavoro creati con Workflow Designer sono basati su una definizione XAML.

Motore e servizi di runtime

Come descritto in precedenza, il ruolo del motore di runtime di WF consiste nell'eseguire le attività di un flusso di lavoro, sfruttando un gruppo di servizi di runtime. In WF questi servizi sono disponibili come implementazioni standard, che possono essere sostituite dagli sviluppatori che lo desiderano. Di seguito sono descritte le due caratteristiche più interessanti tra quelle supportate da questi servizi:

  • Persistenza: un flusso di lavoro bloccato in attesa di un evento può utilizzare questo servizio per memorizzare automaticamente su disco il proprio stato residente in memoria. Al verificarsi dell'evento, lo stato del flusso di lavoro verrà nuovamente caricato dal servizio in modo automatico e l'esecuzione verrà ripresa. Questa caratteristica è particolarmente utile per i flussi di lavoro in cui sono coinvolti gli utenti, poiché l'attesa di una risposta può richiedere ore, giorni o tempi ancora maggiori.

  • Registrazione: le attività di un flusso di lavoro demarcano esattamente l'esecuzione del processo che implementano. Grazie al servizio di registrazione di WF, gli sviluppatori possono impostare la scrittura automatica in un database delle informazioni sull'esecuzione del flusso di lavoro, per registrare ad esempio l'inizio e la fine del flusso di lavoro e di tutte le attività che lo compongono.

Windows Workflow Foundation e altre tecnologie Microsoft

L'introduzione di nuovi approcci influisce inevitabilmente su quelli già esistenti. Questa regola vale anche per le nuove tecnologie di .NET Framework 3.0, ognuna delle quali esercita un'influenza su altre tecnologie Microsoft. Con WF, l'impatto iniziale interessa maggiormente Windows SharePoint Services, 2007 Microsoft Office system e BizTalk Server.

Per consentire agli sviluppatori di creare in maniera più semplice applicazioni per il flusso di lavoro per documentare la collaborazione e altre attività di condivisione delle informazioni, Windows SharePoint Services versione 3 supporta l'hosting del runtime di WF. Office SharePoint Server 2007, parte integrante di 2007 Office system, è sviluppato sulla base del supporto per WF in Windows SharePoint Services. L'aggiunta di questo server permette, tra l'altro, di visualizzare form di InfoPath direttamente nelle applicazioni client di Office 2007 e di utilizzare un insieme di flussi di lavoro predefiniti all'interno di scenari comuni, come l'approvazione di un documento.

Gli utenti che possiedono una certa familiarità con BizTalk Server avranno certamente notato la somiglianza tra le capacità di orchestrazione di questo prodotto e le caratteristiche offerte da WF. Infatti, nella versione successiva a BizTalk Server 2006 la funzione di orchestrazione esistente verrà sostituita con WF, fornendo anche gli strumenti necessari per la migrazione delle orchestrazioni esistenti ai flussi di lavoro WF. Tuttavia, è importante sapere che WF e BizTalk Server 2006 indirizzano problemi distinti:

  • WF fornisce un framework generico per la creazione di applicazioni Windows basate su flussi di lavoro. Può essere eseguito in hosting all'interno di qualsiasi processo, può utilizzare qualunque tipo di attività e affrontare qualsiasi tipo di problematica, incluse quelle legate ai flussi di lavoro per persone e sistemi.

  • BizTalk Server è un prodotto focalizzato sull'integrazione di applicazioni aziendali, l'integrazione business-to-business e la gestione dei processi organizzativi. Offre un'ampia gamma di adapter per il collegamento con sistemi e software diversi, acceleratori per l'implementazione di standard quali RosettaNet e SWIFT e il supporto per il monitoraggio delle attività di business. BizTalk Server offre anche un'infrastruttura e strumenti di gestione, oltre ad offrire una maggiore scalabilità.

Come tecnologia per il flusso di lavoro standard di Windows, in futuro WF potrebbe essere disponibile anche con altri prodotti e tecnologie Microsoft. Indipendentemente da quali saranno le decisioni di Microsoft in proposito, WF verrà certamente incluso in numerose applicazioni create dai clienti finali.

Windows Communication Foundation

Il passaggio a un tipo di comunicazione orientata ai servizi segna un cambiamento nelle modalità di interazione delle applicazioni. Progettato espressamente per il supporto di applicazioni orientate ai servizi, WCF riflette questo cambiamento. In questa sezione verranno descritti gli aspetti più importanti di WCF, inclusi servizi e client, opzioni di comunicazione e supporto per la protezione, l'affidabilità delle comunicazioni e le transazioni.

Servizi e client

Figura 9

Figura 9

Come illustrato nella figura 9, l’idea di base di WCF è molto semplice: un servizio espone un'interfaccia accessibile da un client. Tale interfaccia può essere definita utilizzando il linguaggio WDSL (Web Services Description Language), quindi può essere trasformata in codice o definita direttamente in un linguaggio come C# o Visual Basic. Per una semplice interfaccia che espone un servizio per la richiesta di una copertura assicurativa, quest'ultimo approccio può essere rappresentato nel modo seguente:

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

La definizione di questa interfaccia C# è evidenziata dall'attributo ServiceContract, che indica che WCF può esporre i metodi contenuti nell'interfaccia come operazioni che è possibile chiamare in remoto. I metodi dell'interfaccia esposti sono quelli contrassegnati con l'attributo OperationContract. In questo semplice esempio tutti i metodi sono contrassegnati con questo attributo, pertanto tutti verranno esposti per i chiamanti in remoto. È tuttavia possibile limitare l'applicazione dell'attributo OperationContract solo ad alcuni metodi dell'interfaccia. Indipendentemente da questo, è necessario che l'interfaccia venga implementata da una classe dell'applicazione, fornendo il codice effettivo dei metodi definiti dall'interfaccia stessa. Dopodiché, WCF renderà automaticamente accessibili ai client di questo servizio i metodi contrassegnati con OperationContract.

La figura 10 illustra in maniera più dettagliata il metodo di esposizione del servizio ai client. Anziché accedere a un'interfaccia in modo diretto, il client si connette a un endpoint specifico. Un servizio può esporre più endpoint, consentendo a diversi client di accedervi in modi diversi.

Figura 10

Figura 10

Come si nota nella figura, ogni endpoint specifica tre elementi:

  • Un contratto che descrive le operazioni che è possibile richiamare attraverso l'endpoint. Il contratto può essere identificato utilizzando lo stesso nome dell'interfaccia che definisce tali operazioni, in questo caso IInsuranceApplication.

  • Un binding che definisce il modo in cui è possibile richiamare le operazioni dell'endpoint. Ciascun binding definisce diversi aspetti, incluso il protocollo da utilizzare per richiamare le operazioni, il tipo di protezione da applicare e altro ancora. WCF include un set di binding predefiniti (nell'esempio, BasicHttpBinding) per i casi più frequenti, ma è comunque possibile definire binding personalizzati. Un unico servizio che espone più endpoint consente l'accesso simultaneo a diversi tipi di client tramite protocolli differenti e con opzioni di protezione diverse.

  • Un indirizzo che indica la posizione dell'endpoint. Come illustrato nella figura, l'indirizzo è rappresentato da un URL.

WCF si basa su principi semplici. Come nella maggior parte delle tecnologie di comunicazione, i dettagli possono essere molto complessi e le opzioni disponibili sono molteplici, ma la creazione di normali applicazioni WCF è tutto sommato semplice.

Opzioni di comunicazione

Tipi diversi di applicazioni, realizzate da differenti sviluppatori, implementano modalità dissimili di intercomunicazione. L'approccio più semplice per la maggior parte degli sviluppatori è rappresentato dalla chiamata RPC (Remote Procedure Call), tramite cui un client può richiamare operazioni remote in modo analogo a quelle locali. Nell'interfaccia descritta in precedenza, ad esempio, un client potrebbe richiamare qualsiasi operazione in modo sincrono, rimanendo in attesa fino alla ricezione di una risposta. Oltre a essere molto semplice, questa opzione è la più indicata in alcune circostanze.

Tuttavia, in WCF sono disponibili diverse altre opzioni, tra cui:

  • Chiamate che non ricevono alcuna risposta. Questo tipo di comunicazione, contrassegnato con l'attributo OneWay, può risultare utile per inviare eventi o per altre interazioni unidirezionali.

  • Comunicazione asincrona basata su messaggi, mediante invio e ricezione diretti con messaggi XML.

  • Modifica esplicita dei messaggi SOAP, inclusa la capacità di inserire elementi direttamente nell'intestazione SOAP.

Con WCF, gli sviluppatori sono inoltre in grado di controllare vari aspetti del comportamento di un servizio in locale. Utilizzando l'attributo ServiceBehavior, ad esempio, è possibile impostare il servizio come singolo o con multithreading, stabilire la creazione di una nuova istanza del servizio per ogni chiamata e altre opzioni.

Protezione, affidabilità e transazioni

La comunicazione di base, ovvero la capacità di trasferire dati tra i vari sistemi, è certamente adeguata, ma raramente sufficiente. La maggior parte delle applicazioni presenta altre esigenze. Ad esempio, buona parte delle applicazioni distribuite richiede un certo tipo di protezione, esigenza che può rivelarsi complessa, vista la grande varietà di approcci e tecnologie attualmente in uso. Per consentire agli sviluppatori di creare applicazioni distribuite con un adeguato livello di protezione senza perdersi in dettagli, WCF utilizza prima di tutto i binding di protezione. Ad esempio, il binding BasicHttpBinding illustrato in precedenza può essere configurato per sostituire il protocollo HTTP con HTTPS, mentre altre opzioni di protezione sono disponibili tramite altri binding. Il supporto per WS-Security disponibile in WsHttpBinding, ad esempio, consente l'autenticazione interoperabile basata su SOAP, oltre all'integrità e alla riservatezza dei dati. Gli sviluppatori possono inoltre creare binding personalizzati per offrire esattamente i servizi di protezione richiesti da una determinata applicazione.

La garanzia di affidabilità delle comunicazioni è altrettanto essenziale per numerose applicazioni. In alcuni casi, è sufficiente il tradizionale approccio basato sui Web service, adottato da BasicHttpBinding, che consiste nell'invio di SOAP tramite HTTP. Tuttavia, esistono numerose situazioni in cui questo tipo di approccio diffuso non è sufficiente a garantire l'affidabilità completa, come nel caso dei messaggi che attraversano uno o più intermediari SOAP. In questi casi, WCF implementa la specifica WS-ReliableMessaging. L'utilizzo di un binding che supporta questa opzione, come WsHttpBinding, permette di ottenere automaticamente un approccio per il trasferimento dei messaggi affidabile e interoperabile.

Per alcune applicazioni sono importanti anche le transazioni distribuite. WCF si basa su System.Transactions, un componente di .NET Framework 2.0, per consentire la creazione di software transazionale. L'attributo OperationBehavior può essere utilizzato in un metodo per indicare la necessità di una transazione per il metodo stesso e definirne il comportamento. Per consentire transazioni distribuite interoperabili tra le soluzioni dei vari produttori, WCF sfrutta la specifica WS-AtomicTransaction. Grazie a quanto definito in questo accordo tra produttori, le applicazioni WCF sono in grado di partecipare alle transazioni che coinvolgono diverse tecnologie, tra cui J2EE e altre ancora.

Windows Communication Foundation e altre tecnologie Microsoft

Come accennato in precedenza, WCF ha sostituito diverse tecnologie Microsoft precedenti per la creazione di applicazioni distribuite. La maggior parte delle applicazioni che in passato sarebbero state sviluppate tramite Web service ASP.NET, .NET Remoting, Enterprise Services, System.Messaging o WSE verrà invece sviluppata con WCF. Le applicazioni WCF sono in grado di interagire con le applicazioni basate su Web service ASP.NET, poiché entrambe supportano il protocollo SOAP standard, nonché con le applicazioni basate su Enterprise Services, MSMQ e WSE versione 3.0. WCF è inoltre compatibile con BizTalk Server 2006, che per le prossime versioni sarà sviluppato in modo ancora più diretto sulla base delle funzionalità di WCF.

È importante comprendere che, anche se non saranno normalmente utilizzate nelle nuove applicazioni basate sul.NET Framework 3.0, tutte le tecnologie sostituite da WCF rimangono incluse anche in questa versione del framework e il relativo supporto verrà mantenuto. Le applicazioni sviluppate utilizzando versioni precedenti di queste tecnologie continueranno a essere normalmente utilizzabili e l'installazione e l'utilizzo di .NET Framework 3.0 non influiranno in alcun modo sul codice esistente.

Windows CardSpace

Gli utenti accedono quotidianamente alle applicazioni attraverso una rete, tramite un browser Web o altri tipi di client. Poiché queste applicazioni richiedono in genere una forma di identificazione dell'utente, le persone sono inevitabilmente costrette ad acquisire e presentare informazioni sulla propria identità attraverso un software remoto. Un esempio di questa situazione è l'accesso tramite un browser ad applicazioni Internet o Intranet.

Come descritto in precedenza, attualmente l'identità digitale è in genere rappresentata da nomi utente e password, con tutti i problemi che ne conseguono. Windows CardSpace, un componente del metasistema delle identità, offre un approccio alternativo alla risoluzione di questi problemi. Per comprendere meglio il funzionamento di CardSpace, è utile esaminare i principali concetti alla base del metasistema delle identità.

Windows CardSpace e il metasistema delle identità

Indipendentemente dalle modalità di accesso a un'applicazione, da un browser Web, attraverso il client dell'applicazione o tramite altri metodi, gli utenti devono in genere presentare un'identità digitale. Esistono numerosi tipi di identità digitali, ma praticamente tutte sono rappresentate in rete da un token di protezione. Un token di protezione semplice può essere costituito da un nome utente, mentre uno più complesso può includere un certificato X.509 o un documento XML. Indipendentemente da come siano rappresentati, attualmente i token di protezione sono i meccanismi più diffusi per la rappresentazione delle identità digitali in rete.

Per quanto sia forte la tentazione di pensare che in futuro verrà adottato un unico formato per i token di protezione, la realtà è che continueranno a essere utilizzati approcci diversi. Come nella vita reale vengono utilizzati vari tipi di documenti (patente, carta di credito, tessere aeree per viaggiatori frequenti e altro ancora), allo stesso modo gli utenti disporranno di diverse identità digitali rappresentate da diversi tipi di token di protezione. Non essendo disponibile un unico sistema delle identità in grado di fornire una risposta universale, sarà sempre necessario disporre di più token di protezione.

Tuttavia, gli utenti hanno bisogno di utilizzare le proprie identità digitali in maniera coerente. Benché un unico sistema delle identità non possa essere sufficiente, è possibile creare un sistema di sistemi delle identità, ovvero un "metasistema delle identità", per consentire l'utilizzo coerente di un'infinità di identità digitali. Collaborando con le altre aziende del settore, Microsoft mantenutala guidato il processo di definizione di questo metasistema. Basato su tecnologie Web service aperte, quali WS-Security e WS-Trust, tale metasistema definisce le modalità di acquisizione e utilizzo delle identità digitali, indipendentemente dal relativo token di protezione.

Il processo di creazione, acquisizione e utilizzo delle identità digitali presuppone i tre ruoli distinti descritti di seguito:

  • Utente: talvolta denominato soggetto, l'utente è l'entità che dispone dell'identità digitale.

  • Provider di identità: il provider di identità fornisce l'identità digitale dell'utente. Per l'identità digitale assegnata a un dipendente aziendale, ad esempio, il provider di identità è in genere un sistema quale Active Directory, mentre per un'identità digitale utilizzata su Amazon, il provider di identità è l'utente stesso, incaricato di definire il proprio nome utente e la password. Le identità digitali create da diversi provider possono includere informazioni di natura diversa e offrire livelli diversi di garanzia dell'effettiva identità degli utenti.

  • Garante dell'identità: il garante dell'identità è un'applicazione che riceve ed elabora le informazioni relative all'identità digitale di un utente. Questa applicazione utilizza spesso un'identità (ovvero, le informazioni contenute nel token di protezione) per eseguire l'autenticazione di un utente e assegnare le autorizzazioni appropriate per accedere, ad esempio, a determinate informazioni. Il garante dell'identità può inoltre utilizzare le credenziali fornite per ottenere un numero di carta di credito e verificare se lo stesso utente acceda alla carta di credito in momenti o per scopi diversi. Esempi tipici di garanti dell'identità includono i siti Web di banche, negozi e aste online, oltre alle applicazioni che accettano richieste tramite Web service.

Queste tre entità interagiscono nell'ambito del metasistema delle identità. Le interazioni e i punti in cui interviene CardSpace sono illustrati nella figura 11.

Figura 11

Figura 11

Il processo ha inizio nel momento in cui un utente accede a un garante dell'identità tramite un'applicazione compatibile con CardSpace. Per sapere quale tipo di token di protezione verrà richiesto, l'applicazione deve accedere alle regole del garante dell'identità (fase 1). Se un browser accede a un sito Web (il caso più comune), le regole del sito vengono formulate in linguaggio HTML e reinviate come sezione di una pagina Web. Invece, in caso di applicazioni utilizzate tramite Web service, le regole del garante dell'identità vengono richieste tramite il protocollo standard definito da WS-MetadataExchange. In questo caso, le regole vengono formulate con WS-SecurityPolicy, un altro standard di settore. Indipendentemente dal modo in cui vengono acquisite, le informazioni sulle regole indicano sempre il tipo di token di protezione accettato dal garante dell'identità e le informazioni che deve contenere.

Una volta rilevati i token di protezione richiesti dal garante dell'identità, CardSpace visualizza la schermata dell'identità illustrata in precedenza, in cui ciascuna identità digitale disponibile per l'utente viene rappresentata sotto forma di scheda delle informazioni. Le schede rilasciate da un garante dell'identità esterno sono denominate schede gestite, mentre quelle rilasciate dal provider integrato di CardSpace sono chiamate schede a rilascio automatico. Entrambi i tipi di schede sono visualizzabili in questa schermata e l'utente può scegliere quale dei due selezionare. Per facilitare questa decisione, nella schermata vengono indicate le identità che soddisfano i requisiti del garante dell'identità, disattivando le schede non idonee. In tal modo, l'utente può selezionare l'identità digitale da utilizzare (fase 2).

Le schede non contengono il token di protezione effettivo, ma includono le informazioni necessarie per individuare un determinato provider di identità e richiedere un token di protezione per l'utente (di fatto, tutte le schede sono create in origine da un provider di identità). CardSpace utilizza le informazioni contenute nella scheda selezionata dall'utente per richiedere un token di protezione dal provider di identità che ha rilasciato la scheda (fase 3). Tale richiesta viene effettuata utilizzando WS-Trust, un altro protocollo standard, mentre l'identità degli utenti viene autenticata tramite Kerberos, firma digitale e certificato X.509 oppure con un altro meccanismo. Il token viene restituito in un form crittografato, nel quale viene incluso un timestamp allo scopo di impedire che il token venga sottratto e riutilizzato in futuro.

Una volta restituito, il token di protezione richiesto viene inviato al garante dell'identità (fase 4), che può utilizzare le informazioni contenute nel token in vari modi. Se il token contiene un certificato X.509, ad esempio, ed è accompagnato da una firma digitale, è probabile che il garante dell'identità lo utilizzi per eseguire l'autenticazione dell'utente. Tuttavia, non esiste alcun requisito che imponga l'utilizzo dei token per l'autenticazione o altri scopi inerenti alla protezione (il termine "token di protezione", in effetti, è fuorviante). Un token può contenere informazioni quali l'età dell'utente, l'idoneità a beneficiare di uno sconto in un sito di shopping online e altro ancora. L'autenticazione rappresenta un utilizzo importante dei token di protezione, ma non certo l'unico.

È importante notare che CardSpace e il metasistema delle identità nel suo insieme non conoscono il formato o la tecnologia utilizzata per il token di protezione. Anziché tentare di creare un'unica nuova origine per le identità digitali o un formato standard per i token di protezione, l'obiettivo del metasistema è fornire un metodo coerente per l'utilizzo di qualsiasi identità digitale basata su qualsiasi tipo di token. Offrendo un'implementazione Windows dei principali componenti del metasistema, CardSpace riveste un ruolo determinante per l'applicazione di questo approccio generale alle identità digitali.

Prevenzione degli attacchi di phishing

I provider di identità sono spesso un'entità distinta dall'utente, come nel caso in cui venga assegnata un'identità a un dipendente aziendale. Tuttavia, esistono numerose situazioni in cui il provider di identità è rappresentato dall'utente stesso. Se non si utilizza CardSpace, ad esempio, per accedere a molti siti Web è necessario immettere un nome utente e una password, entrambi definiti dall'utente. Una volta creata l'identità, l'utente è in grado di fornire il nome e la password per verificare il proprio estratto conto, acquistare un libro o eseguire le operazioni consentite dal sito.

Come accennato in precedenza, essendo basate sulle password, le identità rilasciate automaticamente risultano esposte agli attacchi di hacker e pirati informatici. Per contribuire a prevenire questi attacchi, CardSpace offre un metodo alternativo per la creazione di identità rilasciate automaticamente. Il provider di identità a rilascio automatico viene eseguito in locale nel sistema Windows dell'utente. Anziché basarsi su informazioni quali nome utente e password, i token di protezione creati dal provider di identità di questo tipo vengono definiti tramite SAML (Security Assertion Markup Language), uno standard OASIS. Invece di utilizzare una password, l'identità dell'utente viene verificata sfruttando tecnologie a chiave pubblica, che una volta accettate dal garante dell'identità, svolgono la stessa funzione di nomi utente e password, contribuendo tuttavia a evitare che informazioni di questo tipo possano essere sottratte in caso di un attacco di phishing. La riduzione dell'utilizzo di password, insieme a un'autenticazione più rigorosa dell'identità dei siti grazie ai certificati di garanzia elevata descritti in precedenza, contribuisce a ridurre la gravità degli attacchi di questo genere.

Windows CardSpace e altre tecnologie Microsoft

CardSpace è concatenato ad altre tecnologie Microsoft, incluse quelle descritte di seguito:

  • WCF: basandosi su standard per i Web service quali WS-Security e WS-Trust, CardSpace utilizza WCF come tecnologia di comunicazione. Di fatto, l'autore di un'applicazione WCF può impostare l'utilizzo di CardSpace semplicemente specificando un determinato binding.

  • Active Directory: benché non sia ancora possibile attualmente, in futuro Active Directory potrà essere utilizzato da provider di identità nell'ambito del metasistema.

  • Windows Live ID (precedentemente noto con il nome Passport): come per Active Directory, Microsoft ha annunciato che anche il sistema di autenticazione Live ID verrà modificato per fungere da provider di identità. Si noti che CardSpace non sostituisce Live ID, in quanto le due applicazioni ricoprono funzioni diverse. Live ID sarà invece incluso nel metasistema delle identità come qualsiasi altro provider di identità.

Oltre a CardSpace, Microsoft offre altre tecnologie relative alle identità per la risoluzione di problemi diversi. Active Directory Federation Services (ADFS), ad esempio, consente la gestione delle identità tra organizzazioni in base a un modello federato. Questo problema di rilievo, affrontato dalle numerose aziende che necessitano di collaborare con altre organizzazioni, è tuttavia ben distinto dalle più generiche funzioni rivestite da CardSpace e dal metasistema delle identità.

Windows Presentation Foundation

La logica basata sui flussi di lavoro, la comunicazione orientata ai servizi e l'identità sono tutti aspetti importanti delle moderne applicazioni. Tuttavia, gli utenti prestano maggiore attenzione a ciò che possono vedere, ovvero l'interfaccia utente. L'obiettivo di WPF è risolvere le problematiche relative alla creazione dell'interfaccia utente nelle applicazioni più recenti, sfruttando le funzionalità illustrate nelle sezioni successive di questo documento.

Funzionalità di Windows Presentation Foundation

Gli sviluppatori possono scegliere se creare l'interfaccia di un'applicazione WPF interamente in C#, Visual Basic o in qualche altro linguaggio CLR. Tuttavia, come accennato in precedenza, WPF consente di specificare un'interfaccia utilizzando il linguaggio XAML, basato su XML. Gli elementi e gli attributi in XAML vengono associati direttamente alle classi e alle proprietà fornite da WPF. Di seguito è riportato un esempio di pulsante definito in XAML:

<Button Background="Red">
 No
</Button>

In questo esempio viene creato un pulsante rosso contenente il testo "No". Lo stesso risultato può essere ottenuto con il codice riportato di seguito:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Comunque siano definite, praticamente tutte le applicazioni WPF poggiano sullo stesso modello di base. L'applicazione eredita dall'oggetto Application standard di WPF, che fornisce i metodi, gli eventi e le proprietà di base. Un'applicazione WPF può presentare una classica interfaccia a finestre di dialogo oppure un'interfaccia di navigazione, che la rende simile a un'applicazione per il browser. Le applicazioni sviluppate con quest'ultimo tipo di interfaccia sono in genere implementate come un gruppo di pagine, ognuna delle quali è composta da un'interfaccia utente definita in XAML, accompagnata da una logica definita a livello di codice. Per collegare tra loro le pagine, XAML fornisce un elemento Hyperlink, analogamente a HTML. L'applicazione visualizza una pagina alla volta, consente all'utente di spostarsi avanti e indietro fra le pagine, memorizza un elenco cronologico e altro ancora. Benché sia possibile eseguire un'applicazione di navigazione in un browser Web, al pari di un'applicazione XBAP, non è un requisito indispensabile; gli sviluppatori possono infatti utilizzare questo stile di interfaccia anche all'interno di applicazioni WPF standalone. L'obiettivo è creare soluzioni software in grado di combinare gli aspetti migliori di un'interfaccia browser e di un'interfaccia Windows nativa.

Indipendentemente dallo stile dell'interfaccia utilizzato, il layout di base di un'applicazione WPF può essere basato su pannelli, ognuno dei quali contiene in genere controlli, che in WPF includono Button, TextBox, ComboBox, Menu e numerosi altri ancora. Le modalità di posizionamento di tali controlli dipendono dal tipo di pannello scelto. Una griglia, ad esempio, consente di posizionare i controlli all'interno di una griglia specificata, mentre in un'area di disegno i controlli possono essere disposti in un punto qualsiasi. Inoltre, come avviene in genere in un'interfaccia utente di tipo grafico, gli eventi generati dall'utente vengono rilevati e gestiti dai vari controlli e dalle altre classi dell'applicazione. È inoltre possibile applicare stili e modelli ai gruppi di controlli, per attribuire alle applicazioni un aspetto più uniforme.

Oltre a queste caratteristiche di base dell'interfaccia utente, WPF supporta le funzionalità descritte di seguito:

  • Documenti: un'applicazione WPF consente di visualizzare documenti XPS utilizzando il tag XAML FixedDocument, mentre il tag FlowDocument permette di visualizzare documenti dinamici. Un documento dinamico si comporta come un normale documento visualizzato, permettendo all'utente di scorrerne il contenuto. Tuttavia, impostando vari attributi su questo tag, gli sviluppatori possono aumentare l'adattabilità del documento all'ambiente circostante. Ad esempio, è possibile visualizzare il documento una pagina alla volta, eliminando la necessità per il lettore di scorrerlo in continuazione avanti e indietro. WPF è inoltre in grado di determinare automaticamente il numero di colonne in cui suddividere il documento, in base alle dimensioni della finestra in cui viene visualizzato. L'obiettivo è garantire la massima leggibilità dei documenti visualizzati.

  • Elementi grafici: WPF offre il supporto necessario per la creazione di immagini vettoriali a due e tre dimensioni. Per le immagini bidimensionali, WPF fornisce astrazioni standard quali forme, pennelli e penne, oltre alla possibilità di utilizzare immagini tridimensionali per definire un modello in cui inserire informazioni sulla luminosità e la posizione dell'oggetto. Diversamente dalle tecnologie precedenti, come Windows Form, in cui la grafica era basata su GDI+, in WPF le immagini non vengono partizionate tramite un insieme distinto di concetti che gli sviluppatori devono comprendere. Al contrario, gli elementi grafici XAML possono essere combinati in modo del tutto naturale con quelli utilizzati per tutti gli altri aspetti dell'interfaccia. I pulsanti possono visualizzare immagini oppure una combinazione di testo ed elementi grafici e altro ancora.

  • Immagini: il tag XAML Image consente di visualizzare in un'applicazione WPF vari formati di immagini, come JPEG, GIF e altri ancora. WPF si basa sul componente Windows Imaging Component (WIC) per offrire un framework standard per i codec, software per la visualizzazione e memorizzazione delle immagini. Come sempre in WPF, un elemento Image può essere associato ad altri elementi, per consentire ad esempio la creazione di pulsanti contenenti un'immagine, anziché una semplice etichetta di testo.

  • Supporti multimediali: un'applicazione WPF può utilizzare il tag MediaElement per visualizzare filmati e riprodurre audio in vari formati, tra cui WMV, AVI e MPEG. Ancora una volta, è possibile associare questo elemento ad altri elementi XAML, per creare ad esempio un cubo tridimensionale in grado di visualizzare filmati sui diversi lati.

  • Animazioni: WPF offre il supporto incorporato per l'animazione della maggior parte degli elementi di un'interfaccia utente. È ad esempio possibile visualizzare un cerchio che si allarga e si restringe o un pulsante che cambia dimensioni. Le applicazioni possono inoltre definire storyboard dotati di sequenze temporali, per eseguire sequenze coordinate di animazioni.

Associazione dati: dal momento che molte applicazioni WPF visualizzano dati, è utile disporre del supporto automatico per il mapping dei dati agli elementi dell'interfaccia utente. WPF offre questo tipo di associazione dati per le informazioni contenute negli oggetti e in altre origini, oltre a consentire di ordinare e filtrare i dati prima che vengano visualizzati.

Applicazione di Windows Presentation Foundation

In WPF sono disponibili numerose funzionalità dell'interfaccia utente, che consentono a sviluppatori e designer di creare interfacce dall'aspetto accattivante. Tuttavia, per quanto l'aspetto dell'applicazione client possa essere gradevole, alcune organizzazioni potrebbero decidere di non utilizzarla a causa delle problematiche relative al deployment. Se per la distribuzione di una nuova versione del client è necessario intervenire fisicamente su tutti i desktop in cui viene installata l'applicazione, il costo degli aggiornamenti può diventare notevole. Attualmente, un modo per evitare questo problema è creare client basati su browser, anziché client Windows nativi. Questi ultimi, tuttavia, presentano in genere interfacce utente più efficaci rispetto ai browser. Per risolvere le problematiche legate al deployment di questi client, è possibile adottare applicazioni WPF standalone utilizzando ClickOnce. Grazie a questa tecnologia, apparsa per la prima volta in .NET Framework 2.0, gli utenti di Internet Explorer possono selezionare un'applicazione sul Web e quindi installarla automaticamente nel computer locale. Una volta installata l'applicazione, è inoltre possibile eseguirne l'aggiornamento automatico ogni volta che risulta disponibile una nuova versione. L'obiettivo è combinare la semplicità e la convenienza del deployment di un client Web con la potenza e la funzionalità di un'applicazione WPF standalone.

Le applicazioni WPF standalone rappresentano la soluzione client migliore in numerose situazioni, specialmente quando il deployment viene eseguito utilizzando ClickOnce. Tuttavia, esistono casi in cui questo tipo di applicazione non è indicato, anche se gli utenti potrebbero beneficiare dei vantaggi offerti dall'interfaccia WPF. Si pensi, ad esempio, agli agenti assicurativi dello scenario descritto in precedenza che lavorano da postazioni remote oppure a un commerciante online che desidera aggiungere il supporto per elementi grafici tridimensionali, filmati e altre funzionalità avanzate supportate da WPF. In casi simili, non è ragionevole pensare che gli utenti dell'applicazione installino un'applicazione WPF nativa per accedere al sito. Piuttosto, sarebbe meglio includere nel browser Web un'interfaccia in stile WPF.

Le applicazioni browser XAML (XBAP) sono progettate espressamente a questo scopo. Anziché eseguire il deployment di un'applicazione WPF standalone, gli utenti di Internet Explorer possono scaricare direttamente nel browser un'applicazione XBAP, che una volta eseguita in Internet Explorer fornisce un'interfaccia WPF. Tuttavia, scaricare ed eseguire codice dai siti Web può essere rischioso. Per proteggere gli utenti dagli attacchi di sviluppatori malintenzionati, tutte le applicazioni XBAP scaricate da Internet vengono eseguite in una sandbox parzialmente isolata dal sistema. Basato sulla protezione dell'accesso al codice fornita da .NET Framework, questa sandbox pone dei limiti alle funzionalità delle applicazioni XBAP. Ad esempio, un'applicazione XBAP scaricata da Internet non può creare finestre standalone o avviarne di nuove, visualizzare finestre di salvataggio avviate dall'applicazione XBAP stessa o accedere al file system da un'area di archiviazione non isolata. Malgrado le restrizioni imposte dalla sandbox, un'applicazione XBAP può comunque utilizzare gran parte delle funzionalità WPF, inclusi gli elementi grafici a due e tre dimensioni, le animazioni, i documenti, le immagini, i filmati e altro ancora.

Come descritto in precedenza, con WPF le applicazioni sono in grado di visualizzare documenti adattabili all'ambiente circostante, sfruttando l'elemento XAML FlowDocument. Tuttavia, modificare l'aspetto dei documenti in base alla modalità di visualizzazione non sempre rappresenta la soluzione migliore. A volte, infatti, sono più indicati i documenti a formato fisso, il cui aspetto rimane invariato tra lo schermo e la stampante. I documenti XPS di WPF consentono di risolvere questo problema. Definiti mediante un sottoinsieme di XAML, i documenti XPS sono infatti accessibili da qualsiasi sistema in cui sia installato un lettore XPS. Inoltre, il nuovo formato di stampa per Windows supportato in questo tipo di documenti consente di stampare elementi grafici complessi con una migliore fedeltà dell'immagine. Infine, per consentire un utilizzo più uniforme dei vari tipi di documenti, i formati XPS e Office 2007 utilizzano le convenzioni Microsoft Open Packaging, che definiscono metodi comuni per l'archiviazione dei contenuti, oltre a fornire la firma digitale dei documenti e altro ancora.

Strumenti di Windows Presentation Foundation

È possibile creare interfacce utente WPF direttamente a livello di codice e/o XAML, utilizzando un editor di testo di base. Tuttavia, poiché la maggior parte degli utenti preferisce lavorare con strumenti più sofisticati, Microsoft ha aggiunto alcune estensioni in Visual Studio 2005 per la creazione di applicazioni WPF. A questo scopo, inoltre, nella prossima release di Visual Studio, nota con il nome in codice "Orcas", verrà introdotto Visual Designer for Windows Presentation Foundation. Tramite questo strumento, gli sviluppatori potranno creare una rappresentazione grafica dell'interfaccia utente desiderata, il cui codice verrà generato automaticamente.

Spesso, però, gli sviluppatori non sono le persone più indicate per definire un'interfaccia, al contrario dei designer, che in genere sono molto più portati per questo tipo di attività, avendo un maggior contatto con gli utenti. La maggior parte dei designer, tuttavia, non è in grado di scrivere codice, pertanto Visual Designer for Windows Presentation Foundation di Visual Studio non rappresenta uno strumento efficace per questi professionisti. Per consentire ai designer di lavorare in maniera efficiente nell'ambiente WPF, Microsoft ha creato Expression Interactive Designer, uno strumento che consente di definire l'aspetto e l'utilizzo di un'interfaccia, specificare animazioni e altro ancora, per poi generare la versione XAML degli elementi creati. Gli sviluppatori possono quindi importare il codice XAML in Visual Studio e aggiungere codice per eseguire attività quali la gestione degli eventi. Dal momento che Visual Studio ed Expression Interactive Designer utilizzano entrambi lo stesso sistema di generazione, sviluppatori e designer possono lavorare sullo stesso progetto in modo iterativo, ciascuno utilizzando lo strumento più adeguato. L'obiettivo è migliorare la collaborazione tra professionisti con diverse competenze di design grafico e sviluppo di software.

Windows Presentation Foundation e altre tecnologie Microsoft

Al pari di altri componenti .NET Framework 3.0, WPF influisce sulle tecnologie Microsoft esistenti, tra cui le più importanti sono descritte di seguito:

  • Windows Form: approccio originale per la creazione di interfacce utente per le applicazioni in .NET Framework, Windows Form è tuttora utilizzato in molte applicazioni. Per questo, WPF consente l'hosting di controlli Windows Form nelle applicazioni WPF e viceversa. Ad esempio, un'applicazione Windows Form potrebbe eseguire l'hosting di un controllo WPF per la visualizzazione tridimensionale dei dati. Anche se con qualche limitazione, è possibile creare applicazioni con entrambe le tecnologie. Si noti inoltre che le applicazioni Windows Form esistenti continueranno a funzionare normalmente all'interno dell'ambiente .NET Framework 3.0.

  • Win32 e Microsoft Foundation Classes (MFC): come con Windows Form, è possibile eseguire l'hosting di controlli WPF all'interno di applicazioni esistenti sviluppate utilizzando queste tecnologie e viceversa. Tuttavia, l'interoperabilità risulta leggermente più complessa poiché, diversamente da Windows Form, le applicazioni basate su Win32 e MFC non vengono generate tramite CLR. Di conseguenza, per garantire l'interoperabilità con WPF è necessario eseguire il mapping tra codice CLR e codice Win32 nativo.

  • Direct3D: incluso nella famiglia di API DirectX, Direct3D consente di creare e visualizzare nelle applicazioni elementi grafici tridimensionali. Con l'introduzione di .NET Framework 3.0, le principali applicazioni Windows possono utilizzare le funzionalità 3D di WPF, anziché il più sofisticato approccio offerto da Direct3D. Tuttavia, le applicazioni che richiedono prestazioni maggiori, come i giochi 3D, continueranno a utilizzare Direct3D. In realtà, WPF si basa comunque su Direct3D per tutti i tipi di rendering.

  • Windows Communication Foundation: come illustrato nello scenario precedente, le applicazioni WPF possono utilizzare WCF, al contrario delle applicazioni XBAP, dal momento che WFC necessita dell'attendibilità totale. Le applicazioni XBAP scaricate da Internet vengono eseguite in una sandbox parzialmente isolata dal sistema, che impedisce alle singole applicazioni di accedere a WCF. Tuttavia, le applicazioni XBAP possono utilizzare Web service ASP.NET, per eseguire chiamate SOAP in grado di interagire con WCF e altre implementazioni di Web service.

"WPF/E": pur non essendo incluso in .NET Framework 3.0, un altro aspetto di WPF degno di nota è quello noto con il nome in codice "WPF/E", che ha l'obiettivo di supportare le interfacce in stile WPF nei sistemi che non ne prevedono il supporto. Questa tecnologia è pensata per essere disponibile su qualunque sistema, inclusi i sistemi Macintosh, i dispositivi di piccole dimensioni e altri sistemi. WPF/E, che verrà rilasciato dopo WPF, offrirà un sottoinsieme di funzionalità WPF complete, incluso il supporto per elementi grafici bidimensionali, animazioni e filmati.

Opzioni di distribuzione di .NET Framework 3.0

Per far sì che un'applicazione utilizzi .NET Framework 3.0, è necessario installare questa versione del framework in tutti i computer in cui viene eseguita l'applicazione. In Windows Vista è molto semplice, poiché .NET Framework 3.0 è installato per impostazione predefinita. Questo significa che i nuovi computer con installato Windows Vista o i sistemi aggiornati al nuovo sistema operativo saranno in grado di eseguire automaticamente applicazioni .NET Framework 3.0. Per poter eseguire i componenti .NET Framework 3.0 in Windows XP e Windows Server 2003, Microsoft renderà disponibile il relativo software, scaricabile gratuitamente.

Conclusioni

.NET Framework 3.0 rappresenta l'ultima evoluzione del modello di programmazione Windows. Basato su .NET Framework 2.0, di cui rappresenta l'estensione, l'obiettivo di questa nuova versione è supportare la creazione di moderne applicazioni. A questo scopo, .NET Framework 3.0 offre un'ampia gamma di tecnologie diversificate per soddisfare le attuali esigenze nell'ambito dello sviluppo di applicazioni. Concentrando questa varietà di risorse in un'unica piattaforma, Microsoft intende offrire un prodotto il cui insieme è superiore alla somma delle parti, per consentire agli sviluppatori di creare applicazioni in grado di sfruttare i vari componenti di .NET Framework 3.0 in modo coerente.

Indipendentemente dagli aspetti della nuova release adottati, questa tecnologia è certamente destinata ad avere un notevole impatto sul mondo del software Windows. Per tutti gli sviluppatori, architetti o decision-maker che lavorano in questo ambiente, è finalmente arrivato il momento di capire in che modo sfruttare i vantaggi offerti da .NET Framework 3.0.

Per saperne di più

Understanding .NET, Second Edition. David Chappell, Addison-Wesley, 2006

Introduzione a Windows Workflow Foundation (in inglese)

Introduzione a Windows Communication Foundation (in inglese)

Introduzione a Windows CardSpace (in inglese)

Informazioni sull'autore

David Chappell è direttore della Chappell & Associates (www.davidchappell.com) di San Francisco, in California. Consulente e autore di numerosi scritti e interventi, David Chappell aiuta i professionisti IT di tutto il mondo a comprendere, utilizzare e prendere decisioni più mirate riguardo al software aziendale.


Mostra: