Introduzione a .NET Framework 3.0

  • Articolo

 

David Chappell
Chappell & Associates

Luglio 2006

Si applica a:
   .NET Framework 3.0 (in precedenza WinFX)
   Sviluppo per Windows

Riepilogo: La versione 3.0 di Microsoft .NET Framework offre un set diversificato di tecnologie, ognuno dei quali rappresenta una sfida significativa nello sviluppo di applicazioni oggi. (29 pagine stampate)

Contenuto

Descrizione di .NET Framework 3.0
Applicazione di .NET Framework 3.0: scenario
Informazioni su .NET Framework 3.0: Tecnologie
Recupero di .NET Framework 3.0: Opzioni di distribuzione
Conclusione
Ulteriori informazioni

Descrizione di .NET Framework 3.0

L'obiettivo nello sviluppo di applicazioni è sempre lo stesso: creare il software più possibile possibile nel minor tempo. Tuttavia, la barra viene continuamente alzata, come le piattaforme su cui gli sviluppatori creano si ottengono meglio e meglio. In Windows, ad esempio, l'interfaccia Win32 originale è stata subsumata da .NET Framework molto più funzionale. Entrambe le versioni 1.0 del Framework, rilasciate nel 2002 e versione 2.0, rilasciate nel 2005, offrono un ambiente notevolmente migliore e più produttivo per gli utenti che progettano e scrivono software Windows.

.NET Framework 3.0 (in precedenza noto come WinFX) è il passaggio successivo in questa progressione. Le applicazioni basate su questa nuova versione di Framework possono essere create con Visual Studio 2005, rendendo più familiare la maggior parte degli sviluppatori di Windows. Ma .NET Framework 3.0 è anche un'evoluzione, aggiungendo altro alla versione 2.0 del Framework già disponibile. Pianificato per essere rilasciato alla fine del 2006, .NET Framework 3.0 sarà disponibile per Windows Vista, Windows Server 2003 e Windows XP.

Questo documento offre una visualizzazione di grandi dimensioni di .NET Framework 3.0 e dei relativi componenti. L'obiettivo è quello di chiarire qual è la nuova versione, esaminare il modo in cui le tecnologie possono essere usate e fornire brevi spiegazioni di tali tecnologie.

Creazione di applicazioni moderne: sfide

La creazione di un'applicazione tipica oggi non è una semplice attività: i requisiti sono sostanziali. I problemi tradizionali come l'uso dei dati archiviati e l'accesso tramite un Web browser sono ancora importanti, ma non sono più sufficienti. Le applicazioni moderne presentano anche una serie di nuove sfide, tra cui le seguenti:

  • Le organizzazioni stanno sempre più prendendo una visione orientata al processo di ciò che fanno. Poiché la maggior parte delle applicazioni automatizza una parte di un processo aziendale, può essere utile rendere espliciti i passaggi in questo processo nel codice. Un modo efficace per eseguire questa operazione consiste nell'usare la tecnologia del flusso di lavoro, un approccio che richiede il supporto per le applicazioni basate sul flusso di lavoro.
  • Le applicazioni comunicano comunemente con altre applicazioni, sia all'interno che all'esterno dell'organizzazione. Le applicazioni moderne devono spesso adattarsi a un'architettura orientata al servizio (SOA), esponendo alcune delle relative funzionalità come servizi interoperabili accessibili da altri software. Il raggiungimento di questi obiettivi richiede il supporto per le applicazioni orientate al servizio.
  • Le persone che usano un'applicazione hanno comunemente bisogno di un modo per trasmettere informazioni su chi sono. Molte tecnologie diverse per la definizione e l'uso di un'identità digitale sono in uso e i problemi come il phishing sono comuni. Dato questo, un'applicazione moderna e le persone che lo usano possono trarre vantaggio dal controllo utente coerente delle identità digitali.
  • I requisiti per un'interfaccia utente moderna sono cresciuti significativamente. Fornire un valore aziendale reale può richiedere comunemente l'uso di vari tipi di documenti, usando grafica bidirezionale e tridimensionale, visualizzazione di video e altro ancora. Tutto ciò deve essere disponibile anche per i client Windows nativi e i browser Web. Per soddisfare queste esigenze è necessario un approccio unificato alle diverse interfacce utente.

Dato che le applicazioni di oggi devono comunemente affrontare alcune o tutte queste sfide, la piattaforma che tali applicazioni si basano devono affrontare anche in modo coerente e utilizzabile. L'obiettivo di .NET Framework 3.0 consiste nell'eseguire esattamente questa operazione per le applicazioni Windows.

Risoluzione delle sfide: informazioni fornite da .NET Framework 3.0

Come illustrato nella figura 1, la versione 3.0 di .NET Framework si basa sulla versione precedente. Infatti, non viene modificato nulla nella versione 2.0 di .NET Framework, quindi le applicazioni esistenti create per questa base continueranno a funzionare come sempre. .NET Framework 3.0 aggiunge tuttavia quattro nuovi componenti: Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace e Windows Presentation Foundation. Questa sezione illustra brevemente cosa fornisce .NET Framework 2.0 e ognuno di questi nuovi componenti.

Figura 1

.NET Framework 2.0: General-Purpose Foundation per le applicazioni Windows

Anche se è ancora possibile scrivere software che usa direttamente l'interfaccia Win32, .NET Framework è diventato l'ambiente mainstream per le nuove applicazioni Windows. Tra le sue parti più importanti sono le seguenti:

  • ASP.NET, che supporta la creazione di applicazioni accessibili dal Web.
  • ADO.NET, consentendo alle applicazioni di accedere a dati relazionali e altri tipi di dati.
  • Windows Forms, supportando la creazione di interfacce utente grafiche (GUI) per le applicazioni Windows.
  • System.XML, che consente alle applicazioni di usare dati definiti da XML, incluso l'uso di XSLT e XPath.

La versione 2.0 di Framework ha aggiunto diversi elementi utili al suo predecessore, tra cui una tecnologia notevolmente migliorata per la creazione di applicazioni Web ASP.NET, il supporto per le applicazioni a 64 bit in esecuzione su versioni di Windows a 64 bit e un nuovo approccio alla gestione delle transazioni. Sebbene alcune parti di .NET Framework 2.0 siano ampiamente sostituite dai nuovi componenti aggiunti nella versione 3.0, come descritto in seguito, le tecnologie nella versione 2.0 rimangono una parte fondamentale di questa nuova versione.

Windows Workflow Foundation: supporto per le applicazioni Workflow-Based

Un flusso di lavoro è un'idea semplice: è solo una serie di passaggi eseguiti in un ordine. Si potrebbe anche sostenere che ogni applicazione implementa un flusso di lavoro, poiché ogni applicazione esegue un processo. Tuttavia, l'approccio tradizionale alla creazione di un'applicazione usando C# o Visual Basic o un altro linguaggio di programmazione consiste nel rendere i passaggi in questo processo impliciti nel codice. Questo funziona certamente, ma incorpora anche il processo stesso profondamente nella logica di un programma, rendendo questo processo più difficile da implementare e modificare.

L'uso della tecnologia del flusso di lavoro per implementare la logica del processo può essere un modo efficace per risolvere questo problema. Anziché interviare la logica nel codice ordinario, ogni passaggio del processo viene definito in modo esplicito, quindi eseguito da un motore di flusso di lavoro. Il risultato è un'implementazione pulita del processo stesso.

I motori del flusso di lavoro non sono una nuova idea; molti sono oggi disponibili per Windows e per altri sistemi. Microsoft fornisce anche motori di flusso di lavoro incorporati in alcuni dei suoi prodotti. Tuttavia, poiché il flusso di lavoro sta diventando un approccio mainstream alla creazione di applicazioni, fornisce una singola tecnologia del flusso di lavoro per Windows ha senso. Questo è esattamente ciò che viene fatto da Windows Workflow Foundation (l'acronimo ufficiale per cui è WF). Fornendo una tecnologia di flusso di lavoro comune per Windows, WF offre a qualsiasi applicazione basata sul flusso di lavoro la stessa base da compilare. Il software fornito da Microsoft userà WF, incluso il sistema Microsoft Office 2007 e Windows SharePoint Services, come le applicazioni create da altri utenti.

La fornitura di una tecnologia comune del flusso di lavoro presenta tuttavia alcune sfide. Ad esempio, in che modo un unico approccio può soddisfare il set di requisiti diversi presentati da diverse applicazioni del flusso di lavoro? La risposta adottata da WF consiste nel prendere una visione molto generale del flusso di lavoro. Come illustrato nella figura 2, un flusso di lavoro WF è solo un gruppo di attività eseguite dal motore WF. Ogni attività è effettivamente una classe e può contenere qualsiasi lavoro che l'autore del flusso di lavoro ritiene necessario. Le attività possono potenzialmente essere riutilizzate in flussi di lavoro diversi, semplificando la creazione di soluzioni automatizzate ai nuovi problemi.

Figura 2

Un'altra sfida nel fornire una tecnologia di flusso di lavoro comune deriva dalla divisione tradizionale tra flussi di lavoro orientati all'uomo e orientati al sistema. Le applicazioni del flusso di lavoro usate principalmente dalle persone devono essere flessibili, consentendo le operazioni come le modifiche in modalità on-the-fly al processo. Quelli usati principalmente dai sistemi, ovvero dal software, tendono ad essere più statici, ma devono essere più efficienti possibile. WF è destinato a entrambi i tipi di utilizzo e quindi include funzionalità orientate all'uomo, ad esempio la possibilità di apportare modifiche a un flusso di lavoro in esecuzione, insieme al supporto per comportamenti più orientati al sistema.

Fornendo una tecnologia di flusso di lavoro comune per Windows in WF, .NET Framework 3.0 rende questo paradigma utile per la creazione di software a livello generale per gli sviluppatori. Poiché una visione orientata al processo del software continua ad aumentare la popolarità, l'uso del flusso di lavoro aumenterà probabilmente anche.

Windows Communication Foundation: supporto per le applicazioni Service-Oriented

Sia che usino il flusso di lavoro o con un altro approccio, la maggior parte delle applicazioni deve comunicare con altre applicazioni. Come questa comunicazione ha fatto un grande passo avanti negli ultimi anni. Dopo decenni di disaccordo, tutti i principali fornitori hanno accettato di supportare gli stessi protocolli per la comunicazione dell'applicazione. In base a SOAP, questo accordo globale sui servizi Web rende l'interoperabilità tra applicazioni basate su piattaforme tecnologiche diverse, ad esempio J2EE e .NET Framework, notevolmente più semplice rispetto al passato. Rende anche l'idea di architettura orientata al servizio molto più plausibile per la maggior parte delle organizzazioni.

Molti approcci alla comunicazione esistono già, naturalmente. In .NET Framework 2.0, ad esempio, le scelte includono quanto segue:

  • ASP.NET Servizi Web, fornendo comunicazioni basate su SOAP interoperabili.
  • .NET Remoting, incentrato sulla comunicazione tra applicazioni .NET.
  • Servizi aziendali, che offrono supporto per applicazioni scalabili e transazionali.
  • System.Messaging, che supporta la messaggistica in coda tramite Accodamento messaggi Microsoft (MSMQ).
  • Miglioramenti dei servizi Web (WSE), un'estensione per ASP.NET Servizi Web che fornisce supporto per specifiche più recenti, ad esempio WS-Security.

Tutte queste tecnologie hanno valore e tutti hanno avuto un ruolo da svolgere. Ma perché esistono diverse soluzioni per risolvere ciò che è essenzialmente lo stesso problema? Perché non creare invece una singola base per la comunicazione dell'applicazione in base ai servizi interoperabili?

Questo è esattamente ciò che viene fatto da Windows Communication Foundation (WCF). Anziché richiedere agli sviluppatori di usare una tecnologia diversa con un'interfaccia di programmazione dell'applicazione diversa per ogni tipo di comunicazione, WCF (originariamente denominato "Indigo") offre un approccio comune usando un'API comune. Nell'ambiente .NET Framework 3.0 la maggior parte delle applicazioni che potrebbero aver usato una delle tecnologie elencate userà invece WCF per la comunicazione.

WCF offre un supporto sicuro per la comunicazione interoperabile tramite SOAP, una parte essenziale dell'elaborazione moderna. Include il supporto per diverse specifiche WS-*, tra cui WS-Security, WS-ReliableMessaging e WS-AtomicTransaction. WCF non richiede tuttavia SOAP e quindi è possibile usare altri approcci, tra cui un protocollo binario ottimizzato, la messaggistica in coda tramite MSMQ e una semplice comunicazione basata su REST. WCF accetta anche un approccio orientato al servizio in modo esplicito alla comunicazione. Anziché tentare di fornire comunicazioni trasparenti tra oggetti, WCF interpose l'astrazione leggermente diversa di un servizio tra le parti di comunicazione. Un risultato di questo è liberare alcuni degli accoppiamenti stretti che possono esistere nei sistemi a oggetti distribuiti, rendendo l'interazione meno soggetta a errori e più facile da modificare.

La comunicazione tra applicazioni, sia all'interno di un'organizzazione che all'interno di organizzazioni, è una parte fondamentale del software moderno. .NET Framework 3.0 risolve questa sfida usando l'approccio orientato al servizio di WCF.

Windows CardSpace: controllo utente coerente delle identità digitali

Pensa a come la gente si rappresenta oggi su Internet. Nella maggior parte dei casi, l'identità digitale di una persona è espressa come nome utente semplice. Combinata con una password, questa identità viene usata per accedere agli account di posta elettronica, ai commercianti Internet e anche alle banche online e ad altre istituzioni finanziarie. Tuttavia, nonostante la loro semplicità (e ubiquity), i nomi utente e le password hanno diversi svantaggi. Ecco i due più importanti:

  • Persone hanno un tempo difficile ricordare tutti i nomi utente e le password che hanno scelto per siti diversi. Molte persone usano gli stessi valori per siti diversi, semplificando il problema di memoria, ma aumentando il rischio di sicurezza.
  • I nomi utente, le password e altre informazioni personali possono essere rubate dai phishers. Inviando messaggi di posta elettronica ingannevoli, i phishers inviano alla vittima l'accesso a un sito Web simile, ad esempio, al sito della banca della vittima. Il sito è effettivamente controllato dal phisher, tuttavia, e quindi una volta che la vittima immette il nome utente e la password, il phisher può usare queste informazioni per mascherare come l'utente nel sito reale.

La riduzione della gravità di questi problemi richiede un nuovo approccio alla gestione delle identità digitali. Windows CardSpace, originariamente denominato "InfoCard", è una parte importante di tale approccio. Per aiutare le persone a tenere traccia delle proprie identità digitali, CardSpace rappresenta ogni identità come scheda informazioni distinta. Se un sito Web accetta gli account di accesso cardSpace, gli utenti che tentano di accedere a tale sito visualizzeranno una schermata di selezione CardSpace come quella illustrata nella figura 3. Scegliendo una scheda, gli utenti scelgono anche un'identità digitale che verrà usata per accedere a questo sito. Invece di ricordare una pletora di nomi utente e password, gli utenti devono riconoscere solo la scheda che desiderano usare. Le schede diverse possono anche contenere informazioni diverse, consentendo agli utenti di controllare esattamente ciò che ogni sito apprende.

Figura 3

Le identità rappresentate da queste schede vengono create da uno o più provider di identità. Qualsiasi organizzazione può offrire un provider di identità e invece di basarsi su nomi utente e password semplici, le identità fornite in genere useranno meccanismi di crittografia più forti per consentire agli utenti di dimostrare la propria identità. CardSpace include anche un provider di identità auto-rilasciato che viene eseguito nei computer client. Con questo provider, gli utenti possono creare le proprie identità che non si basano sulle password per l'autenticazione. I siti Web possono accettare queste identità CardSpace auto-rilasciate anziché basarsi sull'approccio consueto basato su password, riducendo i problemi che le password portano.

Se le password non vengono usate per accedere a un sito, i phishers non possono rubare queste password. Tuttavia, se i phisher possono ingannare un utente nell'accedere a un sito fittizio, potrebbero essere in grado di acquisire altre informazioni dall'utente, ad esempio informazioni mediche riservate. Impedire questo richiede che gli utenti possano distinguere i siti reali dai falsi simili creati dai phishers. Per consentire questa operazione, l'organizzazione proprietaria di un sito Web può ottenere un certificato di garanzia elevata. A differenza dei certificati SSL semplici di oggi, l'acquisizione di questo nuovo tipo di certificato comporta un processo molto più rigoroso, inclusa una prova più forte che l'organizzazione che si applica effettivamente è chi dichiara di essere. Un certificato a garanzia elevata può anche contenere il logo di un'azienda e altre informazioni per aiutare l'utente a determinare correttamente se un sito che usa questo certificato è legittimo. Quando un utente accede a un nuovo sito, CardSpace visualizza sempre le informazioni nel certificato del sito usando una schermata standard. In base alla forza del certificato ricevuto, questa schermata indicherà diversi livelli di garanzia dell'identità del sito. L'obiettivo è quello di forzare gli utenti a prendere una decisione esplicita di considerare attendibile un sito, quindi aiutarli a fare le scelte corrette su quali siti considerare attendibili.

Windows CardSpace fa effettivamente parte di un metasystem di identità più grande. Basato interamente su protocolli aperti, pubblici, questo metasystem definisce un modo per usare diverse tecnologie di identità digitale in modo coerente tra piattaforme diverse (inclusi i sistemi operativi diversi da Windows) e diverse applicazioni (inclusi browser Web diversi da Internet Explorer). Fornendo un modo comune per selezionare le identità e altro ancora per Windows, CardSpace riempie un ruolo chiave nel metasystem. E risolvendo il problema fondamentale dell'identità, CardSpace svolge anche una parte importante in .NET Framework 3.0.

Windows Presentation Foundation: approccio unificato alle diverse interfacce utente

L'interfaccia utente è una parte importante di quasi ogni applicazione. Tuttavia, gli utenti che si aspettano da tali interfacce hanno avanzato significativamente. Le GU basate su menu tradizionali sono ancora necessarie, ovviamente, ma le applicazioni possono anche dover visualizzare video, eseguire animazioni, usare grafica bidirezionale e tridimensionale e lavorare con vari tipi di documenti. E tutto questo deve essere possibile se l'applicazione è accessibile da un client desktop autonomo o tramite un Web browser.

Tradizionalmente, tutti questi aspetti dell'interfaccia utente sono stati forniti in modi diversi in Windows. Ad esempio, uno sviluppatore può usare Windows Forms, parte di .NET Framework, per creare un'interfaccia utente di Windows. La creazione di un'interfaccia del Web browser richiede l'uso di applet HTML e forse di codice JavaScript o JavaScript. La visualizzazione di video può basarsi su Lettore multimediale Windows o software, ad esempio Adobe Flash Player, mentre i formati di documento potrebbero essere definiti da Microsoft Word o dal PDF di Adobe o da un altro elemento. La sfida per gli sviluppatori è chiara: la creazione di un'interfaccia utente coerente per diversi tipi di client che usano tecnologie diverse non è semplice.

Un obiettivo principale di Windows Presentation Foundation (WPF), originariamente denominato "Avalon", è quello di risolvere questa sfida. Offrendo una base tecnica coerente per tutti questi aspetti dell'interfaccia utente, WPF semplifica la vita per gli sviluppatori. Prendendo un approccio più moderno, incluso il supporto per video, animazione, grafica bidirezionale e tridimensionale, e vari tipi di documenti, WPF può consentire agli utenti di lavorare con informazioni in nuovi modi. E fornendo una base comune per i client desktop e i client browser, WPF semplifica la compilazione di applicazioni che si indirizzano a entrambi.

L'interfaccia di esempio illustrata nella figura 4, contenente immagini, grafica dinamica, viste tridimensionali e altro ancora, illustra alcune delle funzionalità fornite da WPF. Anziché richiedere agli sviluppatori competenze in tecnologie diverse, le interfacce utente come questa possono ora essere create in modo più coerente.

Figura 4

Una sfida che ha lungo affrontato i creatori di interfacce utente deriva dai diversi ruoli necessari per la creazione di interfacce efficaci. Gli sviluppatori di software sono necessari per creare la logica dietro l'interfaccia, ma raramente sono le persone migliori per definire l'aspetto e l'aspetto dell'interfaccia. I progettisti, specialisti nell'interazione umana/macchina, sono in genere una scelta molto migliore per questo ruolo. Ma le tecnologie meno recenti come Windows Forms sono incentrate interamente sullo sviluppatore. Non esiste un modo veramente efficace per sviluppatori e designer di collaborare. Per risolvere questo problema, WPF si basa sul linguaggio xaml (eXtensible Application Markup Language). Un linguaggio basato su XML, XAML consente di specificare un'interfaccia utente dichiarativamente anziché nel codice. In questo modo è molto più semplice generare e usare una specifica dell'interfaccia in base alla rappresentazione visiva creata da una finestra di progettazione. Microsoft offre infatti un nuovo prodotto, Expression Interactive Designer, per farlo esattamente. I progettisti potranno usare questo strumento (e altri forniti da terze parti) per creare l'aspetto di un'interfaccia, quindi avere una definizione XAML di tale interfaccia generata per loro. Lo sviluppatore importa questa definizione in Visual Studio, quindi crea la logica richiesta dall'interfaccia.

Quando gli sviluppatori creano un'applicazione WPF autonoma, una che viene eseguita direttamente in Windows, ha accesso a tutti gli elementi forniti da WPF. Per creare un client che viene eseguito all'interno di un Web browser, tuttavia, gli sviluppatori possono creare un'applicazione browser XAML, comunemente denominata XBAP. Basato sulla stessa base di un'applicazione WPF autonoma, un XBAP consente di presentare lo stesso stile di interfaccia utente all'interno di un'applicazione browser scaricabile. Lo stesso codice può essere usato potenzialmente per entrambi i tipi di applicazioni, che significa che gli sviluppatori non hanno più bisogno di set di competenze diversi per i client desktop e browser. Come in genere per questo tipo di applicazione Internet avanzata, un XBAP scaricato da Internet viene eseguito in una sandbox sicura, che limita le operazioni che l'applicazione può eseguire. Tuttavia, un subset di grandi dimensioni della funzionalità dell'interfaccia utente disponibile per un'applicazione WPF autonoma può essere usata anche in un XBAP.

Sia le applicazioni autonome WPF che gli XBAP possono sfruttare il supporto grafico moderno di WPF, inclusa la possibilità di usare l'accelerazione hardware, il supporto per la grafica vettoriale e altro ancora. Fornendo supporto per grafica più potente, WPF rende possibile un'ampia gamma di opzioni di visualizzazione dei dati che non sono possibili con Windows Forms o altre tecnologie precedenti. WPF fornisce inoltre la base per la specifica di carta XML (XPS), che definisce un formato standard per la visualizzazione, la distribuzione e la stampa di documenti in formato fisso.

Le interfacce utente sono una parte complessa e importante delle applicazioni moderne. Tramite WPF, .NET Framework 3.0 presenta una soluzione più completa e coerente alle sfide presenti. L'obiettivo è consentire agli utenti che creano interfacce utente, sia sviluppatori che designer, di svolgere i loro lavori in modo più efficace.

Applicazione di .NET Framework 3.0: scenario

Un modo per comprendere il funzionamento di un gruppo di tecnologie consiste nell'esaminare un esempio di come possono essere usati. Si supponga, ad esempio, un'applicazione che consenta ai clienti e agli agenti di inviare applicazioni assicurative. Se è stato implementato usando .NET Framework 3.0, questa applicazione potrebbe essere simile alla figura 5.

Figura 5

La logica di business dell'applicazione, illustrata in alto a sinistra del diagramma, viene implementata usando un flusso di lavoro WF. La gestione di un'applicazione per l'assicurazione è un processo in più passaggi, tra cui la valutazione dell'applicazione rispetto alle regole di sottoscrizione dell'organizzazione, forse verificando il credito del richiedente e forse anche ottenendo l'approvazione di un manager. Il flusso di lavoro implementa ognuno di questi passaggi come attività, basandosi su altri software in base alle esigenze. Per accedere ai dati archiviati, ad esempio, le attività in questo flusso di lavoro usano ADO.NET.

Questa compagnia assicurativa fornisce un call center, consentendo ai suoi clienti di richiedere l'assicurazione sul telefono. Il software client usato dal personale che esegue il call center, visualizzato in alto a destra del diagramma, viene implementato come applicazione WPF autonoma. Questo client comunica con la logica di business dell'applicazione usando WCF, usando un protocollo binario ottimizzato per la comunicazione WCF-WCF. Come illustrato nella figura, i lavoratori del call center si basano su Windows CardSpace per selezionare l'identità che useranno durante l'accesso a questa applicazione.

I clienti possono anche richiedere l'assicurazione sul Web e gli agenti assicurativi possono inviare anche le richieste. Per consentire questa operazione, l'applicazione usa ASP.NET per comunicare con i Web browser. Come illustrato nell'angolo inferiore sinistro del diagramma, i clienti che usano Internet Explorer per accedere a questa applicazione tramite un'interfaccia HTML comune possono comunque usare CardSpace per selezionare l'identità che desiderano presentare. Terze parti possono anche implementare un meccanismo di selezione delle identità per altri sistemi operativi client e browser, consentendo al metasystem di identità di estendere ai client non Windows e ai browser Web.

Gli agenti assicurativi che accedono a questa applicazione su Internet potrebbero avere bisogno di un'interfaccia più funzionale. Di conseguenza, possono basarsi su un XBAP anziché su un'interfaccia HTML semplice. Come illustrato nel centro inferiore del diagramma, questo offre ai clienti una grande parte della funzionalità dell'interfaccia utente fornita dall'applicazione desktop WPF usata nel call center. Entrambi sono basati sulla stessa base e quindi gli sviluppatori dell'applicazione possono riutilizzare lo stesso codice nei due tipi di client. Come per gli altri tipi di client, gli agenti possono usare CardSpace per selezionare l'identità che desiderano presentare all'applicazione.

Infine, è probabile che questa applicazione debba accedere e accedervi da altre applicazioni. Se l'approvazione di un cliente richiede un controllo di credito, ad esempio, verrà eseguita una chiamata a un servizio esterno. O forse l'applicazione accetta richieste direttamente da altri software, esponendo i servizi che queste applicazioni esterne possono richiamare. Per i casi come questi, visualizzati nella parte inferiore destra della figura, l'applicazione si basa su WCF per comunicare con i servizi Web standard. Indipendentemente dalla tecnologia basata su queste applicazioni, il supporto di WCF per SOAP rende semplice l'interazione con loro.

Questo scenario illustra come alcuni dei componenti più importanti di .NET Framework 3.0 potrebbero essere usati in un'applicazione tipica. Alcune opzioni sono state omesse e quindi non visualizzano questo semplice esempio come un'illustrazione completa di ciò che offre questa famiglia di tecnologie. L'obiettivo è invece quello di dare un'idea chiara del modo in cui le varie parti di .NET Framework 3.0 possono essere usate in concerto per risolvere i problemi aziendali reali.

Informazioni su .NET Framework 3.0: Tecnologie

Per ottenere davvero un'idea di ciò che offre .NET Framework 3.0, è utile scavare un po ' più profondo in ognuna delle sue tecnologie costitutive. Questa sezione fornisce un'esercitazione breve su ognuna delle cinque parti di .NET Framework 3.0. Per un'introduzione più dettagliata a ognuno di essi, vedere Per ulteriori informazioni alla fine di questo documento.

.NET Framework 2.0

Figura 6

.NET Framework 2.0 è una parte fondamentale dello sviluppo di Windows oggi ed è anche la base di .NET Framework 3.0. La figura 6 illustra le due parti di Common Language Runtime (CLR) e la libreria di classi .NET Framework. Alcuni componenti di .NET Framework 3.0, inclusi WF, WCF e WPF, vengono implementati in gran parte come estensioni alla libreria di classi .NET Framework. Come descritto in precedenza, tuttavia, mentre molte parti della libreria di classi rimangono una parte importante del mondo di uno sviluppatore, altre sono sottosume dalle nuove tecnologie fornite da .NET Framework 3.0. ASP.NET, ad esempio, è ancora la base per la creazione di applicazioni accessibili dal browser e ADO.NET viene ancora usato per lavorare con i dati archiviati. Gli sviluppatori di .NET Framework 3.0 possono usare WPF anziché Windows Forms per creare un'interfaccia utente gui di Windows nativa, ma in genere preferiscono WCF su ASP.NET Servizi Web, .NET Remoting o Enterprise Services. Nonostante queste modifiche, è importante comprendere che anche in un mondo di NET Framework 3.0, la versione precedente di Framework rimane una parte centrale della vita di uno sviluppatore.

Windows Workflow Foundation

Una progettazione orientata al processo, guidata da un flusso di lavoro, può essere l'approccio giusto per una frazione significativa del software Windows. Lo scopo di WF è consentire agli sviluppatori di creare ed eseguire queste applicazioni basate sul flusso di lavoro. La figura 7 mostra i componenti forniti da WF per eseguire questa operazione.

Figura 7

Come descritto in precedenza, ogni flusso di lavoro viene compilato da un certo numero di attività. Entrambi i flussi di lavoro e le attività sono solo classi, quindi entrambi possono essere creati direttamente nel codice. WF fornisce anche l'Designer flusso di lavoro, uno strumento grafico ospitato da Visual Studio per la creazione di flussi di lavoro. Tuttavia, viene creato un flusso di lavoro, le relative attività possono essere disegnate dalla libreria attività di base (BAL) fornita con WF o da qualsiasi altra origine.

Dopo aver definito un flusso di lavoro, alla fine viene eseguito dal motore di runtime di WF. Questo motore si basa su un gruppo di servizi di runtime per rendere persistente lo stato del flusso di lavoro, tenere traccia dell'esecuzione del flusso di lavoro e altro ancora. Tutti questi elementi, ovvero i servizi di runtime, il motore di runtime e il flusso di lavoro stesso, sono contenuti all'interno di un processo host. Questo processo può essere qualsiasi processo di Windows, compreso tra una semplice console o un'applicazione WPF in esecuzione in un desktop a un processo server scalabile.

La comprensione di WF richiede almeno un po' di informazioni su tutti i suoi componenti. Le sezioni seguenti esaminano brevemente ognuna di esse.

Flussi di lavoro

Rimosso ai suoi elementi essenziali, un flusso di lavoro non è più di un gruppo di attività. WF offre il supporto predefinito per due stili di flusso di lavoro:

  • Flussi di lavoro sequenziali, che eseguono attività in un ordine definito. Come un grafico di flusso tradizionale, un flusso di lavoro sequenziale può contenere rami, cicli e altre strutture di controllo. Per impostazione predefinita, tuttavia, le attività eseguite in sequenza, una dopo l'altra.
  • Flussi di lavoro del computer di stato, che implementano una macchina a stato finito tradizionale. Come qualsiasi computer di stato, l'attività eseguita in un determinato momento è determinata dalla combinazione dello stato corrente e di qualsiasi evento ricevuto.

L'opzione sequenziale è utile per i flussi di lavoro ben definiti, ad esempio quelli usati nei processi basati su software puramente. Sono relativamente semplici da creare e comprendere, e inizialmente si sentono più naturali per la maggior parte degli sviluppatori. I flussi di lavoro del computer di stato sono una scelta migliore quando il percorso di esecuzione è meno prevedibile. Un buon esempio di questo è un flusso di lavoro che implica interazioni con persone, chiunque possa annullare il flusso di lavoro in qualsiasi momento. È possibile risolvere questa situazione con un flusso di lavoro sequenziale, ma ogni passaggio potrebbe essere un ramo: eseguire questa operazione se il flusso di lavoro non viene annullato, eseguire un'altra operazione se annullata. La modellazione di questo tipo di comportamento usando un computer di stato è significativamente più semplice, poiché una richiesta di annullamento del flusso di lavoro è solo un altro evento che può essere ricevuto e gestito in qualsiasi momento.

Il supporto per i flussi di lavoro del computer di stato è un esempio del modo in cui WF tenta di fornire supporto per l'uomo e il flusso di lavoro del sistema. Un altro esempio di questo è il supporto di WF per la modifica di un flusso di lavoro in esecuzione. Persone può essere capriccioso e non è raro che qualcuno coinvolto in un flusso di lavoro voglia aggiungere un passaggio, eliminare un passaggio o apportare alcune altre modifiche nel processo mentre è in corso. Per soddisfare questo problema in modo controllato, WF consente allo sviluppatore che crea un flusso di lavoro di specificare se e come è possibile modificare il flusso di lavoro durante l'esecuzione.

Libreria attività di base

Gli sviluppatori sono liberi di creare attività personalizzate. Infatti, l'obiettivo di Microsoft è quello di promuovere la crescita di un ecosistema WF pieno di attività riutilizzabili. Tuttavia, a partire da un set comune di attività fondamentali rende la vita più semplice per tutti. La fornitura di questo set comune è il ruolo della Libreria attività di base (BAL).

Non è necessario usare alcun flusso di lavoro da BAL. Ancora, molti sviluppatori troveranno che la BAL rende più semplice la loro vita, soprattutto in primo luogo. Tra le attività contenute nel BAL sono le seguenti:

  • IfElse: esegue le attività contenute in due o più percorsi possibili in base alla presenza di una condizione.
  • Mentre: esegue ripetutamente una o più attività purché una condizione sia true.
  • Sequenza: esegue un gruppo di attività una alla volta in un ordine definito.
  • Parallel: esegue due o più gruppi di attività in parallelo.
  • Codice: esegue un blocco definito di codice.
  • Listen: attende un evento specifico, quindi esegue una o più attività quando tale evento viene ricevuto.
  • InvokeWebService: chiama un servizio Web.
  • Stato: rappresenta uno stato nel computer dello stato di un flusso di lavoro.
  • EventDriven: definisce una transizione contenente una o più attività che devono essere eseguite quando viene ricevuto un evento specifico durante uno stato specifico.
  • Criterio: consente di definire ed eseguire regole di business usando un motore regole fornito da WF.

Anziché definire un linguaggio specifico per specificare i flussi di lavoro, WF accetta invece l'approccio più generale dell'uso delle attività. Il BAL fornisce anche una "lingua", ma tutti gli utenti che usano WF sono liberi di definire anche i propri.

Strumenti per Windows Workflow Foundation: Flusso di lavoro Designer

Uno dei vantaggi della creazione di applicazioni tramite flussi di lavoro è la possibilità di definire il flusso di lavoro in modo grafico. Il flusso di lavoro di WF Designer consente di farlo, come illustrato nella figura 8. Per impostazione predefinita, le attività nella casella degli strumenti vengono visualizzate nella casella degli strumenti, consentendo agli sviluppatori di trascinarle e rilasciarle nell'area di progettazione dello strumento per creare un flusso di lavoro.

Figura 8

Alcuni sviluppatori preferiscono scrivere codice, non amano i progettisti grafici. WF consente anche questo approccio (e a volte lo richiede: le attività vengono in genere compilate direttamente nel codice). È anche possibile combinare i due approcci, creando un flusso di lavoro usando il flusso di lavoro Designer e la codifica diretta. L'obiettivo è consentire agli sviluppatori di usare l'approccio più produttivo per loro. E per consentire il supporto più ampio degli strumenti, i flussi di lavoro possono essere espressi anche in XAML, lo stesso linguaggio usato da WPF. I flussi di lavoro creati usando il flusso di lavoro Designer impostazione predefinita per una definizione XAML.

Motore di runtime e Servizi di runtime

Come descritto in precedenza, il motore di runtime di WF ha il processo di esecuzione delle attività in un flusso di lavoro. Come parte di questa operazione, si basa su un gruppo di servizi di runtime. WF include implementazioni standard di questi servizi, ma gli sviluppatori ambiziosi possono sostituirli, se necessario. Questi servizi supportano alcune cose diverse, ma due si distinguono come più interessanti:

  • Persistenza: Un flusso di lavoro bloccato in attesa di un evento può usare questo servizio per rendere persistente automaticamente lo stato in memoria su disco. Quando si verifica l'evento, il servizio ricarica automaticamente lo stato del flusso di lavoro e riavvia l'esecuzione. Ciò è particolarmente utile per i flussi di lavoro che coinvolgono persone, dal momento che ore, giorni o più potrebbero trascorrere durante l'attesa di una risposta.
  • Monitoraggio: Le attività in un flusso di lavoro demarcano in modo pulito l'esecuzione del processo implementato. Il servizio di rilevamento di WF consente a uno sviluppatore di fare in modo che le informazioni sull'esecuzione del flusso di lavoro vengano scritte automaticamente in un database. Ad esempio, uno sviluppatore potrebbe voler tenere traccia dell'avvio e della fine di un flusso di lavoro, quando ognuna delle attività inizia e termina e altre informazioni.

Windows Workflow Foundation e altre tecnologie Microsoft

L'introduzione di nuovi approcci influenza inevitabilmente ciò che esiste già. Le nuove tecnologie in .NET Framework 3.0 non sono eccezioni e ognuna ha un impatto sulle altre tecnologie Microsoft. Con WF, l'impatto iniziale è sentito più fortemente da Windows SharePoint Services, dal sistema di Microsoft Office 2007 e BizTalk Server.

Per consentire agli sviluppatori di creare più facilmente applicazioni flusso di lavoro per la collaborazione di documenti e altri tipi di condivisione delle informazioni, Windows SharePoint Services, versione 3 ospita il runtime di WF. Office SharePoint Server 2007, parte del sistema Office 2007, si basa sul supporto di WF in Windows SharePoint Services. Tra le altre cose, l'aggiunta di questo server consente di visualizzare i moduli di InfoPath direttamente nelle applicazioni client di Office 2007 e di usare un set di flussi di lavoro predefiniti per scenari comuni, ad esempio l'approvazione di un documento.

Chiunque abbia familiarità con BizTalk Server ha certamente notato da ora la somiglianza tra le funzionalità di orchestrazione di questo prodotto e ciò che WF fornisce. Infatti, la versione seguente BizTalk Server 2006 sostituirà la funzione di orchestrazione esistente del prodotto con WF, fornendo strumenti per la migrazione delle orchestrazioni esistenti ai flussi di lavoro di WF. È importante comprendere, tuttavia, che WF e BizTalk Server 2006 affrontano problemi ben distinti:

  • WF offre un framework generale per la creazione di applicazioni Windows basate sul flusso di lavoro. Può essere ospitato in qualsiasi processo, usare qualsiasi tipo di attività e risolvere qualsiasi tipo di problema aziendale, inclusi i flussi di lavoro umani e di sistema.
  • BizTalk Server è un prodotto concesso in licenza incentrato sull'integrazione delle applicazioni aziendali, sull'integrazione business-to-business e sulla gestione dei processi aziendali. Offre un ampio set di adattatori per la connessione a sistemi e software diversi, acceleratori per l'implementazione di standard come RosettaNet e SWIFT e il supporto per il monitoraggio delle attività aziendali. BizTalk Server offre anche un'infrastruttura e strumenti di gestione, oltre al supporto per una maggiore scalabilità.

Poiché si tratta della tecnologia del flusso di lavoro standard per Windows, WF potrebbe essere visualizzato in altri prodotti e tecnologie Microsoft in futuro. Qualunque cosa Microsoft scelga di fare, WF troverà sicuramente una casa in una serie di applicazioni create dai suoi clienti.

Windows Communication Foundation

La modifica alla comunicazione orientata ai servizi segna un cambiamento nel modo in cui le applicazioni interagiscono. Progettato in modo esplicito per supportare applicazioni orientate ai servizi, WCF riflette questo cambiamento. Questa sezione descrive gli aspetti più importanti di WCF, inclusi servizi e client, opzioni di comunicazione e supporto per la sicurezza, la comunicazione affidabile e le transazioni.

Servizi e client

Figura 9

Come illustrato nella figura 9, l'idea fondamentale di WCF è semplice: un servizio espone un'interfaccia accessibile da un client. Tale interfaccia può essere definita usando il linguaggio WSDL (Web Services Description Language), quindi trasformato in codice oppure può essere definito direttamente in un linguaggio come C# o Visual Basic. Per un'interfaccia semplice che espone un servizio di applicazione assicurativa, quest'ultimo approccio potrebbe avere un aspetto simile al 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# è contrassegnata con l'attributo ServiceContract . Questo attributo indica che WCF può esporre metodi in questa interfaccia come operazioni chiamabili in remoto. Quale dei metodi dell'interfaccia vengono esposti dipende da cui sono contrassegnati con l'attributo OperationContract . In questo semplice esempio, ogni metodo viene contrassegnato con questo attributo e quindi tutti verranno esposti ai chiamanti remoti. Non è tuttavia necessario, ma è legale applicare OperationContract solo alcuni dei metodi di un'interfaccia. Indipendentemente dalla scelta effettuata, alcune classi nell'applicazione devono implementare questa interfaccia, fornendo codice effettivo per i metodi definiti dall'interfaccia. Al termine, WCF rende automaticamente i metodi contrassegnati con OperationContract accessibili ai client di questo servizio.

La figura 10 offre una visualizzazione leggermente più dettagliata del modo in cui un servizio viene effettivamente esposto ai client. Anziché accedere direttamente a un'interfaccia, un client si connette a un endpoint specifico. Un servizio può esporre più endpoint, consentendo potenzialmente a client diversi di accedervi in modi diversi.

Figura 10

Come illustrato nella figura, ogni endpoint specifica tre elementi:

  • Contratto che descrive le operazioni che è possibile richiamare tramite questo endpoint. Il contratto può essere identificato usando solo il nome dell'interfaccia che definisce queste operazioni, che qui è IInsuranceApplication.
  • Associazione che definisce il modo in cui è possibile richiamare le operazioni dell'endpoint. Ogni associazione definisce diversi aspetti, tra cui il protocollo da usare per richiamare le operazioni, il tipo di sicurezza da usare e altro ancora. WCF include un set di associazioni predefinite, ad esempio BasicHttpBinding illustrato di seguito, per i casi più comuni ed è anche possibile definire associazioni personalizzate. Poiché un singolo servizio può esporre più endpoint, può consentire simultaneamente l'accesso a diversi tipi di client su protocolli diversi e con diverse opzioni di sicurezza.
  • Indirizzo che indica dove è possibile trovare questo endpoint. Come illustrato nella figura, l'indirizzo è rappresentato come URL.

Le nozioni di base di WCF sono semplici. Come per la maggior parte delle tecnologie di comunicazione, i dettagli possono diventare complessi, ma la creazione di applicazioni WCF normali non è difficile.

Opzioni di comunicazione

Diversi tipi di applicazioni compilate da diversi tipi di sviluppatori necessitano di modi diversi per comunicare. L'approccio più semplice per la maggior parte degli sviluppatori è la chiamata rpc (Remote Procedure Call), che consente a un client di richiamare operazioni remote molto simili a quelle locali. Data l'interfaccia illustrata in precedenza, ad esempio, un client potrebbe richiamare qualsiasi operazione nel modo sincrono consueto, attendendo pazientemente fino a quando non viene restituita una risposta. Questa opzione è facile per gli sviluppatori ed è la scelta giusta in alcune circostanze.

WCF offre anche diverse altre opzioni. Essi includono quanto segue:

  • Chiamate che non hanno risposta. Contrassegnato con l'attributo OneWay, questo tipo di comunicazione può essere utile per l'invio di eventi o altre interazioni unidirezionale.
  • Comunicazione asincrona basata su messaggi, utilizzando invii diretti e riceve con messaggi XML.
  • Manipolazione esplicita dei messaggi SOAP, inclusa la possibilità di inserire elementi direttamente nell'intestazione SOAP.

WCF consente anche agli sviluppatori di controllare vari aspetti locali del comportamento di un servizio. Usando l'attributo ServiceBehavior , ad esempio, possono impostare se il servizio è a thread singolo o multithread, se viene creata una nuova istanza del servizio per ogni chiamata e altre opzioni.

Sicurezza, affidabilità e transazioni

La comunicazione di base, ovvero la possibilità di spostare i dati tra sistemi, è utile, ma raramente è sufficiente. La maggior parte delle applicazioni necessita di più. Ad esempio, la maggior parte delle applicazioni distribuite richiede una certa sicurezza. Fornire sicurezza può essere complessa, data la gamma di diversi approcci e diversità di tecnologie in uso oggi. Per consentire agli sviluppatori di creare applicazioni distribuite sicure senza forzarle a comprendere tutti i dettagli, WCF si basa principalmente sulle associazioni per la sicurezza. Ad esempio, basicHttpBinding illustrato in precedenza può essere configurato per l'uso di HTTPS anziché HTTP normale e altre associazioni offrono più opzioni di sicurezza. WsHttpBinding, ad esempio, supporta WS-Security, consentendo l'autenticazione basata su SOAP interoperabile, l'integrità dei dati e la riservatezza dei dati. Gli sviluppatori possono anche creare un'associazione personalizzata che fornisca i servizi di sicurezza esatti necessari all'applicazione.

Assicurarsi che la comunicazione sia affidabile è essenziale anche per molte applicazioni. L'approccio tradizionale ai servizi Web, l'invio di SOAP tramite HTTP, è sufficiente in alcuni casi ed è ciò che viene fatto quando viene usato BasicHttpBinding. Ci sono molte situazioni, tuttavia, in cui questa scelta ampiamente usata non è sufficiente. I messaggi che passano attraverso uno o più intermediari SOAP, ad esempio, non possono basarsi su questo semplice approccio per l'affidabilità end-to-end. Per questi casi, WCF implementa WS-ReliableMessaging. Scegliendo un'associazione che supporta questa opzione, ad esempio WsHttpBinding, uno sviluppatore può ottenere automaticamente un trasferimento affidabile dei messaggi interoperabili.

Le transazioni distribuite possono essere importanti anche in alcune applicazioni. WCF si basa su System.Transactions, parte di .NET Framework 2.0, per consentire la creazione di software transazionale. Un metodo può usare l'attributo OperationBehavior per indicare che richiede una transazione e definire il comportamento della transazione. Per consentire transazioni distribuite interoperabili tra i limiti del fornitore, WCF si basa sulla specifica WS-AtomicTransaction. Usando la tecnologia definita in questo contratto multi-fornitore, le applicazioni WCF possono partecipare a transazioni che si estendono su tecnologie diverse, tra cui J2EE e altri.

Windows Communication Foundation e altre tecnologie Microsoft

Come accennato in precedenza, WCF sostituisce diverse tecnologie Microsoft precedenti per la creazione di applicazioni distribuite. La maggior parte delle applicazioni che sarebbero state compilate usando ASP.NET Servizi Web, servizi remoti .NET, Enterprise Services, System.Messaging o WSE verrà invece compilata in WCF. Le applicazioni WCF possono interagire con le applicazioni ASP.NET Servizi Web, sia il supporto SOAP standard, sia le applicazioni basate su Servizi aziendali, MSMQ e la versione 3.0 di WSE. WCF può essere usato anche da BizTalk Server 2006 e una versione futura di BizTalk Server verrà compilata ancora più direttamente su ciò che offre WCF.

È importante comprendere che anche se le nuove applicazioni .NET Framework 3.0 non le useranno comunemente, tutte le tecnologie sostituite da WCF fanno ancora parte di questa versione di Framework e saranno tutte supportate come di consueto. Anche le applicazioni compilate con versioni precedenti di queste tecnologie continueranno a essere eseguite normalmente; l'installazione e l'uso di .NET Framework 3.0 non interromperanno il codice esistente.

Windows CardSpace

Che si tratti di un Web browser o di un altro tipo di client, gli utenti accedono regolarmente alle applicazioni in una rete. Poiché queste applicazioni richiedono in genere agli utenti di identificarsi in qualche modo, l'inescapace è che le persone sono regolarmente costrette ad acquisire e presentare informazioni sull'identità al software remoto. L'accesso alle applicazioni Internet tramite un browser offre un esempio molto comune di questo e anche gli utenti nelle intranet affrontano il problema.

Come descritto in precedenza, le persone spesso si basano su nomi utente e password per le identità digitali, con tutti i problemi che ciò comporta. Windows CardSpace, parte del metasistema di identità più ampio, offre un approccio alternativo per risolvere questi problemi. Per comprendere in modo più approfondito il modo in cui CardSpace esegue questa operazione, il punto di partenza è con i concetti di base del metasistema di identità.

Windows CardSpace e il metasistema di identità

Quando gli utenti accedono a un'applicazione, da un Web browser o da un client specifico dell'applicazione o da un altro tipo di identità digitale. Le identità digitali sono disponibili in molte varietà, ma praticamente tutte sono rappresentate nella rete da un token di sicurezza. Anche se un token di sicurezza semplice può essere solo un nome utente, un token più complesso potrebbe includere un certificato X.509 o un documento XML. Tuttavia, sono rappresentati, i token di sicurezza sono il meccanismo tipico di oggi per rappresentare le identità digitali nella rete.

Anche se è tentabile credere che tutti i giorni adotteremo un formato comune di token di sicurezza, la realtà è che verranno usati approcci diversi. Proprio come oggi portiamo più carte di identità nel nostro portafoglio, ovvero patente, carta di credito, carta di credito, carta di volantino frequente e altro ancora, abbiamo sempre identità digitali diverse rappresentate da diversi tipi di token di sicurezza. Nessun sistema di identità singolo può fornire una risposta universale e quindi saranno sempre necessari più token di sicurezza.

Tuttavia, gli utenti hanno ancora bisogno di un modo per lavorare in modo coerente con le diverse identità digitali. Anche se non è sufficiente un singolo sistema di identità, è possibile creare un sistema di sistemi di identità, un metasistema di identità, che consente di usare una miriade di identità digitali in modo coerente. Lavorando con altri utenti, Microsoft ha guidato il processo di definizione di questo metasistema. In base alle tecnologie dei servizi Web aperte, ad esempio WS-Security e WS-Trust, questo metasistema definisce il modo in cui le identità digitali possono essere acquisite e usate, indipendentemente dal tipo di token di sicurezza da cui dipendono.

Il processo di emissione, acquisizione e uso delle identità digitali può essere considerato come un requisito di tre ruoli distinti. Questi ruoli sono i seguenti:

  • Utente: A volte chiamato oggetto, l'utente è l'entità che ha un'identità digitale.
  • Provider di identità: Un provider di identità fornisce un'identità digitale per un utente. Per l'identità digitale assegnata dal datore di lavoro, ad esempio, il provider di identità è in genere un sistema come Active Directory. Per l'identità digitale usata con Amazon, il provider di identità è effettivamente l'utente, poiché si definisce il proprio nome utente e password. Le identità digitali create da diversi provider di identità possono fornire informazioni diverse e fornire diversi livelli di garanzia che gli utenti siano realmente quelli che sostengono di essere.
  • Relying party: Una relying party è un'applicazione che in qualche modo si basa su un'identità digitale. Una relying party usa spesso un'identità (ovvero le informazioni contenute nel token di sicurezza di questa identità) per autenticare un utente, quindi prendere una decisione di autorizzazione, ad esempio consentire all'utente di accedere ad alcune informazioni. Una relying party può anche usare l'identità per ottenere un numero di carta di credito, per verificare che lo stesso utente vi acceda in momenti diversi o per altri scopi. Esempi tipici di relying party includono siti Web Internet, ad esempio banche, commercianti online e siti di aste, e qualsiasi applicazione che accetta richieste tramite servizi Web.

Questi tre tipi di entità interagiscono nel metasistema di identità. La figura 11 illustra queste interazioni, insieme alla posizione in cui si inserisce CardSpace.

Figura 11

Il processo inizia quando un utente accede a una relying party tramite un'applicazione compatibile con CardSpace. Per informazioni sul tipo di token di sicurezza richiesto da questa relying party, l'applicazione deve ottenere i criteri della relying party (passaggio 1). Per un browser che accede a un sito Web, che è probabile che sia il caso più comune, il criterio del sito è espresso in HTML e inviato come parte di una pagina Web. Per le applicazioni accessibili tramite i servizi Web, tuttavia, l'applicazione usa invece il protocollo standard del settore definito da WS-MetadataExchange per chiedere alla relying party il relativo criterio. In questo caso, il criterio viene espresso usando WS-SecurityPolicy, un altro standard del settore. Tuttavia, le informazioni sui criteri vengono acquisite, indica sempre il tipo di token di sicurezza che questa relying party accetterà e quali informazioni devono contenere tali token.

Una volta che CardSpace conosce il tipo di token di sicurezza necessari per la relying party, viene visualizzata la schermata di identità illustrata in precedenza. Ogni identità digitale disponibile per questo utente è rappresentata come scheda informativa in questa schermata. Le schede rilasciate da una relying party esterna vengono definite schede gestite , mentre quelle rilasciate dal provider autoemesso di CardSpace sono note come carte autocertificate . Entrambi i tipi di schede possono essere visualizzati su questa schermata e l'utente può potenzialmente selezionare uno di entrambi i tipi. Per semplificare questa decisione, la schermata indica le identità che soddisfano i requisiti della relying party visualizzando le schede non qualificate. L'utente seleziona quindi uno di questi come identità digitale che vuole usare (passaggio 2).

Una scheda non contiene tuttavia un token di sicurezza effettivo. Contiene invece le informazioni necessarie per individuare un provider di identità specifico e richiedere un token di sicurezza per l'utente. In realtà, ogni scheda viene creata originariamente da un provider di identità. CardSpace usa il contenuto della scheda selezionata dall'utente per richiedere un token di sicurezza dal provider di identità che ha emesso tale scheda (passaggio 3). Questa richiesta viene effettuata usando WS-Trust, un altro protocollo standard del settore e gli utenti si autenticano con il provider di identità usando Kerberos, un certificato X.509 e una firma digitale o un altro meccanismo. Il token viene restituito in un formato crittografato, che contiene anche un timestamp per impedire che questo token venga rubato dalla rete e riutilizzato in futuro.

Una volta restituito il token di sicurezza richiesto, viene inviato alla relying party (passaggio 4). Il modo in cui la relying party usa le informazioni nel token può variare. Se il token contiene un certificato X.509, ad esempio ed è accompagnato da una firma digitale, la relying party userà probabilmente il token per autenticare l'utente. Non è necessario che i token vengano usati per l'autenticazione o per qualsiasi altro scopo correlato alla sicurezza. In realtà, il termine "token di sicurezza" è un errore. Un token può contenere informazioni come la prova dell'età di un utente, l'idoneità per uno sconto in un sito di shopping Internet o qualsiasi altra cosa. L'autenticazione è un uso importante per i token di sicurezza, ma non è l'unica opzione.

È importante notare che né CardSpace né il metasistema di identità nel suo complesso sono consapevoli del formato o della tecnologia usata per il token di sicurezza. Anziché tentare di creare una nuova origine singola per le identità digitali o un formato standard per i token di sicurezza, l'obiettivo del metasistema è quello di fornire un modo coerente per usare qualsiasi identità digitale basata su qualsiasi tipo di token di sicurezza. Fornendo un'implementazione di Windows di parti chiave del metasistema, CardSpace svolge un ruolo importante nel rendere questo approccio generale all'identità digitale una realtà.

Lotta al phishing

I provider di identità sono spesso distinti dall'utente, ad esempio quando un'identità viene assegnata da un datore di lavoro. Tuttavia, esistono molte situazioni in cui il provider di identità è effettivamente gli utenti stessi. Se CardSpace non viene usato, ad esempio, per accedere a molti siti Web è necessario specificare un nome utente e una password, entrambi definiti dagli utenti. Dopo aver creato questa identità, gli utenti potranno in seguito specificare il nome utente e la password, quindi controllare il saldo bancario, acquistare un libro o eseguire qualsiasi altra operazione consentita da questo sito.

Poiché dipendono dalle password, tuttavia, questi tipi di identità autocertificate sono destinazioni per gli utenti malintenzionati, come descritto in precedenza. Per ridurre questi attacchi, CardSpace offre un modo alternativo per creare un'identità autocertificata. Questo provider di identità autocertificato viene eseguito localmente nel sistema Windows dell'utente. Invece di basarsi su un nome utente e una password, i token di sicurezza creati dal provider di identità autocertificati vengono definiti usando il saml (Security Assertion Markup Language), uno standard definito da OASIS. Questi token si basano sulla tecnologia a chiave pubblica anziché sulle password per dimostrare l'identità dell'utente e, se una relying party li accetta, può svolgere lo stesso ruolo del nome utente e della password tradizionali. Il vantaggio è che non c'è più una password per i phisher da rubare. Ridurre l'uso delle password, insieme alla prova più forte dell'identità di un sito fornita dai certificati ad alta garanzia descritti in precedenza, può rendere il phishing un problema molto meno grave.

Windows CardSpace e altre tecnologie Microsoft

CardSpace è correlato a diverse altre tecnologie Microsoft, tra cui:

  • WCF: Poiché si basa su standard dei servizi Web, ad esempio WS-Security e WS-Trust, CardSpace usa WCF per la comunicazione. Infatti, l'autore di un'applicazione WCF può causare l'uso di CardSpace solo specificando un'associazione specifica.
  • Active Directory: Anche se attualmente non è possibile, Active Directory sarà in grado di fungere da provider di identità nel metasistema.
  • Windows Live ID (in precedenza noto come Passport): Come per Active Directory, Microsoft ha annunciato che anche il sistema di autenticazione Live ID verrà modificato in modo da fungere da provider di identità. Si noti che CardSpace non è una sostituzione per Live ID, poiché i due risolvere problemi molto diversi. Live ID diventerà invece parte del metasistema di identità esattamente come qualsiasi altro provider di identità.

Microsoft offre anche altre tecnologie correlate all'identità che affrontano problemi leggermente diversi rispetto a CardSpace. Active Directory Federation Services (ADFS), ad esempio, è incentrata sulla federazione delle identità tra le organizzazioni. Questa è una sfida importante e si trova di fronte a molte aziende che devono collaborare con altre organizzazioni. Questo problema è tuttavia piuttosto distinto dai problemi più ampi risolti da CardSpace e dal metasistema delle identità.

Windows Presentation Foundation

La logica basata sul flusso di lavoro, la comunicazione orientata ai servizi e l'identità sono tutte importanti nelle applicazioni moderne. Tuttavia, gli utenti spesso si preoccupano maggiormente di ciò che vedono: l'interfaccia utente. L'obiettivo di WPF è affrontare le sfide della creazione di interfacce utente per le applicazioni moderne. Come descritto di seguito, WPF offre una gamma di funzionalità per eseguire questa operazione.

Funzionalità di Windows Presentation Foundation

Uno sviluppatore è gratuito per creare interamente l'interfaccia di un'applicazione WPF in C#, Visual Basic o in un altro linguaggio basato su CLR. Come descritto in precedenza, tuttavia, WPF consente anche di specificare un'interfaccia usando il codice XAML basato su XML. Gli elementi e gli attributi in XAML vengono mappati direttamente alle classi e alle proprietà fornite da WPF. Ad esempio, ecco un pulsante semplice definito in XAML:

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

In questo esempio viene creato un pulsante rosso contenente il testo "No". È anche possibile produrre lo stesso risultato con il codice seguente:

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

Tuttavia, viene definita, praticamente ogni applicazione WPF segue lo stesso modello di base. L'applicazione eredita dall'oggetto Application standard di WPF, che fornisce metodi, eventi e proprietà di base. Un'applicazione WPF può avere un'interfaccia tradizionale basata su dialoghi o un'interfaccia di spostamento, consentendo di funzionare in modo molto simile a un'applicazione browser. Un'applicazione compilata in quest'ultimo stile viene in genere implementata come gruppo di pagine, ognuna costituita da un'interfaccia utente definita in XAML insieme a una logica definita nel codice. Per collegare queste pagine, XAML fornisce un elemento Hyperlink, molto simile a HTML. L'applicazione visualizza una pagina alla volta, consente a un utente di spostarsi tra le pagine, di mantenere un elenco di cronologia e altro ancora. Anche se un'applicazione di navigazione può essere eseguita all'interno di un Web browser come XBAP, questa operazione non è necessaria; uno sviluppatore è libero di usare questo stile di interfaccia anche nelle applicazioni WPF autonome. L'obiettivo è creare software che combina gli aspetti migliori di un'interfaccia del browser e un'interfaccia nativa di Windows.

Qualsiasi stile usato dall'interfaccia, un'applicazione WPF può basarsi su pannelli per il layout di base. Ogni pannello contiene in genere controlli e quelli forniti da WPF includono Button, TextBox, ComboBox, Menu e molti altri. Il modo in cui questi controlli vengono posizionati dipende dal tipo di pannello scelto. Una griglia, ad esempio, consente di posizionare i controlli in una griglia specificata, mentre un oggetto Canvas consente agli sviluppatori di posizionare i controlli in qualsiasi punto all'interno dei relativi limiti. Come di consueto in un'interfaccia utente grafica, gli eventi generati dall'utente vengono intercettati e gestiti dai vari controlli e da altre classi nell'applicazione. È anche possibile applicare stili e modelli a gruppi di controlli, semplificando così l'aspetto uniforme delle applicazioni.

WPF supporta molto di più di queste funzioni di interfaccia utente di base, tra cui:

  • Documenti: Un'applicazione WPF può visualizzare documenti XPS usando il tag FixedDocument di XAML. Un'applicazione può anche visualizzare i documenti di flusso usando il tag FlowDocument . Un documento di flusso può comportarsi come un documento sullo schermo tradizionale, consentendo all'utente di scorrere il contenuto. Impostando vari attributi su questo tag, tuttavia, uno sviluppatore può rendere il documento più adattivo all'ambiente circostante. Un documento può visualizzare una pagina alla volta, ad esempio liberando il lettore dalla necessità di scorrere avanti e indietro. WPF può anche determinare automaticamente il numero di colonne in cui deve essere suddiviso un documento in base alle dimensioni della finestra in cui viene visualizzata. L'obiettivo è consentire ai documenti sullo schermo di essere il più leggibili possibile.
  • Grafica: WPF include il supporto per la creazione di grafica vettoriale bidimensionale e tridimensionale. Per il lavoro 2D, WPF fornisce astrazioni standard, ad esempio forme, pennelli e penne, consentendo al contempo alla grafica 3D di definire un modello a cui è possibile assegnare informazioni sulla posizione della fotocamera e dell'illuminazione. A differenza delle tecnologie precedenti, ad esempio Windows Forms, che si basa su GDI+ per la grafica, la grafica WPF non viene partizionata usando un set separato di concetti che gli sviluppatori devono comprendere. Gli elementi XAML usati per la grafica possono invece essere combinati naturalmente con quelli usati per qualsiasi altro elemento in un'interfaccia utente. I pulsanti possono avere contenuto grafico, testo e grafica possono essere combinati e altro ancora.
  • Immagini: Usando il tag Image di XAML, un'applicazione WPF può visualizzare immagini in diversi formati, tra cui JPEG, GIF e altri. WPF si basa sul componente Windows Imaging (WIC) per fornire un framework standard per codec, software che visualizza e archivia le immagini. Come di consueto in WPF, un elemento Image può essere combinato con altri elementi, consentendo ad esempio un pulsante che visualizza un'immagine anziché una semplice etichetta di testo.
  • Media: Un'applicazione WPF può usare il tag MediaElement per visualizzare video e audio in vari formati, tra cui WMV, AVI e MPEG. Ancora una volta, questo elemento può essere combinato con altri elementi XAML, consentendo elementi come un cubo 3D che visualizza video sui lati.
  • Animazione: WPF offre il supporto predefinito per animare la maggior parte delle parti di un'interfaccia utente. Un cerchio può crescere e compattare, ad esempio, o un pulsante può modificare senza problemi le dimensioni. Le applicazioni possono anche definire storyboard contenenti sequenze temporali, consentendo l'esecuzione di sequenze coordinate di animazioni.
  • Associazione dati: Poiché molte applicazioni WPF visualizzano dati, è utile avere il supporto automatico per il mapping dei dati agli elementi dell'interfaccia utente. WPF fornisce questo tipo di data binding per informazioni contenute in oggetti e altre origini. Il data binding WPF consente anche l'ordinamento e il filtro dei dati prima che vengano visualizzati.

Applicazione di Windows Presentation Foundation

WPF offre un ampio set di funzionalità dell'interfaccia utente, consentendo agli sviluppatori e ai progettisti di creare interfacce utente molto interessanti. Tuttavia, indipendentemente dall'aspetto di un'applicazione client, alcune organizzazioni potrebbero resistere all'uso a causa di problemi di distribuzione. Se la distribuzione di una nuova versione del client richiede il tocco fisico di ogni computer desktop in cui è installata l'applicazione, il costo degli aggiornamenti può essere significativo. Un modo comune per evitare questo problema è quello di creare client basati su browser anziché client Windows nativi. Tuttavia, i client Windows nativi possono in genere avere interfacce utente migliori e più reattive rispetto ai browser. Per risolvere la sfida della distribuzione di questi client, è possibile implementare applicazioni WPF autonome usando ClickOnce. Una tecnologia che è apparsa per la prima volta in .NET Framework 2.0, ClickOnce consente agli utenti di Internet Explorer di selezionare un'applicazione sul Web, quindi di installarla automaticamente nel computer locale. Dopo l'installazione, l'applicazione può anche essere aggiornata automaticamente quando viene resa disponibile una nuova versione. L'obiettivo è combinare la semplicità e la distribuzione economica di un client Web con la potenza e la funzionalità di un'applicazione WPF autonoma.

Soprattutto quando vengono distribuite usando ClickOnce, le applicazioni WPF autonome sono una scelta ottimale in molte situazioni. Tuttavia, esistono casi in cui questo tipo di applicazione non è appropriato, anche quando gli utenti potrebbero trarre vantaggio dal tipo di interfaccia consentita da WPF. Considerare gli agenti assicurativi remoti nello scenario descritto in precedenza, ad esempio, o un commerciante Internet che vuole fornire grafica, video 3D e altre funzionalità moderne supportate da WPF. Spesso non sarà ragionevole aspettarsi che gli utenti di questa applicazione installino un'applicazione WPF nativa per accedere al sito. Una soluzione migliore consiste nell'offrire agli utenti un'interfaccia di tipo WPF all'interno del Web browser.

Le applicazioni browser XAML, XBAP, sono progettate per eseguire questa operazione. Invece di distribuire un'applicazione WPF autonoma, un utente di Internet Explorer può scaricare un XBAP direttamente nel browser. In esecuzione in Internet Explorer, questa applicazione può quindi presentare all'utente un'interfaccia utente basata su WPF. Tuttavia, il download e l'esecuzione di codice da siti Web Internet possono essere pericolosi. Per proteggere l'utente da sviluppatori malintenzionati, tutti gli XBAP scaricati da Internet vengono eseguiti in una sandbox parzialmente attendibile. In base alla sicurezza di accesso al codice fornita da .NET Framework, questa sandbox limita le operazioni che gli XBAP possono eseguire. Ad esempio, un XBAP scaricato da Internet non può creare finestre autonome o avviare nuove finestre, visualizzare una finestra di dialogo Salva avviata da XBAP o accedere al file system, ad eccezione di un'area di archiviazione isolata. Nonostante le restrizioni imposte dalla sandbox, un XBAP può comunque usare una grande frazione di funzionalità WPF, tra cui grafica 2D e 3D, animazioni, documenti su schermo, immagini, video e altro ancora.

Come descritto in precedenza, WPF consente alle applicazioni di visualizzare documenti adattivi usando l'elemento FlowDocument di XAML. I documenti il cui aspetto cambia in base alla modalità di visualizzazione non sono sempre la soluzione migliore. I documenti in formato fisso, che hanno sempre lo stesso aspetto su uno schermo e una stampante, sono talvolta una scelta migliore. I documenti XPS di WPF risondono questo problema. Definito usando un subset di documenti XAML, XPS può essere letto in qualsiasi sistema che fornisce un lettore XPS. Forniscono anche un nuovo formato di stampa per Windows, consentendo la stampa di grafica complessa con maggiore fedeltà. Per rendere più coerente l'uso di diversi tipi di documenti, sia i documenti XPS che i documenti di Office 2007 usano Le convenzioni open packaging di Microsoft, che definiscono modi comuni per archiviare il contenuto del documento, firmare digitalmente i documenti e altro ancora.

Strumenti per Windows Presentation Foundation

È possibile creare qualsiasi interfaccia utente WPF direttamente nel codice e/o xaml usando un editor di testo di base. La maggior parte delle persone preferisce lavorare con strumenti migliori, tuttavia, e quindi Microsoft fornisce estensioni a Visual Studio 2005 che consentono agli sviluppatori di creare applicazioni WPF. La prossima versione di Visual Studio, denominata "Orcas", fornirà ancora più funzionalità con Visual Designer per Windows Presentation Foundation. Usando questo strumento, gli sviluppatori potranno creare graficamente l'interfaccia utente che desiderano visualizzare, quindi consentire allo strumento di generare il codice per questa interfaccia.

Tuttavia, gli sviluppatori spesso non sono le persone migliori per definire le interfacce utente. I designer sono di solito molto meglio in questo tipo di lavoro, poiché sono specializzati nella comunicazione con le persone. Tuttavia, la maggior parte dei progettisti non scrive codice e quindi Visual Designer per Windows Presentation Foundation, ospitato all'interno di Visual Studio, non è uno strumento efficace per questo gruppo. Per consentire ai progettisti di lavorare in modo efficace nel mondo WPF, Microsoft ha creato Expression Interactive Designer. Una finestra di progettazione può usare questo strumento per definire l'aspetto di un'interfaccia, specificare animazioni e altro ancora, quindi consentire allo strumento di generare una versione XAML di ciò che viene creato. Uno sviluppatore può importare questo codice XAML in Visual Studio e aggiungere codice per elementi come la gestione degli eventi. Poiché sia Visual Studio che Expression Interactive Designer usano lo stesso sistema di compilazione, è possibile che gli sviluppatori e i progettisti lavorino su un progetto in modo iterativo, ognuno dei quali usa lo strumento con cui si è a proprio agio. L'obiettivo è aiutare le persone delle discipline divergenti di progettazione e ingegneria del software a collaborare in modo efficace.

Windows Presentation Foundation e altre tecnologie Microsoft

Analogamente ad altri componenti di .NET Framework 3.0, WPF ha un impatto sulle tecnologie Microsoft esistenti. I più importanti sono i seguenti:

  • Windows Forms: l'approccio originale di .NET Framework per la creazione di interfacce utente di applicazioni, Windows Forms viene attualmente usato in molte applicazioni. A tale scopo, WPF consente di ospitare controlli Windows Forms in applicazioni WPF e controlli WPF in applicazioni Windows Forms. Ad esempio, un'applicazione Windows Forms potrebbe ospitare un controllo WPF che fornisce la visualizzazione dei dati tridimensionali. Anche se esistono alcune limitazioni, la creazione di applicazioni che usano entrambe le tecnologie è certamente possibile. Si noti anche che le applicazioni Windows Forms esistenti continueranno a funzionare senza modifiche in un mondo .NET Framework 3.0.
  • Classi Win32 e Microsoft Foundation (MFC): Come per Windows Forms, è possibile ospitare controlli WPF nelle applicazioni esistenti compilate usando queste tecnologie esistenti e viceversa. L'interoperabilità è piuttosto complessa rispetto a Windows Forms, tuttavia, perché a differenza di Windows Forms, le applicazioni basate su Win32 e MFC non si basano su CLR. Di conseguenza, l'interoperabilità con WPF richiede anche il mapping tra il codice basato su CLR e il codice Win32 nativo.
  • Direct3d: Parte della famiglia di API DirectX, Direct3D consente alle applicazioni di creare e visualizzare grafica 3D. Con l'avvento di .NET Framework 3.0, le applicazioni Windows mainstream possono usare le funzionalità 3D in WPF anziché l'approccio più specializzato fornito da Direct3D. Tuttavia, alcune applicazioni che richiedono prestazioni più elevate, ad esempio i giochi 3D, continueranno a usare Direct3D. In effetti, in background, WPF si basa su Direct3D per tutto il rendering.
  • Windows Communication Foundation: Come illustrato nello scenario precedente, le applicazioni WPF possono usare WCF. Gli XBAP in genere non possono usare WCF, perché WCF richiede l'attendibilità completa. Ogni XBAP scaricato da Internet viene eseguito in una sandbox parzialmente attendibile, che impedisce l'accesso a WCF. Gli XBAP possono tuttavia usare ASP.NET Servizi Web, consentendo loro di effettuare chiamate SOAP che interagiscono con WCF e altre implementazioni di servizi Web.
  • "WPF/E": Un altro aspetto di WPF vale anche la pena menzionare qui, anche se non fa parte di .NET Framework 3.0. L'obiettivo è quello di supportare interfacce di tipo WPF nei sistemi che non supportano WPF stesso. Come suggerisce "E", questa tecnologia è destinata a essere disponibile ovunque, tra cui Macintosh, piccoli dispositivi e altri sistemi. Programmata per la spedizione dopo WPF stessa, WPF/E fornirà un subset di funzionalità WPF complete, tra cui grafica 2D, animazione e video.

Recupero di .NET Framework 3.0: Opzioni di distribuzione

Affinché un'applicazione usi .NET Framework 3.0, questa versione di Framework deve essere installata nei computer in cui viene eseguita l'applicazione. Per Windows Vista, questo è semplice: .NET Framework 3.0 è installato per impostazione predefinita. Ciò significa che i nuovi computer con Windows Vista installato o i computer esistenti aggiornati a Vista saranno automaticamente in grado di eseguire applicazioni .NET Framework 3.0. .NET Framework 3.0 può tuttavia essere eseguito anche in Windows XP e Windows Server 2003. Per rendere disponibili i nuovi componenti di .NET Framework 3.0 per gli utenti esistenti di questi sistemi, Microsoft renderà disponibile questo software come download gratuito.

Conclusione

.NET Framework 3.0 è l'evoluzione del modello di programmazione di Windows. Basato su e estendendo .NET Framework 2.0, il suo obiettivo è supportare la creazione di applicazioni moderne. A tale scopo, la versione 3.0 di Framework offre un set di tecnologie diversificato, ognuna che affronta una sfida significativa nello sviluppo di applicazioni oggi. Creando questa diversità su una base comune, Microsoft sta cercando di rendere l'intero più grande della somma delle parti, consentendo agli sviluppatori di creare applicazioni che usano le varie parti di .NET Framework 3.0 in modo coerente.

Qualunque aspetto di questa nuova versione un'organizzazione sceglie di adottare, la tecnologia è certa di avere un impatto significativo sul mondo del software Windows. Per chiunque funzioni in questo mondo, sviluppatore, architetto o decision maker, il momento di iniziare a comprendere come trarre vantaggio da .NET Framework 3.0 è ora.

Ulteriori informazioni

Informazioni su .NET, seconda edizione. David Chappell, Addison-Wesley, 2006

Introduzione a Windows Workflow Foundation

Introduzione a Windows Communication Foundation

Introduzione a Windows CardSpace

Introduzione Windows Presentation Foundation: (in corso)

 

Informazioni sull'autore

David Chappell è Principal of Chappell & Associates (www.davidchappell.com) a San Francisco, California. Attraverso la sua parola, scrittura e consulenza, aiuta i professionisti tecnologici in tutto il mondo a comprendere, usare e prendere decisioni migliori sul software aziendale.